@fernado03/zoo-flow 0.11.3 → 0.12.1

package/templates/full/.roo/skills/engineering/update-docs/SKILL.md

@@ -1,76 +1,76 @@
----
-name: update-docs
-description: Update repo documentation (flow, app map, architecture, README, module docs) so it matches current code. Use when docs are stale and need to be reconciled with the codebase.
----
-
-# Update Docs
-
-Edit repo docs that explain how code works (flow docs, app/module maps, architecture overviews, README, module-local markdown). Surgical edits, not rewrites.
-
-## 1. Identify target
-
-Infer or ask for the target doc. Prefer existing docs over new ones:
-
-- Subsystem flow → nearby flow doc.
-- App-wide navigation/module map → app map doc.
-- System-level structure → architecture doc.
-- Setup/usage → `README.md`.
-
-If the doc does not exist, ask before creating. Never invent a new doc location silently.
-
-## 2. Read first
-
-Read the target fully before editing. Also read nearby related docs (neighbouring flow docs, app/architecture docs, README, module-local docs). Match the existing style, structure, vocabulary, and detail level.
-
-## 3. Verify against code
-
-Inspect the code the doc describes. Update from code reality, not guesses. Check entrypoints, main functions/classes, data flow, state changes, side effects, deps, error/fallback paths, files involved.
-
-Unverifiable claims → remove or move to an `Open questions` section. Never present guesses as facts.
-
-## 4. Surgical edits
-
-Default to small edits: keep useful sections, update stale ones, add missing flows, remove false claims, preserve heading style and tone. Rewrite the whole file only if it is too stale to salvage; if so, say why before editing.
-
-## 5. Freshness block
-
-If it fits the doc's style, add or update at the bottom:
-
-```md
-## Freshness
-
-Last checked against code: YYYY-MM-DD
-Relevant files checked:
-- `path/to/file.py`
-- `path/to/other_file.py`
-```
-
-Use today's date. Include only files actually inspected.
-
-## 6. Sanity check
-
-After editing: re-read, confirm referenced paths exist, every major claim maps to code or a cited doc, no stale contradiction with nearby docs. Summarise the change.
-
-## 7. Recommend next step
-
-Recommend one: `/explore` (still unclear), `/feature` (plan emerged), `/refactor` (tangled-but-working code), `/fix` (bug found), `/commit-and-document` (done). Do not auto-run.
-
-## Complete
-
-Call `attempt_completion` with:
-- docs updated (file paths)
-- what changed (summary)
-- status (complete / blocked with reason)
-- recommended next command
-
-Do NOT use `ask_followup_question` or write results as plain text without calling the tool.
-
-## Context economy
-
-Before broad reads, locate relevant files/symbols with `list_files`, `search_files`, or `codebase_search`.
-
-Prefer targeted `read_file` ranges or indentation/block reads once the relevant area is known.
-
-Read full files only when structure, ordering, or surrounding context is required for correctness.
-
-Do not re-read unchanged files; use prior findings unless the file changed.
+---
+name: update-docs
+description: Update repo documentation (flow, app map, architecture, README, module docs) so it matches current code. Use when docs are stale and need to be reconciled with the codebase.
+---
+
+# Update Docs
+
+Edit repo docs that explain how code works (flow docs, app/module maps, architecture overviews, README, module-local markdown). Surgical edits, not rewrites.
+
+## 1. Identify target
+
+Infer or ask for the target doc. Prefer existing docs over new ones:
+
+- Subsystem flow → nearby flow doc.
+- App-wide navigation/module map → app map doc.
+- System-level structure → architecture doc.
+- Setup/usage → `README.md`.
+
+If the doc does not exist, ask before creating. Never invent a new doc location silently.
+
+## 2. Read first
+
+Read the target fully before editing. Also read nearby related docs (neighbouring flow docs, app/architecture docs, README, module-local docs). Match the existing style, structure, vocabulary, and detail level.
+
+## 3. Verify against code
+
+Inspect the code the doc describes. Update from code reality, not guesses. Check entrypoints, main functions/classes, data flow, state changes, side effects, deps, error/fallback paths, files involved.
+
+Unverifiable claims → remove or move to an `Open questions` section. Never present guesses as facts.
+
+## 4. Surgical edits
+
+Default to small edits: keep useful sections, update stale ones, add missing flows, remove false claims, preserve heading style and tone. Rewrite the whole file only if it is too stale to salvage; if so, say why before editing.
+
+## 5. Freshness block
+
+If it fits the doc's style, add or update at the bottom:
+
+```md
+## Freshness
+
+Last checked against code: YYYY-MM-DD
+Relevant files checked:
+- `path/to/file.py`
+- `path/to/other_file.py`
+```
+
+Use today's date. Include only files actually inspected.
+
+## 6. Sanity check
+
+After editing: re-read, confirm referenced paths exist, every major claim maps to code or a cited doc, no stale contradiction with nearby docs. Summarise the change.
+
+## 7. Recommend next step
+
+Recommend one: `/zoo-explore` (still unclear), `/zoo-feature` (plan emerged), `/zoo-refactor` (tangled-but-working code), `/zoo-fix` (bug found), `/zoo-commit-and-document` (done). Do not auto-run.
+
+## Complete
+
+Call `attempt_completion` with:
+- docs updated (file paths)
+- what changed (summary)
+- status (complete / blocked with reason)
+- recommended next command
+
+Do NOT use `ask_followup_question` or write results as plain text without calling the tool.
+
+## Context economy
+
+Before broad reads, locate relevant files/symbols with `list_files`, `search_files`, or `codebase_search`.
+
+Prefer targeted `read_file` ranges or indentation/block reads once the relevant area is known.
+
+Read full files only when structure, ordering, or surrounding context is required for correctness.
+
+Do not re-read unchanged files; use prior findings unless the file changed.

package/templates/full/.roo/skills/engineering/verify/SKILL.md

@@ -65,7 +65,7 @@ Status: pass | fail | partial | blocked
 
 ## Recommended next step
 
-<none | /review | /tweak | /tdd | /fix | /commit-and-document>
+<none | /zoo-review | /zoo-tweak | /zoo-tdd | /zoo-fix | /zoo-commit-and-document>
 ```
 
 Hard rule: never say `verified`, `all good`, or `tests pass` unless commands actually ran and passed.
@@ -81,7 +81,7 @@ Do not auto-launch any follow-up command.
 
 ## 6. Complete
 
-Write the full verification report to `.scratch/verify/<date>/verify-<slug>.md`.
+Write the full verification report to `.scratch/zoo-verify/<date>/zoo-verify-<slug>.md`.
 
 Call `attempt_completion` with:
 - file path where report was saved

package/templates/full/.roo/skills/engineering/zoom-out/SKILL.md

@@ -22,7 +22,7 @@ Start with `list_files` and `search_files`/`codebase_search`. Read representativ
 
 ## Multi-dimension mapping
 
-Initialize session: `.scratch/explorations/<YYYY-MM-DD>/zoom-out-<slug>/`
+Initialize session: `.scratch/explorations/<YYYY-MM-DD>/zoo-zoom-out-<slug>/`
 
 Write `<session-dir>/session.md` with target area, scope, user request.
 

package/templates/full/.roo/skills/productivity/caveman/SKILL.md

@@ -4,7 +4,7 @@ description: >
   Ultra-compressed communication mode. Cuts token usage ~75% by dropping
   filler, articles, and pleasantries while keeping full technical accuracy.
   Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
+  "less tokens", "be brief", or invokes /zoo-caveman.
 ---
 
 # Caveman

package/templates/full/.roo/skills/productivity/teach/SKILL.md

@@ -1,119 +1,119 @@
----
-name: teach
-description: Teach a topic over multiple stateful sessions, treating the current directory as a teaching workspace. Tracks mission, glossary, resources, and learning records to ground every session and pace the user inside their zone of proximal development. Use when user asks to be taught a topic, wants to learn something over time, or mentions ongoing study.
-disable-model-invocation: true
-argument-hint: "What would you like to learn about?"
----
-
-# Teach
-
-Stateful. Treat current directory as the teaching workspace.
-
-## Files
-
-- `MISSION.md` — why user wants this; grounds every decision. Format: `mission-format.md`.
-- `RESOURCES.md` — trusted knowledge + community sources. Format: `resources-format.md`.
-- `./reference/*.html` — A directory of reference materials. These are the compressed learnings from the lessons — cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
-- `./lessons/*.html` — A directory of lessons. A lesson is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in the workspace.
-- `NOTES.md` — A scratchpad for you to jot down user preferences, or working notes.
-- `learning-records/NNNN-slug.md` — non-obvious lessons + prior knowledge. Format: `learning-record-format.md`.
-
-## Triad
-
-- **Knowledge** — drawn from `RESOURCES.md`. Never parametric.
-- **Skills** — exercises built from the knowledge.
-- **Wisdom** — real-world community interaction via `RESOURCES.md`.
-
-Topic mix varies: theoretical → knowledge-heavy; practical → skills-heavy.
-
-### Fluency vs Storage Strength
-
-You should be careful to split between two types of learning:
-
-- **Fluency strength**: in-the-moment retrieval of knowledge
-- **Storage strength**: long-term retention of knowledge
-
-Fluency can give the user an illusory sense of mastery, but storage strength is the real goal. Try to design lessons which build long-term retention by desirable difficulty:
-
-- Using retrieval practice (recall from memory)
-- Spacing (distributing practice over time)
-- Interleaving (mixing up different but related topics in practice - for skill practice only)
-
-## Lessons
-
-A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html`, where the number increments each time.
-
-A lesson should be **beautiful** - clean, readable typography and layout since the user will return to these later to review. Think Tufte.
-
-The lesson should be short, and completable very quickly. Learners' working memory is very small, and we need to stay within it. But each lesson should give the user a single tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
-
-If possible, open the lesson file for the user by running a CLI command.
-
-Each lesson should link via HTML anchors to other lessons and reference documents.
-
-Each lesson should recommend a primary source for the user to read or watch. This should be the most high-quality, high-trust resource you found on the topic.
-
-Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear.
-
-## Mission first
-
-If `MISSION.md` missing or vague, interview before teaching. No mission = no grounding, abstract exercises, no signal for what's next.
-
-Missions may change as the user develops more skills and knowledge. This is normal - make sure to update the `MISSION.md` and add a learning record to capture the change. Confirm with the user before changing the mission.
-
-## Zone of proximal development
-
-The user may specify an exact thing they want to learn. If they don't, figure out their zone of proximal development.
-
-Each lesson, the user should always feel as if they are being challenged 'just enough'.
-
-Pick next topic by:
-1. Read `learning-records/`.
-2. Align to `MISSION.md`.
-3. Pick tightest scope that still stretches the user.
-
-User says "I already know X" → record in `learning-records/`.
-
-## Knowledge
-
-Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson, and gives the user a path to acquire more knowledge if they want to go deeper.
-
-For acquiring knowledge, difficulty is the enemy. It eats working memory you need for understanding.
-
-1. Pull from `RESOURCES.md`.
-2. Write HTML explainer to local file. Beautiful, glossary-correct. Litter with citations linking external resources backing every claim. Interactive: "try this" callouts to apply the knowledge.
-3. Give one-line CLI command to open it.
-4. Take questions; amend explainer or write a new one.
-
-
-## Skills
-
-For skill acquisition, difficulty is the tool. Effortful retrieval is what builds storage strength. Skills should be taught through interactive lessons. There are several tools at your disposal:
-
-- Interactive lessons, using quizzes and light in-browser tasks
-- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
-- In-agent quizzes, where you ask the user scenario-based questions about what they've learned
-
-Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
-
-For quizzes, each answer should be exactly the same number of words (and characters, if possible). Don't give the user any clues about the answer through formatting.
-
-## Wisdom
-
-Default: attempt an answer, then route to a high-reputation community from `RESOURCES.md`. If user opted out of communities, record it in `RESOURCES.md` and stop suggesting.
-
-## `NOTES.md`
-
-The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.
-
-## Complete
-
-When the user ends the teaching session or says "done" / "stop teaching":
-
-Call `attempt_completion` with:
-- lessons created (count, paths)
-- mission status (created / updated)
-- learning records updated (count)
-- status (session complete / paused)
-
-Do NOT use `ask_followup_question` or write results as plain text without calling the tool.
+---
+name: teach
+description: Teach a topic over multiple stateful sessions, treating the current directory as a teaching workspace. Tracks mission, glossary, resources, and learning records to ground every session and pace the user inside their zone of proximal development. Use when user asks to be taught a topic, wants to learn something over time, or mentions ongoing study.
+disable-model-invocation: true
+argument-hint: "What would you like to learn about?"
+---
+
+# Teach
+
+Stateful. Treat current directory as the teaching workspace.
+
+## Files
+
+- `MISSION.md` — why user wants this; grounds every decision. Format: `mission-format.md`.
+- `RESOURCES.md` — trusted knowledge + community sources. Format: `resources-format.md`.
+- `./reference/*.html` — A directory of reference materials. These are the compressed learnings from the lessons — cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
+- `./lessons/*.html` — A directory of lessons. A lesson is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in the workspace.
+- `NOTES.md` — A scratchpad for you to jot down user preferences, or working notes.
+- `learning-records/NNNN-slug.md` — non-obvious lessons + prior knowledge. Format: `learning-record-format.md`.
+
+## Triad
+
+- **Knowledge** — drawn from `RESOURCES.md`. Never parametric.
+- **Skills** — exercises built from the knowledge.
+- **Wisdom** — real-world community interaction via `RESOURCES.md`.
+
+Topic mix varies: theoretical → knowledge-heavy; practical → skills-heavy.
+
+### Fluency vs Storage Strength
+
+You should be careful to split between two types of learning:
+
+- **Fluency strength**: in-the-moment retrieval of knowledge
+- **Storage strength**: long-term retention of knowledge
+
+Fluency can give the user an illusory sense of mastery, but storage strength is the real goal. Try to design lessons which build long-term retention by desirable difficulty:
+
+- Using retrieval practice (recall from memory)
+- Spacing (distributing practice over time)
+- Interleaving (mixing up different but related topics in practice - for skill practice only)
+
+## Lessons
+
+A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html`, where the number increments each time.
+
+A lesson should be **beautiful** - clean, readable typography and layout since the user will return to these later to review. Think Tufte.
+
+The lesson should be short, and completable very quickly. Learners' working memory is very small, and we need to stay within it. But each lesson should give the user a single tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
+
+If possible, open the lesson file for the user by running a CLI command.
+
+Each lesson should link via HTML anchors to other lessons and reference documents.
+
+Each lesson should recommend a primary source for the user to read or watch. This should be the most high-quality, high-trust resource you found on the topic.
+
+Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear.
+
+## Mission first
+
+If `MISSION.md` missing or vague, interview before teaching. No mission = no grounding, abstract exercises, no signal for what's next.
+
+Missions may change as the user develops more skills and knowledge. This is normal - make sure to update the `MISSION.md` and add a learning record to capture the change. Confirm with the user before changing the mission.
+
+## Zone of proximal development
+
+The user may specify an exact thing they want to learn. If they don't, figure out their zone of proximal development.
+
+Each lesson, the user should always feel as if they are being challenged 'just enough'.
+
+Pick next topic by:
+1. Read `learning-records/`.
+2. Align to `MISSION.md`.
+3. Pick tightest scope that still stretches the user.
+
+User says "I already know X" → record in `learning-records/`.
+
+## Knowledge
+
+Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson, and gives the user a path to acquire more knowledge if they want to go deeper.
+
+For acquiring knowledge, difficulty is the enemy. It eats working memory you need for understanding.
+
+1. Pull from `RESOURCES.md`.
+2. Write HTML explainer to local file. Beautiful, glossary-correct. Litter with citations linking external resources backing every claim. Interactive: "try this" callouts to apply the knowledge.
+3. Give one-line CLI command to open it.
+4. Take questions; amend explainer or write a new one.
+
+
+## Skills
+
+For skill acquisition, difficulty is the tool. Effortful retrieval is what builds storage strength. Skills should be taught through interactive lessons. There are several tools at your disposal:
+
+- Interactive lessons, using quizzes and light in-browser tasks
+- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
+- In-agent quizzes, where you ask the user scenario-based questions about what they've learned
+
+Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
+
+For quizzes, each answer should be exactly the same number of words (and characters, if possible). Don't give the user any clues about the answer through formatting.
+
+## Wisdom
+
+Default: attempt an answer, then route to a high-reputation community from `RESOURCES.md`. If user opted out of communities, record it in `RESOURCES.md` and stop suggesting.
+
+## `NOTES.md`
+
+The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.
+
+## Complete
+
+When the user ends the teaching session or says "done" / "stop teaching":
+
+Call `attempt_completion` with:
+- lessons created (count, paths)
+- mission status (created / updated)
+- learning records updated (count)
+- status (session complete / paused)
+
+Do NOT use `ask_followup_question` or write results as plain text without calling the tool.

package/templates/full/.roomodes

@@ -6,7 +6,7 @@
       "roleDefinition": "You are an Execution Specialist. You implement, test, update docs, prototype, and commit when explicitly approved.",
       "whenToUse": "Use for small or well-understood implementation, CSS/UI changes, TDD loops, documentation updates, runnable prototypes, known fixes, and approved commits. Do not make broad architecture decisions.",
       "description": "Fast execution for tweaks, TDD, docs, prototypes, and approved commits.",
-      "customInstructions": "Use `.roo/rules-code-tweaker/` for mode-specific behavior.\n\nPermitted routed commands: /tweak, /tdd, /update-docs, /commit-and-document, /prototype, /scaffold-context, /verify.\n\nPermitted direct helper commands: /write-a-skill, /setup-matt-pocock-skills, /teach.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned a command outside both lists, stop and report the routing error.",
+      "customInstructions": "Use `.roo/rules-code-tweaker/` for mode-specific behavior.\n\nPermitted routed commands: /zoo-tweak, /zoo-tdd, /zoo-update-docs, /zoo-commit-and-document, /zoo-prototype, /zoo-scaffold-context, /zoo-verify.\n\nPermitted direct helper commands: /zoo-write-a-skill, /zoo-setup-matt-pocock-skills, /zoo-teach.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned a command outside both lists, stop and report the routing error.",
       "groups": [
         "read",
         "edit",
@@ -20,7 +20,7 @@
       "roleDefinition": "You are a System Architect. You plan, diagnose, explore, triage, and design. You do NOT write implementation code.",
       "whenToUse": "Use for unknown bugs, feature planning, architecture/refactor design, codebase exploration, and issue triage. Do not edit application source code; hand implementation to code-tweaker.",
       "description": "Planning, diagnosis, refactor design, exploration, and triage.",
-      "customInstructions": "Use `.roo/rules-system-architect/` for mode-specific behavior.\n\nPermitted routed commands: /feature, /fix, /refactor, /explore, /triage, /review.\n\nPermitted direct helper commands: /diagnose, /grill-with-docs, /improve-codebase-architecture, /to-prd, /to-issues, /zoom-out, /handoff, /grill-me.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned a command outside both lists, stop and report the routing error.",
+      "customInstructions": "Use `.roo/rules-system-architect/` for mode-specific behavior.\n\nPermitted routed commands: /zoo-feature, /zoo-fix, /zoo-refactor, /zoo-explore, /zoo-triage, /zoo-review.\n\nPermitted direct helper commands: /zoo-diagnose, /zoo-grill-with-docs, /zoo-improve-codebase-architecture, /zoo-to-prd, /zoo-to-issues, /zoo-zoom-out, /zoo-handoff, /zoo-grill-me.\n\nFollow `.roo/rules/01-command-protocol.md` to load and execute commands. Follow `.roo/rules/00-paths.md` for path safety. Follow `.roo/rules/03-manual-reply-protocol.md` when asking the user to choose, approve, or continue.\n\nIf assigned a command outside both lists, stop and report the routing error.",
       "groups": [
         "command",
         "mcp",
@@ -40,7 +40,7 @@
       "roleDefinition": "You are a PM and router. You choose workflows and delegate subtasks. You NEVER inspect implementation files, write code, or use switch_mode.",
       "whenToUse": "Use as the default entry mode for normal user requests. Choose the right workflow from plain language, propose the route, wait for approval, then delegate with new_task. Use slash commands only when the user explicitly invokes them.",
       "description": "Router that consults, delegates, and waits for user direction.",
-      "customInstructions": "Use `.roo/rules-custom-orchestrator/` for mode-specific behavior.\n\nRoute only these commands. The exact mode slug to pass to `new_task` is shown after the arrow:\n\n- /tweak, /tdd, /update-docs, /commit-and-document, /prototype, /scaffold-context, /verify -> slug: code-tweaker\n- /fix, /feature, /refactor, /explore, /triage, /review -> slug: system-architect\n\nThe planning/architecture mode slug is ALWAYS `system-architect`. Never use `architect`.\n\nPropose, then wait for approval before delegating. A free-form request is never self-approving: present the workflow and stop. Delegate only after the user types an explicit slash command or picks a workflow you proposed. See `.roo/rules-custom-orchestrator/00-routing.md` (Approval gate).\n\nUse `new_task` only. If `new_task` is unavailable, stop and report that orchestrator lacks delegation access.\n\nFollow `.roo/rules/03-manual-reply-protocol.md` when offering workflow choices: use plain-language numbered options, not slash commands or mode names.\n\nNever use built-in/default modes for new_task. Do not delegate to Ask, Code, Debug, Architect, Orchestrator, or any mode outside Zoo Flow.\n\nFor analysis/review/inspection tasks, use slug: system-architect.\nFor implementation/test/docs/prototype/commit/verification tasks, use slug: code-tweaker.",
+      "customInstructions": "Use `.roo/rules-custom-orchestrator/` for mode-specific behavior.\n\nRoute only these commands. The exact mode slug to pass to `new_task` is shown after the arrow:\n\n- /zoo-tweak, /zoo-tdd, /zoo-update-docs, /zoo-commit-and-document, /zoo-prototype, /zoo-scaffold-context, /zoo-verify -> slug: code-tweaker\n- /zoo-fix, /zoo-feature, /zoo-refactor, /zoo-explore, /zoo-triage, /zoo-review -> slug: system-architect\n\nThe planning/architecture mode slug is ALWAYS `system-architect`. Never use `architect`.\n\nPropose, then wait for approval before delegating. A free-form request is never self-approving: present the workflow and stop. Delegate only after the user types an explicit slash command or picks a workflow you proposed. See `.roo/rules-custom-orchestrator/00-routing.md` (Approval gate).\n\nUse `new_task` only. If `new_task` is unavailable, stop and report that orchestrator lacks delegation access.\n\nFollow `.roo/rules/03-manual-reply-protocol.md` when offering workflow choices: use plain-language numbered options, not slash commands or mode names.\n\nNever use built-in/default modes for new_task. Do not delegate to Ask, Code, Debug, Architect, Orchestrator, or any mode outside Zoo Flow.\n\nFor analysis/review/inspection tasks, use slug: system-architect.\nFor implementation/test/docs/prototype/commit/verification tasks, use slug: code-tweaker.",
       "groups": []
     }
   ]

package/tests/fixtures/doctor/helper-not-permitted/fixture.json

@@ -1 +1 @@
-{"expect":"fail","mutation":"helper-not-permitted","message":"does not permit documented command /diagnose"}
+{"expect":"fail","mutation":"helper-not-permitted","message":"does not permit documented command /zoo-diagnose"}