@fernado03/zoo-flow 0.7.1 → 0.7.4

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fernado03/zoo-flow",
   "description": "Workflow control plane for Zoo Code.",
-  "version": "0.7.1",
+  "version": "0.7.4",
   "type": "module",
   "bin": {
     "zoo-flow": "bin/zoo-flow.js"

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

@@ -6,8 +6,8 @@ mode: system-architect
 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.
 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.
+3. OUTPUT MAP: Create markdown with sections: Domain language, Modules, Data flow, Seams/callers, ADRs, Open questions. Write the full map to `.scratch/explorations/<date>/explore-<slug>.md`.
 4. NEXT STEPS: Suggest `/scaffold-context`, `/feature`, `/refactor`, or `/fix`. DO NOT auto-launch.
-5. SAVE (Optional): Ask to save map to .scratch/explorations/<date>/explore-<slug>.md.
+5. COMPLETION: Reference the `.scratch/` file path in `attempt_completion`. The orchestrator will read and present it.
 
 $ARGUMENTS

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

@@ -10,7 +10,7 @@ Batch related small reads when useful.
 
 Do not re-read unchanged files unless needed.
 
-For long command output, summarize or search the output instead of dumping everything.
+For long shell command output (tests, builds, lint), summarize or search the output instead of dumping everything. This is about context window management, not about hiding results from the user.
 
 ## Domain-doc read gate
 

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

@@ -20,7 +20,9 @@ Before any `attempt_completion`, re-read the command body and confirm no later p
 - remaining risk (what was not checked or is uncertain)
 - recommended next command (one only, no auto-launch)
 
-The orchestrator forwards your output to the user. Include enough detail that the user can act on it without re-running commands.
+The orchestrator forwards your output to the user. Include enough detail that the user can act on it without re-running commands.
+
+If the output is long (multi-file diff summary, full test output, verification report), write it to `.scratch/` first and reference the path in `attempt_completion`. The extension may truncate long completion messages, so files ensure nothing is lost.
 
 Before running `git commit` or `git push`, halt and wait for explicit user approval. Never push unless explicitly asked.
 

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

@@ -6,9 +6,10 @@ Router only. No reading implementation files, editing, shell, or answering imple
 
 After `attempt_completion` from a worker, the orchestrator must:
 
-1. Show the worker's full output to the user without truncating or summarizing.
-2. Add one line: recommended next command (if any).
-3. Stop and wait for user input.
+1. If the completion message references a `.scratch/` file, read and present that file's content.
+2. Show the worker's full output to the user without truncating or summarizing.
+3. Add one line: recommended next command (if any).
+4. Stop and wait for user input.
 
 Do not route a new user message until the previous subtask result is fully presented. If the user sends a new message before the result was shown, finish presenting the result first, then route the new message.
 

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

@@ -13,6 +13,8 @@ Before any `attempt_completion`, re-read the command body and confirm no later p
 
 Do not use `attempt_completion` to avoid required implementation work. Every `attempt_completion` must include the full output the user needs to see (review findings, exploration map, diagnosis, plan), not just summaries. The orchestrator will forward your output to the user; if you summarize, the user loses detail.
 
+If the output is long (multi-page review, full exploration map, detailed diagnosis), write it to `.scratch/` first and reference the path in `attempt_completion`. The extension may truncate long completion messages, so files ensure nothing is lost.
+
 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.

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

@@ -82,3 +82,7 @@ MUST finish:
 - [ ] Throwaway harnesses deleted/moved.
 - [ ] Winning hypothesis stated in commit/PR.
 - [ ] Seam/locality blocker → recommend `/improve-codebase-architecture`.
+
+## 7. Save
+
+Write the full diagnosis (hypotheses, instrumentation, root cause, fix) to `.scratch/diagnoses/<date>/diagnose-<slug>.md`. Reference this file path in `attempt_completion` so the orchestrator can read and present it.

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

@@ -32,5 +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.
-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."
+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."

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

@@ -97,6 +97,10 @@ End with exactly one result line:
 - `Review result: changes requested`
 - `Review result: blocked`
 
+## 6. Save
+
+Write the full review (findings, axes, result) to `.scratch/reviews/<date>/review-<slug>.md`. Reference this file path in `attempt_completion` so the orchestrator can read and present it.
+
 ## Recommended next command
 
 If fixes are needed, recommend one next command only:

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

@@ -16,9 +16,10 @@ Issue tracker + label vocabulary should exist; run `/setup-matt-pocock-skills` i
 5. Present numbered breakdown: title; `HITL`/`AFK`; blockers; user stories.
 6. Ask user to validate granularity/deps/HITL/AFK/merge/split.
 7. Iterate until approved.
-8. Publish in dependency order.
-9. Apply `ready-for-agent` label unless instructed otherwise.
-10. DO NOT close/modify parent issue.
+8. Save approved issues to `.scratch/issues/<date>/issues-<slug>.md`.
+9. Publish in dependency order.
+10. Apply `ready-for-agent` label unless instructed otherwise.
+11. DO NOT close/modify parent issue.
 
 ## Issue template
 

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

@@ -15,8 +15,9 @@ RULE: Do not interview user. Synthesize current context.
 2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can.
 3. Check with the user that these seams match their expectations.
 4. Write PRD.
-5. Publish to issue tracker.
-6. Apply `ready-for-agent`.
+5. Save PRD to `.scratch/prds/<date>/prd-<slug>.md`.
+6. Publish to issue tracker.
+7. Apply `ready-for-agent`.
 
 ## PRD template