flow-workflows 0.75.0 → 0.76.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.75.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.76.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

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

@@ -95,7 +95,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `$flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 

package/adapters/codex/skills/flow-doctor/SKILL.md

@@ -235,6 +235,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -150,6 +150,8 @@ Execution mode:
 
 Use `TaskCreate` to track the steps of the **§2.0ter plan for this MR/PR** — one task per numbered step, same order. Step skipped there (small MR/PR) → seed from `03-design.md` §"Implementation plan (order)", taking only the steps this MR/PR covers per `04-mr-plan.md`; the feature's plan predates the split and carries steps that belong to siblings. Mark each step `in_progress` when starting and `completed` when done — do not batch.
 
+**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+
 ### 2.1bis The premise this change rests on (any size, XS included)
 
 `$flow-feat-design §6` challenges the beliefs a plan rests on — and XS never runs `design`. On a
@@ -197,9 +199,9 @@ The step's changes are **always reported before anything is recorded**. Who deci
 - **`guided`** — ask **once**, at the first step; apply the answer to the rest of this build and record it in `05-implementation.md`. Do not re-ask per step.
 - **`auto`** — commit the step's WIP yourself and continue. **Invoking a flow command with `autonomy.mode: auto` is the explicit authorization** the system rule (*never commit unless the user asks*) requires. It authorizes **only** WIP commits on the work branch: push and MR/PR creation remain hard gates in every mode.
 
-**After completing each `TaskCreate` step**:
+**After completing each plan step**:
 
-1. **Mark the step `completed`** in `TaskCreate`.
+1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.75.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.76.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

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

@@ -91,7 +91,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow:feat:build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 

package/adapters/gemini/commands/flow/doctor.toml

@@ -231,6 +231,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -146,6 +146,8 @@ Execution mode:
 
 Use `TaskCreate` to track the steps of the **§2.0ter plan for this MR/PR** — one task per numbered step, same order. Step skipped there (small MR/PR) → seed from `03-design.md` §"Implementation plan (order)", taking only the steps this MR/PR covers per `04-mr-plan.md`; the feature's plan predates the split and carries steps that belong to siblings. Mark each step `in_progress` when starting and `completed` when done — do not batch.
 
+**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+
 ### 2.1bis The premise this change rests on (any size, XS included)
 
 `/flow:feat:design §6` challenges the beliefs a plan rests on — and XS never runs `design`. On a
@@ -193,9 +195,9 @@ The step's changes are **always reported before anything is recorded**. Who deci
 - **`guided`** — ask **once**, at the first step; apply the answer to the rest of this build and record it in `05-implementation.md`. Do not re-ask per step.
 - **`auto`** — commit the step's WIP yourself and continue. **Invoking a flow command with `autonomy.mode: auto` is the explicit authorization** the system rule (*never commit unless the user asks*) requires. It authorizes **only** WIP commits on the work branch: push and MR/PR creation remain hard gates in every mode.
 
-**After completing each `TaskCreate` step**:
+**After completing each plan step**:
 
-1. **Mark the step `completed`** in `TaskCreate`.
+1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.75.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.76.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

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

@@ -95,7 +95,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 

package/adapters/hermes/skills/flow-doctor/SKILL.md

@@ -235,6 +235,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -150,6 +150,8 @@ Execution mode:
 
 Use `TaskCreate` to track the steps of the **§2.0ter plan for this MR/PR** — one task per numbered step, same order. Step skipped there (small MR/PR) → seed from `03-design.md` §"Implementation plan (order)", taking only the steps this MR/PR covers per `04-mr-plan.md`; the feature's plan predates the split and carries steps that belong to siblings. Mark each step `in_progress` when starting and `completed` when done — do not batch.
 
+**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+
 ### 2.1bis The premise this change rests on (any size, XS included)
 
 `/flow-feat-design §6` challenges the beliefs a plan rests on — and XS never runs `design`. On a
@@ -197,9 +199,9 @@ The step's changes are **always reported before anything is recorded**. Who deci
 - **`guided`** — ask **once**, at the first step; apply the answer to the rest of this build and record it in `05-implementation.md`. Do not re-ask per step.
 - **`auto`** — commit the step's WIP yourself and continue. **Invoking a flow command with `autonomy.mode: auto` is the explicit authorization** the system rule (*never commit unless the user asks*) requires. It authorizes **only** WIP commits on the work branch: push and MR/PR creation remain hard gates in every mode.
 
-**After completing each `TaskCreate` step**:
+**After completing each plan step**:
 
-1. **Mark the step `completed`** in `TaskCreate`.
+1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

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.75.0`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.76.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

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

@@ -93,7 +93,7 @@ Save it in `04-fix.md` under `## Plan`, right after the brief. **A fix that was
 
 - Apply the minimal fix targeting the finding of `03-investigation.md` (or the diagnosis if investigate was skipped).
 - Sensitive area (authentication, payments, sensitive data) → consult the `agents.architecture` agent from FLOW.md to confirm the correct layer; empty → check against `conventions` in FLOW.md.
-- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one, otherwise tick them off in `04-fix.md` where they stand. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
+- More than 2 fix steps → the §2.0bis plan is already written: track its numbered steps with `TaskCreate` where the harness offers one — looked for as `/flow-feat-build §2.1` says, since it may be deferred or named otherwise — otherwise tick them off in `04-fix.md` where they stand and say so once in the first step report. One task per step, same order, marked `in_progress` and `completed` as they go — not batched.
 - **Comment discipline**: comment only a *why* the code cannot say (a non-obvious constraint, the reason for a workaround, a subtle invariant); match the surrounding file's comment density. **Never write the ticket ID or "fix for #N" into a code comment** — that lives in the commit/branch/MR-PR.
 - Keep the log updated while editing.
 

package/adapters/opencode/commands/flow-doctor.md

@@ -233,6 +233,7 @@ refuse) · **degraded** (it runs, quietly worse than the config promises), plus
   a non-negative integer (`0` = no ceiling; else the default `12` applies). Report both effective
   numbers with the count of panel members `quality.review_skill`/`quality.reviewers` defines, so
   the widest command's cost is visible before it is paid, not after.
+- **A task-list tool** (`TaskCreate` on Claude Code, possibly deferred) is exposed. Absent → `build` and `fix` track their plan steps as a checklist in the phase artifact instead, and the terminal draws no step list — `warn`, not `fail`. On Claude Code the usual cause is a model the harness withholds it from by default: name the fix, `"CLAUDE_CODE_ENABLE_TODO_TOOLS": "true"` under `env` in `~/.claude/settings.json`.
 - **The `flow-workflows` CLI, which `review` reaches for before it composes a panel**:
   `npx flow-workflows@<version> --version` answers, with `<version>` read from `version` in
   `~/.claude/flow/.claude-plugin/plugin.json` — the same pin `review` uses, so the number that

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

@@ -148,6 +148,8 @@ Execution mode:
 
 Use `TaskCreate` to track the steps of the **§2.0ter plan for this MR/PR** — one task per numbered step, same order. Step skipped there (small MR/PR) → seed from `03-design.md` §"Implementation plan (order)", taking only the steps this MR/PR covers per `04-mr-plan.md`; the feature's plan predates the split and carries steps that belong to siblings. Mark each step `in_progress` when starting and `completed` when done — do not batch.
 
+**Find the task-list tool before you conclude there is none.** `TaskCreate` is the Claude Code name; a harness may call it otherwise (`TodoWrite` on older builds), list it **deferred** — by name only, uncallable until its schema is loaded — or not offer it at all: Claude Code withholds it from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set. A deferred tool is a tool that is there: load it and seed the list. Only when the search comes back empty, the plan in `05-implementation.md` **is** the list — tick each step there (`- [x]`) as it lands, same cadence, and say it once in the first step report (`no task-list tool here — steps tracked in 05-implementation.md`), so the user does not wait for a list that will never draw. An instruction to use a tool that is not there is otherwise skipped in silence, and the plan is written and never followed.
+
 ### 2.1bis The premise this change rests on (any size, XS included)
 
 `/flow-feat-design §6` challenges the beliefs a plan rests on — and XS never runs `design`. On a
@@ -195,9 +197,9 @@ The step's changes are **always reported before anything is recorded**. Who deci
 - **`guided`** — ask **once**, at the first step; apply the answer to the rest of this build and record it in `05-implementation.md`. Do not re-ask per step.
 - **`auto`** — commit the step's WIP yourself and continue. **Invoking a flow command with `autonomy.mode: auto` is the explicit authorization** the system rule (*never commit unless the user asks*) requires. It authorizes **only** WIP commits on the work branch: push and MR/PR creation remain hard gates in every mode.
 
-**After completing each `TaskCreate` step**:
+**After completing each plan step**:
 
-1. **Mark the step `completed`** in `TaskCreate`.
+1. **Mark the step `completed`** in the task list — or tick it in `05-implementation.md` where there is none (§2.1).
 2. **Report to the user** a step summary (≤ 5 lines):
    ```
    Step N done: <description>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.75.0",
+  "version": "0.76.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.75.0",
+  "version": "0.76.0",
   "author": {
     "name": "Alberto Vioque",
     "email": "mashware@gmail.com"

package/plugins/flow/CHANGELOG.md

@@ -5,6 +5,20 @@ 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.76.0 — The plan was written for a list the terminal was never given  ·  2026-09-22
+
+**In short**
+- **`build` and `fix` look for the task-list tool before they use it**, including the deferred list,
+  and when there is none they tick the plan's steps in the phase artifact and say so once.
+- **`/flow:doctor` reports whether a task-list tool is there**, and on Claude Code names the setting
+  that brings it back.
+
+Since v0.70.0 `build` writes a plan per MR/PR and seeds the terminal's step list from it. On 22
+September the plan was written (`## Plan MR/PR #3`) and no list ever appeared: Claude Code withholds
+its task tools from newer models unless `CLAUDE_CODE_ENABLE_TODO_TOOLS=true` is set, and when the
+setting is on it lists them deferred. Either way the instruction named a tool that was not callable,
+and it was skipped without a word — across three sessions, not one task call.
+
 ## v0.75.0 — The words the panel understands now travel with every command  ·  2026-09-22
 
 **In short**