@fernado03/zoo-flow 0.5.2 → 0.7.0

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

@@ -1,69 +1,83 @@
-# 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 |
+# 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", "branch review", "pre-commit review", "analyze", "deep inspection", "investigate", or "reason about safety", route it to `system-architect`.
+
+If a task requires source edits, tests, verification, 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, review, verification. 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 |
+| review               | `/review`              | system-architect |
+| verification         | `/verify`              | code-tweaker     |
+
+## 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; 11. diff, branch, PR, standards, architecture, or pre-commit inspection → review; 12. check if this passes, run tests for this change, verify the branch, or make sure nothing broke → verification.
+
+## 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, then suggest verification or review. R4 cross-module change or design tradeoff → feature planning or refactor planning, then suggest verification and review. R5 auth/payments/security/migrations/data loss/external API contracts → strict planning/diagnosis with explicit approval gates, then suggest verification and review.
+
+## 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. A free-form request is never self-approving; propose a workflow and wait for approval. 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`.
 
-## 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
+## Follow-up recommendations
 
-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.
+For non-trivial work, suggest the next command chain only after the current command completes. Do not auto-launch follow-up commands merely because they are mentioned.
 
-## Delegation
+Recommended chains:
 
-Delegate only after the approval gate is satisfied. Choose the safest proceed policy from `01-delegation-message.md`.
+- test-first → verification → review → commit and journal
+- diagnosis → verification → review → commit and journal
+- refactor planning → verification → review → commit and journal
+- feature planning → verification → review → commit and journal
+- small implementation → verification or review when risk is R3+

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

@@ -1,62 +1,66 @@
-# 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
+# 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
+- `/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.

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

@@ -11,6 +11,10 @@ If you entered this window via `switch_mode` (you are mid-chain, not the entry p
 
 Before any `attempt_completion`, re-read the command body and confirm no later phase is assigned to another mode. If one is, `switch_mode` instead.
 
-Do not use `attempt_completion` to avoid required implementation work.
+Do not use `attempt_completion` to avoid required implementation work. Every `attempt_completion` must include evidence of what was produced or discovered, not just summaries.
 
-Halt for explicit user approval before testing a bug hypothesis, finalizing an architecture plan, publishing issues, or making irreversible decisions.
+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.
+
+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/engineering/README.md

@@ -10,3 +10,5 @@
 - **[to-prd](./to-prd/SKILL.md)** — Context → PRD issue.
 - **[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.

package/templates/full/.roo/skills/engineering/commit-and-document/SKILL.md

@@ -123,8 +123,7 @@ Date via `date +%Y-%m-%d`. Create `docs/journal/<YYYY-MM-DD>/` if missing. Write
 ## 7. Surface stale docs (if any)
 
 Read `git diff --cached --stat`. If any staged path overlaps with a path
-referenced in `.zoo-flow/CONTEXT.md`, `.zoo-flow/ARCHITECTURE.md`,
-`.zoo-flow/APP_MAP.md`, or any nearby `FLOW.md`, output exactly one line
+referenced in `.zoo-flow/CONTEXT.md`, output exactly one line
 before "Confirm":
 
   "Public surface may have drifted. Run /update-docs? (yes / skip)"

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

@@ -1,6 +1,6 @@
 # ADR Format
 
-Path: `docs/adr/NNNN-slug.md`. Create dir lazily.
+Path: `.zoo-flow/docs/adr/NNNN-slug.md`. Create dir lazily.
 
 ## Template
 

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

@@ -1,61 +1,36 @@
-# CONTEXT.md Format
-
-## Shape
-
-```md
-# {Context Name}
-
-{1-2 sentences: context purpose.}
-
-## Language
-
-**Order**:
-{1-2 sentence definition}
-_Avoid_: Purchase, transaction
-
-## Flagged ambiguities
-
-**Account** means Customer here, not User.
-```
-
-## Rules
-
-- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid`.
-- Define term in 1–2 sentences: what it is, not behavior.
-- Include domain terms only; exclude generic programming terms.
-
-## Slots
-
-| Slot | File (if present) | Authored by | Default location |
-|---|---|---|---|
-| Domain language | `CONTEXT.md` | User via /grill-with-docs | `.zoo-flow/CONTEXT.md` |
-| Decisions | `docs/adr/<NNNN-slug>.md` | User via /grill-with-docs | `.zoo-flow/docs/adr/` |
-| Subsystem flow | `FLOW.md` | Subsystem owner | Next to the code |
-| App map | `APP_MAP.md` | User via /update-docs | `.zoo-flow/APP_MAP.md` |
-| Architecture | `ARCHITECTURE.md` | User via /update-docs | `.zoo-flow/ARCHITECTURE.md` |
-| Setup | `README.md` | Project owner | Project root |
-
-## Discovery rule (used by /explore, /update-docs, /grill-with-docs)
-
-For each slot, in this order:
-
-1. If the file exists at the documented location, read it.
-2. If the slot is empty/missing, that is **not an error**. The user has
-   not authored it yet. Do not invent content. Do not lazy-create unless
-   the calling command explicitly says so (e.g. /grill-with-docs on a
-   first resolved term).
-3. If the calling command depends on a populated slot and none exist,
-   surface once: "Slot `<name>` not yet authored. Run /grill-with-docs
-   to fill, or continue without."
-
-## Multi-context (rare)
-
-A single project can hold multiple domain contexts when subsystems do
-not share language. Use:
-
-- `.zoo-flow/CONTEXT-MAP.md` — index of contexts.
-- `.zoo-flow/contexts/<slug>/CONTEXT.md` — per-context.
-- `.zoo-flow/contexts/<slug>/docs/adr/` — per-context ADRs.
-
-`/grill-with-docs` and `/explore` consult the map first, then the
-relevant per-context file.
+# CONTEXT.md Format
+
+## Shape
+
+```md
+# {Context Name}
+
+{1-2 sentences: context purpose.}
+
+## Language
+
+**Order**:
+{1-2 sentence definition}
+_Avoid_: Purchase, transaction
+
+## Flagged ambiguities
+
+**Account** means Customer here, not User.
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid`.
+- Define term in 1–2 sentences: what it is, not behavior.
+- Include domain terms only; exclude generic programming terms.
+
+## Directory layout
+
+- `.zoo-flow/CONTEXT.md` — domain language glossary
+- `.zoo-flow/docs/adr/<NNNN-slug>.md` — architecture decisions
+
+## Discovery rule
+
+1. If the file exists, read it.
+2. If the file is missing, that is **not an error**. Do not invent content.
+3. For commands that depend on populated context, surface once: "No CONTEXT.md or ADRs found yet. Run /grill-with-docs or /scaffold-context to fill, or continue without."

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

@@ -7,7 +7,7 @@ description: Grilling session that challenges your plan against the existing dom
 
 ## Loop
 
-1. Read relevant `CONTEXT.md`/`CONTEXT-MAP.md` + ADRs.
+1. Read relevant `.zoo-flow/CONTEXT.md` + ADRs.
 2. Ask one question at a time.
 3. Include recommended answer.
 4. Inspect code instead of asking when code can answer.

package/templates/full/.roo/skills/engineering/improve-codebase-architecture/SKILL.md

@@ -5,11 +5,11 @@ description: Find deepening opportunities in a codebase, informed by the domain
 
 # Improve Codebase Architecture
 
-RULE: Use `LANGUAGE.md` terms. Use glossary. Respect ADRs; surface only reopen-worthy conflicts.
+RULE: Use `.zoo-flow/CONTEXT.md` terms. Use glossary. Respect ADRs; surface only reopen-worthy conflicts.
 
 ## Explore
 
-1. Read relevant `CONTEXT.md`/`CONTEXT-MAP.md`.
+1. Read relevant `.zoo-flow/CONTEXT.md`.
 2. Read relevant ADRs.
 3. Explore code organically.
 4. Find friction:
@@ -52,4 +52,4 @@ Use searches to identify dependency/call patterns before reading full modules. R
 2. If module name introduces unresolved domain term, update `CONTEXT.md` lazily.
 3. If term sharpened, update `CONTEXT.md` immediately.
 4. Durable rejected reason useful later → offer ADR.
-5. Interface options requested → run `INTERFACE-DESIGN.md`.
+5. Interface options requested → run interface-design workflow.

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

@@ -1,37 +1,37 @@
----
-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/ADR/issue/`NOTES.md`; delete or fold into real code.
+---
+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/ADR/issue/`NOTES.md`; delete or fold into real code.

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

@@ -0,0 +1,111 @@
+---
+name: review
+description: Review a diff, branch, PR, or work-in-progress change against the requested spec, repo standards, architecture, and likely regressions. Use before committing non-trivial work.
+---
+
+# Review
+
+Purpose: answer whether the diff matches the spec, standards, architecture, and project intent.
+
+Review only. Do not patch application source. As `system-architect`, edits are limited to Markdown, `.scratch/`, and `docs/`.
+
+## 1. Identify target
+
+Use the narrowest target that fits the request:
+
+- User-provided base ref, PR, issue, files, or review focus.
+- Staged diff when staged changes exist.
+- Unstaged diff when unstaged changes exist.
+- Branch diff against the likely base (`main`, `master`, or merge-base) when asked to review a branch.
+- Specific files/specs/PRDs when provided.
+
+If the target is unclear, ask one short question and stop.
+
+## 2. Read needed context only
+
+Start with:
+
+- `git status --short`
+- `git diff --stat`
+- `git diff --cached --stat` when staged changes exist
+
+Then read targeted diffs only:
+
+- `git diff -- <file>`
+- `git diff --cached -- <file>`
+- `git diff <base>...HEAD -- <file>`
+
+Read relevant specs, issues, PRDs, standards, docs, ADRs, security notes, or project conventions only when they affect the changed area or the user requested that axis.
+
+## 3. Review axes
+
+Standards axis:
+
+- style
+- architecture
+- test quality
+- maintainability
+- security
+- project conventions
+
+Spec axis:
+
+- did it solve the requested problem?
+- did it change public behavior unexpectedly?
+- did it miss edge cases?
+- did it violate PRD, issue, or user intent?
+
+Security/Risk axis:
+
+- does the change touch auth, payments, PII, session data, or external API contracts?
+- does it introduce new dependencies or entitlements?
+- are there error paths that could leak information?
+- is there a regression path that would be hard to detect?
+- does the change affect audit logs or compliance obligations?
+
+For every Security/Risk finding, include the severity and a concrete
+mitigation suggestion. Omitting this axis is allowed when the change
+clearly cannot affect security (copy changes, comment fixes, test-only
+additions, docs-only updates).
+
+## 4. Findings
+
+Order findings by severity:
+
+- Blocker
+- High
+- Medium
+- Low
+- Nit
+
+For every finding include:
+
+- file/path
+- line or symbol when possible
+- problem
+- why it matters
+- suggested fix
+
+Prefer concrete findings over commentary. If no findings exist for a severity, omit that severity.
+
+## 5. Result
+
+End with exactly one result line:
+
+- `Review result: approve`
+- `Review result: approve with nits`
+- `Review result: changes requested`
+- `Review result: blocked`
+
+## Recommended next command
+
+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`
+
+Do not auto-launch any follow-up command.