@fernado03/zoo-flow 0.1.0

package/package.json

@@ -0,0 +1,44 @@
+{
+  "name": "@fernado03/zoo-flow",
+  "version": "0.1.0",
+  "description": "Smoke-tested workflow control plane for Zoo Code.",
+  "type": "module",
+  "bin": {
+    "zoo-flow": "bin/zoo-flow.js"
+  },
+  "files": [
+    "bin",
+    "templates",
+    "README.md",
+    "LICENSE"
+  ],
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/Fernado03/zoo-flow.git"
+  },
+  "bugs": {
+    "url": "https://github.com/Fernado03/zoo-flow/issues"
+  },
+  "homepage": "https://github.com/Fernado03/zoo-flow#readme",
+  "keywords": [
+    "zoo-code",
+    "zoo",
+    "ai-agents",
+    "coding-agents",
+    "workflow",
+    "slash-commands",
+    "custom-modes",
+    "agent-workflows"
+  ],
+  "scripts": {
+    "check": "node bin/zoo-flow.js doctor --template-only",
+    "pack:check": "npm pack --dry-run"
+  },
+  "engines": {
+    "node": ">=18"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}

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

@@ -0,0 +1,7 @@
+---
+description: "Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says \"caveman mode\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", or invokes /caveman."
+---
+
+Run skill: `.roo/skills/productivity/caveman/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/commit-and-document.md

@@ -0,0 +1,202 @@
+---
+description: "Update repo documentation so it matches the current code."
+argument-hint: <doc or area to update>
+mode: code-tweaker
+---
+
+You are running the **commit + document** procedure. This is a deterministic flow, not a skill — execute the steps in order. Do not deviate.
+
+## Step 1 — Inspect git changes
+
+Run these three commands and read the output:
+
+- `git status --short`
+- `git diff --stat`
+- `git diff --cached --stat` (in case anything is already staged)
+
+Summarise to the user what's changed: which files, roughly what the changes do.
+
+## Step 2 — Suggest a Conventional Commit message
+
+Propose ONE single-line commit message in this exact format:
+
+```
+<type>(<scope>): <short, action-focused summary>
+```
+
+- **type** — one of: `feat`, `fix`, `refactor`, `docs`, `chore`, `test`, `style`, `perf`
+- **scope** — the area of the repo touched (e.g. `chat`, `documents`, `ui`, `core`, or a specific module name). Omit parens if scope is unclear.
+- **summary** — imperative mood, present tense, under 70 chars total. Start with a verb.
+
+Show the user the proposed message, the list of files that will be staged, and a separate list of excluded files such as test files, test folders, docs, or secrets. Ask: "Commit with this message? (yes / edit / cancel)"
+
+If they say `edit`, take their revised message. If `cancel`, stop the whole procedure and report.
+
+## Step 2.5 — Detect or ask for an issue reference
+
+This step links the commit to a GitHub issue if one applies. It is opt-in — if no issue applies, skip cleanly.
+
+### Pre-checks (silent, fast bail-out)
+
+Before asking the user anything, run these silent checks:
+
+1. Run `git remote -v` and look for a `github.com` remote.
+2. If no GitHub remote exists, skip this entire step. Do NOT prompt.
+3. If `gh` CLI is not installed (check with `command -v gh`), skip this entire step. Do NOT prompt.
+
+### Detection
+
+Scan the proposed commit message from Step 2 for issue references:
+
+- Closing keywords: `Closes #N`, `Close #N`, `Closed #N`, `Fixes #N`, `Fix #N`, `Fixed #N`, `Resolves #N`, `Resolve #N`, `Resolved #N` (case-insensitive)
+- Bare references: `#N` anywhere in the message
+
+### Branch A — Commit message already has a closing keyword
+
+Show the user the detected reference and ask:
+
+> Detected `Closes #42` in the commit message. After commit, comment on issue #42 and close it? (yes / no)
+
+- yes → proceed; remember `{action: close, issue: 42}` for Step 3.5
+- no → proceed without issue actions
+
+### Branch B — Commit message has bare `#N` (not a closing keyword)
+
+> Detected `#42` in the commit message. After commit, post a progress comment on issue #42? (yes / no / close)
+
+- yes → remember `{action: comment, issue: 42}`
+- close → remember `{action: close, issue: 42}`
+- no → no issue actions
+
+### Branch C — No reference detected
+
+Ask once:
+
+> Is this commit related to a GitHub issue? (issue number / no / skip)
+
+- A number like `42` → ask one follow-up: "Comment only or close after commit? (comment / close)" — remember the chosen action
+- `no` or `skip` or empty input → no issue actions; do NOT ask again
+- Anything that doesn't parse as a number → treat as `no`
+
+### Carry-over
+
+Whatever was decided in Branch A / B / C, store it as `issue_action` for Step 3.5 to act on. If nothing was decided, `issue_action` is `none`.
+
+## Step 3 — Stage and commit
+
+Stage the specific files (not `git add .`). Use `git add <file1> <file2> ...` with the files identified in Step 1.
+
+Before staging, exclude:
+- any file or folder under `test/`, `tests/`, `__tests__/`, `spec/`, or `specs/`
+- any test file matching `*.test.*`, `*.spec.*`, `test_*`, or `*_test.*`
+- any file that looks like it contains secrets (`.env`, credentials, tokens)
+
+Flag excluded files to the user instead of staging them.
+
+Commit with the approved message: `git commit -m "<message>"`.
+
+Capture the commit hash from the commit output. The user will need it for Step 6. You can also run `git rev-parse --short HEAD` to get it.
+
+## Step 3.5 — Act on the issue reference (if any)
+
+If `issue_action` from Step 2.5 is `none`, skip this step entirely.
+
+Otherwise, do the following:
+
+1. Capture the short commit hash from Step 3.
+2. Construct a comment body:
+
+```
+> *This was generated by AI during commit.*
+
+Linked from commit `<short-hash>`: <commit message subject line>
+```
+
+3. Post the comment with `gh issue comment <N> --body "<body>"`.
+4. If `issue_action.action == "close"`, also run `gh issue close <N>`. Do NOT pass a comment to `gh issue close`; the comment was already posted in step 3.
+5. If either gh command fails (auth missing, issue doesn't exist, network error), DO NOT abort the workflow. Print the error to the user with a clear note: "Issue update failed — commit and journal entry are still complete. Re-run `gh issue comment <N>` manually if needed." Then continue.
+
+Safety:
+
+- Never use `gh issue close --comment` — comment first, then close, so a closing comment is always posted even if `gh close` later fails.
+- Never close an issue you couldn't successfully comment on.
+- Never push. The commit stays local; gh API calls are separate from `git push`.
+
+## Step 4 — Ensure docs/ is gitignored
+
+Read [`.gitignore`](.gitignore:1). The repo treats the entire `docs/` tree as local-only — nothing under `docs/` should ever be committed.
+
+If `.gitignore` does NOT contain a line matching `docs/` (with or without trailing slash), append this block to the end:
+
+```
+# Local documentation — never committed
+docs/
+```
+
+If `.gitignore` was modified, tell the user — but do NOT commit the gitignore change as part of this flow.
+
+If the user has staged any file under `docs/` in Step 3 by mistake, unstage it (`git restore --staged docs/<path>`) and warn them: "Files under `docs/` should not be committed. Unstaged."
+
+## Step 5 — Inspect existing docs/journal/ structure
+
+Look at the current shape of `docs/journal/` if it exists:
+
+- Run `ls -la docs/journal/` (or list it via tools).
+- Note the existing date subfolders and file naming pattern, if any. Match whatever convention is already in use.
+
+If `docs/journal/` does not exist yet, create it.
+
+## Step 6 — Create a dated subfolder and write the entry
+
+Determine today's date in `YYYY-MM-DD` format using `date +%Y-%m-%d`.
+
+Create `docs/journal/<YYYY-MM-DD>/` if it does not exist.
+
+Inside that folder, write a new markdown file named `<HH-MM>-<short-slug>.md` where:
+- `<HH-MM>` is the current local time in 24-hour format
+- `<short-slug>` is a kebab-case version of the commit summary (3–6 words max)
+
+Use this template for the entry:
+
+```md
+# <Commit summary>
+
+**Commit:** <full commit hash>
+**Short hash:** <short hash>
+**Date:** <YYYY-MM-DD HH:MM local time>
+
+## What changed
+
+<2–4 sentences describing what the commit changes. Plain English, not a file list.>
+
+## Why
+
+<1–3 sentences on the motivation. Pull from the conversation context if available.>
+
+## Notes for future me
+
+<Any gotchas, follow-ups, or things to revisit. One paragraph max. Skip the section if there's nothing worth saying.>
+```
+
+Fill in the placeholders from:
+- The commit hash from Step 3
+- The conversation context for "What changed" and "Why"
+
+## Step 7 — Confirm
+
+Tell the user:
+- Commit hash and message
+- Path to the journal entry just created
+- Whether `.gitignore` was updated
+- If `issue_action` was acted on: "Issue #N commented and closed." or "Issue #N commented." (whichever applies)
+
+End with: "All of `docs/` is gitignored, so this entry stays local."
+
+## Safety notes
+
+- Never run `git push`. Commits stay local.
+- Never use `--amend`, `--force`, or `reset --hard`.
+- If `git status` shows the working tree is clean, abort early: tell the user there's nothing to commit and skip the rest of the flow.
+- If files look like they contain secrets, flag them and skip staging them.
+
+$ARGUMENTS

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

@@ -0,0 +1,7 @@
+---
+description: "Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says \"diagnose this\" / \"debug this\", reports a bug, says something is broken/throwing/failing, or describes a performance regression."
+---
+
+Run skill: `.roo/skills/engineering/diagnose/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,13 @@
+---
+description: "Explore unfamiliar code before /feature, /refactor, or /fix. Produces written map."
+argument-hint: <feature or folder to map>
+mode: system-architect
+---
+EXECUTION RULES:
+1. READ: `CONTEXT.md`, `CONTEXT-MAP.md`, `docs/adr/`, `FLOW.md`, `ARCHITECTURE.md`, `APP_MAP.md` in target area.
+2. RUN skill: `.roo/skills/engineering/zoom-out/SKILL.md`.
+3. OUTPUT MAP: Create markdown with sections: Domain language, Modules, Data flow, Seams/callers, ADRs, Open questions.
+4. NEXT STEPS: Suggest `/grill-with-docs`, `/feature`, `/refactor`, or `/fix`. DO NOT auto-launch.
+5. SAVE (Optional): Ask to save map to .scratch/explorations/<date>/explore-<slug>.md.
+
+$ARGUMENTS

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

@@ -0,0 +1,24 @@
+---
+description: "Add new feature. Chains grill-with-docs, prototype, to-prd, to-issues, tdd."
+argument-hint: <describe the feature>
+mode: system-architect
+---
+EXECUTION RULES (Run sequentially. Wait for user between phases):
+1. SHARPEN (Architect): Run skill `.roo/skills/engineering/grill-with-docs/SKILL.md`. Update docs.
+   HARD STOP: Ask user to choose: Prototype OR skip to PRD.
+2. PROTOTYPE [Optional]:
+   - Architect summarizes the prototype question, constraints, relevant context, and expected decision.
+   - Architect MUST `switch_mode` -> `code-tweaker`.
+   - Tweaker executes the `/prototype` command workflow using `.roo/rules/01-command-protocol.md`.
+   - Tweaker MUST `switch_mode` -> `system-architect` with prototype result, run command/URL if any, files changed, and decision needed.
+   HARD STOP: Wait for user verdict.
+3. PRD (Architect): Run skill `.roo/skills/engineering/to-prd/SKILL.md` using a 3-bullet summary of prior phases.
+   HARD STOP: Ask "Ready to slice into issues?". Wait for approval.
+4. SLICE (Architect): Run skill `.roo/skills/engineering/to-issues/SKILL.md`.
+   HARD STOP: Wait for user to approve issues list.
+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 `/commit-and-document`.
+
+$ARGUMENTS

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

@@ -0,0 +1,19 @@
+---
+description: "Fix bugs/regressions. Chains diagnose -> tweak -> post-mortem."
+argument-hint: <describe the bug or error>
+mode: system-architect
+---
+EXECUTION RULES:
+1. DIAGNOSE (Architect): Run skill `.roo/skills/engineering/diagnose/SKILL.md`. Run phases 1-3.
+   HARD STOP: Present hypotheses. Wait for user selection. Ignore internal AFK rules.
+2. INSTRUMENT (Architect): Run phase 4 on chosen hypothesis. Find root cause.
+3. IMPLEMENT (Tweaker):
+   - Architect summarizes fix.
+   - 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`.
+   - Architect MUST `switch_mode` -> `code-tweaker`.
+5. COMMIT (Tweaker): Suggest `/commit-and-document`.
+
+$ARGUMENTS

package/templates/full/.roo/commands/grill-me.md

@@ -0,0 +1,7 @@
+---
+description: "Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions \"grill me\"."
+---
+
+Run skill: `.roo/skills/productivity/grill-me/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/grill-with-docs.md

@@ -0,0 +1,7 @@
+---
+description: "Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions."
+---
+
+Run skill: `.roo/skills/engineering/grill-with-docs/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,8 @@
+---
+description: "Compact the current conversation into a handoff document for another agent to pick up."
+argument-hint: "What will the next session be used for?"
+---
+
+Run skill: `.roo/skills/productivity/handoff/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/improve-codebase-architecture.md

@@ -0,0 +1,7 @@
+---
+description: "Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable."
+---
+
+Run skill: `.roo/skills/engineering/improve-codebase-architecture/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,9 @@
+---
+description: "Build a throwaway prototype to flesh out a design before committing to it. Routes between logic/state/data-model prototypes and UI prototypes."
+argument-hint: <prototype question or design uncertainty>
+mode: code-tweaker
+---
+
+Run skill: `.roo/skills/engineering/prototype/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,17 @@
+---
+description: "Improve working code. Chains improve-codebase-architecture -> tdd."
+argument-hint: <area to refactor>
+mode: system-architect
+---
+EXECUTION RULES:
+1. FIND (Architect): Run skill `.roo/skills/engineering/improve-codebase-architecture/SKILL.md`. List candidates.
+   HARD STOP: Ask user which candidate to explore.
+2. GRILL (Architect): Run grilling loop. Update CONTEXT/ADRs inline.
+   HARD STOP: Summarize plan, get explicit user approval.
+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 `/commit-and-document`.
+
+$ARGUMENTS

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

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

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

@@ -0,0 +1,9 @@
+---
+description: "Test-driven development with red-green-refactor loop, one vertical slice at a time. Use when user wants to write tests first, build a feature TDD-style, or follow a strict test-first loop."
+argument-hint: <feature or bug to build>
+mode: code-tweaker
+---
+
+Run skill: `.roo/skills/engineering/tdd/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/to-issues.md

@@ -0,0 +1,7 @@
+---
+description: "Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues."
+---
+
+Run skill: `.roo/skills/engineering/to-issues/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/to-prd.md

@@ -0,0 +1,7 @@
+---
+description: "Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context."
+---
+
+Run skill: `.roo/skills/engineering/to-prd/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,7 @@
+---
+description: "Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow."
+---
+
+Run skill: `.roo/skills/engineering/triage/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,9 @@
+---
+description: "Direct implementation mode for small, known fixes or UI updates. Bypasses heavy diagnosis or PRD creation."
+argument-hint: <what to change>
+mode: code-tweaker
+---
+
+Run skill: `.roo/skills/engineering/tweak/SKILL.md`
+
+$ARGUMENTS

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

@@ -0,0 +1,130 @@
+---
+description: "Update repo documentation so it matches the current code."
+argument-hint: <doc or area to update>
+mode: code-tweaker
+---
+
+You are guiding the user through the **Update Docs** workflow. Use this when the goal is to make repo documentation match the current code.
+
+This command edits repo docs such as:
+
+- `FLOW.md` files
+- `APP_MAP.md`
+- `ARCHITECTURE.md`
+- `README.md`
+- Other markdown docs that explain how code works
+
+Do NOT use this for:
+
+- Domain glossary terms — use `/grill-with-docs` instead
+- ADRs / architectural decisions — use `/grill-with-docs` or `/refactor` so ADRs are offered properly
+- Local commit journal entries — use `/commit-and-document`
+- Read-only understanding — use `/explore`
+
+The user may pass a target doc or area as `$ARGUMENTS`, e.g.:
+
+- `apps/kikonnekt_w_sso/core/chat/FLOW.md`
+- `chat flow`
+- `documents flow`
+- `APP_MAP.md`
+- `ARCHITECTURE.md`
+
+If no target is provided, ask once: "Which documentation file or area should I update?"
+
+## Phase 1 — Identify target doc
+
+Infer or ask for the target documentation file.
+
+Prefer existing docs when possible:
+
+- For a subsystem flow, look for a nearby `FLOW.md`.
+- For app-wide navigation or module mapping, use `APP_MAP.md`.
+- For system-level structure and constraints, use `ARCHITECTURE.md`.
+- For setup or usage, use `README.md`.
+
+If the target doc does not exist, ask before creating it. Do not invent a new doc location silently.
+
+## Phase 2 — Read existing docs first
+
+Read the target doc fully before editing.
+
+Also read nearby related docs, if relevant:
+
+- Neighboring `FLOW.md` files
+- `APP_MAP.md`
+- `ARCHITECTURE.md`
+- `README.md`
+- Any module-local docs in the same subtree
+
+Goal: match the existing documentation style, section structure, vocabulary, and level of detail.
+
+## Phase 3 — Verify against code
+
+Inspect the code that the doc claims to describe. Update docs from code reality, not guesses.
+
+Check:
+
+- Entrypoints
+- Main functions/classes
+- Data flow
+- State changes
+- Side effects
+- Dependencies
+- Error/fallback paths
+- Files involved
+
+If a claim cannot be verified, either remove it or move it to an `Open questions` section. Do not present guesses as facts.
+
+## Phase 4 — Make surgical edits
+
+Do not rewrite the whole doc by default.
+
+Prefer surgical edits:
+
+- Keep useful existing sections
+- Update stale sections
+- Add missing flows
+- Remove false claims
+- Preserve heading style
+- Preserve existing tone and detail level
+
+Only rewrite the whole file if the current doc is too stale to salvage. If doing that, say why before editing.
+
+## Phase 5 — Add or update freshness block
+
+At the bottom of the doc, add or update this section if it fits the existing style:
+
+```md
+## Freshness
+
+Last checked against code: YYYY-MM-DD
+Relevant files checked:
+- `path/to/file.py`
+- `path/to/other_file.py`
+```
+
+Use today's date. Include only files actually inspected.
+
+## Phase 6 — Sanity check
+
+After editing:
+
+- Re-read the updated doc
+- Check referenced file paths exist
+- Ensure every major claim maps to code or a cited doc
+- Ensure no stale contradiction remains with nearby docs
+- Summarise what changed
+
+## Phase 7 — Recommend next step
+
+Recommend one next command:
+
+- `/explore` if the user still seems unsure how the area works
+- `/feature` if the docs update revealed a feature plan
+- `/refactor` if the docs update revealed tangled-but-working code
+- `/fix` if the docs update revealed a bug
+- `/commit-and-document` if the docs update is complete
+
+Do not auto-run the next command. The user chooses.
+
+$ARGUMENTS

package/templates/full/.roo/commands/write-a-skill.md

@@ -0,0 +1,7 @@
+---
+description: "Create new agent skills with proper structure, progressive disclosure, and bundled resources. Use when user wants to create, write, or build a new skill."
+---
+
+Run skill: `.roo/skills/productivity/write-a-skill/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/commands/zoom-out.md

@@ -0,0 +1,7 @@
+---
+description: "Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture."
+---
+
+Run skill: `.roo/skills/engineering/zoom-out/SKILL.md`
+
+$ARGUMENTS

package/templates/full/.roo/rules/00-paths.md

@@ -0,0 +1,17 @@
+# Path Safety
+
+All skill and command paths are workspace-root paths.
+
+Valid skill path form:
+
+- `.roo/skills/{bucket}/{skill}/SKILL.md`
+
+Valid command path form:
+
+- `.roo/commands/{command}.md`
+
+Commands and modes must load skills only from `.roo/skills/...`.
+
+Never resolve skill paths relative to `.roo/rules/`, `.roo/rules-{mode}/`, or the command file location.
+
+Invalid path forms include any skill path under `.roo/rules/`.

package/templates/full/.roo/rules/01-command-protocol.md

@@ -0,0 +1,25 @@
+# Command Protocol
+
+When assigned a slash command, execute the command workflow before doing task-specific work.
+
+Protocol:
+
+1. Normalize the command by stripping the leading slash.
+   - `/fix` becomes `fix`
+   - `/tdd` becomes `tdd`
+
+2. Preferred execution:
+   - Use `run_slash_command` if available.
+   - Pass `command` as the normalized command name.
+   - Pass `args` as the full user/delegated task context.
+
+3. Fallback execution:
+   - If `run_slash_command` is unavailable, disabled, rejected, or fails, read the command file from:
+     - `.roo/commands/{command}.md`
+
+4. If the command file references a skill:
+   - Read the exact `.roo/skills/...` path from the command file.
+   - Follow the skill instructions after loading.
+
+5. Do not auto-run follow-up commands merely because they are mentioned in a subtask summary.
+   - Only the human user or orchestrator routing may authorize a new command.

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

@@ -0,0 +1,13 @@
+# Manual Reply Protocol
+
+For workflow routing choices, use numbered options and ask the user to type the number.
+
+Example:
+
+1. `/tweak`
+2. `/fix`
+3. Hold
+
+Clickable suggestions, if shown, must be numeric only. Do not put slash commands or mode names in clickable suggestions.
+
+Only treat slash commands as commands when manually typed by the user.

package/templates/full/.roo/rules-code-tweaker/00-scope.md

@@ -0,0 +1,7 @@
+# Code Tweaker Scope
+
+Implement, test, update docs, prototype, and commit only after approval.
+
+Do not make broad architecture decisions.
+
+Escalate to `system-architect` with `switch_mode` when architecture decisions are needed or the same test/approach fails 3 times.