@fernado03/zoo-flow 0.7.6 → 0.7.7

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.7",
   "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.
+Before `attempt_completion`, present the full output to the user in a normal message if the work produced long results (verification report, diff summary). Then `attempt_completion` with only: brief status, file path if written to `.scratch/`, and recommended next command. The orchestrator summarizes completion messages — the user must see the full output first.
 
 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,12 @@ 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 (brief status + file path + 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 worker already presented the full output in a normal message before `attempt_completion`. The orchestrator does not need to repeat it.
 
-The `.scratch/` file referenced in the completion is for user reference only — the orchestrator does not read it.
+Do not route a new user message until the completion message is fully presented.
 
 ## 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. Before `attempt_completion`, present the full output to the user in a normal message so they see the complete details (review findings, exploration map, diagnosis, plan). Then `attempt_completion` with only: brief status, file path if written to `.scratch/`, and recommended next command. The orchestrator summarizes completion messages — the user must see the full output first.
 
 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