flow-workflows 0.73.0 → 0.74.0

package/adapters/codex/CORE.md

@@ -17,7 +17,7 @@ Every `$flow-*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.73.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.74.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -261,6 +261,7 @@ I need: <one line — the decision or action you are waiting on>
 - **Out of the chat, into the artifact:** your own process, your mistakes, corrections to subagent reports, bookkeeping. Subagent completion or idle notifications never earn a turn of their own.
 - **Zero-context rule.** First mention of an identifier carries 4–6 words of what it is. Never cite a section number without naming what it is. No jargon the user has not used first.
 - **If it is a question, it is `AskUserQuestion`.** Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
+- **What the question is about travels with the question.** A brief, an MR/PR body, a plan, a finding: put it where the user answers it — in the question text and its options — and not only in the prose above. **Nothing runs between the two**: a tool call after that prose is what makes a terminal fold it away, and the last thing a chat UI collapses is exactly the thing they were asked to read. A gate answered without seeing what it was about is not a gate; "it is in `05-implementation.md`" is not showing it, because the answer then costs opening an editor and finding the file. Too long for the harness's question → print it as the **last** thing before asking, tool calls already done.
 
 ## 4. Live panel — over the terminal's MCP, or `panel.json`
 

package/adapters/codex/skills/flow-bug-fix/SKILL.md

@@ -48,7 +48,9 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief.
+
+**The brief travels inside the question** (flow-core §3) — read in the prompt being answered, not by opening `04-fix.md` — and **nothing runs between the brief and the question**: a tool call after it is what lets a terminal fold it away. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 

package/adapters/codex/skills/flow-feat-build/SKILL.md

@@ -59,7 +59,9 @@ Rules for writing it:
 
 **Ask the user with `AskUserQuestion`** whether the brief reflects what they expect — **hard gate, in every autonomy mode, `auto` included**: it is the last point where scope can be corrected before there is a diff to argue with.
 
-In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
+In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief.
+
+**The brief travels inside the question** (flow-core §3): the user reads it in the prompt they are answering, never by opening `05-implementation.md`. Write the file, run whatever you need, and *then* open the gate — **nothing runs between the brief and the question**, because a tool call after it is what lets a terminal fold the brief into one collapsed line, and the gate is answered blind. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
 

package/adapters/codex/skills/flow-feat-ship/SKILL.md

@@ -153,7 +153,7 @@ Description:
 
 If there is pre-deploy SQL, ask the user to **explicitly confirm that the block is complete and correct** — it will be executed in production.
 
-Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
+The preview is the last thing before the question — **no tool call between them** (flow-core §3), or the block the user is meant to approve is the one their terminal folds away. Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
 
 - **Create with this content** → invoke §4.
 - **Edit before creating** → user says what to change (title, a section, both); adjust and return to §3 with the new preview.

package/adapters/gemini/CORE.md

@@ -16,7 +16,7 @@ Every `/flow:*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.73.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.74.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -260,6 +260,7 @@ I need: <one line — the decision or action you are waiting on>
 - **Out of the chat, into the artifact:** your own process, your mistakes, corrections to subagent reports, bookkeeping. Subagent completion or idle notifications never earn a turn of their own.
 - **Zero-context rule.** First mention of an identifier carries 4–6 words of what it is. Never cite a section number without naming what it is. No jargon the user has not used first.
 - **If it is a question, it is `AskUserQuestion`.** Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
+- **What the question is about travels with the question.** A brief, an MR/PR body, a plan, a finding: put it where the user answers it — in the question text and its options — and not only in the prose above. **Nothing runs between the two**: a tool call after that prose is what makes a terminal fold it away, and the last thing a chat UI collapses is exactly the thing they were asked to read. A gate answered without seeing what it was about is not a gate; "it is in `05-implementation.md`" is not showing it, because the answer then costs opening an editor and finding the file. Too long for the harness's question → print it as the **last** thing before asking, tool calls already done.
 
 ## 4. Live panel — over the terminal's MCP, or `panel.json`
 

package/adapters/gemini/commands/flow/bug/fix.toml

@@ -44,7 +44,9 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief.
+
+**The brief travels inside the question** (flow-core §3) — read in the prompt being answered, not by opening `04-fix.md` — and **nothing runs between the brief and the question**: a tool call after it is what lets a terminal fold it away. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 

package/adapters/gemini/commands/flow/feat/build.toml

@@ -55,7 +55,9 @@ Rules for writing it:
 
 **Ask the user with `AskUserQuestion`** whether the brief reflects what they expect — **hard gate, in every autonomy mode, `auto` included**: it is the last point where scope can be corrected before there is a diff to argue with.
 
-In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
+In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief.
+
+**The brief travels inside the question** (flow-core §3): the user reads it in the prompt they are answering, never by opening `05-implementation.md`. Write the file, run whatever you need, and *then* open the gate — **nothing runs between the brief and the question**, because a tool call after it is what lets a terminal fold the brief into one collapsed line, and the gate is answered blind. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
 

package/adapters/gemini/commands/flow/feat/ship.toml

@@ -149,7 +149,7 @@ Description:
 
 If there is pre-deploy SQL, ask the user to **explicitly confirm that the block is complete and correct** — it will be executed in production.
 
-Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
+The preview is the last thing before the question — **no tool call between them** (flow-core §3), or the block the user is meant to approve is the one their terminal folds away. Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
 
 - **Create with this content** → invoke §4.
 - **Edit before creating** → user says what to change (title, a section, both); adjust and return to §3 with the new preview.

package/adapters/hermes/CORE.md

@@ -17,7 +17,7 @@ Every `/flow-*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.73.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.74.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -261,6 +261,7 @@ I need: <one line — the decision or action you are waiting on>
 - **Out of the chat, into the artifact:** your own process, your mistakes, corrections to subagent reports, bookkeeping. Subagent completion or idle notifications never earn a turn of their own.
 - **Zero-context rule.** First mention of an identifier carries 4–6 words of what it is. Never cite a section number without naming what it is. No jargon the user has not used first.
 - **If it is a question, it is `AskUserQuestion`.** Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
+- **What the question is about travels with the question.** A brief, an MR/PR body, a plan, a finding: put it where the user answers it — in the question text and its options — and not only in the prose above. **Nothing runs between the two**: a tool call after that prose is what makes a terminal fold it away, and the last thing a chat UI collapses is exactly the thing they were asked to read. A gate answered without seeing what it was about is not a gate; "it is in `05-implementation.md`" is not showing it, because the answer then costs opening an editor and finding the file. Too long for the harness's question → print it as the **last** thing before asking, tool calls already done.
 
 ## 4. Live panel — over the terminal's MCP, or `panel.json`
 

package/adapters/hermes/skills/flow-bug-fix/SKILL.md

@@ -48,7 +48,9 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief.
+
+**The brief travels inside the question** (flow-core §3) — read in the prompt being answered, not by opening `04-fix.md` — and **nothing runs between the brief and the question**: a tool call after it is what lets a terminal fold it away. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 

package/adapters/hermes/skills/flow-feat-build/SKILL.md

@@ -59,7 +59,9 @@ Rules for writing it:
 
 **Ask the user with `AskUserQuestion`** whether the brief reflects what they expect — **hard gate, in every autonomy mode, `auto` included**: it is the last point where scope can be corrected before there is a diff to argue with.
 
-In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
+In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief.
+
+**The brief travels inside the question** (flow-core §3): the user reads it in the prompt they are answering, never by opening `05-implementation.md`. Write the file, run whatever you need, and *then* open the gate — **nothing runs between the brief and the question**, because a tool call after it is what lets a terminal fold the brief into one collapsed line, and the gate is answered blind. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
 

package/adapters/hermes/skills/flow-feat-ship/SKILL.md

@@ -153,7 +153,7 @@ Description:
 
 If there is pre-deploy SQL, ask the user to **explicitly confirm that the block is complete and correct** — it will be executed in production.
 
-Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
+The preview is the last thing before the question — **no tool call between them** (flow-core §3), or the block the user is meant to approve is the one their terminal folds away. Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
 
 - **Create with this content** → invoke §4.
 - **Edit before creating** → user says what to change (title, a section, both); adjust and return to §3 with the new preview.

package/adapters/opencode/CORE.md

@@ -16,7 +16,7 @@ Every `/flow-*` command assumes these rules. They are stated once, here, so a co
 carries what is specific to its phase. Read this once per session; a command that says "load
 `flow-core`" means this file.
 
-**This file belongs to flow `0.73.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.74.0`.** Compare it once, at the start of the session, against
 `version` in `~/.claude/flow/.claude-plugin/plugin.json`. The two differing means the session
 is running a **mixture** — the commands from one copy of the plugin, these shared rules from another
 — which is exactly what happens when a branch or a release candidate is loaded over an installed
@@ -260,6 +260,7 @@ I need: <one line — the decision or action you are waiting on>
 - **Out of the chat, into the artifact:** your own process, your mistakes, corrections to subagent reports, bookkeeping. Subagent completion or idle notifications never earn a turn of their own.
 - **Zero-context rule.** First mention of an identifier carries 4–6 words of what it is. Never cite a section number without naming what it is. No jargon the user has not used first.
 - **If it is a question, it is `AskUserQuestion`.** Never end a message with a question in prose. If it does not deserve the menu, it is a decision you take and record.
+- **What the question is about travels with the question.** A brief, an MR/PR body, a plan, a finding: put it where the user answers it — in the question text and its options — and not only in the prose above. **Nothing runs between the two**: a tool call after that prose is what makes a terminal fold it away, and the last thing a chat UI collapses is exactly the thing they were asked to read. A gate answered without seeing what it was about is not a gate; "it is in `05-implementation.md`" is not showing it, because the answer then costs opening an editor and finding the file. Too long for the harness's question → print it as the **last** thing before asking, tool calls already done.
 
 ## 4. Live panel — over the terminal's MCP, or `panel.json`
 

package/adapters/opencode/commands/flow-bug-fix.md

@@ -46,7 +46,9 @@ What is NOT touched:
 
 **Ask with `AskUserQuestion`** whether this reflects the expected fix — a hard gate, **in every mode, `auto` included**: widening the fix is the main source of collateral regressions, and this is the last point to settle scope before there is a diff.
 
-In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief. Options:
+In `auto` this is one of the only two stops of the whole flow (this one and `ship`; `guided` adds the plan of §2.0bis on a fix of more than two steps): open with the **full stop header** (flow-core §3), then the brief.
+
+**The brief travels inside the question** (flow-core §3) — read in the prompt being answered, not by opening `04-fix.md` — and **nothing runs between the brief and the question**: a tool call after it is what lets a terminal fold it away. Options:
 - **Yes, go ahead** → apply the fix.
 - **No, something is missing or wrong** → adjust the brief, ask again. No code until confirmed.
 

package/adapters/opencode/commands/flow-feat-build.md

@@ -57,7 +57,9 @@ Rules for writing it:
 
 **Ask the user with `AskUserQuestion`** whether the brief reflects what they expect — **hard gate, in every autonomy mode, `auto` included**: it is the last point where scope can be corrected before there is a diff to argue with.
 
-In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief. Options:
+In `auto` this is one of the only two stops per MR/PR (`guided` adds the plan of §2.0ter on a big one), so it carries the **full stop header** (flow-core §3) — ticket, size, phase, `MR #<n> of <N>`, plan state — followed by the brief.
+
+**The brief travels inside the question** (flow-core §3): the user reads it in the prompt they are answering, never by opening `05-implementation.md`. Write the file, run whatever you need, and *then* open the gate — **nothing runs between the brief and the question**, because a tool call after it is what lets a terminal fold the brief into one collapsed line, and the gate is answered blind. Options:
 - **Yes, proceed** → start building.
 - **No, something is extra or missing** → the user clarifies, adjust the brief, ask again. **Do not touch code** until the brief is confirmed.
 

package/adapters/opencode/commands/flow-feat-ship.md

@@ -151,7 +151,7 @@ Description:
 
 If there is pre-deploy SQL, ask the user to **explicitly confirm that the block is complete and correct** — it will be executed in production.
 
-Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
+The preview is the last thing before the question — **no tool call between them** (flow-core §3), or the block the user is meant to approve is the one their terminal folds away. Then ask with `AskUserQuestion` (header: "Create <MR or PR>"):
 
 - **Create with this content** → invoke §4.
 - **Edit before creating** → user says what to change (title, a section, both); adjust and return to §3 with the new preview.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.73.0",
+  "version": "0.74.0",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
   "type": "module",
   "bin": {

package/plugins/flow/.claude-plugin/plugin.json

@@ -3,7 +3,7 @@
   "name": "flow",
   "displayName": "Flow — guided dev workflows",
   "description": "Guided feat/bug workflows (start→ship), post-deploy monitoring and multi-agent code review, stack-agnostic. Each repo uses a shared FLOW.md plus optional harness overlay.",
-  "version": "0.73.0",
+  "version": "0.74.0",
   "author": {
     "name": "Alberto Vioque",
     "email": "mashware@gmail.com"

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,22 @@ plugin and is what `/flow:news` reads to show you what changed since your previo
 
 The canonical, richest notes live in the [GitHub Releases](https://github.com/mashware/flow-workflows/releases).
 
+## v0.74.0 — The thing you were asked to approve was the thing the terminal hid  ·  2026-09-22
+
+**In short**
+- **What a gate asks about now travels with the question** — the brief, the MR/PR body, the plan — so it is read in the prompt being answered instead of by opening the artifact in an editor.
+- **Nothing runs between showing it and asking.** A tool call right after is what lets a terminal collapse that message into one line, and the line it collapses is exactly the one the user needed.
+- Applied at the two briefs (`feat:build`, `bug:fix`) and at the MR/PR preview, the three gates that exist to catch scope before there is a diff to argue with.
+
+The rule already said to print the brief and then ask. It never said what had to sit between them,
+so a status line, a file write or a `git` call landed in the middle — and a chat UI that folds a
+message once a tool call follows it turned a nine-line brief into "· summarized". What reached the
+user was a one-line paraphrase above a Yes/No, and the honest way to answer it was to open
+`05-implementation.md` and read the brief there, which is the cost the gate exists to avoid.
+
+Where a harness's question cannot hold the content, it is printed as the **last** thing before
+asking, with the tool calls already done.
+
 ## v0.73.0 — The panel kept asking what you had already answered  ·  2026-09-22
 
 **In short**