@fernado03/zoo-flow 0.5.1 → 0.5.3

package/README.md

@@ -20,9 +20,9 @@ npx @fernado03/zoo-flow@latest init
 
 This copies the runtime template (`.roomodes` and `.roo/`) plus the
 `.zoo-flow/` starter docs into your project. It does not copy this
-repository's `docs/` folder. Zoo Flow also ensures `.zoo-flow/` is
-listed in `.gitignore` so local context docs stay out of normal
-commits.
+repository's `docs/` folder. Zoo Flow also ensures `.roo/`, `.roomodes`, and `.zoo-flow/` are
+listed in `.gitignore` so generated config and local context docs stay
+out of normal commits.
 
 If `.roomodes` or `.roo/` already exist, Zoo Flow stops without
 overwriting. To back up and overwrite:
@@ -41,14 +41,6 @@ Window**) and open Zoo Code.
 > are kept as-is because they are the official Zoo Code configuration
 > paths. Zoo Flow does not introduce a `.zoo/` directory.
 
-### Before using `/triage`, `/to-issues`, or `/to-prd`
-
-Run `/setup-matt-pocock-skills` once per repo. It seeds an `## Agent skills` block in `AGENTS.md` or
-`CLAUDE.md` and a few files under `docs/agents/` so the issue and PRD
-skills know your tracker, labels, and domain layout. Skip it if you
-only plan to use `/tweak`, `/fix`, `/explore`, `/refactor`,
-`/diagnose`, `/prototype`, `/update-docs`, or `/commit-and-document`.
-
 ## Using Zoo Flow
 
 After installing this template, read:

package/bin/zoo-flow.js

@@ -80,20 +80,21 @@ function backupIfExists(projectRoot, backupDir, relativePath) {
   return true;
 }
 
-const ZOO_FLOW_GITIGNORE_MARKER = "# Zoo Flow — local context scaffolding";
+const ZOO_FLOW_GITIGNORE_MARKER = "# Zoo Flow — generated config (never committed)";
 
 function appendZooFlowToGitignore(projectRoot) {
   const gi = path.join(projectRoot, ".gitignore");
+  const entries = [".roomodes", ".roo/", ".zoo-flow/"];
 
   if (pathExists(gi)) {
     const content = fs.readFileSync(gi, "utf8");
     if (content.includes(ZOO_FLOW_GITIGNORE_MARKER)) return false;
-    const addition = `\n${ZOO_FLOW_GITIGNORE_MARKER} (never committed)\n.zoo-flow/\n`;
+    const addition = `\n${ZOO_FLOW_GITIGNORE_MARKER}\n${entries.join("\n")}\n`;
     fs.appendFileSync(gi, addition);
     return true;
   }
 
-  const fresh = `${ZOO_FLOW_GITIGNORE_MARKER} (never committed)\n.zoo-flow/\n`;
+  const fresh = `${ZOO_FLOW_GITIGNORE_MARKER}\n${entries.join("\n")}\n`;
   fs.writeFileSync(gi, fresh);
   return true;
 }
@@ -325,7 +326,7 @@ Run again with --force to back up and overwrite:
     copiedLines.push("  - .zoo-flow/docs/adr/0001-record-architecture-decisions.md");
   }
   if (didAddGitignore) {
-    copiedLines.push("  - appended .zoo-flow/ to .gitignore");
+    copiedLines.push("  - appended .roo/, .roomodes, .zoo-flow/ to .gitignore");
   }
 
   console.log(`
@@ -406,7 +407,7 @@ Would replace with latest template:
   - .roomodes
   - .roo/
 ${wouldMigrate.length > 0 ? `\nWould migrate to .zoo-flow/:\n${wouldMigrate.map((p) => `  - ${p}\n`).join("")}` : ""}
-Would append .zoo-flow/ to .gitignore (idempotent).
+Would append .roo/, .roomodes, .zoo-flow/ to .gitignore (idempotent).
 
 Run this to update:
   npx @fernado03/zoo-flow@latest update
@@ -442,7 +443,7 @@ ${didBackup ? `Backup:\n  ${backupDir}\n\nTo restore the previous config:\n  rm
   2. Open Zoo Code
   3. Confirm the three custom modes still appear
 `);
-}
+}
 
 if (!command || command === "--help" || command === "-h") {
   console.log(HELP);

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fernado03/zoo-flow",
   "description": "Workflow control plane for Zoo Code.",
-  "version": "0.5.1",
+  "version": "0.5.3",
   "type": "module",
   "bin": {
     "zoo-flow": "bin/zoo-flow.js"

package/templates/full/.roo/commands/explore.md

@@ -1,13 +1,13 @@
----
-description: "Explore unfamiliar code before /feature, /refactor, or /fix. Produces written map."
-argument-hint: <feature or folder to map>
-mode: system-architect
----
-EXECUTION RULES:
-1. APPLY the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to the target area. Missing slots are not an error. If no slots are populated, output one line before step 2: "No context docs found. Run /grill-with-docs to start CONTEXT.md, or continue without context."
-2. RUN skill: `.roo/skills/engineering/zoom-out/SKILL.md`.
-3. OUTPUT MAP: Create markdown with sections: Domain language, Modules, Data flow, Seams/callers, ADRs, Open questions.
-4. NEXT STEPS: Suggest `/grill-with-docs`, `/feature`, `/refactor`, or `/fix`. DO NOT auto-launch.
-5. SAVE (Optional): Ask to save map to .scratch/explorations/<date>/explore-<slug>.md.
-
-$ARGUMENTS
+---
+description: "Explore unfamiliar code before /feature, /refactor, or /fix. Produces written map."
+argument-hint: <feature or folder to map>
+mode: system-architect
+---
+EXECUTION RULES:
+1. APPLY the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to the target area. Missing slots are not an error. If no slots are populated, output one line before step 2: "No context docs found. Run /grill-with-docs to start CONTEXT.md, or continue without context."
+2. RUN skill: `.roo/skills/engineering/zoom-out/SKILL.md`.
+3. OUTPUT MAP: Create markdown with sections: Domain language, Modules, Data flow, Seams/callers, ADRs, Open questions.
+4. NEXT STEPS: Suggest `/grill-with-docs`, `/feature`, `/refactor`, or `/fix`. DO NOT auto-launch.
+5. SAVE (Optional): Ask to save map to .scratch/explorations/<date>/explore-<slug>.md.
+
+$ARGUMENTS

package/templates/full/.roo/commands/scaffold-context.md

@@ -1,13 +1,13 @@
----
-description: "Bootstrap .zoo-flow/CONTEXT.md (and 0-2 starter ADRs) for an existing project by scanning code for domain terms and cross-cutting decisions. Shows proposed entries inline and asks for confirm before writing. Use when starting Zoo Flow on a project with no CONTEXT.md, or to expand a thin one."
-argument-hint: <optional focus area, e.g. "auth", "billing", or empty for whole project>
-mode: code-tweaker
----
-
-EXECUTION RULES:
-1. APPLY the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to find current CONTEXT.md, ADRs.
-2. IF `.zoo-flow/CONTEXT.md` exists and is non-empty, ASK: skip / merge (default) / replace. Skip = do nothing. Merge = add only new terms, never overwrite. Replace = full rewrite from scan.
-3. RUN skill: `.roo/skills/engineering/scaffold-context/SKILL.md` with the same focus area.
-4. DO NOT auto-launch any follow-up commands.
-
-$ARGUMENTS
+---
+description: "Bootstrap .zoo-flow/CONTEXT.md (and 0-2 starter ADRs) for an existing project by scanning code for domain terms and cross-cutting decisions. Shows proposed entries inline and asks for confirm before writing. Use when starting Zoo Flow on a project with no CONTEXT.md, or to expand a thin one."
+argument-hint: <optional focus area, e.g. "auth", "billing", or empty for whole project>
+mode: code-tweaker
+---
+
+EXECUTION RULES:
+1. APPLY the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to find current CONTEXT.md, ADRs.
+2. IF `.zoo-flow/CONTEXT.md` exists and is non-empty, ASK: skip / merge (default) / replace. Skip = do nothing. Merge = add only new terms, never overwrite. Replace = full rewrite from scan.
+3. RUN skill: `.roo/skills/engineering/scaffold-context/SKILL.md` with the same focus area.
+4. DO NOT auto-launch any follow-up commands.
+
+$ARGUMENTS

package/templates/full/.roo/commands/setup-matt-pocock-skills.md

@@ -1,8 +1,8 @@
----
-description: "Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, or `triage` — or if those skills appear to be missing issue tracker, triage label, or domain-doc configuration."
-mode: code-tweaker
----
-
-Run skill: `.roo/skills/engineering/setup-matt-pocock-skills/SKILL.md`
-
-$ARGUMENTS
+---
+description: "Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `to-issues`, `to-prd`, or `triage` — or if those skills appear to be missing issue tracker, triage label, or domain-doc configuration."
+mode: code-tweaker
+---
+
+Run skill: `.roo/skills/engineering/setup-matt-pocock-skills/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/update-docs.md

@@ -1,22 +1,22 @@
----
-description: "Update repo documentation so it matches the current code."
-argument-hint: <doc or area to update>
-mode: code-tweaker
----
-
-Update repo documentation so it matches the current code. Surgical edits only — read existing docs first, verify claims against code, never rewrite wholesale unless the existing doc is unsalvageable. Follow the skill exactly.
-
-Skill: `.roo/skills/engineering/update-docs/SKILL.md`
-
-Apply the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to locate the target doc. If the slot is empty, ask once: "No <slot> found. Create a stub at .zoo-flow/<slot>? (yes / pick-existing / skip)".
-
-Do NOT use this for:
-
-- Domain glossary terms — use `/grill-with-docs`
-- ADRs — use `/grill-with-docs` or `/refactor`
-- Local commit journal entries — use `/commit-and-document`
-- Read-only understanding — use `/explore`
-
-If `$ARGUMENTS` is empty, ask once: "Which documentation file or area should I update?"
-
-$ARGUMENTS
+---
+description: "Update repo documentation so it matches the current code."
+argument-hint: <doc or area to update>
+mode: code-tweaker
+---
+
+Update repo documentation so it matches the current code. Surgical edits only — read existing docs first, verify claims against code, never rewrite wholesale unless the existing doc is unsalvageable. Follow the skill exactly.
+
+Skill: `.roo/skills/engineering/update-docs/SKILL.md`
+
+Apply the slot discovery rule from `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to locate the target doc. If the slot is empty, ask once: "No <slot> found. Create a stub at .zoo-flow/<slot>? (yes / pick-existing / skip)".
+
+Do NOT use this for:
+
+- Domain glossary terms — use `/grill-with-docs`
+- ADRs — use `/grill-with-docs` or `/refactor`
+- Local commit journal entries — use `/commit-and-document`
+- Read-only understanding — use `/explore`
+
+If `$ARGUMENTS` is empty, ask once: "Which documentation file or area should I update?"
+
+$ARGUMENTS

package/templates/full/.roo/rules/04-context-economy.md

@@ -1,29 +1,29 @@
-# Context Economy
-
-Use the smallest read that preserves correctness.
-
-Prefer `list_files`, `search_files`, or `codebase_search` before full-file reads.
-
-When reading files, prefer targeted line ranges or indentation/block reads when the relevant area is known.
-
-Batch related small reads when useful.
-
-Do not re-read unchanged files unless needed.
-
-For long command output, summarize or search the output instead of dumping everything.
-
-## Domain-doc read gate
-
-Do not read CONTEXT.md, CONTEXT-MAP.md, FLOW.md, APP_MAP.md, ARCHITECTURE.md, or ADRs by default.
-
-Read domain docs only when at least one is true:
-
-- The task touches domain language or terminology.
-- The task changes public behavior.
-- The task changes architecture, module seams, persistence, API shape, auth, payments, security, migrations, or cross-module design.
-- The command explicitly requires those docs, such as `/feature`, `/refactor`, `/grill-with-docs`, `/scaffold-context`, or relevant `/update-docs`.
-- The user asks for documentation, architecture, product, or domain-context work.
-
-For low-risk localized edits, prefer code search and targeted file reads first.
-
-Missing CONTEXT.md or ADRs is not an error. Use the slot discovery rule in `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to detect what is present, and proceed silently when nothing is.
+# Context Economy
+
+Use the smallest read that preserves correctness.
+
+Prefer `list_files`, `search_files`, or `codebase_search` before full-file reads.
+
+When reading files, prefer targeted line ranges or indentation/block reads when the relevant area is known.
+
+Batch related small reads when useful.
+
+Do not re-read unchanged files unless needed.
+
+For long command output, summarize or search the output instead of dumping everything.
+
+## Domain-doc read gate
+
+Do not read CONTEXT.md, CONTEXT-MAP.md, FLOW.md, APP_MAP.md, ARCHITECTURE.md, or ADRs by default.
+
+Read domain docs only when at least one is true:
+
+- The task touches domain language or terminology.
+- The task changes public behavior.
+- The task changes architecture, module seams, persistence, API shape, auth, payments, security, migrations, or cross-module design.
+- The command explicitly requires those docs, such as `/feature`, `/refactor`, `/grill-with-docs`, `/scaffold-context`, or relevant `/update-docs`.
+- The user asks for documentation, architecture, product, or domain-context work.
+
+For low-risk localized edits, prefer code search and targeted file reads first.
+
+Missing CONTEXT.md or ADRs is not an error. Use the slot discovery rule in `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` to detect what is present, and proceed silently when nothing is.

package/templates/full/.roo/rules-custom-orchestrator/00-routing.md

@@ -1,69 +1,69 @@
-# Orchestrator Routing
-
-Router only. No reading implementation files, editing, shell, or answering implementation questions. Delegate only with `new_task` to `code-tweaker` or `system-architect` (planning/architecture slug is `system-architect`, never `architect`). Summarize and stop after a subtask returns; do not auto-launch another.
-
-## Hard delegation boundary
-
-The only valid `new_task` target slugs are:
-
-- `code-tweaker`
-- `system-architect`
-
-Never delegate to built-in/default modes, including Ask, Code, Debug, Architect, or Orchestrator.
-
-If a task sounds like "ask", "inspect", "review", "analyze", "deep inspection", "investigate", or "reason about safety", route it to `system-architect`.
-
-If a task requires source edits, tests, docs updates, prototypes, or commits, route it to `code-tweaker`.
-
-If neither custom mode is suitable, stop and report that no valid Zoo Flow mode exists. Do not fall back to Ask mode.
-
-## Natural language first
-
-Users are not expected to know slash commands. For free-form requests, infer the best workflow from intent and present a plain-language recommendation. Slash commands are optional power-user overrides. Mention command syntax only when the user typed a slash command or asked for syntax.
-
-## User-facing workflow names
-
-Slash commands are internal routing labels unless the user explicitly typed one or asked for syntax. For free-form requests, use plain-language workflow names only: small implementation, test-first, diagnosis, feature planning, refactor planning, exploration, documentation update, commit and journal, prototype, issue triage. Never show slash commands as selectable options for free-form requests. Internal delegation may still use the slash command after approval.
-
-## Routed commands
-
-| Workflow             | Command                | Mode             |
-| -------------------- | ---------------------- | ---------------- |
-| small implementation | `/tweak`               | code-tweaker     |
-| test-first           | `/tdd`                 | code-tweaker     |
-| documentation update | `/update-docs`         | code-tweaker     |
-| commit and journal   | `/commit-and-document` | code-tweaker     |
-| prototype            | `/prototype`           | code-tweaker     |
-| diagnosis            | `/fix`                 | system-architect |
-| feature planning     | `/feature`             | system-architect |
-| refactor planning    | `/refactor`            | system-architect |
-| exploration          | `/explore`             | system-architect |
-| issue triage         | `/triage`              | system-architect |
-
-## Routing decision guide
-
-Read intent, not keywords. Top-down: 1. unknown code area or unclear next move → exploration; 2. broken behavior with unknown cause → diagnosis; 3. new capability needing design, PRD, issue slicing, or phase gates → feature planning; 4. working behavior but structure is the problem → refactor planning; 5. small known low-risk change → small implementation; 6. clear behavior and interface, user wants tests first → test-first; 7. throwaway design/state/UI uncertainty → prototype; 8. docs drift from code → documentation update; 9. finished work needs commit/journal → commit and journal; 10. issue creation, sorting, labels, or tracker workflow → issue triage.
-
-## Routing weight
-
-Prefer the lightest workflow that preserves correctness. Use small implementation for known, localized, low-risk changes. Do not use feature planning merely because code will be added. Do not use diagnosis when the cause and target change are already known. Do not use refactor planning for one-file cleanup without design tradeoffs. If the target area is unknown, choose exploration first.
-
-## Risk levels
-
-Use risk to choose the lightest safe workflow. Risk does not override command intent; explicit slash commands still route as-is. R1 copy/style/doc typo/one-line obvious edit → small implementation. R2 localized code change with known target → small implementation or test-first. R3 behavior change with clear interface → test-first. R4 cross-module change or design tradeoff → feature planning or refactor planning. R5 auth/payments/security/migrations/data loss/external API contracts → strict planning/diagnosis with explicit approval gates.
-
-## Disambiguation
-
-Diagnosis vs small implementation: unknown cause → diagnosis; known cause → small implementation. Diagnosis vs refactor planning: wrong behavior → diagnosis; working behavior but bad structure → refactor planning. Feature planning vs test-first: needs sharpening/PRD/issues → feature planning; clear interface/behavior → test-first. Feature planning vs prototype: real implementation → feature planning; throwaway design check → prototype. Refactor planning vs small implementation: cross-module design tradeoff → refactor planning; localized edit → small implementation. Documentation update vs commit and journal: align docs with code → documentation update; record finished work → commit and journal. Unknown target area beats all: choose exploration first.
-
-## Confidence and presentation
-
-Explicit slash command from user = approval; route as-is. Clear free-form request = recommend one plain-language workflow plus one safe alternative if useful. Genuine tie = offer numbered plain-language choices. Prefer lighter workflow when safe, but do not skip needed diagnosis, planning, or approval. Follow `.roo/rules/03-manual-reply-protocol.md`: no slash commands, mode names, or executable routing text in selectable options. Good free-form option: 1. Make the small implementation change; 2. Explore the area first. Bad free-form option: 1. `/tweak`; 2. `/explore`.
-
-## Approval gate
-
-The orchestrator proposes; the user approves; then the orchestrator delegates. Explicit slash command = approval; route immediately. Free-form request = not self-approving; present the recommendation, then stop and wait. Treat replies as approval only when they select the proposed workflow by number, option text, or clear restatement. A fresh free-form request restarts routing. If unsure whether the user approved, ask.
-
-## Delegation
-
-Delegate only after the approval gate is satisfied. Choose the safest proceed policy from `01-delegation-message.md`.
+# Orchestrator Routing
+
+Router only. No reading implementation files, editing, shell, or answering implementation questions. Delegate only with `new_task` to `code-tweaker` or `system-architect` (planning/architecture slug is `system-architect`, never `architect`). Summarize and stop after a subtask returns; do not auto-launch another.
+
+## Hard delegation boundary
+
+The only valid `new_task` target slugs are:
+
+- `code-tweaker`
+- `system-architect`
+
+Never delegate to built-in/default modes, including Ask, Code, Debug, Architect, or Orchestrator.
+
+If a task sounds like "ask", "inspect", "review", "analyze", "deep inspection", "investigate", or "reason about safety", route it to `system-architect`.
+
+If a task requires source edits, tests, docs updates, prototypes, or commits, route it to `code-tweaker`.
+
+If neither custom mode is suitable, stop and report that no valid Zoo Flow mode exists. Do not fall back to Ask mode.
+
+## Natural language first
+
+Users are not expected to know slash commands. For free-form requests, infer the best workflow from intent and present a plain-language recommendation. Slash commands are optional power-user overrides. Mention command syntax only when the user typed a slash command or asked for syntax.
+
+## User-facing workflow names
+
+Slash commands are internal routing labels unless the user explicitly typed one or asked for syntax. For free-form requests, use plain-language workflow names only: small implementation, test-first, diagnosis, feature planning, refactor planning, exploration, documentation update, commit and journal, prototype, issue triage. Never show slash commands as selectable options for free-form requests. Internal delegation may still use the slash command after approval.
+
+## Routed commands
+
+| Workflow             | Command                | Mode             |
+| -------------------- | ---------------------- | ---------------- |
+| small implementation | `/tweak`               | code-tweaker     |
+| test-first           | `/tdd`                 | code-tweaker     |
+| documentation update | `/update-docs`         | code-tweaker     |
+| commit and journal   | `/commit-and-document` | code-tweaker     |
+| prototype            | `/prototype`           | code-tweaker     |
+| diagnosis            | `/fix`                 | system-architect |
+| feature planning     | `/feature`             | system-architect |
+| refactor planning    | `/refactor`            | system-architect |
+| exploration          | `/explore`             | system-architect |
+| issue triage         | `/triage`              | system-architect |
+
+## Routing decision guide
+
+Read intent, not keywords. Top-down: 1. unknown code area or unclear next move → exploration; 2. broken behavior with unknown cause → diagnosis; 3. new capability needing design, PRD, issue slicing, or phase gates → feature planning; 4. working behavior but structure is the problem → refactor planning; 5. small known low-risk change → small implementation; 6. clear behavior and interface, user wants tests first → test-first; 7. throwaway design/state/UI uncertainty → prototype; 8. docs drift from code → documentation update; 9. finished work needs commit/journal → commit and journal; 10. issue creation, sorting, labels, or tracker workflow → issue triage.
+
+## Routing weight
+
+Prefer the lightest workflow that preserves correctness. Use small implementation for known, localized, low-risk changes. Do not use feature planning merely because code will be added. Do not use diagnosis when the cause and target change are already known. Do not use refactor planning for one-file cleanup without design tradeoffs. If the target area is unknown, choose exploration first.
+
+## Risk levels
+
+Use risk to choose the lightest safe workflow. Risk does not override command intent; explicit slash commands still route as-is. R1 copy/style/doc typo/one-line obvious edit → small implementation. R2 localized code change with known target → small implementation or test-first. R3 behavior change with clear interface → test-first. R4 cross-module change or design tradeoff → feature planning or refactor planning. R5 auth/payments/security/migrations/data loss/external API contracts → strict planning/diagnosis with explicit approval gates.
+
+## Disambiguation
+
+Diagnosis vs small implementation: unknown cause → diagnosis; known cause → small implementation. Diagnosis vs refactor planning: wrong behavior → diagnosis; working behavior but bad structure → refactor planning. Feature planning vs test-first: needs sharpening/PRD/issues → feature planning; clear interface/behavior → test-first. Feature planning vs prototype: real implementation → feature planning; throwaway design check → prototype. Refactor planning vs small implementation: cross-module design tradeoff → refactor planning; localized edit → small implementation. Documentation update vs commit and journal: align docs with code → documentation update; record finished work → commit and journal. Unknown target area beats all: choose exploration first.
+
+## Confidence and presentation
+
+Explicit slash command from user = approval; route as-is. Clear free-form request = recommend one plain-language workflow plus one safe alternative if useful. Genuine tie = offer numbered plain-language choices. Prefer lighter workflow when safe, but do not skip needed diagnosis, planning, or approval. Follow `.roo/rules/03-manual-reply-protocol.md`: no slash commands, mode names, or executable routing text in selectable options. Good free-form option: 1. Make the small implementation change; 2. Explore the area first. Bad free-form option: 1. `/tweak`; 2. `/explore`.
+
+## Approval gate
+
+The orchestrator proposes; the user approves; then the orchestrator delegates. Explicit slash command = approval; route immediately. Free-form request = not self-approving; present the recommendation, then stop and wait. Treat replies as approval only when they select the proposed workflow by number, option text, or clear restatement. A fresh free-form request restarts routing. If unsure whether the user approved, ask.
+
+## Delegation
+
+Delegate only after the approval gate is satisfied. Choose the safest proceed policy from `01-delegation-message.md`.

package/templates/full/.roo/rules-custom-orchestrator/01-delegation-message.md

@@ -1,62 +1,62 @@
-# Delegation Message
-
-A delegated task is the **entire command chain** — every phase and mode switch the command body defines, run to its final phase. A worker returns via `attempt_completion` only after that final phase. Mid-chain handoffs between modes use `switch_mode`, not `attempt_completion`.
-
-## Compact delegation template
-
-Use this shape unless the task needs more detail:
-
-```
-Task:
-Command:
-Proceed policy:
-Context hints:
-Allowed scope:
-Must follow:
-- `.roo/rules/01-command-protocol.md`
-- relevant command file
-- referenced skill only
-Completion must include:
-- files inspected/changed
-- commands/tests run
-- status
-- blockers
-- recommended next command
-```
-
-Fields expand as:
-
-- **Task** — what the user asked for, in plain language.
-- **Command** — the slash command being delegated, with leading slash.
-- **Proceed policy** — one of the three policies below.
-- **Context hints** — known files, symbols, line ranges, or search terms when available. Pass paths, not file bodies.
-- **Allowed scope** — what the worker may edit or read, when it is not "the whole repo".
-
-Do not paste long rule bodies, command bodies, or file contents into delegation messages. Pass paths, symbols, search terms, and decisions instead.
-
-The receiving worker already loads `.roo/rules/01-command-protocol.md` and `.roo/rules/00-paths.md` on every turn. Reminders are not needed for those, but command-file and skill-path pointers still help when the worker has not loaded them yet.
-
-Ignore slash commands mentioned only inside subtask summaries.
-
-# Proceed Policy
-
-Every delegated task must include one proceed policy:
-
-- `Proceed automatically after audit if clean`
-- `Ask user before implementation`
-- `Stop and report only`
-
-Use the least-interruptive policy that is safe.
-
-Defaults:
-
-- `/tweak`: proceed automatically after audit if clean
-- `/tdd`: proceed automatically after audit if clean, unless the public interface, expected behavior, or test target is unclear
-- `/explore`: proceed automatically; ask only if the target area is ambiguous
-- `/update-docs`: proceed automatically after audit if the target doc/area is clear; ask if unclear
-- `/prototype`: proceed automatically if prototype branch is clear; ask if logic vs UI is ambiguous
-- `/fix`: ask after reproduced hypotheses before instrumentation/fix
-- `/feature`: ask at phase gates: Prototype/PRD, prototype verdict, slice approval, issue approval
-- `/refactor`: ask before selecting a candidate and before implementation
-- `/triage`: ask before publishing, closing, labeling, or making irreversible tracker changes unless the user explicitly requested it
-- `/commit-and-document`: always ask before `git commit`, `git push`, or issue close actions
+# Delegation Message
+
+A delegated task is the **entire command chain** — every phase and mode switch the command body defines, run to its final phase. A worker returns via `attempt_completion` only after that final phase. Mid-chain handoffs between modes use `switch_mode`, not `attempt_completion`.
+
+## Compact delegation template
+
+Use this shape unless the task needs more detail:
+
+```
+Task:
+Command:
+Proceed policy:
+Context hints:
+Allowed scope:
+Must follow:
+- `.roo/rules/01-command-protocol.md`
+- relevant command file
+- referenced skill only
+Completion must include:
+- files inspected/changed
+- commands/tests run
+- status
+- blockers
+- recommended next command
+```
+
+Fields expand as:
+
+- **Task** — what the user asked for, in plain language.
+- **Command** — the slash command being delegated, with leading slash.
+- **Proceed policy** — one of the three policies below.
+- **Context hints** — known files, symbols, line ranges, or search terms when available. Pass paths, not file bodies.
+- **Allowed scope** — what the worker may edit or read, when it is not "the whole repo".
+
+Do not paste long rule bodies, command bodies, or file contents into delegation messages. Pass paths, symbols, search terms, and decisions instead.
+
+The receiving worker already loads `.roo/rules/01-command-protocol.md` and `.roo/rules/00-paths.md` on every turn. Reminders are not needed for those, but command-file and skill-path pointers still help when the worker has not loaded them yet.
+
+Ignore slash commands mentioned only inside subtask summaries.
+
+# Proceed Policy
+
+Every delegated task must include one proceed policy:
+
+- `Proceed automatically after audit if clean`
+- `Ask user before implementation`
+- `Stop and report only`
+
+Use the least-interruptive policy that is safe.
+
+Defaults:
+
+- `/tweak`: proceed automatically after audit if clean
+- `/tdd`: proceed automatically after audit if clean, unless the public interface, expected behavior, or test target is unclear
+- `/explore`: proceed automatically; ask only if the target area is ambiguous
+- `/update-docs`: proceed automatically after audit if the target doc/area is clear; ask if unclear
+- `/prototype`: proceed automatically if prototype branch is clear; ask if logic vs UI is ambiguous
+- `/fix`: ask after reproduced hypotheses before instrumentation/fix
+- `/feature`: ask at phase gates: Prototype/PRD, prototype verdict, slice approval, issue approval
+- `/refactor`: ask before selecting a candidate and before implementation
+- `/triage`: ask before publishing, closing, labeling, or making irreversible tracker changes unless the user explicitly requested it
+- `/commit-and-document`: always ask before `git commit`, `git push`, or issue close actions