@fernado03/zoo-flow 0.11.3 → 0.12.0

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

@@ -1,47 +1,47 @@
----
-name: prototype
-description: Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
----
-
-# Prototype
-
-RULE: Prototype answers one question. Throw away or absorb after answer.
-
-## Branch
-
-- Logic/state/data-model → `LOGIC.md`.
-- Visual/layout/UI → `UI.md`.
-- Ambiguous → ask.
-- User AFK → infer + state assumption.
-
-## 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.
-
-## Rules
-
-1. Mark throwaway clearly.
-2. Place under `.scratch/prototypes/<slug>/` (logic/state/data-model) or near the real module/page (UI). UI prototypes need the real route, data fetching, and auth, so they stay adjacent to the page they mock up; logic prototypes have no such constraint, so they go in `.scratch/` with the other throwaway work.
-3. Follow existing routing/tooling.
-4. Provide one run command.
-5. Default no persistence; state in memory.
-6. Persistence target → scratch DB/file named `PROTOTYPE — wipe me` in the prototype folder.
-7. No polish: no tests, minimal errors, no abstractions.
-8. Surface full relevant state after each action/variant switch.
-9. Done → capture answer in commit (only after explicit user approval)/ADR/issue/`NOTES.md`; delete or fold into real code.
-
-## Complete
-
-Call `attempt_completion` with:
-- question answered
-- prototype location (`.scratch/prototypes/<slug>/` or real module path)
-- outcome (absorbed / discarded / needs decision)
-- recommended next command
-
-Do NOT end the task with `ask_followup_question` or write results as plain text without calling the tool.
+---
+name: prototype
+description: Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
+---
+
+# Prototype
+
+RULE: Prototype answers one question. Throw away or absorb after answer.
+
+## Branch
+
+- Logic/state/data-model → `LOGIC.md`.
+- Visual/layout/UI → `UI.md`.
+- Ambiguous → ask.
+- User AFK → infer + state assumption.
+
+## 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.
+
+## Rules
+
+1. Mark throwaway clearly.
+2. Place under `.scratch/prototypes/<slug>/` (logic/state/data-model) or near the real module/page (UI). UI prototypes need the real route, data fetching, and auth, so they stay adjacent to the page they mock up; logic prototypes have no such constraint, so they go in `.scratch/` with the other throwaway work.
+3. Follow existing routing/tooling.
+4. Provide one run command.
+5. Default no persistence; state in memory.
+6. Persistence target → scratch DB/file named `PROTOTYPE — wipe me` in the prototype folder.
+7. No polish: no tests, minimal errors, no abstractions.
+8. Surface full relevant state after each action/variant switch.
+9. Done → capture answer in commit (only after explicit user approval)/ADR/issue/`NOTES.md`; delete or fold into real code.
+
+## Complete
+
+Call `attempt_completion` with:
+- question answered
+- prototype location (`.scratch/prototypes/<slug>/` or real module path)
+- outcome (absorbed / discarded / needs decision)
+- recommended next command
+
+Do NOT end the task with `ask_followup_question` or write results as plain text without calling the tool.

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

@@ -41,7 +41,7 @@ Read relevant specs, issues, PRDs, standards, docs, ADRs, security notes, or pro
 
 ## 3. Review axes (multi-pass with working memory)
 
-Initialize session: `.scratch/reviews/<YYYY-MM-DD>/review-<slug>/`
+Initialize session: `.scratch/reviews/<YYYY-MM-DD>/zoo-review-<slug>/`
 
 Write `<session-dir>/session.md` with review target, base ref, scope.
 
@@ -136,11 +136,11 @@ Do NOT use `ask_followup_question` or write results as plain text without callin
 
 If fixes are needed, recommend one next command only:
 
-- small fix -> `/tweak`
-- behavior fix -> `/tdd`
-- unknown cause -> `/fix`
-- design issue -> `/refactor`
-- ready for evidence -> `/verify`
-- ready to commit -> `/commit-and-document`
+- small fix -> `/zoo-tweak`
+- behavior fix -> `/zoo-tdd`
+- unknown cause -> `/zoo-fix`
+- design issue -> `/zoo-refactor`
+- ready for evidence -> `/zoo-verify`
+- ready to commit -> `/zoo-commit-and-document`
 
 Do not auto-launch any follow-up command.

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

@@ -1,228 +1,228 @@
----
-name: scaffold-context
-description: Bootstrap .zoo-flow/CONTEXT.md from an existing codebase by detecting project shape and scanning for domain terms and cross-cutting decisions. Proposes 5-12 terms + 0-2 ADRs, asks for confirm before writing. Use on projects with no CONTEXT.md, or to expand a thin one.
----
-
-# Scaffold Context
-
-## Loop
-
-1. Read existing context via slot discovery rule (see `CONTEXT-FORMAT.md`).
-2. Detect project shape (see Detection).
-3. Scan codebase for terms (see Detection).
-4. Propose 5-12 terms with one-line definitions + evidence (file:line counts).
-5. Show inline, ask: confirm / edit / cancel.
-6. On confirm, write to `.zoo-flow/CONTEXT.md` (preserve any existing entries in merge mode).
-7. If 1-2 cross-cutting decisions are visible in code, propose ADRs (see ADR gate).
-8. Show ADR draft(s) inline, ask confirm per ADR.
-9. On confirm, write to `.zoo-flow/docs/adr/NNNN-slug.md` using `ADR-FORMAT.md` numbering.
-10. Report what was written, with file paths.
-
-## Detection
-
-### Step 1: Detect project shape
-
-Inspect (in order):
-- `package.json` `keywords`, `name`, `scripts` (Node/JS)
-- `pyproject.toml` / `setup.py` / `setup.cfg` (Python)
-- `Cargo.toml` (Rust)
-- `go.mod` (Go)
-- Top-level folder names
-- `README.md` first paragraph
-
-Pick the dominant shape:
-
-| Signal folders / files | Shape | Priority sources for terms |
-|---|---|---|
-| `app/`, `pages/`, `routes/`, `controllers/`, `api/` | web app | API routes, page names, URL paths, model types |
-| `lib/`, `pkg/`, `src/` (no `app/`) | library | exported types, public API surface |
-| `cmd/`, `bin/`, `commands/`, `cli/` | CLI tool | subcommand names, flag names |
-| `workers/`, `jobs/`, `tasks/`, `etl/`, `pipelines/` | data pipeline | job/queue/event names |
-| `services/`, `lambda/`, `functions/`, `handlers/` | serverless | function names, event sources, triggers |
-| `services/` + `web/` + `workers/` | monorepo | treat each top-level as a sub-shape; ask user if unclear |
-
-If signals are mixed, prefer the shape that owns the entry point (`main.*`, `index.*`, `server.*`).
-
-### Step 2: Extract candidate terms
-
-For the chosen shape, prefer:
-- **Web app**: route paths (`/accounts/:id`), controller class names, view/component names
-- **Library**: exported type/class/interface names
-- **CLI**: subcommand names, top-level argument names
-- **Data pipeline**: job names, queue names, event types
-- **Serverless**: function names, event source names
-
-Universal signals (any shape):
-- Type/class/struct/interface definitions with noun names
-- Database table/model names (migrations, `schema.prisma`, `models/`, SQL files)
-- Top-level module/folder names that are nouns
-- README/docs that state purpose ("we manage X for Y")
-
-### Step 3: Filter
-
-Drop without showing:
-- Generic: `utils`, `helpers`, `common`, `base`, `lib`, `core`, `misc`, `types`, `models`, `helpers`, `shared`, `internal`, `errors`, `tests`
-- Single-letter or unexpanded acronym: `T`, `M`, `VM`, `DTO` (unless defined in code)
-- Already-defined terms in existing `CONTEXT.md` (merge mode)
-- Framework-required boilerplate: `App`, `Server`, `Router`, `Config`
-
-Keep candidates that:
-- Appear in 2+ distinct files OR
-- Appear in 1 file but are central (entry point, root config, README)
-- Are domain nouns (Account, Order, Tenant, Invoice) over technical nouns (Worker, Queue)
-
-### Step 4: Score and rank
-
-For each kept candidate, count:
-- Type/def files where it appears
-- Route/file references
-- DB schema references
-
-Take the top 5-12. Show the count in the proposal so the user can judge.
-
-## ADR gate
-
-Propose an ADR only if ALL:
-- You can point at code: a single pattern/import/module used across N+ files
-- The pattern is not obvious from the framework (e.g. "uses Express" is obvious, "all errors go through `Result<T, AppError>`" is not)
-- A reasonable engineer would be surprised to learn it from scratch
-- It maps to `ADR-FORMAT.md` "Qualifies" criteria (hard to reverse, real trade-off)
-
-Do NOT propose ADRs for:
-- Framework defaults
-- Single-file patterns
-- Speculative "this might be a decision" guesses
-- Anything where the README doesn't hint at reasoning
-
-Cap at 0-2 ADRs per scaffold. Zero is fine. Better to ship no ADR than a wrong one.
-
-## Context-pack selector
-
-After detecting project shape and proposing CONTEXT.md terms + ADRs, recommend the smallest useful set of optional context docs.
-
-Rules:
-
-- Templates live under `.roo/skills/engineering/scaffold-context/templates/` (candidates only, never installed by default).
-- Missing optional docs are **not an error**.
-- Recommend a doc only when code evidence shows it would change future agent behavior.
-- Prefer one compact doc over many thin docs.
-- Better to create zero optional docs than wrong docs.
-- Ask for confirmation before writing any optional doc.
-
-Consider optional docs only with code evidence:
-
-| Doc | When to recommend |
-|---|---|
-| `TESTING.md` | unusual verification setup, multiple test layers, important seams |
-| `DATA_MODEL.md` | schemas, lifecycle states, ownership, migrations visible in code |
-| `API_CONTRACTS.md` | public routes, SDK exports, webhooks, event payloads |
-| `RUNBOOK.md` | deploys, jobs, queues, cron, recovery procedures |
-| `SECURITY_NOTES.md` | auth, permissions, tenant isolation, secrets, payments |
-| `INTEGRATIONS.md` | third-party APIs, OAuth, Stripe, email, queues, LLM providers |
-| `MONOREPO_MAP.md` | multiple apps/packages/services with different responsibilities |
-
-### Output shape
-
-```
-## Suggested context pack
-
-Detected shape: <shape>
-
-Recommended:
-1. `.zoo-flow/CONTEXT.md`
-   Reason: repeated domain terms found.
-2. `.zoo-flow/DATA_MODEL.md`
-   Reason: schema migration logic found in 4 files.
-
-Maybe:
-1. `.zoo-flow/SECURITY_NOTES.md`
-   Reason: auth middleware exists, but permission model appears simple.
-
-Skipped:
-- `RUNBOOK.md` — no deployment or operational recovery surface found.
-- `DATA_MODEL.md` — schema is simple; terms fit in CONTEXT.md.
-
-Choose:
-1. Create recommended only
-2. Choose manually
-3. Cancel
-```
-
-### Selection matrix by shape
-
-| Shape | Likely recommended | Likely maybe | Likely skipped |
-|---|---|---|---|
-| web app | CONTEXT.md | SECURITY_NOTES.md, INTEGRATIONS.md | RUNBOOK.md, MONOREPO_MAP.md |
-| library | CONTEXT.md, API_CONTRACTS.md | TESTING.md | RUNBOOK.md, MONOREPO_MAP.md |
-| CLI tool | CONTEXT.md | RUNBOOK.md | DATA_MODEL.md, MONOREPO_MAP.md |
-| data pipeline | CONTEXT.md, DATA_MODEL.md | RUNBOOK.md | API_CONTRACTS.md |
-| serverless | CONTEXT.md, INTEGRATIONS.md | SECURITY_NOTES.md | MONOREPO_MAP.md |
-| monorepo | CONTEXT.md, MONOREPO_MAP.md | INTEGRATIONS.md, API_CONTRACTS.md | RUNBOOK.md |
-
-Do not let this selector delay the core CONTEXT.md + ADR proposal. Present the pack selection after the main confirm flow.
-
-## MUST
-
-- Ask confirm before writing `CONTEXT.md` (show full proposed list + diff against existing)
-- Ask confirm per ADR before writing
-- Ask confirm per optional doc before writing
-- Never overwrite non-empty `CONTEXT.md` without explicit "replace"
-- Never invent cross-cutting decisions; only propose ADRs you can point at code
-- Keep `CONTEXT.md` glossary-only; no impl/spec notes
-- Use `ADR-FORMAT.md` for any proposed ADR (template + numbering)
-- Report file paths and section headers at the end
-- In merge mode, append new terms below existing ones; do not reorder
-
-## Context economy
-
-Before broad reads, locate candidates with `list_files`, `search_files`, or `codebase_search`.
-
-Prefer targeted `read_file` ranges or block reads once the candidate 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.
-
-## Output shape (for the inline confirm step)
-
-```
-## Proposed CONTEXT.md entries (N)
-
-1. **Account** — a tenant-scoped record of a customer relationship.
-   Evidence: 12 type defs, 4 routes, 1 DB table.
-2. **Order** — a request to purchase one or more SKUs.
-   Evidence: 8 type defs, 3 routes, 1 DB table.
-...
-
-Confirm? (yes / edit / cancel)
-```
-
-```
-## Proposed ADR (1 of N)
-
-# Use Result type for all fallible operations
-
-We use a Rust-style `Result<T, AppError>` for all operations that can
-fail, instead of throwing exceptions. This is enforced by a linter
-rule and visible in every service module.
-
-Considered Options:
-- Exceptions
-- Error codes (Go-style)
-- Result type (chosen)
-
-Consequences: easier to reason about error paths; verbose for happy
-paths.
-
-Confirm? (yes / edit / cancel)
-```
-
-## Complete
-
-Call `attempt_completion` with:
-- file paths written (CONTEXT.md, ADRs, optional docs)
-- terms added (count)
-- status (complete / blocked with reason)
-- recommended next command
-
-Do NOT use `ask_followup_question` or write results as plain text without calling the tool.
+---
+name: scaffold-context
+description: Bootstrap .zoo-flow/CONTEXT.md from an existing codebase by detecting project shape and scanning for domain terms and cross-cutting decisions. Proposes 5-12 terms + 0-2 ADRs, asks for confirm before writing. Use on projects with no CONTEXT.md, or to expand a thin one.
+---
+
+# Scaffold Context
+
+## Loop
+
+1. Read existing context via slot discovery rule (see `CONTEXT-FORMAT.md`).
+2. Detect project shape (see Detection).
+3. Scan codebase for terms (see Detection).
+4. Propose 5-12 terms with one-line definitions + evidence (file:line counts).
+5. Show inline, ask: confirm / edit / cancel.
+6. On confirm, write to `.zoo-flow/CONTEXT.md` (preserve any existing entries in merge mode).
+7. If 1-2 cross-cutting decisions are visible in code, propose ADRs (see ADR gate).
+8. Show ADR draft(s) inline, ask confirm per ADR.
+9. On confirm, write to `.zoo-flow/docs/adr/NNNN-slug.md` using `ADR-FORMAT.md` numbering.
+10. Report what was written, with file paths.
+
+## Detection
+
+### Step 1: Detect project shape
+
+Inspect (in order):
+- `package.json` `keywords`, `name`, `scripts` (Node/JS)
+- `pyproject.toml` / `setup.py` / `setup.cfg` (Python)
+- `Cargo.toml` (Rust)
+- `go.mod` (Go)
+- Top-level folder names
+- `README.md` first paragraph
+
+Pick the dominant shape:
+
+| Signal folders / files | Shape | Priority sources for terms |
+|---|---|---|
+| `app/`, `pages/`, `routes/`, `controllers/`, `api/` | web app | API routes, page names, URL paths, model types |
+| `lib/`, `pkg/`, `src/` (no `app/`) | library | exported types, public API surface |
+| `cmd/`, `bin/`, `commands/`, `cli/` | CLI tool | subcommand names, flag names |
+| `workers/`, `jobs/`, `tasks/`, `etl/`, `pipelines/` | data pipeline | job/queue/event names |
+| `services/`, `lambda/`, `functions/`, `handlers/` | serverless | function names, event sources, triggers |
+| `services/` + `web/` + `workers/` | monorepo | treat each top-level as a sub-shape; ask user if unclear |
+
+If signals are mixed, prefer the shape that owns the entry point (`main.*`, `index.*`, `server.*`).
+
+### Step 2: Extract candidate terms
+
+For the chosen shape, prefer:
+- **Web app**: route paths (`/accounts/:id`), controller class names, view/component names
+- **Library**: exported type/class/interface names
+- **CLI**: subcommand names, top-level argument names
+- **Data pipeline**: job names, queue names, event types
+- **Serverless**: function names, event source names
+
+Universal signals (any shape):
+- Type/class/struct/interface definitions with noun names
+- Database table/model names (migrations, `schema.prisma`, `models/`, SQL files)
+- Top-level module/folder names that are nouns
+- README/docs that state purpose ("we manage X for Y")
+
+### Step 3: Filter
+
+Drop without showing:
+- Generic: `utils`, `helpers`, `common`, `base`, `lib`, `core`, `misc`, `types`, `models`, `helpers`, `shared`, `internal`, `errors`, `tests`
+- Single-letter or unexpanded acronym: `T`, `M`, `VM`, `DTO` (unless defined in code)
+- Already-defined terms in existing `CONTEXT.md` (merge mode)
+- Framework-required boilerplate: `App`, `Server`, `Router`, `Config`
+
+Keep candidates that:
+- Appear in 2+ distinct files OR
+- Appear in 1 file but are central (entry point, root config, README)
+- Are domain nouns (Account, Order, Tenant, Invoice) over technical nouns (Worker, Queue)
+
+### Step 4: Score and rank
+
+For each kept candidate, count:
+- Type/def files where it appears
+- Route/file references
+- DB schema references
+
+Take the top 5-12. Show the count in the proposal so the user can judge.
+
+## ADR gate
+
+Propose an ADR only if ALL:
+- You can point at code: a single pattern/import/module used across N+ files
+- The pattern is not obvious from the framework (e.g. "uses Express" is obvious, "all errors go through `Result<T, AppError>`" is not)
+- A reasonable engineer would be surprised to learn it from scratch
+- It maps to `ADR-FORMAT.md` "Qualifies" criteria (hard to reverse, real trade-off)
+
+Do NOT propose ADRs for:
+- Framework defaults
+- Single-file patterns
+- Speculative "this might be a decision" guesses
+- Anything where the README doesn't hint at reasoning
+
+Cap at 0-2 ADRs per scaffold. Zero is fine. Better to ship no ADR than a wrong one.
+
+## Context-pack selector
+
+After detecting project shape and proposing CONTEXT.md terms + ADRs, recommend the smallest useful set of optional context docs.
+
+Rules:
+
+- Templates live under `.roo/skills/engineering/zoo-scaffold-context/templates/` (candidates only, never installed by default).
+- Missing optional docs are **not an error**.
+- Recommend a doc only when code evidence shows it would change future agent behavior.
+- Prefer one compact doc over many thin docs.
+- Better to create zero optional docs than wrong docs.
+- Ask for confirmation before writing any optional doc.
+
+Consider optional docs only with code evidence:
+
+| Doc | When to recommend |
+|---|---|
+| `TESTING.md` | unusual verification setup, multiple test layers, important seams |
+| `DATA_MODEL.md` | schemas, lifecycle states, ownership, migrations visible in code |
+| `API_CONTRACTS.md` | public routes, SDK exports, webhooks, event payloads |
+| `RUNBOOK.md` | deploys, jobs, queues, cron, recovery procedures |
+| `SECURITY_NOTES.md` | auth, permissions, tenant isolation, secrets, payments |
+| `INTEGRATIONS.md` | third-party APIs, OAuth, Stripe, email, queues, LLM providers |
+| `MONOREPO_MAP.md` | multiple apps/packages/services with different responsibilities |
+
+### Output shape
+
+```
+## Suggested context pack
+
+Detected shape: <shape>
+
+Recommended:
+1. `.zoo-flow/CONTEXT.md`
+   Reason: repeated domain terms found.
+2. `.zoo-flow/DATA_MODEL.md`
+   Reason: schema migration logic found in 4 files.
+
+Maybe:
+1. `.zoo-flow/SECURITY_NOTES.md`
+   Reason: auth middleware exists, but permission model appears simple.
+
+Skipped:
+- `RUNBOOK.md` — no deployment or operational recovery surface found.
+- `DATA_MODEL.md` — schema is simple; terms fit in CONTEXT.md.
+
+Choose:
+1. Create recommended only
+2. Choose manually
+3. Cancel
+```
+
+### Selection matrix by shape
+
+| Shape | Likely recommended | Likely maybe | Likely skipped |
+|---|---|---|---|
+| web app | CONTEXT.md | SECURITY_NOTES.md, INTEGRATIONS.md | RUNBOOK.md, MONOREPO_MAP.md |
+| library | CONTEXT.md, API_CONTRACTS.md | TESTING.md | RUNBOOK.md, MONOREPO_MAP.md |
+| CLI tool | CONTEXT.md | RUNBOOK.md | DATA_MODEL.md, MONOREPO_MAP.md |
+| data pipeline | CONTEXT.md, DATA_MODEL.md | RUNBOOK.md | API_CONTRACTS.md |
+| serverless | CONTEXT.md, INTEGRATIONS.md | SECURITY_NOTES.md | MONOREPO_MAP.md |
+| monorepo | CONTEXT.md, MONOREPO_MAP.md | INTEGRATIONS.md, API_CONTRACTS.md | RUNBOOK.md |
+
+Do not let this selector delay the core CONTEXT.md + ADR proposal. Present the pack selection after the main confirm flow.
+
+## MUST
+
+- Ask confirm before writing `CONTEXT.md` (show full proposed list + diff against existing)
+- Ask confirm per ADR before writing
+- Ask confirm per optional doc before writing
+- Never overwrite non-empty `CONTEXT.md` without explicit "replace"
+- Never invent cross-cutting decisions; only propose ADRs you can point at code
+- Keep `CONTEXT.md` glossary-only; no impl/spec notes
+- Use `ADR-FORMAT.md` for any proposed ADR (template + numbering)
+- Report file paths and section headers at the end
+- In merge mode, append new terms below existing ones; do not reorder
+
+## Context economy
+
+Before broad reads, locate candidates with `list_files`, `search_files`, or `codebase_search`.
+
+Prefer targeted `read_file` ranges or block reads once the candidate 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.
+
+## Output shape (for the inline confirm step)
+
+```
+## Proposed CONTEXT.md entries (N)
+
+1. **Account** — a tenant-scoped record of a customer relationship.
+   Evidence: 12 type defs, 4 routes, 1 DB table.
+2. **Order** — a request to purchase one or more SKUs.
+   Evidence: 8 type defs, 3 routes, 1 DB table.
+...
+
+Confirm? (yes / edit / cancel)
+```
+
+```
+## Proposed ADR (1 of N)
+
+# Use Result type for all fallible operations
+
+We use a Rust-style `Result<T, AppError>` for all operations that can
+fail, instead of throwing exceptions. This is enforced by a linter
+rule and visible in every service module.
+
+Considered Options:
+- Exceptions
+- Error codes (Go-style)
+- Result type (chosen)
+
+Consequences: easier to reason about error paths; verbose for happy
+paths.
+
+Confirm? (yes / edit / cancel)
+```
+
+## Complete
+
+Call `attempt_completion` with:
+- file paths written (CONTEXT.md, ADRs, optional docs)
+- terms added (count)
+- status (complete / blocked with reason)
+- recommended next command
+
+Do NOT use `ask_followup_question` or write results as plain text without calling the tool.

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

@@ -40,7 +40,7 @@ C. Domain docs:
 Show:
 1. `## Agent skills` block.
 2. `docs/agents/issue-tracker.md`.
-3. `docs/agents/triage-labels.md`.
+3. `docs/agents/zoo-triage-labels.md`.
 4. `docs/agents/domain.md`.
 
 ## Write
@@ -63,7 +63,7 @@ Block:
 
 ### Triage labels
 
-[one-line summary]. See `docs/agents/triage-labels.md`.
+[one-line summary]. See `docs/agents/zoo-triage-labels.md`.
 
 ### Domain docs
 

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

@@ -50,7 +50,7 @@ Checklist per cycle:
 - [ ] Code minimal.
 - [ ] No speculation.
 
-After green, suggest `/verify`, then `/review`, then `/commit-and-document` for non-trivial work. Do not auto-launch follow-up commands.
+After green, suggest `/zoo-verify`, then `/zoo-review`, then `/zoo-commit-and-document` for non-trivial work. Do not auto-launch follow-up commands.
 
 ## Complete
 

package/templates/full/.roo/skills/engineering/to-issues/SKILL.md

@@ -5,7 +5,7 @@ description: Break a plan, spec, or PRD into independently-grabbable issues on t
 
 # To Issues
 
-Issue tracker + label vocabulary should exist; run `/setup-matt-pocock-skills` if missing.
+Issue tracker + label vocabulary should exist; run `/zoo-setup-matt-pocock-skills` if missing.
 
 ## Process
 
@@ -49,6 +49,6 @@ If no blockers: `None - can start immediately`.
 Call `attempt_completion` with:
 - issues created (count and tracker URLs or `.scratch/{feature-slug}/issues/` path)
 - status (complete / blocked with reason)
-- recommended next command (`/tweak` or `/tdd` to start implementing the first issue)
+- recommended next command (`/zoo-tweak` or `/zoo-tdd` to start implementing the first issue)
 
 Do NOT use `ask_followup_question` or write results as plain text without calling the tool.