reins-method 0.1.0

package/ADAPTERS.md

@@ -0,0 +1,117 @@
+# Adapters
+
+An adapter teaches REINS about a specific stack, company, or team. It's the only place
+where stack-specific or proprietary content should live — the `core/` engine never
+contains it.
+
+Adapters are **user-owned**: they live at `~/.reins/user/adapters/<name>/`, are never
+modified by `reins update`, and you decide whether to keep them local, share them
+privately within a team, or publish them.
+
+---
+
+## Creating an adapter
+
+```bash
+reins new-adapter my-company
+```
+
+This scaffolds:
+
+```
+~/.reins/user/adapters/my-company/
+├── ADAPTER.md
+├── standards/
+│   └── floor.md
+├── workflow/      (empty — add 3_implement.md only if needed)
+└── skills/        (empty — add SKILL.md dirs as needed)
+```
+
+### 1. `ADAPTER.md`
+
+```yaml
+---
+name: my-company
+stacks: [ruby, node]   # which detected stacks this adapter applies to
+author: you
+version: 0.1.0
+description: >
+  Conventions and skills for ACME Corp's Rails + Angular stack.
+---
+```
+
+`stacks` is matched against the marker-derived identifiers the orchestrator detects
+(`core/workflow/1_orchestrator.md` §2 — `ruby` for `Gemfile`, `node` for
+`package.json`, `python`, `go`, `jvm`, `rust`, `php`, ...). If more than one installed
+adapter matches a project, all of them load.
+
+### 2. `standards/floor.md`
+
+The non-negotiable baseline for this stack: naming, architecture, test conventions —
+whatever must always apply. Optionally add `standards/personal.md` for personal style
+on top of the floor (precedence 2 — must never contradict the floor).
+
+### 3. `workflow/3_implement.md` (optional)
+
+Only add this if the stack needs a different development loop than the generic
+SPEC → PLAN → IMPLEMENT → VERIFY → CONFIRM cycle in
+`core/workflow/3_implement.md`. Common variants:
+
+- **TDD/STDD** (backend with a test suite): `SPEC → TESTS → REVIEW → RED → GREEN`
+- **SDD** (UI-only frontend, no automated tests): `SPEC → IMPLEMENT → VISUAL REVIEW → CONFIRM`
+
+Keep the same "Permanent constraints" and "Start prompt" structure as the generic file
+so behavior stays predictable.
+
+### 4. `skills/`
+
+Stack-specific, on-demand skills (scaffold generators, library reference browsers,
+hotfix workflows, etc.). See [SKILLS.md](SKILLS.md).
+
+---
+
+## Example: a minimal Rails adapter
+
+```
+~/.reins/user/adapters/rails/
+├── ADAPTER.md          # stacks: [ruby]
+├── standards/
+│   └── floor.md         # "use RSpec", "service objects under app/services", ...
+└── workflow/
+    └── 3_implement.md    # STDD cycle: SPEC -> TESTS -> RED -> GREEN
+```
+
+## Example: a minimal Python/FastAPI adapter
+
+```
+~/.reins/user/adapters/fastapi/
+├── ADAPTER.md          # stacks: [python]
+├── standards/
+│   └── floor.md         # "pydantic models in schemas/", "pytest", ...
+└── skills/
+    └── new-router/SKILL.md   # scaffolds a new FastAPI router + schema + test
+```
+
+---
+
+## Multi-stack projects
+
+If a project matches more than one adapter (e.g. a `ruby` backend + `node` frontend
+repo), the orchestrator loads both. Breakdown steps in `2_new_task.md` get labeled by
+component (`(backend)`, `(frontend)`, `(integration)`), and the context file's
+`branches`/`prs` fields become maps with one entry per component.
+
+---
+
+## Sharing adapters
+
+- **Local only**: do nothing — it's already at `~/.reins/user/adapters/<name>/`.
+- **Private team sharing**: put it in a private git repo, `git clone` it into
+  `~/.reins/user/adapters/<name>/` on each machine.
+- **Public**: publish it if there's nothing proprietary (no internal library names,
+  no internal process docs, no personal data). Review it the same way you'd review
+  any other open-source contribution before publishing.
+
+REINS core never inspects adapter contents beyond `ADAPTER.md`'s `stacks:` field and the
+optional `workflow/3_implement.md` override — it's safe to keep adapters completely
+separate from this repo.

package/HISTORIC_MODE.md

@@ -0,0 +1,52 @@
+# Historic Mode
+
+Optional, off by default. Turns each closed task into a short entry in a monthly
+file, and compiles a summary on request — useful for self-assessment and
+performance check-ins.
+
+All data is **user-owned** and lives at `~/.reins/user/historic/` — never inside a
+project repo, never touched by `reins update`.
+
+---
+
+## Enable / disable
+
+```bash
+reins historic on    # creates ~/.reins/user/historic/ and this month's file
+reins historic off   # stops recording new entries; existing data is kept
+```
+
+---
+
+## What happens when it's on
+
+- `core/workflow/4_close_task.md` Step 8 records a short entry for every closed task:
+  type, context, what was done, impact, and (optionally) a 0–10 difficulty rating
+  across size/complexity/impact.
+- Entries accumulate in `~/.reins/user/historic/YYYY-MM.md`, one file per month, created
+  from `core/evaluation/templates/monthly.md`.
+- On request ("generate monthly summary" / `reins historic summary`), the agent compiles
+  the month's entries — optionally enriched with PR/commit metrics from available
+  tooling — into a summary covering deliveries, progress against priorities, impact,
+  skills demonstrated, and a one-line takeaway.
+
+---
+
+## Details
+
+See `core/evaluation/README.md` for the full procedure (Mode A: recording an entry,
+Mode B: generating a summary), the difficulty scale, and the rules (one file per
+month, record at close not at month-end, no duplicates, enrichment is additive).
+
+---
+
+## Privacy
+
+This is the one part of REINS that holds personal data by design. It is intentionally
+kept:
+- Outside any project repository
+- Outside `~/.reins/core/` (so it's never confused with the updatable engine)
+- Untouched by `reins update`
+
+If you ever want to back it up or move it, it's just markdown files at
+`~/.reins/user/historic/`.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Gustavo Dias
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/MIGRATION.md

@@ -0,0 +1,82 @@
+# Migration — from the old `personal_ai_workflow` to REINS Method
+
+This repo was redesigned from a project-coupled workflow (Rails/Angular + Hitax +
+personal evaluation data, all in one repo) into REINS Method: a public, stack-agnostic
+core (`~/.reins/core/`) plus user-owned adapters and historic data
+(`~/.reins/user/`).
+
+**Phase 1 (done in this repo):** the generic core, CLI, agent bridges, and docs
+described in the rest of this repo.
+
+**Phase 2 (TODO — separate, private session):** migrate everything stack-specific or
+personal out of this repo into your local `~/.reins/user/`.
+
+---
+
+## What needs to move, and where
+
+### 1. Hitax/Rails/Angular adapter → private adapter pack
+
+The old `adapters/backend/` and `adapters/frontend/` directories contained Rails/RSpec
+and Angular/hitax-ng conventions and skills (`hitax-*`, `reins-add-*`, etc.) tied to a
+specific employer's stack and internal libraries (`hitax_ai`, `hitax_hub`, `hitax-ng`,
+`HtxApiService`, ...).
+
+To migrate:
+
+1. `reins new-adapter hitax`
+2. Move `standards/code_standards.md`, `personal_code_standards.md`,
+   `test_conventions.md`, `test_runner.md` (backend) and
+   `code_standards.md`, `frontend_standards.md`, `i18n_workflow.md`,
+   `personal_code_standards.md` (frontend) into
+   `~/.reins/user/adapters/hitax/standards/` — split/merge into `floor.md` (precedence 1)
+   and `personal.md` (precedence 2) per `ADAPTERS.md`.
+3. Move `adapters/backend/workflow/3_stdd_instructions.md` and
+   `adapters/frontend/workflow/3_sdd_instructions.md` into
+   `~/.reins/user/adapters/hitax/workflow/3_implement.md` — pick (or merge) whichever
+   applies based on the stack the adapter targets, following the structure of
+   `core/workflow/3_implement.md`.
+4. Move all `hitax-*` skills and the `reins-*` frontend/backend skills into
+   `~/.reins/user/adapters/hitax/skills/`.
+5. Set `ADAPTER.md` `stacks: [ruby, node]` (or split into two adapters,
+   `hitax-backend` / `hitax-frontend`, if they should load independently).
+6. Keep this adapter **private** — it references an employer's internal libraries and
+   processes (`hitax apps`, `Deloitte TaxIT`, etc.).
+
+### 2. Personal evaluation data → `~/.reins/user/historic/`
+
+The old `core/evaluation/monthly/*.md` files (2025-11 through 2026-06) contain real
+performance-review content. Move them as-is to `~/.reins/user/historic/`:
+
+```bash
+mkdir -p ~/.reins/user/historic
+mv core/evaluation/monthly/*.md ~/.reins/user/historic/
+reins historic on
+```
+
+Then remove `core/evaluation/monthly/` from this repo (already done in Phase 1 — this
+repo only ships empty templates now).
+
+### 3. Active project contexts/specs → `~/.reins/user/projects/<project-slug>/`
+
+The old `projects/contexts/*.md` and `projects/specs/*.md` described in-progress
+company work. For each active context:
+
+1. Determine `<project-slug>` for the project it belongs to (per
+   `core/workflow/1_orchestrator.md` §1).
+2. `mkdir -p ~/.reins/user/projects/<project-slug>/{contexts,specs}`
+3. Move the relevant context/spec files there.
+4. Update the frontmatter to the new model (`branches`/`prs` as maps — see
+   `core/templates/context.md`) if it used the old single `branch`/`pr` fields.
+
+---
+
+## After migrating
+
+- `reins doctor` should report no issues.
+- Open a project that matches the `hitax` adapter's `stacks:` and confirm the
+  orchestrator loads it.
+- Confirm `reins historic on` picks up the current month correctly and that closing a
+  task appends to it.
+- This repo (REINS Method core) should now contain **no personal data and nothing
+  proprietary** — safe to make public.

package/README.md

@@ -0,0 +1,332 @@
+```
+█████ █████ ███ █   █  ████
+█   █ █      █  ██  █ █
+█   █ █      █  █ █ █ █
+█████ ████   █  █  ██  ███
+█ █   █      █  █   █     █
+█  █  █      █  █   █     █
+█   █ █████ ███ █   █ ████
+
+  agent-agnostic · stack-agnostic
+  globally installed · customizable
+  ──────────────────────────────────────────
+```
+
+<p align="center">
+  <a href="#quick-start"><img alt="Install" src="https://img.shields.io/badge/install-npx%20reins--method-orange?style=flat-square"></a>
+  <a href="#supported-agents"><img alt="Agents" src="https://img.shields.io/badge/agents-Claude%20%7C%20Gemini%20%7C%20Copilot%20%7C%20Codex%20%7C%20Aider-8A2BE2?style=flat-square"></a>
+  <a href="#"><img alt="Dependencies" src="https://img.shields.io/badge/dependencies-bash%20%2B%20git%20(installer%3A%20node)-4EAA25?style=flat-square&logo=gnu-bash&logoColor=white"></a>
+  <a href="LICENSE"><img alt="License" src="https://img.shields.io/badge/license-MIT-yellow?style=flat-square"></a>
+</p>
+
+# REINS Method
+
+> AI is like a horse — far stronger than any human, but without a rider it goes
+> wherever it wants. REINS is the bridle. It does not limit the horse; it gives the
+> rider control over where that power goes.
+
+A universal, agent-agnostic AI pair-programming workflow. Install it once, globally,
+and use it in every project — without ever adding files to a project repository.
+
+---
+
+## Why
+
+Most AI coding workflows end up either:
+- copy-pasted into every repo (drifts out of sync, leaks into commits), or
+- tightly coupled to one company's stack and conventions (can't be shared or open-sourced)
+
+REINS Method solves both: a small, **stack-agnostic core** that defines how you and your
+AI agent move through a task (new task → implement → close task, with an optional
+historic/performance-tracking mode), plus **user-owned adapter packs** that teach it
+your company's or project's specific conventions and skills.
+
+---
+
+## Quick start
+
+```bash
+npx reins-method@latest install
+```
+
+This clones REINS Method to `~/.reins/` and runs the setup wizard — arrow-key
+menus for:
+- pick your AI agent (Claude Code, GitHub Copilot CLI, Codex CLI, Gemini CLI, Aider, OpenCode, Cursor, other)
+- optionally fill in your company/personal coding standards
+- optionally enable Historic Mode (performance tracking)
+- optionally install an adapter pack
+
+Then restart your terminal/agent and run:
+
+```bash
+reins status
+```
+
+Open any project with your AI agent — REINS's orchestrator is now part of its
+instructions and will detect the project's stack automatically.
+
+No Node.js? Use the plain bash installer instead — same questions, numbered
+prompts instead of arrow-key menus:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/gustavodiasp/reins-method/main/install.sh | bash
+```
+
+### Where should I install this?
+
+**Install once, in your home directory — not inside or next to your projects.**
+`reins install` always installs to `~/.reins/`, regardless of where you run it from.
+
+There's no need to create a parent folder containing all your projects, and no
+need to install REINS per-project or per-workspace: REINS wires itself into each AI
+agent's *global* config (`~/.claude/CLAUDE.md`, `~/.gemini/GEMINI.md`, etc. — see
+"Supported agents" below), so every project you open with that agent
+automatically gets REINS's orchestrator instructions and stack detection. One
+global install covers every project on the machine, in every supported agent.
+
+### Why does the installer need Node, if REINS is a bash CLI?
+
+Only the *installer* (`npx reins-method install`) uses Node — for the
+[@clack/prompts](https://github.com/bombshell-dev/clack)-based arrow-key menus,
+in the same style as [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)'s
+`npx bmad-method install`. It collects your answers, then hands them to `bin/reins
+install --non-interactive` to do the actual file work. Everything you run
+afterwards — `reins update`, `reins sync`, `reins new-adapter`, etc. — is plain
+bash with no runtime dependencies. If you'd rather not use Node at all, `install.sh`
+runs the same wizard with `read -p` prompts instead of menus.
+
+---
+
+## How it works
+
+```
+~/.reins/
+├── core/        ← the workflow engine (updated via `reins update`)
+├── user/        ← your config, standards, adapters, skills, project state, historic data
+└── agents/      ← generated bridge files, one per AI agent
+```
+
+- **`core/`** defines the workflow phases: `1_orchestrator.md` (read first every
+  session — detects stack, loads adapters, locates the active task), `2_new_task.md`
+  (understand → breakdown → confirm), `3_implement.md` (SPEC → implement → verify),
+  `4_close_task.md` (summary → commit → optional historic entry → cleanup).
+- **`user/`** is yours. `reins update` never touches it. It holds your standards, your
+  adapters, your custom skills, per-project task contexts/specs, and (optionally)
+  monthly historic records.
+- **`agents/`** holds generated files that each AI agent's native config imports or
+  references — see [agents/README.md](agents/README.md).
+
+No REINS file is ever written into a project repository. `.gitignore` hacks aren't
+needed because there's nothing to ignore.
+
+---
+
+## The workflow
+
+```
+New task arrives
+      ↓
+2_new_task.md   — understand task & epic, propose breakdown, flag decisions, create context
+      ↓
+3_implement.md  — SPEC → implement → verify, per confirmed step
+                  (adapters can override this with TDD/SDD-style cycles)
+      ↓
+4_close_task.md — summary, epic impact, commit message, PR review,
+                  optional historic entry, context cleanup
+```
+
+Context files (one per active task, per project) live at
+`~/.reins/user/projects/<project-slug>/contexts/`. See `core/workflow/1_orchestrator.md`
+for the full model, including the "exactly one active context" invariant and the
+multi-component branch guard.
+
+---
+
+## Adapters — teaching REINS your stack
+
+An adapter pack is a folder with conventions (`standards/floor.md`), an optional
+override of the implement phase (`workflow/3_implement.md`), and optional on-demand
+skills (`skills/<name>/SKILL.md`). The orchestrator matches an adapter's declared
+`stacks:` against marker files it finds in your project (`Gemfile`, `package.json`,
+`pyproject.toml`, `go.mod`, ...).
+
+```bash
+reins new-adapter my-company
+```
+
+See [ADAPTERS.md](ADAPTERS.md) for the full contract. Adapters are **user-owned** —
+keep them local, share them privately within your team, or publish them if there's
+nothing proprietary inside.
+
+---
+
+## Skills — on-demand procedures
+
+Skills are single `SKILL.md` files the agent loads only when relevant — never
+proactively. Use the built-in meta-skill to create one:
+
+```bash
+reins new-skill my-skill
+```
+
+or invoke `skill-creator` for guided creation. See [SKILLS.md](SKILLS.md).
+
+---
+
+## Personas, Party Mode & Code Review
+
+Six built-in persona skills give you BMAD-style perspectives natively, with no
+external install — each named after its role (`reins-<role>`), with a character
+identity for flavor:
+
+| Skill | Persona | Lens |
+|---|---|---|
+| `reins-business-analyst` | Toby | Methodical, evidence-based (Porter, Minto Pyramid), represents every stakeholder — including the inconvenient ones — never takes sides |
+| `reins-technical-writer` | Pam | CommonMark/DITA/OpenAPI, writes for the reader with zero context, diagrams over walls of text |
+| `reins-product-manager` | Jim | Jobs-to-be-Done, pragmatic and people-focused, skeptical of complexity that doesn't earn its cost |
+| `reins-ux-designer` | Erin | Deeply empathetic, thinks in user flows and friction points, every decision serves a genuine user need |
+| `reins-system-architect` | David | Calm and strategic, favors proven tech, developer productivity, ties decisions to business value |
+| `reins-senior-engineer` | Angela | Test-first (red/green/refactor), 100% passing before review, no shortcuts |
+
+Each is callable individually ("give me David's take on this"). Before a
+breakdown, ask for **`party-mode`** — Michael (Facilitator) picks the relevant
+personas (always Toby) and announces the lineup, each speaks in turn, then Jim
+(Synthesizer) distills it into what matters for the breakdown. Before proposing a
+commit message, ask for **`code-review`** — Michael opens the session and
+launches independent subagents (Dwight for logic, Creed for security, and Oscar for
+requirements if a SPEC exists) for adversarial, parallel review; Jim then closes
+with a plain-language summary of what needs fixing before merge.
+
+---
+
+## Historic Mode — optional performance tracking
+
+```bash
+reins historic on
+```
+
+Each closed task can leave a short entry in a monthly file under
+`~/.reins/user/historic/`. On request, REINS compiles a Monthly Summary to support
+self-assessment and check-ins. All data is local and user-owned. See
+[HISTORIC_MODE.md](HISTORIC_MODE.md).
+
+---
+
+## Companion tools (optional)
+
+REINS has no required dependencies, but its workflow is designed to take advantage of
+these tools if you choose to install them separately:
+
+- **[headroom](https://github.com/chopratejas/headroom)** — token-efficient context
+  compression for AI agents. Wrap your agent to cut context usage without losing
+  comprehension:
+  ```bash
+  pip install "headroom-ai[all]"
+  headroom wrap <agent>
+  ```
+- **[graphify](https://github.com/safishamsi/graphify)** — generates a knowledge
+  graph of your codebase (code, docs, SQL, PDFs, images) at `graphify-out/`. REINS's
+  orchestrator (`1_orchestrator.md` §2.5) automatically reads
+  `graphify-out/GRAPH_REPORT.md` at session start if present:
+  ```bash
+  pip install graphifyy && graphify install
+  # then, in a project:
+  /graphify .
+  ```
+
+---
+
+## CLI reference
+
+```
+reins install              First-time setup (interactive wizard)
+reins update                Pull latest core, regenerate agent bridge files
+reins new-adapter <name>    Scaffold a new adapter pack
+reins new-skill <name>      Scaffold a new skill
+reins sync                  Regenerate agent bridges + skill registration (no git pull)
+reins link-agents           Wire any newly-installed AI agents into existing bridges
+reins historic on|off       Enable/disable historic mode
+reins status                Show installed version, agent, adapters, historic mode
+reins doctor                Validate the installation
+reins uninstall             Unhook REINS from your agent/shell, optionally delete ~/.reins
+```
+
+---
+
+## Supported agents
+
+REINS doesn't just wire the one agent you pick during `reins install` — every `reins
+update`/`reins sync` run wires **every agent it finds installed on the machine**
+(detected by the presence of that agent's config directory), plus a generic
+`~/AGENTS.md` fallback used by tools without a dedicated config directory:
+
+| Agent | Bridge mechanism | Detected via |
+|---|---|---|
+| Claude Code | `~/.claude/CLAUDE.md` imports `~/.reins/agents/CLAUDE.md` | `~/.claude/` exists |
+| Gemini CLI | `~/.gemini/GEMINI.md` imports `~/.reins/agents/GEMINI.md` | `~/.gemini/` exists |
+| GitHub Copilot CLI | `~/.copilot/instructions.md` references `~/.reins/agents/copilot-instructions.md` | `~/.copilot/` exists |
+| Codex CLI | `~/.codex/AGENTS.md` references `~/.reins/agents/AGENTS.md` | `~/.codex/` exists |
+| Aider / OpenCode / Cursor / other | `~/AGENTS.md` references `~/.reins/agents/AGENTS.md` | always wired |
+
+The agent you pick during `reins install` is just your *default* for `reins
+status`/`reins doctor` — it doesn't limit which agents get REINS's instructions.
+If you install a new AI agent later, run `reins link-agents` to wire it in
+without a full `reins update`. Run `reins doctor` to check your default agent's
+bridge is wired correctly.
+
+---
+
+## Project structure (this repo)
+
+```
+reins-method/
+├── core/
+│   ├── workflow/        ← 1_orchestrator, 2_new_task, 3_implement, 4_close_task
+│   ├── templates/        ← context, current_task, adapter, skill, spec, plan templates
+│   ├── evaluation/        ← historic mode docs + templates
+│   └── skills/            ← skill-creator, party-mode, code-review,
+│                              reins-business-analyst, reins-technical-writer,
+│                              reins-product-manager, reins-ux-designer,
+│                              reins-system-architect, reins-senior-engineer
+├── agents/                ← generated bridge file templates
+├── bin/reins                ← the CLI
+├── tools/installer/cli.js ← `npx reins-method install` (Node wizard, @clack/prompts)
+├── install.sh             ← curl | bash entry point (no Node required)
+├── package.json           ← npm package for the installer (`reins-method`)
+├── ADAPTERS.md
+├── SKILLS.md
+├── HISTORIC_MODE.md
+└── MIGRATION.md
+```
+
+---
+
+## Inspiration
+
+REINS Method's design borrows specific ideas from these projects (full credit to their
+authors — nothing here is a fork or a dependency):
+
+- **[spec-kit](https://github.com/github/spec-kit)** (GitHub) — the per-feature
+  `specs/<feature>/{spec,plan}.md` artifact separation that shaped
+  `specs/<type>_<slug>/step-NN-{spec,plan}.md` and `core/templates/{spec,plan}.md`.
+- **[BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)** — the
+  multi-persona "Party Mode" discussion and the adversarial, parallel code-review
+  pattern, reimplemented natively as `party-mode`, `code-review`, and the six
+  `reins-business-analyst`/`reins-technical-writer`/`reins-product-manager`/
+  `reins-ux-designer`/`reins-system-architect`/`reins-senior-engineer` persona skills.
+- **[headroom](https://github.com/chopratejas/headroom)** — token-efficient context
+  compression; documented as an optional companion tool (see "Companion tools"
+  above).
+- **[graphify](https://github.com/safishamsi/graphify)** — codebase knowledge-graph
+  generation; the orchestrator (`1_orchestrator.md` §2.5) reads its
+  `graphify-out/GRAPH_REPORT.md` output if present (see "Companion tools" above).
+- **[ruflo](https://github.com/ruvnet/ruflo)** — informed thinking on fluid
+  interlinking of workflow phases; no dedicated subsystem was added, but it shaped
+  how `1_orchestrator.md` surfaces optional steps (project map, party-mode,
+  code-review) inline in the workflow diagram.
+
+---
+
+## License
+
+MIT (or your choice — update before publishing).