@fernado03/zoo-flow 0.7.6 → 0.7.8

package/package.json

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

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

@@ -20,9 +20,7 @@ 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.
-
-If the output is long, also write it to `.scratch/` for persistence and user reference. Mention the file path in `attempt_completion` so the user can open it. The orchestrator will not read the file — it only presents your completion message.
+Write long output (verification report, diff summary) to `.scratch/` with a descriptive path. `attempt_completion` must include: file path where output was saved, brief status, and recommended next command. The user will open the file to see full details.
 
 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,13 +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. Show the worker's completion message to the user (file path + brief status + recommended next command).
+2. 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.
-
-The `.scratch/` file referenced in the completion is for user reference only — the orchestrator does not read it.
+The full output is in the `.scratch/` file referenced by the worker. The orchestrator does not read it — the user opens it in the editor.
 
 ## Hard delegation boundary
 

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

@@ -11,9 +11,7 @@ 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. Every `attempt_completion` must include the full output the user needs to see (review findings, exploration map, diagnosis, plan), not just summaries. The orchestrator forwards your output to the user; if you summarize, the user loses detail.
-
-If the output is long, also write it to `.scratch/` for persistence and user reference. Mention the file path in `attempt_completion` so the user can open it. The orchestrator will not read the file — it only presents your completion message.
+Do not use `attempt_completion` to avoid required implementation work. Write the full output (review findings, exploration map, diagnosis, plan) to `.scratch/` with a descriptive path. `attempt_completion` must include: file path where output was saved, brief status, and recommended next command. The user will open the file to see full details.
 
 Halt for explicit user approval before testing a bug hypothesis, finalizing an architecture plan, publishing issues, or making irreversible decisions.
 

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

@@ -16,10 +16,9 @@ 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. 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.
+8. Publish in dependency order.
+9. Apply `ready-for-agent` label unless instructed otherwise.
+10. DO NOT close/modify parent issue.
 
 ## Issue template
 

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

@@ -15,9 +15,8 @@ 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. Save PRD to `.scratch/prds/<date>/prd-<slug>.md`.
-6. Publish to issue tracker.
-7. Apply `ready-for-agent`.
+5. Publish to issue tracker.
+6. Apply `ready-for-agent`.
 
 ## PRD template