@fernado03/zoo-flow 0.12.0 → 0.12.2

package/templates/claude-code/CLAUDE.md

@@ -5,7 +5,7 @@ You are part of a structured workflow system with two behavioral profiles that a
 ## Behavioral Profiles
 
 ### Architect Profile
-- **Activation**: Commands like `/fix`, `/feature`, `/refactor`, `/explore`, `/diagnose`, `/review`, `/triage`, `/grill-with-docs`, `/improve-codebase-architecture`, `/to-prd`, `/to-issues`, `/zoom-out`, `/handoff`, `/grill-me`
+- **Activation**: Commands like `/zoo-fix`, `/zoo-feature`, `/zoo-refactor`, `/zoo-explore`, `/zoo-diagnose`, `/zoo-review`, `/zoo-triage`, `/zoo-grill-with-docs`, `/zoo-improve-codebase-architecture`, `/zoo-to-prd`, `/zoo-to-issues`, `/zoo-zoom-out`, `/zoo-handoff`, `/zoo-grill-me`
 - **Scope**: Plan, diagnose, explore, refactor-design, triage, and review
 - **File access**: Read-only for application code. May edit markdown files, `.scratch/`, and `docs/`
 - **Delegation**: Use `Agent` tool to delegate implementation to implementer profile
@@ -13,7 +13,7 @@ You are part of a structured workflow system with two behavioral profiles that a
 - **Never**: Write implementation code, run tests, or make direct source changes
 
 ### Implementer Profile
-- **Activation**: Commands like `/tweak`, `/tdd`, `/update-docs`, `/commit-and-document`, `/prototype`, `/scaffold-context`, `/verify`, `/write-a-skill`, `/setup-matt-pocock-skills`, `/teach`
+- **Activation**: Commands like `/zoo-tweak`, `/zoo-tdd`, `/zoo-update-docs`, `/zoo-commit-and-document`, `/zoo-prototype`, `/zoo-scaffold-context`, `/zoo-verify`, `/zoo-write-a-skill`, `/zoo-setup-matt-pocock-skills`, `/zoo-teach`
 - **Scope**: Implement, test, update docs, prototype, and commit (after approval)
 - **File access**: Full repository access within task scope
 - **Escalation**: Use `Agent` tool to delegate architecture decisions to architect profile
@@ -28,64 +28,64 @@ When a user makes a request without a slash command, infer the best workflow and
 
 | User Request Pattern | Workflow | Command | Profile |
 |---|---|---|---|
-| "Fix bug", "Why is X broken?", "Error in..." | Diagnose and fix | `/fix` | Architect → Implementer |
-| "Add feature", "Implement X", "New capability" | Feature development | `/feature` | Architect → Implementer |
-| "Refactor", "Clean up", "Improve structure" | Refactoring | `/refactor` | Architect → Implementer |
-| "Explore codebase", "How does X work?", "Map..." | Exploration | `/explore` | Architect |
-| "Review code", "Check this PR", "Audit..." | Code review | `/review` | Architect |
-| "Triage issues", "Review tickets", "Sort bugs" | Issue triage | `/triage` | Architect |
-| "Grill design", "Challenge assumptions", "What if..." | Design validation | `/grill-with-docs` | Architect |
-| "Improve architecture", "Deepen design", "Find patterns" | Architecture improvement | `/improve-codebase-architecture` | Architect |
-| "Write PRD", "Product spec", "Requirements doc" | PRD creation | `/to-prd` | Architect |
-| "Break into issues", "Create tasks", "Slice work" | Issue creation | `/to-issues` | Architect |
-| "Zoom out", "Big picture", "Architectural view" | High-level overview | `/zoom-out` | Architect |
-| "Small change", "Quick fix", "Update this", "Change X to Y" | Direct implementation | `/tweak` | Implementer |
-| "Write tests first", "TDD", "Test-driven" | Test-driven development | `/tdd` | Implementer |
-| "Update docs", "Fix documentation", "Docs are wrong" | Documentation update | `/update-docs` | Implementer |
-| "Commit and document", "Journal this", "Document changes" | Commit workflow | `/commit-and-document` | Implementer |
-| "Prototype", "Try this out", "Experiment with" | Prototyping | `/prototype` | Implementer |
-| "Scaffold context", "Initialize docs", "Set up CONTEXT.md" | Context scaffolding | `/scaffold-context` | Implementer |
-| "Verify", "Check if tests pass", "Run validation" | Verification | `/verify` | Implementer |
-| "Caveman mode", "Be brief", "Less tokens" | Compressed communication | `/caveman` | Implementer |
+| "Fix bug", "Why is X broken?", "Error in..." | Diagnose and fix | `/zoo-fix` | Architect → Implementer |
+| "Add feature", "Implement X", "New capability" | Feature development | `/zoo-feature` | Architect → Implementer |
+| "Refactor", "Clean up", "Improve structure" | Refactoring | `/zoo-refactor` | Architect → Implementer |
+| "Explore codebase", "How does X work?", "Map..." | Exploration | `/zoo-explore` | Architect |
+| "Review code", "Check this PR", "Audit..." | Code review | `/zoo-review` | Architect |
+| "Triage issues", "Review tickets", "Sort bugs" | Issue triage | `/zoo-triage` | Architect |
+| "Grill design", "Challenge assumptions", "What if..." | Design validation | `/zoo-grill-with-docs` | Architect |
+| "Improve architecture", "Deepen design", "Find patterns" | Architecture improvement | `/zoo-improve-codebase-architecture` | Architect |
+| "Write PRD", "Product spec", "Requirements doc" | PRD creation | `/zoo-to-prd` | Architect |
+| "Break into issues", "Create tasks", "Slice work" | Issue creation | `/zoo-to-issues` | Architect |
+| "Zoom out", "Big picture", "Architectural view" | High-level overview | `/zoo-zoom-out` | Architect |
+| "Small change", "Quick fix", "Update this", "Change X to Y" | Direct implementation | `/zoo-tweak` | Implementer |
+| "Write tests first", "TDD", "Test-driven" | Test-driven development | `/zoo-tdd` | Implementer |
+| "Update docs", "Fix documentation", "Docs are wrong" | Documentation update | `/zoo-update-docs` | Implementer |
+| "Commit and document", "Journal this", "Document changes" | Commit workflow | `/zoo-commit-and-document` | Implementer |
+| "Prototype", "Try this out", "Experiment with" | Prototyping | `/zoo-prototype` | Implementer |
+| "Scaffold context", "Initialize docs", "Set up CONTEXT.md" | Context scaffolding | `/zoo-scaffold-context` | Implementer |
+| "Verify", "Check if tests pass", "Run validation" | Verification | `/zoo-verify` | Implementer |
+| "Caveman mode", "Be brief", "Less tokens" | Compressed communication | `/zoo-caveman` | Implementer |
 
 ### Decision Guide
 
 When inferring workflow, consider:
 
-1. **Is it a bug or error?** → `/fix` (diagnose first, then implement)
-2. **Is it a new feature?** → `/feature` (architect plans, implementer builds)
-3. **Is it improving existing code structure?** → `/refactor` (architect identifies improvements, implementer applies)
-4. **Is it exploratory?** → `/explore` (architect maps the territory)
-5. **Is it a code review?** → `/review` (architect evaluates)
-6. **Is it a small, well-defined change?** → `/tweak` (implementer handles directly)
-7. **Is it test-first development?** → `/tdd` (implementer writes tests, then code)
-8. **Is it documentation?** → `/update-docs` (implementer updates)
-9. **Is it committing work?** → `/commit-and-document` (implementer follows commit workflow)
-10. **Is it prototyping?** → `/prototype` (implementer builds throwaway)
+1. **Is it a bug or error?** → `/zoo-fix` (diagnose first, then implement)
+2. **Is it a new feature?** → `/zoo-feature` (architect plans, implementer builds)
+3. **Is it improving existing code structure?** → `/zoo-refactor` (architect identifies improvements, implementer applies)
+4. **Is it exploratory?** → `/zoo-explore` (architect maps the territory)
+5. **Is it a code review?** → `/zoo-review` (architect evaluates)
+6. **Is it a small, well-defined change?** → `/zoo-tweak` (implementer handles directly)
+7. **Is it test-first development?** → `/zoo-tdd` (implementer writes tests, then code)
+8. **Is it documentation?** → `/zoo-update-docs` (implementer updates)
+9. **Is it committing work?** → `/zoo-commit-and-document` (implementer follows commit workflow)
+10. **Is it prototyping?** → `/zoo-prototype` (implementer builds throwaway)
 
 ### Risk Levels
 
 Assess risk to choose appropriate workflow:
 
-- **Low risk** (typos, comments, simple renames): `/tweak`
-- **Medium risk** (single-function changes, clear requirements): `/tweak` or `/tdd`
-- **High risk** (architecture changes, cross-cutting concerns): `/fix`, `/feature`, or `/refactor`
-- **Critical risk** (security, performance, data handling): Always start with architect workflow (`/fix`, `/feature`, `/refactor`)
+- **Low risk** (typos, comments, simple renames): `/zoo-tweak`
+- **Medium risk** (single-function changes, clear requirements): `/zoo-tweak` or `/zoo-tdd`
+- **High risk** (architecture changes, cross-cutting concerns): `/zoo-fix`, `/zoo-feature`, or `/zoo-refactor`
+- **Critical risk** (security, performance, data handling): Always start with architect workflow (`/zoo-fix`, `/zoo-feature`, `/zoo-refactor`)
 
 ## Approval Gates
 
 **Critical rule**: When proposing a workflow, always wait for explicit user approval before delegating.
 
-1. **Propose**: "This sounds like it needs [workflow]. Should I proceed with `/command`?"
+1. **Propose**: "This sounds like it needs [workflow]. Should I proceed with `/zoo-[command]`?"
 2. **Wait**: Do not delegate until user confirms (e.g., "yes", "proceed", "go ahead")
 3. **Delegate**: Only after approval, use `Agent` tool with appropriate profile and command
 
 Example:
 ```
 User: "The login page is broken"
-Assistant: "This sounds like it needs diagnosis and fixing. Should I proceed with `/fix`?"
+Assistant: "This sounds like it needs diagnosis and fixing. Should I proceed with `/zoo-fix`?"
 User: "yes"
-Assistant: [delegates to architect with /fix command]
+Assistant: [delegates to architect with /zoo-fix command]
 ```
 
 Never assume approval. Never delegate without explicit confirmation.
@@ -147,7 +147,7 @@ This is similar to how ultracode's Workflow tool handles subagent completion.
 
 ### Multi-Phase Commands
 
-Commands like `/fix`, `/feature`, and `/refactor` involve multiple phases:
+Commands like `/zoo-fix`, `/zoo-feature`, and `/zoo-refactor` involve multiple phases:
 
 **Fix workflow:**
 1. Architect diagnoses the problem
@@ -203,7 +203,7 @@ When presenting options or choices:
 - Wait for numbered response: "1" or "Option A"
 
 **DON'T:**
-- Reference internal commands: "Should I use `/fix` or `/feature`?"
+- Reference internal commands: "Should I use `/zoo-fix` or `/zoo-feature`?"
 - Use profile names: "Should the architect or implementer handle this?"
 - Assume approval: Never delegate without explicit confirmation
 
@@ -229,24 +229,15 @@ When using tools:
 6. **Never delete branches**: Let users manage branch lifecycle
 7. **Never modify protected files**: Respect `.gitignore` and security-sensitive files
 
-### MCP Awareness
-
-If MCP (Model Context Protocol) servers are available:
-
-1. **Check available tools**: Use `mcp_list_tools` to see what's available
-2. **Use when appropriate**: Prefer MCP tools when they're more efficient (e.g., database queries, API calls)
-3. **Fall back gracefully**: If MCP tools fail, use standard Claude Code tools
-4. **Don't assume**: Not all environments have MCP servers configured
-
 ## Quick Start
 
-1. **First session**: Run `/scaffold-context` to initialize project documentation
-2. **Small changes**: Use `/tweak` for quick fixes and updates
-3. **Bug fixes**: Use `/fix` for diagnosis and repair
-4. **New features**: Use `/feature` for planned implementation
-5. **Refactoring**: Use `/refactor` for structural improvements
-6. **Exploration**: Use `/explore` to understand unfamiliar code
-7. **Reviews**: Use `/review` before committing significant changes
+1. **First session**: Run `/zoo-scaffold-context` to initialize project documentation
+2. **Small changes**: Use `/zoo-tweak` for quick fixes and updates
+3. **Bug fixes**: Use `/zoo-fix` for diagnosis and repair
+4. **New features**: Use `/zoo-feature` for planned implementation
+5. **Refactoring**: Use `/zoo-refactor` for structural improvements
+6. **Exploration**: Use `/zoo-explore` to understand unfamiliar code
+7. **Reviews**: Use `/zoo-review` before committing significant changes
 
 ## Workflow Philosophy
 

package/templates/full/.roo/commands/zoo-caveman.md

@@ -1,5 +1,5 @@
 ---
-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."
+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 /zoo-caveman."
 ---
 
 Skill: `.roo/skills/productivity/caveman/SKILL.md`

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

@@ -1,5 +1,5 @@
 ---
-description: "Explore unfamiliar code before /feature, /refactor, or /fix. Produces written map."
+description: "Explore unfamiliar code before /zoo-feature, /zoo-refactor, or /zoo-fix. Produces written map."
 argument-hint: <feature or folder to map>
 mode: system-architect
 ---
@@ -9,10 +9,10 @@ Explore unfamiliar code and produce a written map. Follow the skill exactly.
 Skill: `.roo/skills/engineering/zoom-out/SKILL.md`
 
 EXECUTION RULES:
-1. READ `.zoo-flow/CONTEXT.md`. If it does not exist, output one line before step 2: "No CONTEXT.md found. Run /scaffold-context to fill, or continue without." Do not invent content.
+1. READ `.zoo-flow/CONTEXT.md`. If it does not exist, output one line before step 2: "No CONTEXT.md found. Run /zoo-scaffold-context to fill, or continue without." Do not invent content.
 2. OUTPUT MAP: Create markdown with sections: Domain language, Modules, Data flow, Seams/callers, ADRs, Open questions. Derive slug from the target area (e.g. "auth module" → `auth-module.md`). Write to `.scratch/explorations/<YYYY-MM-DD>/<slug>.md`.
 3. WRITE POINTER: Write the exact file path to `.scratch/LAST-EXPLORATION.md` so next commands can find it.
-4. NEXT STEPS: Suggest `/scaffold-context`, `/feature`, `/refactor`, or `/fix`. DO NOT auto-launch.
+4. NEXT STEPS: Suggest `/zoo-scaffold-context`, `/zoo-feature`, `/zoo-refactor`, or `/zoo-fix`. DO NOT auto-launch.
 5. COMPLETION: Call `attempt_completion` with the exact file path, status, and recommended next command. Do NOT use `ask_followup_question` or write results as plain text.
 
 $ARGUMENTS

package/templates/full/.roo/commands/zoo-feature.md

@@ -17,6 +17,6 @@ EXECUTION RULES (Run sequentially. Wait for user between phases):
 5. IMPLEMENT (Tweaker):
    - Architect summarizes issues.
    - Architect MUST `switch_mode` -> `code-tweaker`.
-   - Tweaker: For each issue, execute the `/tdd` command workflow (per `.roo/rules/01-command-protocol.md`). After each ships, suggest `/verify`, then `/review` (requires `switch_mode` back to system-architect), then `/commit-and-document`. Do not auto-launch.
+   - Tweaker: For each issue, execute the `/zoo-tdd` command workflow (per `.roo/rules/01-command-protocol.md`). After each ships, suggest `/zoo-verify`, then `/zoo-review` (requires `switch_mode` back to system-architect), then `/zoo-commit-and-document`. Do not auto-launch.
 
 $ARGUMENTS

package/templates/full/.roo/commands/zoo-fix.md

@@ -14,7 +14,7 @@ EXECUTION RULES:
    - Architect MUST `switch_mode` -> `code-tweaker`.
    - Tweaker executes phase 5 (Fix + test).
    - Tweaker MUST `switch_mode` -> `system-architect`.
-4. POST-MORTEM (Architect): Execute Phase 6. If architectural rot, suggest `/refactor`.
-5. FOLLOW-UP (Architect): Suggest `/verify`, then `/review`, then `/commit-and-document`. Do not auto-launch. Call `attempt_completion` with diagnosis summary, fix applied, post-mortem findings, and recommended next command.
+4. POST-MORTEM (Architect): Execute Phase 6. If architectural rot, suggest `/zoo-refactor`.
+5. FOLLOW-UP (Architect): Suggest `/zoo-verify`, then `/zoo-review`, then `/zoo-commit-and-document`. Do not auto-launch. Call `attempt_completion` with diagnosis summary, fix applied, post-mortem findings, and recommended next command.
 
 $ARGUMENTS

package/templates/full/.roo/commands/zoo-refactor.md

@@ -13,8 +13,8 @@ EXECUTION RULES:
 3. EXECUTE (Tweaker):
    - Architect summarizes approved plan.
    - Architect MUST `switch_mode` -> `code-tweaker`.
-   - Tweaker executes the `/tdd` command workflow (per `.roo/rules/01-command-protocol.md`) — new tests at interface, delete old.
-   - Tweaker suggests `/verify`, then `/review` (requires `switch_mode` back to system-architect), then `/commit-and-document`. Do not auto-launch.
+   - Tweaker executes the `/zoo-tdd` command workflow (per `.roo/rules/01-command-protocol.md`) — new tests at interface, delete old.
+   - Tweaker suggests `/zoo-verify`, then `/zoo-review` (requires `switch_mode` back to system-architect), then `/zoo-commit-and-document`. Do not auto-launch.
    - Tweaker calls `attempt_completion` with: what was refactored, files changed, tests added, status, and recommended next command.
 
 $ARGUMENTS

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

@@ -12,10 +12,10 @@ Find the target doc in `.zoo-flow/` or `docs/`. If it does not exist, ask once:
 
 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`
+- Domain glossary terms — use `/zoo-grill-with-docs`
+- ADRs — use `/zoo-grill-with-docs` or `/zoo-refactor`
+- Local commit journal entries — use `/zoo-commit-and-document`
+- Read-only understanding — use `/zoo-explore`
 
 If `$ARGUMENTS` is empty, ask once: "Which documentation file or area should I update?"
 

package/templates/full/.roo/rules/03-manual-reply-protocol.md

@@ -20,7 +20,7 @@ Safe suggestions:
 
 Unsafe suggestions:
 
-- `/tweak`
+- `/zoo-tweak`
 - `Switch to code-tweaker`
 - `Route to system-architect`
 - `Fix it → code`

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

@@ -21,7 +21,7 @@ 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 (e.g. `/feature`, `/refactor`, `/grill-with-docs`, `/scaffold-context`, `/update-docs`, `/tdd`).
+- The command explicitly requires those docs (e.g. `/zoo-feature`, `/zoo-refactor`, `/zoo-grill-with-docs`, `/zoo-scaffold-context`, `/zoo-update-docs`, `/zoo-tdd`).
 - The user asks for documentation, architecture, product, or domain-context work.
 
 Missing CONTEXT.md or ADRs is not an error. Proceed silently when nothing is present.

package/templates/full/.roo/rules-code-tweaker/01-completion.md

@@ -16,7 +16,7 @@ Before any `attempt_completion`, re-read the command body and confirm no later p
 `attempt_completion` is a tool call with a `result` parameter. You MUST call it as a tool, not as plain text. Example:
 
 ```
-attempt_completion(result="Done. Changed X in file Y. Status: complete. Next: /verify")
+attempt_completion(result="Done. Changed X in file Y. Status: complete. Next: /zoo-verify")
 ```
 
 Do NOT:
@@ -38,6 +38,6 @@ Write long output (verification report, diff summary) to `.scratch/` with a desc
 
 Before running `git commit` or `git push`, halt and wait for explicit user approval. Never push unless explicitly asked.
 
-For non-trivial `/tdd`, `/fix`, `/feature`, `/refactor`, or R3+ `/tweak` work, recommend `/verify` before `/review` before `/commit-and-document`. Do not auto-launch those commands.
+For non-trivial `/zoo-tdd`, `/zoo-fix`, `/zoo-feature`, `/zoo-refactor`, or R3+ `/zoo-tweak` work, recommend `/zoo-verify` before `/zoo-review` before `/zoo-commit-and-document`. Do not auto-launch those commands.
 
-If the user explicitly says to remember a project rule, or the same mistake has repeated, ask before appending a short lesson to `.zoo-flow/LESSONS.md`. Do not read or write lessons by default.
+If the user explicitly says to remember a project rule, or the same mistake has repeated, ask before appending a short lesson to `.zoo-flow/LESSONS.md`. Do not read or write lessons by default.

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

@@ -30,7 +30,7 @@ If neither custom mode is suitable, stop and report that no valid Zoo Flow mode
 
 ## Slash command handling
 
-When the user types a slash command (e.g. `/tweak`, `/explore`), the extension reads the `mode:` frontmatter from the command file and auto-switches to that mode. The orchestrator does not route slash commands — the extension handles it.
+When the user types a slash command (e.g. `/zoo-tweak`, `/zoo-explore`), the extension reads the `mode:` frontmatter from the command file and auto-switches to that mode. The orchestrator does not route slash commands — the extension handles it.
 
 The orchestrator only routes **free-form requests** (natural language without a leading `/`).
 

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

@@ -50,17 +50,17 @@ 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
-- `/verify`: proceed automatically after changed scope and project checks are identified; report exact commands run
-- `/review`: stop and report only; do not patch application source
-- `/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
-
-Do not auto-launch `/verify`, `/review`, or `/commit-and-document` merely because a worker recommended it. Suggest only; wait for explicit approval.
+- `/zoo-tweak`: proceed automatically after audit if clean
+- `/zoo-tdd`: proceed automatically after audit if clean, unless the public interface, expected behavior, or test target is unclear
+- `/zoo-explore`: proceed automatically; ask only if the target area is ambiguous
+- `/zoo-update-docs`: proceed automatically after audit if the target doc/area is clear; ask if unclear
+- `/zoo-prototype`: proceed automatically if prototype branch is clear; ask if logic vs UI is ambiguous
+- `/zoo-verify`: proceed automatically after changed scope and project checks are identified; report exact commands run
+- `/zoo-review`: stop and report only; do not patch application source
+- `/zoo-fix`: ask after reproduced hypotheses before instrumentation/fix
+- `/zoo-feature`: ask at phase gates: Prototype/PRD, prototype verdict, slice approval, issue approval
+- `/zoo-refactor`: ask before selecting a candidate and before implementation
+- `/zoo-triage`: ask before publishing, closing, labeling, or making irreversible tracker changes unless the user explicitly requested it
+- `/zoo-commit-and-document`: always ask before `git commit`, `git push`, or issue close actions
+
+Do not auto-launch `/zoo-verify`, `/zoo-review`, or `/zoo-commit-and-document` merely because a worker recommended it. Suggest only; wait for explicit approval.

package/templates/full/.roo/rules-system-architect/01-feature-prototype.md

@@ -1,10 +1,10 @@
 # Feature Prototype Handoff
 
-During `/feature`, do not run prototype implementation directly.
+During `/zoo-feature`, do not run prototype implementation directly.
 
 If the user chooses Prototype:
 
 1. Summarize the prototype question and constraints.
 2. Use `switch_mode` to `code-tweaker`.
-3. Have `code-tweaker` execute `/prototype`.
+3. Have `code-tweaker` execute `/zoo-prototype`.
 4. Resume architecture flow after the prototype result returns.

package/templates/full/.roo/rules-system-architect/02-completion.md

@@ -14,7 +14,7 @@ NEVER call `switch_mode` to the built-in `code`, `Code`, `ask`, `Ask`, `debug`,
 
 - **More phases remain** (this or a later phase is assigned to `code-tweaker`, or control returns to you afterward): use `switch_mode` to `code-tweaker` (exact slug, never `code`). Never `attempt_completion` mid-chain. Writing a plan, diagnosis, or `.scratch/` notes is not "done" — it is a handoff. Switch to `code-tweaker` to implement.
 - **You are running the command's final phase** and it is complete or blocked: use `attempt_completion` to return to the orchestrator.
-- **Standalone command with no implementation phase** (e.g. `/review`, `/explore`, `/grill-with-docs`, `/triage`): use `attempt_completion` with the recommended next command.
+- **Standalone command with no implementation phase** (e.g. `/zoo-review`, `/zoo-explore`, `/zoo-grill-with-docs`, `/zoo-triage`): use `attempt_completion` with the recommended next command.
 
 If you entered this window via `switch_mode` (you are mid-chain, not the entry point) and any phase remains, you hand back with `switch_mode`. Only the command's final phase returns to the orchestrator.
 
@@ -25,7 +25,7 @@ Before any `attempt_completion`, re-read the command body and confirm no later p
 `attempt_completion` is a tool call with a `result` parameter. You MUST call it as a tool, not as plain text. Example:
 
 ```
-attempt_completion(result="Done. Explored X. Status: complete. Next: /feature")
+attempt_completion(result="Done. Explored X. Status: complete. Next: /zoo-feature")
 ```
 
 Do NOT:
@@ -40,6 +40,6 @@ Do not use `attempt_completion` to avoid required implementation work. Write the
 
 Halt for explicit user approval before testing a bug hypothesis, finalizing an architecture plan, publishing issues, or making irreversible decisions.
 
-For non-trivial completed plans or reviews, recommend the next command only. Typical chain: implementation command -> `/verify` -> `/review` -> `/commit-and-document`. Do not auto-launch those commands.
+For non-trivial completed plans or reviews, recommend the next command only. Typical chain: implementation command -> `/zoo-verify` -> `/zoo-review` -> `/zoo-commit-and-document`. Do not auto-launch those commands.
 
 If the user explicitly says to remember a project rule, or the same mistake has repeated, ask before appending a short lesson to `.zoo-flow/LESSONS.md`. Do not read or write lessons by default.

package/templates/full/.roo/skills/docs/adr/0001-explicit-setup-pointer-only-for-hard-dependencies.md

@@ -1,13 +1,13 @@
 # ADR-0001: Explicit setup pointer only for hard dependencies
 
-RULE: explicit `/setup-matt-pocock-skills` pointer only for hard deps.
+RULE: explicit `/zoo-setup-matt-pocock-skills` pointer only for hard deps.
 
 MUST include pointer:
 - `to-issues`
 - `to-prd`
 - `triage`
 
-Required wording: mapping/config should exist; run `/setup-matt-pocock-skills` if missing.
+Required wording: mapping/config should exist; run `/zoo-setup-matt-pocock-skills` if missing.
 
 MUST NOT include pointer:
 - `diagnose`

package/templates/full/.roo/skills/engineering/README.md

@@ -11,4 +11,4 @@
 - **[zoom-out](./zoom-out/SKILL.md)** — Map modules/callers.
 - **[prototype](./prototype/SKILL.md)** — Throwaway logic/UI prototype.
 - **[review](./review/SKILL.md)** — Diff/branch review against spec and standards.
-- **[verify](./verify/SKILL.md)** — Targeted tests/typecheck/lint/build evidence.
+- **[verify](./verify/SKILL.md)** — Targeted tests/typecheck/lint/build evidence.

package/templates/full/.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md

@@ -32,4 +32,4 @@ _Avoid_: Purchase, transaction
 ## Discovery rule
 
 1. If the file exists, read it.
-2. If the file is missing, that is **not an error**. Do not invent content. Surface once: "No CONTEXT.md found. Run /scaffold-context to fill, or continue without."
+2. If the file is missing, that is **not an error**. Do not invent content. Surface once: "No CONTEXT.md found. Run /zoo-scaffold-context to fill, or continue without."

package/templates/full/.roo/skills/engineering/scaffold-context/templates/writing-patterns.md

@@ -13,5 +13,5 @@ This pack adds structured writing workflows:
 - **Beats** — narrative/argument sequencing patterns
 - **Fragments** — reusable content components
 
-None of these are activated by default. Run `/scaffold-context` and
+None of these are activated by default. Run `/zoo-scaffold-context` and
 select "writing-patterns" to install.

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

@@ -16,5 +16,5 @@ See `.roo/skills/engineering/grill-with-docs/CONTEXT-FORMAT.md` for layout and d
 
 - Use glossary vocabulary in outputs/tests/issues/hypotheses.
 - Avoid `_Avoid_` synonyms.
-- If term missing, reconsider wording or note `/grill-with-docs` gap.
+- If term missing, reconsider wording or note `/zoo-grill-with-docs` gap.
 - If output contradicts ADR, surface conflict.

package/templates/full/.zoo-flow/CONTEXT.md

@@ -1,5 +1,5 @@
 # Context
-<!-- Domain language, terms, and ambiguities for this project. Run /grill-with-docs to fill. -->
+<!-- Domain language, terms, and ambiguities for this project. Run /zoo-grill-with-docs to fill. -->
 
 ## Language
 <!-- Term: 1-2 sentence definition. _Avoid_: aliases. -->

package/templates/full/.zoo-flow/START_HERE.md

@@ -4,5 +4,5 @@
 
 1. Reload VS Code and open Zoo Code.
 2. Switch to **Custom Orchestrator** mode.
-3. Run `/scaffold-context` for an existing project, or `/setup-matt-pocock-skills` if using PRDs, issue slicing, or triage.
+3. Run `/zoo-scaffold-context` for an existing project, or `/zoo-setup-matt-pocock-skills` if using PRDs, issue slicing, or triage.
 4. Then describe tasks normally.

package/templates/full/.zoo-flow/evals/no-regression-checklist.md

@@ -20,9 +20,9 @@ Before accepting workflow changes, verify:
 - [ ] README links to `.zoo-flow/START_HERE.md`.
 - [ ] README does not duplicate the full Zoo Flow onboarding guide.
 - [ ] `.zoo-flow/START_HERE.md` remains the source of truth for first-run initialization.
-- [ ] First-run guidance explains `/scaffold-context` and `/setup-matt-pocock-skills`.
+- [ ] First-run guidance explains `/zoo-scaffold-context` and `/zoo-setup-matt-pocock-skills`.
 - [ ] Custom Orchestrator never delegates to built-in/default Ask mode.
-- [ ] Analysis, review, inspection, and safety-check subtasks route to `system-architect`.
-- [ ] Implementation, tests, docs, prototype, and commit subtasks route to `code-tweaker`.
-- [ ] Verification requests route to `code-tweaker`.
-- [ ] Non-trivial work suggests `/verify` and `/review` before `/commit-and-document` but does not auto-launch them.
+- [ ] Analysis, review, inspection, and safety-check subtasks route to `system-architect`.
+- [ ] Implementation, tests, docs, prototype, and commit subtasks route to `code-tweaker`.
+- [ ] Verification requests route to `code-tweaker`.
+- [ ] Non-trivial work suggests `/zoo-verify` and `/zoo-review` before `/zoo-commit-and-document` but does not auto-launch them.

package/templates/full/.zoo-flow/evals/routing-cases.md

@@ -67,7 +67,7 @@ Expected:
 Recommend exploration first.
 
 Must:
-- Produce a map before choosing feature/fix/refactor.
+- Produce a map before choosing zoo-feature/zoo-fix/zoo-refactor.
 
 ## Case 6 — Known mechanical fix
 
@@ -142,7 +142,7 @@ Must:
 ## Case 12 — Explicit slash command
 
 User:
-"/tweak rename the cancel button to close."
+"/zoo-tweak rename the cancel button to close."
 
 Expected:
 Route immediately. Do not second-guess the explicit command.
@@ -178,12 +178,12 @@ Good response:
 2. Explore the area first"
 
 Must not:
-- Say "use `/tweak`" in the user-facing recommendation.
-- Offer `/tweak` as a selectable option.
+- Say "use `/zoo-tweak`" in the user-facing recommendation.
+- Offer `/zoo-tweak` as a selectable option.
 - Tell the user to type a slash command.
 
 Allowed:
-- Internally delegate using `/tweak` after the user approves.
+- Internally delegate using `/zoo-tweak` after the user approves.
 - Mention slash commands only if the user explicitly asks for command syntax.
 
 ## Case — Deep inspection must not route to Ask mode
@@ -198,30 +198,30 @@ Delegation target after approval:
 `system-architect`
 
 Must not:
-- Delegate to Ask mode.
-- Delegate to default Architect mode.
-- Use any mode other than `system-architect` or `code-tweaker`.
-
-## Case — Review
-
-User:
-"Review this branch before I commit it."
-
-Expected:
-Recommend the review workflow.
-
-Must:
-- Route to `system-architect` after approval.
-- Report findings by severity.
-
-## Case — Verification
-
-User:
-"Run tests for this change and make sure nothing broke."
-
-Expected:
-Recommend the verification workflow.
-
-Must:
-- Route to `code-tweaker` after approval.
-- Report exact commands run and results.
+- Delegate to Ask mode.
+- Delegate to default Architect mode.
+- Use any mode other than `system-architect` or `code-tweaker`.
+
+## Case — Review
+
+User:
+"Review this branch before I commit it."
+
+Expected:
+Recommend the review workflow.
+
+Must:
+- Route to `system-architect` after approval.
+- Report findings by severity.
+
+## Case — Verification
+
+User:
+"Run tests for this change and make sure nothing broke."
+
+Expected:
+Recommend the verification workflow.
+
+Must:
+- Route to `code-tweaker` after approval.
+- Report exact commands run and results.

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"}