flow-workflows 0.94.1 → 0.95.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.94.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.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
@@ -249,16 +249,18 @@ sensible default and record it.
 
 Asking these anyway is how a run in `guided`/`auto` degrades into a manual one.
 
-**A study made for handoff.** `git.handoff_branch` set and the mode not `unattended` → the study is
-built somewhere else, so wherever a study phase (`start`, `design`, `plan`, `investigate`) or
-`resume` would hand the work to `$flow-feat-build` or `$flow-bug-fix`, it hands it to
-`$flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
+**A study made for handoff.** A work started with `--study` (`$flow-feat-start`,
+`$flow-bug-start`) records `meta.json.handoff: true`: it is studied here and built somewhere else.
+That field set and the mode not `unattended` → wherever a study phase (`start`, `design`, `plan`,
+`investigate`) or `resume` would hand the work to `$flow-feat-build` or `$flow-bug-fix`, it hands it
+to `$flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
 off the study** recommended and **Build here** second; a Close that chains (`guided`/`auto`) chains
-into handoff, whose push question is the one confirmation — no stop is added. In `unattended` the
-rule does not apply: the repo's `FLOW.md` reaches the server too, and a run that studies a ticket
-there goes on to build it — unless the orchestrator launched it as a study run (§2.1), which stops
-at the door to code. A repo that hands its studies off pairs the key with
-`autonomy.mode: auto`, and the study then runs on its own up to the push.
+into handoff, whose push question is the one confirmation — no stop is added. A work started without
+`--study` is built here, whatever `git.handoff_branch` says: the key only names where a study is
+pushed, so one repo can hold both kinds of work. In `unattended` the rule does not apply: a run that
+studies a ticket there goes on to build it — unless the orchestrator launched it as a study run
+(§2.1), which stops at the door to code. With `autonomy.mode: auto`, a `--study` work runs on its
+own up to the push.
 
 ### 2.1 `unattended` — where a person would have been asked
 

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

@@ -36,7 +36,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
-- `type` is not `bug` → refuse. `size` is `XS` → suggest `$flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
+- `type` is not `bug` → refuse. `size` is `XS` → suggest `$flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
 - Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
@@ -232,5 +232,5 @@ If `knowledge.stage` is set and the root cause reveals a **non-obvious "why"** a
 
 - Update `meta.json`: `phase = "investigate"`, add to `phases_done`.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
-- Suggest `$flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `$flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `$flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `$flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -22,12 +22,13 @@ Start a bug. `$ARGUMENTS` is **optional**:
 
 - **Given** — a ticket (format `tracker.prefix` from FLOW.md) → *ticket mode*: start from it (§1 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop. Synthesize the bug from the conversation just held with the user (§1.5). Ask for a one-line symptom only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The bug is studied here and fixed somewhere else: §4 records `meta.json.handoff: true`, and the study ends at `$flow-work-handoff` instead of `fix` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work fixed here. Without the flag the bug is fixed here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §1's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §1.1; `$ARGUMENTS` that disagrees with `number` is
-ignored and named. The order failing or empty → `blocked` · **the base is the ticket's `base`**
+ignored and named, and `--study` is ignored (the orchestrator says why it launched the run). The order failing or empty → `blocked` · **the base is the ticket's `base`**
 (empty → `git.default_base`), recorded as `meta.json.base` — the branch of §3 starts there, and asks
 nothing · uncommitted changes, or a checkout not on that base → `blocked`: the orchestrator owns the
 checkout · the branch is named `<number>-<slug>` whatever `git.branch_pattern` says · cross-repo
@@ -47,7 +48,7 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Verify you are in the correct repo.
-- **Determine the mode** from `$ARGUMENTS`: non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
+- **Determine the mode** from `$ARGUMENTS` (`--study` already taken out): non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
 - Once the identifier is known, check whether the work already exists: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after §1.5.2 decides the slug. If one exists, suggest `$flow-work-resume`.
 - This command **creates** `00-summary.md` (§4); there is nothing to read yet.
 
@@ -185,6 +186,8 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
+Add `"handoff": true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
+
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 
 **This fix *is* an accepted follow-up** (the ticket came from another work's `followups[]` — typically a prevention action or a neighbouring bug, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim rather than re-deriving it, and move the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin`.
@@ -228,6 +231,6 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket` and `{ASSIGNEE}` =
 
 ## 5. Close
 
-- Suggest the next command by size: `$flow-bug-fix` for XS (`git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `$flow-bug-investigate` for the rest.
+- Suggest the next command by size: `$flow-bug-fix` for XS (`meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `$flow-bug-investigate` for the rest.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Apply `autonomy.mode`: `manual` stops and recommends; `guided`/`auto` chain into that command automatically, subject to the hard gates.

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

@@ -40,7 +40,7 @@ after writing each challenge's Response.
 
 - Load `meta.json` by current branch — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `$flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
-- `size` is `XS` → suggest jumping to `$flow-feat-build` — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
+- `size` is `XS` → suggest jumping to `$flow-feat-build` — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
 
 ## 1.5 Approaches — open the option space first (M/L)
 
@@ -438,6 +438,6 @@ Never invoke `knowledge.save` here — the final save is in `$flow-feat-ship` af
 - **Confirm the acceptance criteria** within the design review: present the enumerated list. If every criterion is unambiguous and verifiable, the review covers them — no separate prompt. `AskUserQuestion` **only** when a criterion is ambiguous, not verifiable, or one is likely missing for today's ticket (same restraint as the challenger). Apply the user's edits to `03-design.md` before advancing.
 - **In `manual`/`guided`**, ask the user to review the design; edit the artifact on requested changes before advancing. **In `auto`, do not ask** — record it as accepted per the handoff below. Not an unconditional stop.
 - Next step by size:
-  - **XS / S**: suggest `$flow-feat-build` (1 single MR/PR, no planned split) — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+  - **XS / S**: suggest `$flow-feat-build` (1 single MR/PR, no planned split) — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
   - **M / L**: suggest `$flow-feat-plan` to split the work into independently mergeable MRs/PRs before implementing.
-- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.
+- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.

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

@@ -31,7 +31,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 - Load `meta.json` by current branch — in `unattended`, the work `$flow-work-run` found (flow-core §2.1). Missing → send the user to `$flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `$flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md` — and, when `01-context.md` has `## Study revisions` (a person's reply to an unattended study, flow-core §2.1), that section too: a request about the split is applied here, and goes into §2's brief. (flow-core §5)
-- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `$flow-feat-build` — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
+- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `$flow-feat-build` — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
 
 ## 2. Work
 
@@ -166,5 +166,5 @@ A slice landing in **another repo** is not one of *this* repo's `mrs`: record it
 
   `∥` = no dependency between them, can be built in parallel or as a train; `→` = the next wave waits for the previous one to merge. Then the table with `#`, wave, `depends_on`, title and estimate. One line for the split rationale, and — when any pair was merged — one line saying how many were and what they would have cost (`merged #a into #b: would have been a wave of its own`). Nothing else — risks and discarded alternatives live in the artifact.
 - Changes requested → edit the artifact and `meta.json.mrs` before advancing.
-- Suggest `$flow-feat-build` to start the first MR/PR — `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `$flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `$flow-feat-build` to start the first MR/PR — `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `$flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -28,12 +28,14 @@ Read `~/.claude/flow/CORE.codex.md` first (shared rules: `FLOW.md` step 0, model
 
 - **Given** — an identifier in `tracker.prefix` format from `FLOW.md` → *ticket mode* (§2 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop or demand a ticket. Draft a ticket from the conversation just held (§2.5), as `$flow-feat-ship` builds the MR/PR body from the work log. Ask for a one-liner only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The work is studied here and built somewhere else: §6 records `meta.json.handoff: true`, and the study ends at `$flow-work-handoff` instead of `build` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work built here. Without the flag the work is built here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §2's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §2.1, read as that section says; `$ARGUMENTS` that
-disagrees with `number` is ignored and named. The order failing or empty → `blocked` (there is no
+disagrees with `number` is ignored and named, and `--study` is ignored (the orchestrator says why it
+launched the run). The order failing or empty → `blocked` (there is no
 conversation to draft from and nobody to paste it) · **the base is the ticket's `base`** (empty →
 `git.default_base`), recorded as `meta.json.base` — the branch of §5.2 starts there, never from
 where the checkout stands, and §5.1 asks nothing · uncommitted changes, or a checkout not on that
@@ -53,7 +55,7 @@ its reason file in a `mktemp -d` directory (flow-core §2.1).
 - Read the effective FLOW configuration per flow-core §0; no FLOW layer present → each
   step's default. This command **creates** `00-summary.md` (§6) instead of reading it (flow-core §5).
 - No recognizable project structure → warn and stop.
-- **Determine the mode**: `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
+- **Determine the mode** (`--study` already taken out): `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
 - Once the identifier is known, check the work does not exist: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after the slug is decided in §2.5. Exists → do not overwrite; warn and suggest `$flow-work-resume`.
 
 **Work directory naming.** Work lives in `.claude/work/<work-dir>/`. `meta.json.ticket` stays the **pure identifier** (real ticket id, or the slug in ticket-less local-only) — it feeds the tracker view, the issue link and `{TICKET}`. The directory adds a slug:
@@ -254,6 +256,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 }
 ```
 
+- `handoff` — `true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
 - `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `$flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
@@ -309,5 +312,5 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket`, `{ASSIGNEE}` = `tr
 ## 7. Close
 
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5) — first written in §6; refresh it if §6.5 changed anything.
-- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
+- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
 - Apply `autonomy.mode`: `manual` → stop and let the user invoke the recommended command; `guided`/`auto` → chain into it, subject to the hard gates (the §5 branch-base ambiguity already stops on its own).

package/adapters/codex/skills/flow-work-README/SKILL.md

@@ -256,7 +256,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
 - `$flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`$flow-feat-start`, `$flow-work-green`, `$flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `$flow-news`.
 - `$flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
 - `$flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · study · answer · merged · review · pipeline), routes to the phase that answers it — a `study` run stops at the door to code with a summary for a person to approve — and makes no decision of its own. Refuses to run in any other mode.
-- `$flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`).
+- `$flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`). A work started with `$flow-feat-start --study` (or `$flow-bug-start --study`) ends its study here on its own; one started without the flag is built here, even with the key set.
 - `$flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `$flow-work-try <branch>` / `$flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `$flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

package/adapters/codex/skills/flow-work-resume/SKILL.md

@@ -92,7 +92,7 @@ With what is new (there is already work on disk):
 ## 4. Next step
 
 - An `Unattended:` line → the question is the orchestrator's to bring back: say so, and that answering it here instead means clearing `meta.json.pending` and continuing in this session's mode; the next step itself comes from `phase` as always.
-- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `git.handoff_branch` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `$flow-feat-build` or `$flow-bug-fix`.
+- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `meta.json.handoff` set and not `unattended` → `$flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `$flow-feat-build` or `$flow-bug-fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `$flow-feat-start <TICKET>` there. flow only reminds; it never scans or touches the other repo.
 - Do not advance on your own. The user decides.

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.94.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.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
@@ -248,16 +248,18 @@ sensible default and record it.
 
 Asking these anyway is how a run in `guided`/`auto` degrades into a manual one.
 
-**A study made for handoff.** `git.handoff_branch` set and the mode not `unattended` → the study is
-built somewhere else, so wherever a study phase (`start`, `design`, `plan`, `investigate`) or
-`resume` would hand the work to `/flow:feat:build` or `/flow:bug:fix`, it hands it to
-`/flow:work:handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
+**A study made for handoff.** A work started with `--study` (`/flow:feat:start`,
+`/flow:bug:start`) records `meta.json.handoff: true`: it is studied here and built somewhere else.
+That field set and the mode not `unattended` → wherever a study phase (`start`, `design`, `plan`,
+`investigate`) or `resume` would hand the work to `/flow:feat:build` or `/flow:bug:fix`, it hands it
+to `/flow:work:handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
 off the study** recommended and **Build here** second; a Close that chains (`guided`/`auto`) chains
-into handoff, whose push question is the one confirmation — no stop is added. In `unattended` the
-rule does not apply: the repo's `FLOW.md` reaches the server too, and a run that studies a ticket
-there goes on to build it — unless the orchestrator launched it as a study run (§2.1), which stops
-at the door to code. A repo that hands its studies off pairs the key with
-`autonomy.mode: auto`, and the study then runs on its own up to the push.
+into handoff, whose push question is the one confirmation — no stop is added. A work started without
+`--study` is built here, whatever `git.handoff_branch` says: the key only names where a study is
+pushed, so one repo can hold both kinds of work. In `unattended` the rule does not apply: a run that
+studies a ticket there goes on to build it — unless the orchestrator launched it as a study run
+(§2.1), which stops at the door to code. With `autonomy.mode: auto`, a `--study` work runs on its
+own up to the push.
 
 ### 2.1 `unattended` — where a person would have been asked
 

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

@@ -32,7 +32,7 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
-- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow:bug:fix` — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
+- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow:bug:fix` — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
 - Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
@@ -228,6 +228,6 @@ If `knowledge.stage` is set and the root cause reveals a **non-obvious "why"** a
 
 - Update `meta.json`: `phase = "investigate"`, add to `phases_done`.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
-- Suggest `/flow:bug:fix` — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow:bug:fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow:bug:fix` — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow:bug:fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
 """

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

@@ -18,12 +18,13 @@ Start a bug. `{{args}}` is **optional**:
 
 - **Given** — a ticket (format `tracker.prefix` from FLOW.md) → *ticket mode*: start from it (§1 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop. Synthesize the bug from the conversation just held with the user (§1.5). Ask for a one-line symptom only if there is no conversation to draft from.
+- **`--study`**, anywhere in `{{args}}` — a flag, not part of the identifier: take it out before deciding the mode. The bug is studied here and fixed somewhere else: §4 records `meta.json.handoff: true`, and the study ends at `/flow:work:handoff` instead of `fix` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work fixed here. Without the flag the bug is fixed here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §1's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §1.1; `{{args}}` that disagrees with `number` is
-ignored and named. The order failing or empty → `blocked` · **the base is the ticket's `base`**
+ignored and named, and `--study` is ignored (the orchestrator says why it launched the run). The order failing or empty → `blocked` · **the base is the ticket's `base`**
 (empty → `git.default_base`), recorded as `meta.json.base` — the branch of §3 starts there, and asks
 nothing · uncommitted changes, or a checkout not on that base → `blocked`: the orchestrator owns the
 checkout · the branch is named `<number>-<slug>` whatever `git.branch_pattern` says · cross-repo
@@ -43,7 +44,7 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Verify you are in the correct repo.
-- **Determine the mode** from `{{args}}`: non-empty → *ticket mode* (identifier = `{{args}}`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
+- **Determine the mode** from `{{args}}` (`--study` already taken out): non-empty → *ticket mode* (identifier = `{{args}}`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
 - Once the identifier is known, check whether the work already exists: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after §1.5.2 decides the slug. If one exists, suggest `/flow:work:resume`.
 - This command **creates** `00-summary.md` (§4); there is nothing to read yet.
 
@@ -181,6 +182,8 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
+Add `"handoff": true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
+
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 
 **This fix *is* an accepted follow-up** (the ticket came from another work's `followups[]` — typically a prevention action or a neighbouring bug, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim rather than re-deriving it, and move the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin`.
@@ -224,7 +227,7 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket` and `{ASSIGNEE}` =
 
 ## 5. Close
 
-- Suggest the next command by size: `/flow:bug:fix` for XS (`git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow:bug:investigate` for the rest.
+- Suggest the next command by size: `/flow:bug:fix` for XS (`meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow:bug:investigate` for the rest.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Apply `autonomy.mode`: `manual` stops and recommends; `guided`/`auto` chain into that command automatically, subject to the hard gates.
 """

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

@@ -36,7 +36,7 @@ after writing each challenge's Response.
 
 - Load `meta.json` by current branch — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Missing → ask the user to start with `/flow:feat:start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
-- `size` is `XS` → suggest jumping to `/flow:feat:build` — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
+- `size` is `XS` → suggest jumping to `/flow:feat:build` — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
 
 ## 1.5 Approaches — open the option space first (M/L)
 
@@ -434,7 +434,7 @@ Never invoke `knowledge.save` here — the final save is in `/flow:feat:ship` af
 - **Confirm the acceptance criteria** within the design review: present the enumerated list. If every criterion is unambiguous and verifiable, the review covers them — no separate prompt. `AskUserQuestion` **only** when a criterion is ambiguous, not verifiable, or one is likely missing for today's ticket (same restraint as the challenger). Apply the user's edits to `03-design.md` before advancing.
 - **In `manual`/`guided`**, ask the user to review the design; edit the artifact on requested changes before advancing. **In `auto`, do not ask** — record it as accepted per the handoff below. Not an unconditional stop.
 - Next step by size:
-  - **XS / S**: suggest `/flow:feat:build` (1 single MR/PR, no planned split) — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+  - **XS / S**: suggest `/flow:feat:build` (1 single MR/PR, no planned split) — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
   - **M / L**: suggest `/flow:feat:plan` to split the work into independently mergeable MRs/PRs before implementing.
-- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.
+- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.
 """

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

@@ -27,7 +27,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 - Load `meta.json` by current branch — in `unattended`, the work `/flow:work:run` found (flow-core §2.1). Missing → send the user to `/flow:feat:start`.
 - Require `design` in `phases_done`. Missing → send to `/flow:feat:design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md` — and, when `01-context.md` has `## Study revisions` (a person's reply to an unattended study, flow-core §2.1), that section too: a request about the split is applied here, and goes into §2's brief. (flow-core §5)
-- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow:feat:build` — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
+- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow:feat:build` — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
 
 ## 2. Work
 
@@ -162,6 +162,6 @@ A slice landing in **another repo** is not one of *this* repo's `mrs`: record it
 
   `∥` = no dependency between them, can be built in parallel or as a train; `→` = the next wave waits for the previous one to merge. Then the table with `#`, wave, `depends_on`, title and estimate. One line for the split rationale, and — when any pair was merged — one line saying how many were and what they would have cost (`merged #a into #b: would have been a wave of its own`). Nothing else — risks and discarded alternatives live in the artifact.
 - Changes requested → edit the artifact and `meta.json.mrs` before advancing.
-- Suggest `/flow:feat:build` to start the first MR/PR — `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow:feat:build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow:feat:build` to start the first MR/PR — `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow:feat:build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
 """

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

@@ -24,12 +24,14 @@ Read `~/.claude/flow/CORE.gemini.md` first (shared rules: `FLOW.md` step 0, mode
 
 - **Given** — an identifier in `tracker.prefix` format from `FLOW.md` → *ticket mode* (§2 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop or demand a ticket. Draft a ticket from the conversation just held (§2.5), as `/flow:feat:ship` builds the MR/PR body from the work log. Ask for a one-liner only if there is no conversation to draft from.
+- **`--study`**, anywhere in `{{args}}` — a flag, not part of the identifier: take it out before deciding the mode. The work is studied here and built somewhere else: §6 records `meta.json.handoff: true`, and the study ends at `/flow:work:handoff` instead of `build` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work built here. Without the flag the work is built here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §2's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §2.1, read as that section says; `{{args}}` that
-disagrees with `number` is ignored and named. The order failing or empty → `blocked` (there is no
+disagrees with `number` is ignored and named, and `--study` is ignored (the orchestrator says why it
+launched the run). The order failing or empty → `blocked` (there is no
 conversation to draft from and nobody to paste it) · **the base is the ticket's `base`** (empty →
 `git.default_base`), recorded as `meta.json.base` — the branch of §5.2 starts there, never from
 where the checkout stands, and §5.1 asks nothing · uncommitted changes, or a checkout not on that
@@ -49,7 +51,7 @@ its reason file in a `mktemp -d` directory (flow-core §2.1).
 - Read the effective FLOW configuration per flow-core §0; no FLOW layer present → each
   step's default. This command **creates** `00-summary.md` (§6) instead of reading it (flow-core §5).
 - No recognizable project structure → warn and stop.
-- **Determine the mode**: `{{args}}` non-empty → *ticket mode* (identifier = `{{args}}`); empty → *ticket-less* (identifier = the §2.5 slug).
+- **Determine the mode** (`--study` already taken out): `{{args}}` non-empty → *ticket mode* (identifier = `{{args}}`); empty → *ticket-less* (identifier = the §2.5 slug).
 - Once the identifier is known, check the work does not exist: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after the slug is decided in §2.5. Exists → do not overwrite; warn and suggest `/flow:work:resume`.
 
 **Work directory naming.** Work lives in `.claude/work/<work-dir>/`. `meta.json.ticket` stays the **pure identifier** (real ticket id, or the slug in ticket-less local-only) — it feeds the tracker view, the issue link and `{TICKET}`. The directory adds a slug:
@@ -250,6 +252,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 }
 ```
 
+- `handoff` — `true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
 - `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow:work:run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
@@ -305,6 +308,6 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket`, `{ASSIGNEE}` = `tr
 ## 7. Close
 
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5) — first written in §6; refresh it if §6.5 changed anything.
-- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
+- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
 - Apply `autonomy.mode`: `manual` → stop and let the user invoke the recommended command; `guided`/`auto` → chain into it, subject to the hard gates (the §5 branch-base ambiguity already stops on its own).
 """

package/adapters/gemini/commands/flow/work/README.toml

@@ -252,7 +252,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
 - `/flow:work:daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow:feat:start`, `/flow:work:green`, `/flow:work:respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow:news`.
 - `/flow:work:status` — all works in `.claude/work/`, current phase, divergence with git.
 - `/flow:work:run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · study · answer · merged · review · pipeline), routes to the phase that answers it — a `study` run stops at the door to code with a summary for a person to approve — and makes no decision of its own. Refuses to run in any other mode.
-- `/flow:work:handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`).
+- `/flow:work:handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`). A work started with `/flow:feat:start --study` (or `/flow:bug:start --study`) ends its study here on its own; one started without the flag is built here, even with the key set.
 - `/flow:work:resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow:work:try <branch>` / `/flow:work:try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow:work:clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

package/adapters/gemini/commands/flow/work/resume.toml

@@ -88,7 +88,7 @@ With what is new (there is already work on disk):
 ## 4. Next step
 
 - An `Unattended:` line → the question is the orchestrator's to bring back: say so, and that answering it here instead means clearing `meta.json.pending` and continuing in this session's mode; the next step itself comes from `phase` as always.
-- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `git.handoff_branch` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow:feat:build` or `/flow:bug:fix`.
+- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `meta.json.handoff` set and not `unattended` → `/flow:work:handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow:feat:build` or `/flow:bug:fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `/flow:feat:start <TICKET>` there. flow only reminds; it never scans or touches the other repo.
 - Do not advance on your own. The user decides.

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.94.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.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
@@ -249,16 +249,18 @@ sensible default and record it.
 
 Asking these anyway is how a run in `guided`/`auto` degrades into a manual one.
 
-**A study made for handoff.** `git.handoff_branch` set and the mode not `unattended` → the study is
-built somewhere else, so wherever a study phase (`start`, `design`, `plan`, `investigate`) or
-`resume` would hand the work to `/flow-feat-build` or `/flow-bug-fix`, it hands it to
-`/flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
+**A study made for handoff.** A work started with `--study` (`/flow-feat-start`,
+`/flow-bug-start`) records `meta.json.handoff: true`: it is studied here and built somewhere else.
+That field set and the mode not `unattended` → wherever a study phase (`start`, `design`, `plan`,
+`investigate`) or `resume` would hand the work to `/flow-feat-build` or `/flow-bug-fix`, it hands it
+to `/flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
 off the study** recommended and **Build here** second; a Close that chains (`guided`/`auto`) chains
-into handoff, whose push question is the one confirmation — no stop is added. In `unattended` the
-rule does not apply: the repo's `FLOW.md` reaches the server too, and a run that studies a ticket
-there goes on to build it — unless the orchestrator launched it as a study run (§2.1), which stops
-at the door to code. A repo that hands its studies off pairs the key with
-`autonomy.mode: auto`, and the study then runs on its own up to the push.
+into handoff, whose push question is the one confirmation — no stop is added. A work started without
+`--study` is built here, whatever `git.handoff_branch` says: the key only names where a study is
+pushed, so one repo can hold both kinds of work. In `unattended` the rule does not apply: a run that
+studies a ticket there goes on to build it — unless the orchestrator launched it as a study run
+(§2.1), which stops at the door to code. With `autonomy.mode: auto`, a `--study` work runs on its
+own up to the push.
 
 ### 2.1 `unattended` — where a person would have been asked
 

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

@@ -36,7 +36,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
-- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
+- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
 - Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
@@ -232,5 +232,5 @@ If `knowledge.stage` is set and the root cause reveals a **non-obvious "why"** a
 
 - Update `meta.json`: `phase = "investigate"`, add to `phases_done`.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
-- Suggest `/flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -22,12 +22,13 @@ Start a bug. `$ARGUMENTS` is **optional**:
 
 - **Given** — a ticket (format `tracker.prefix` from FLOW.md) → *ticket mode*: start from it (§1 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop. Synthesize the bug from the conversation just held with the user (§1.5). Ask for a one-line symptom only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The bug is studied here and fixed somewhere else: §4 records `meta.json.handoff: true`, and the study ends at `/flow-work-handoff` instead of `fix` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work fixed here. Without the flag the bug is fixed here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §1's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §1.1; `$ARGUMENTS` that disagrees with `number` is
-ignored and named. The order failing or empty → `blocked` · **the base is the ticket's `base`**
+ignored and named, and `--study` is ignored (the orchestrator says why it launched the run). The order failing or empty → `blocked` · **the base is the ticket's `base`**
 (empty → `git.default_base`), recorded as `meta.json.base` — the branch of §3 starts there, and asks
 nothing · uncommitted changes, or a checkout not on that base → `blocked`: the orchestrator owns the
 checkout · the branch is named `<number>-<slug>` whatever `git.branch_pattern` says · cross-repo
@@ -47,7 +48,7 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Verify you are in the correct repo.
-- **Determine the mode** from `$ARGUMENTS`: non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
+- **Determine the mode** from `$ARGUMENTS` (`--study` already taken out): non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
 - Once the identifier is known, check whether the work already exists: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after §1.5.2 decides the slug. If one exists, suggest `/flow-work-resume`.
 - This command **creates** `00-summary.md` (§4); there is nothing to read yet.
 
@@ -185,6 +186,8 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
+Add `"handoff": true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
+
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 
 **This fix *is* an accepted follow-up** (the ticket came from another work's `followups[]` — typically a prevention action or a neighbouring bug, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim rather than re-deriving it, and move the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin`.
@@ -228,6 +231,6 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket` and `{ASSIGNEE}` =
 
 ## 5. Close
 
-- Suggest the next command by size: `/flow-bug-fix` for XS (`git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow-bug-investigate` for the rest.
+- Suggest the next command by size: `/flow-bug-fix` for XS (`meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow-bug-investigate` for the rest.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Apply `autonomy.mode`: `manual` stops and recommends; `guided`/`auto` chain into that command automatically, subject to the hard gates.

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

@@ -40,7 +40,7 @@ after writing each challenge's Response.
 
 - Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `/flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
-- `size` is `XS` → suggest jumping to `/flow-feat-build` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
+- `size` is `XS` → suggest jumping to `/flow-feat-build` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
 
 ## 1.5 Approaches — open the option space first (M/L)
 
@@ -438,6 +438,6 @@ Never invoke `knowledge.save` here — the final save is in `/flow-feat-ship` af
 - **Confirm the acceptance criteria** within the design review: present the enumerated list. If every criterion is unambiguous and verifiable, the review covers them — no separate prompt. `AskUserQuestion` **only** when a criterion is ambiguous, not verifiable, or one is likely missing for today's ticket (same restraint as the challenger). Apply the user's edits to `03-design.md` before advancing.
 - **In `manual`/`guided`**, ask the user to review the design; edit the artifact on requested changes before advancing. **In `auto`, do not ask** — record it as accepted per the handoff below. Not an unconditional stop.
 - Next step by size:
-  - **XS / S**: suggest `/flow-feat-build` (1 single MR/PR, no planned split) — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+  - **XS / S**: suggest `/flow-feat-build` (1 single MR/PR, no planned split) — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
   - **M / L**: suggest `/flow-feat-plan` to split the work into independently mergeable MRs/PRs before implementing.
-- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.
+- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.

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

@@ -31,7 +31,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 - Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → send the user to `/flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `/flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md` — and, when `01-context.md` has `## Study revisions` (a person's reply to an unattended study, flow-core §2.1), that section too: a request about the split is applied here, and goes into §2's brief. (flow-core §5)
-- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
+- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
 
 ## 2. Work
 
@@ -166,5 +166,5 @@ A slice landing in **another repo** is not one of *this* repo's `mrs`: record it
 
   `∥` = no dependency between them, can be built in parallel or as a train; `→` = the next wave waits for the previous one to merge. Then the table with `#`, wave, `depends_on`, title and estimate. One line for the split rationale, and — when any pair was merged — one line saying how many were and what they would have cost (`merged #a into #b: would have been a wave of its own`). Nothing else — risks and discarded alternatives live in the artifact.
 - Changes requested → edit the artifact and `meta.json.mrs` before advancing.
-- Suggest `/flow-feat-build` to start the first MR/PR — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow-feat-build` to start the first MR/PR — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -28,12 +28,14 @@ Read `~/.claude/flow/CORE.hermes.md` first (shared rules: `FLOW.md` step 0, mode
 
 - **Given** — an identifier in `tracker.prefix` format from `FLOW.md` → *ticket mode* (§2 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop or demand a ticket. Draft a ticket from the conversation just held (§2.5), as `/flow-feat-ship` builds the MR/PR body from the work log. Ask for a one-liner only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The work is studied here and built somewhere else: §6 records `meta.json.handoff: true`, and the study ends at `/flow-work-handoff` instead of `build` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work built here. Without the flag the work is built here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §2's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §2.1, read as that section says; `$ARGUMENTS` that
-disagrees with `number` is ignored and named. The order failing or empty → `blocked` (there is no
+disagrees with `number` is ignored and named, and `--study` is ignored (the orchestrator says why it
+launched the run). The order failing or empty → `blocked` (there is no
 conversation to draft from and nobody to paste it) · **the base is the ticket's `base`** (empty →
 `git.default_base`), recorded as `meta.json.base` — the branch of §5.2 starts there, never from
 where the checkout stands, and §5.1 asks nothing · uncommitted changes, or a checkout not on that
@@ -53,7 +55,7 @@ its reason file in a `mktemp -d` directory (flow-core §2.1).
 - Read the effective FLOW configuration per flow-core §0; no FLOW layer present → each
   step's default. This command **creates** `00-summary.md` (§6) instead of reading it (flow-core §5).
 - No recognizable project structure → warn and stop.
-- **Determine the mode**: `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
+- **Determine the mode** (`--study` already taken out): `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
 - Once the identifier is known, check the work does not exist: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after the slug is decided in §2.5. Exists → do not overwrite; warn and suggest `/flow-work-resume`.
 
 **Work directory naming.** Work lives in `.claude/work/<work-dir>/`. `meta.json.ticket` stays the **pure identifier** (real ticket id, or the slug in ticket-less local-only) — it feeds the tracker view, the issue link and `{TICKET}`. The directory adds a slug:
@@ -254,6 +256,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 }
 ```
 
+- `handoff` — `true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
 - `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
@@ -309,5 +312,5 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket`, `{ASSIGNEE}` = `tr
 ## 7. Close
 
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5) — first written in §6; refresh it if §6.5 changed anything.
-- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
+- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
 - Apply `autonomy.mode`: `manual` → stop and let the user invoke the recommended command; `guided`/`auto` → chain into it, subject to the hard gates (the §5 branch-base ambiguity already stops on its own).

package/adapters/hermes/skills/flow-work-README/SKILL.md

@@ -256,7 +256,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
 - `/flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow-feat-start`, `/flow-work-green`, `/flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow-news`.
 - `/flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
 - `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · study · answer · merged · review · pipeline), routes to the phase that answers it — a `study` run stops at the door to code with a summary for a person to approve — and makes no decision of its own. Refuses to run in any other mode.
-- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`).
+- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`). A work started with `/flow-feat-start --study` (or `/flow-bug-start --study`) ends its study here on its own; one started without the flag is built here, even with the key set.
 - `/flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow-work-try <branch>` / `/flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

package/adapters/hermes/skills/flow-work-resume/SKILL.md

@@ -92,7 +92,7 @@ With what is new (there is already work on disk):
 ## 4. Next step
 
 - An `Unattended:` line → the question is the orchestrator's to bring back: say so, and that answering it here instead means clearing `meta.json.pending` and continuing in this session's mode; the next step itself comes from `phase` as always.
-- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
+- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `/flow-feat-start <TICKET>` there. flow only reminds; it never scans or touches the other repo.
 - Do not advance on your own. The user decides.

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.94.1`.** Compare it once, at the start of the session, against
+**This file belongs to flow `0.95.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
@@ -248,16 +248,18 @@ sensible default and record it.
 
 Asking these anyway is how a run in `guided`/`auto` degrades into a manual one.
 
-**A study made for handoff.** `git.handoff_branch` set and the mode not `unattended` → the study is
-built somewhere else, so wherever a study phase (`start`, `design`, `plan`, `investigate`) or
-`resume` would hand the work to `/flow-feat-build` or `/flow-bug-fix`, it hands it to
-`/flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
+**A study made for handoff.** A work started with `--study` (`/flow-feat-start`,
+`/flow-bug-start`) records `meta.json.handoff: true`: it is studied here and built somewhere else.
+That field set and the mode not `unattended` → wherever a study phase (`start`, `design`, `plan`,
+`investigate`) or `resume` would hand the work to `/flow-feat-build` or `/flow-bug-fix`, it hands it
+to `/flow-work-handoff` instead. Only the target changes: a Close that asks (`manual`) offers **Hand
 off the study** recommended and **Build here** second; a Close that chains (`guided`/`auto`) chains
-into handoff, whose push question is the one confirmation — no stop is added. In `unattended` the
-rule does not apply: the repo's `FLOW.md` reaches the server too, and a run that studies a ticket
-there goes on to build it — unless the orchestrator launched it as a study run (§2.1), which stops
-at the door to code. A repo that hands its studies off pairs the key with
-`autonomy.mode: auto`, and the study then runs on its own up to the push.
+into handoff, whose push question is the one confirmation — no stop is added. A work started without
+`--study` is built here, whatever `git.handoff_branch` says: the key only names where a study is
+pushed, so one repo can hold both kinds of work. In `unattended` the rule does not apply: a run that
+studies a ticket there goes on to build it — unless the orchestrator launched it as a study run
+(§2.1), which stops at the door to code. With `autonomy.mode: auto`, a `--study` work runs on its
+own up to the push.
 
 ### 2.1 `unattended` — where a person would have been asked
 

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

@@ -34,7 +34,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md`. (flow-core §5)
-- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
+- `type` is not `bug` → refuse. `size` is `XS` → suggest `/flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop.
 - Require `context` in `phases_done`.
 
 ## 1.5 Reproduce — what is failing, before why
@@ -230,5 +230,5 @@ If `knowledge.stage` is set and the root cause reveals a **non-obvious "why"** a
 
 - Update `meta.json`: `phase = "investigate"`, add to `phases_done`.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
-- Suggest `/flow-bug-fix` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow-bug-fix` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff** (`autonomy.mode`, flow-core §2): `manual` → propose `/flow-bug-fix` with a single `AskUserQuestion`, invoke it only on confirmation; `guided`/`auto` → chain into it in this same turn. Either way: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -20,12 +20,13 @@ Start a bug. `$ARGUMENTS` is **optional**:
 
 - **Given** — a ticket (format `tracker.prefix` from FLOW.md) → *ticket mode*: start from it (§1 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop. Synthesize the bug from the conversation just held with the user (§1.5). Ask for a one-line symptom only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The bug is studied here and fixed somewhere else: §4 records `meta.json.handoff: true`, and the study ends at `/flow-work-handoff` instead of `fix` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work fixed here. Without the flag the bug is fixed here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §1's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §1.1; `$ARGUMENTS` that disagrees with `number` is
-ignored and named. The order failing or empty → `blocked` · **the base is the ticket's `base`**
+ignored and named, and `--study` is ignored (the orchestrator says why it launched the run). The order failing or empty → `blocked` · **the base is the ticket's `base`**
 (empty → `git.default_base`), recorded as `meta.json.base` — the branch of §3 starts there, and asks
 nothing · uncommitted changes, or a checkout not on that base → `blocked`: the orchestrator owns the
 checkout · the branch is named `<number>-<slug>` whatever `git.branch_pattern` says · cross-repo
@@ -45,7 +46,7 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 **In `unattended`, before this phase's first step, read flow-core §2.1 whole — from its heading to the next section, unless it is already in your context whole; having read parts of it does not count** — the orchestrator command, the question stop and the way its answer comes back are all in it, and a phase that reads only part of it skips them.
 
 - Verify you are in the correct repo.
-- **Determine the mode** from `$ARGUMENTS`: non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
+- **Determine the mode** from `$ARGUMENTS` (`--study` already taken out): non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less mode* (identifier = the slug resolved in §1.5).
 - Once the identifier is known, check whether the work already exists: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after §1.5.2 decides the slug. If one exists, suggest `/flow-work-resume`.
 - This command **creates** `00-summary.md` (§4); there is nothing to read yet.
 
@@ -183,6 +184,8 @@ Create the work directory per §0: `.claude/work/<TICKET>-<slug>/` in ticket mod
 
 In `unattended`, add `"base"`: the ticket's `base`, or `git.default_base` when it is empty — never empty; the branch the fix starts from and targets. Omit it in every other mode.
 
+Add `"handoff": true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
+
 Populate `related_repos` from §1.6 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo the fix touches; `[]` for a single-repo fix. `pending` only when the fix **changes a surface that sibling consumes** (a payload key, an error code, a route, an event shape); otherwise `none`.
 
 **This fix *is* an accepted follow-up** (the ticket came from another work's `followups[]` — typically a prevention action or a neighbouring bug, flow-core §7) → set `origin: { "work": "<originating work dir>", "followup": "F<n>" }`, carry that entry's recorded `why` into `01-context.md` verbatim rather than re-deriving it, and move the originating entry to `in_progress` with `work` naming this folder. Not a follow-up → omit `origin`.
@@ -226,6 +229,6 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket` and `{ASSIGNEE}` =
 
 ## 5. Close
 
-- Suggest the next command by size: `/flow-bug-fix` for XS (`git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow-bug-investigate` for the rest.
+- Suggest the next command by size: `/flow-bug-fix` for XS (`meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)), `/flow-bug-investigate` for the rest.
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5).
 - Apply `autonomy.mode`: `manual` stops and recommends; `guided`/`auto` chain into that command automatically, subject to the hard gates.

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

@@ -38,7 +38,7 @@ after writing each challenge's Response.
 
 - Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → ask the user to start with `/flow-feat-start`.
 - Read `meta.json` and `00-summary.md`; open in full only `01-context.md` (ticket, decisions, contracts received). (flow-core §5)
-- `size` is `XS` → suggest jumping to `/flow-feat-build` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
+- `size` is `XS` → suggest jumping to `/flow-feat-build` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff) — and stop unless the user insists.
 
 ## 1.5 Approaches — open the option space first (M/L)
 
@@ -436,6 +436,6 @@ Never invoke `knowledge.save` here — the final save is in `/flow-feat-ship` af
 - **Confirm the acceptance criteria** within the design review: present the enumerated list. If every criterion is unambiguous and verifiable, the review covers them — no separate prompt. `AskUserQuestion` **only** when a criterion is ambiguous, not verifiable, or one is likely missing for today's ticket (same restraint as the challenger). Apply the user's edits to `03-design.md` before advancing.
 - **In `manual`/`guided`**, ask the user to review the design; edit the artifact on requested changes before advancing. **In `auto`, do not ask** — record it as accepted per the handoff below. Not an unconditional stop.
 - Next step by size:
-  - **XS / S**: suggest `/flow-feat-build` (1 single MR/PR, no planned split) — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+  - **XS / S**: suggest `/flow-feat-build` (1 single MR/PR, no planned split) — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
   - **M / L**: suggest `/flow-feat-plan` to split the work into independently mergeable MRs/PRs before implementing.
-- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.
+- **Autonomy handoff.** Design review is a genuine decision point: `manual` and `guided` ask for it before advancing. `auto` records the design as accepted in the artifact and **chains into the command for the size** in this same turn — `build` there: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). `manual` proposes that command with a single `AskUserQuestion` (recommended option by default), never a written suggestion. Unresolved `high`-severity findings (§6) stop the flow in **every** mode — do not chain over them.

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

@@ -29,7 +29,7 @@ Delivery planning phase. **No code is written.** Splits the feature into MRs/PRs
 - Load `meta.json` by current branch — in `unattended`, the work `/flow-work-run` found (flow-core §2.1). Missing → send the user to `/flow-feat-start`.
 - Require `design` in `phases_done`. Missing → send to `/flow-feat-design` and stop.
 - Read `meta.json` and `00-summary.md`; open in full only `03-design.md` — and, when `01-context.md` has `## Study revisions` (a person's reply to an unattended study, flow-core §2.1), that section too: a request about the split is applied here, and goes into §2's brief. (flow-core §5)
-- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build` — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
+- **`size` `XS` or `S`** → warn that this phase does not apply (always 1 MR/PR), add `"plan:skipped"` to `phases_done`, suggest `/flow-feat-build` — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Stop.
 
 ## 2. Work
 
@@ -164,5 +164,5 @@ A slice landing in **another repo** is not one of *this* repo's `mrs`: record it
 
   `∥` = no dependency between them, can be built in parallel or as a train; `→` = the next wave waits for the previous one to merge. Then the table with `#`, wave, `depends_on`, title and estimate. One line for the split rationale, and — when any pair was merged — one line saying how many were and what they would have cost (`merged #a into #b: would have been a wave of its own`). Nothing else — risks and discarded alternatives live in the artifact.
 - Changes requested → edit the artifact and `meta.json.mrs` before advancing.
-- Suggest `/flow-feat-build` to start the first MR/PR — `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
-- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- Suggest `/flow-feat-build` to start the first MR/PR — `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).
+- **Autonomy handoff.** Approving the split is a genuine decision point: in `manual` and `guided` ask before advancing. In `auto`, record the plan as accepted in `04-mr-plan.md` and **chain into `/flow-feat-build` automatically** in this same turn. In `manual`, propose it with a single `AskUserQuestion`. Either way: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff).

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

@@ -26,12 +26,14 @@ Read `~/.claude/flow/CORE.opencode.md` first (shared rules: `FLOW.md` step 0, mo
 
 - **Given** — an identifier in `tracker.prefix` format from `FLOW.md` → *ticket mode* (§2 reads it).
 - **Empty** — *ticket-less mode*: do **not** stop or demand a ticket. Draft a ticket from the conversation just held (§2.5), as `/flow-feat-ship` builds the MR/PR body from the work log. Ask for a one-liner only if there is no conversation to draft from.
+- **`--study`**, anywhere in `$ARGUMENTS` — a flag, not part of the identifier: take it out before deciding the mode. The work is studied here and built somewhere else: §6 records `meta.json.handoff: true`, and the study ends at `/flow-work-handoff` instead of `build` (flow-core §2, a study made for handoff). `git.handoff_branch` empty → say in one line that `--study` needs that key, and go on as a work built here. Without the flag the work is built here, whatever `git.handoff_branch` says.
 
 **In `unattended`** (flow-core §2.1) this command asks nothing; each place it would ask resolves as
 that table says. Here: **the ticket is `<cmd> ticket --json`**, not the tracker — `number` is the
 identifier, `title` and `body` replace §2's tracker read, and its `comments` (already limited to
 authorised authors) are the whole thread of §2.1, read as that section says; `$ARGUMENTS` that
-disagrees with `number` is ignored and named. The order failing or empty → `blocked` (there is no
+disagrees with `number` is ignored and named, and `--study` is ignored (the orchestrator says why it
+launched the run). The order failing or empty → `blocked` (there is no
 conversation to draft from and nobody to paste it) · **the base is the ticket's `base`** (empty →
 `git.default_base`), recorded as `meta.json.base` — the branch of §5.2 starts there, never from
 where the checkout stands, and §5.1 asks nothing · uncommitted changes, or a checkout not on that
@@ -51,7 +53,7 @@ its reason file in a `mktemp -d` directory (flow-core §2.1).
 - Read the effective FLOW configuration per flow-core §0; no FLOW layer present → each
   step's default. This command **creates** `00-summary.md` (§6) instead of reading it (flow-core §5).
 - No recognizable project structure → warn and stop.
-- **Determine the mode**: `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
+- **Determine the mode** (`--study` already taken out): `$ARGUMENTS` non-empty → *ticket mode* (identifier = `$ARGUMENTS`); empty → *ticket-less* (identifier = the §2.5 slug).
 - Once the identifier is known, check the work does not exist: ticket mode → glob `.claude/work/<TICKET>/` and `.claude/work/<TICKET>-*/` for a `meta.json` whose `ticket` equals `<TICKET>`; ticket-less → `.claude/work/<slug>/meta.json`, right after the slug is decided in §2.5. Exists → do not overwrite; warn and suggest `/flow-work-resume`.
 
 **Work directory naming.** Work lives in `.claude/work/<work-dir>/`. `meta.json.ticket` stays the **pure identifier** (real ticket id, or the slug in ticket-less local-only) — it feeds the tracker view, the issue link and `{TICKET}`. The directory adds a slug:
@@ -252,6 +254,7 @@ Create the work directory per §1: `.claude/work/<TICKET>-<slug>/` (ticket mode)
 }
 ```
 
+- `handoff` — `true` only when `--study` was given and `git.handoff_branch` is set; omit it otherwise.
 - Ticket-less (§2.5) → `draft_from_conversation: true`, `tracker_issue` = created issue id/url (or `null` if local-only). Ticket mode → defaults above.
 - `base` — `unattended` only: the ticket's `base`, or `git.default_base` when it is empty — never empty (the branch every MR/PR of this work starts from and targets; `/flow-work-run` refreshes it on `merged`). Omit it in every other mode.
 - `related_repos` from §3.5 — one `{ "repo": "<name>", "scope": "<one line>", "status": "pending", "contract_handoff": "pending" | "none" }` per *other* repo; `[]` for a single-repo task.
@@ -307,5 +310,5 @@ Run `tracker.start_cmd` with `{TICKET}` = `meta.json.ticket`, `{ASSIGNEE}` = `tr
 ## 7. Close
 
 - Overwrite `00-summary.md` whole (≤15 lines, flow-core §5) — first written in §6; refresh it if §6.5 changed anything.
-- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
+- Report **following the stop header** (flow-core §3), branch added, body 2-3 lines: ticket, size, branch; recommended next command per the §4 table (`build` on XS: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff)) — in `guided`/`auto` you run it in this same turn, so there is no report and no question here: update the panel and chain (flow-core §3).
 - Apply `autonomy.mode`: `manual` → stop and let the user invoke the recommended command; `guided`/`auto` → chain into it, subject to the hard gates (the §5 branch-base ambiguity already stops on its own).

package/adapters/opencode/commands/flow-work-README.md

@@ -254,7 +254,7 @@ Two signals arrive on an open MR/PR, each with its own cross-cutting loop (feat
 - `/flow-work-daily [question]` — the **work assistant** (daily standup), read-only. **Local** (`.claude/work/` + git) + **forge** (open MRs/PRs, reviews awaiting you, red CI, unmergeable, unresolved threads via `git.cli`) + **tracker** (assigned tickets, priority changes via `tracker.tool`); where they cross, concrete commands (`/flow-feat-start`, `/flow-work-green`, `/flow-work-respond`). No argument → *yesterday · today · blockers*; a question → just that. External sources best-effort, never blocking; the only write is a "last seen" marker, like `/flow-news`.
 - `/flow-work-status` — all works in `.claude/work/`, current phase, divergence with git.
 - `/flow-work-run [ticket]` — the **entry an orchestrator launches** for an `unattended` run: asks it `why` (start · study · answer · merged · review · pipeline), routes to the phase that answers it — a `study` run stops at the door to code with a summary for a person to approve — and makes no decision of its own. Refuses to run in any other mode.
-- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`).
+- `/flow-work-handoff` — hands a **finished study** to whoever builds it elsewhere (an unattended server, another machine): refuses an unfinished one, pushes only this work's folder as a parentless commit to `git.handoff_branch` without touching the checkout, asks before the push, then offers a marked summary for the ticket body (`tracker.edit_cmd`). A work started with `/flow-feat-start --study` (or `/flow-bug-start --study`) ends its study here on its own; one started without the flag is built here, even with the key set.
 - `/flow-work-resume` — detects the branch, reads `meta.json`, recaps, suggests the next step. **Re-reads the ticket's comment thread** (§2.5), reports only what is new since `01-context.md`, appends it to the artifact; never amends the design on its own.
 - `/flow-work-try <branch>` / `/flow-work-try --back` — point the main checkout at a branch to test it here, then return; re-syncs per `git.worktree_resync`. Resolves the work behind the branch and, once the environment is up, **prints the manual test plan already written** (the `needs-manual`/`unproven` criteria, or the acceptance criteria when `validate` has not run) and offers to collect Pass/Fail/Blocked into the validation artifact. No work behind the branch → the plain switch, as before.
 - `/flow-work-clean [--dry-run]` — **periodic sweep** of finished work's residue: worktree, local branch, `.claude/work/` folder (intermediate train MR/PRs never set `phase: done`, so the `ship`/`abandon` prompt never fires). Verdict per branch from **the forge** with local fallbacks, including patch-equivalence for **squash merges** (`git branch --merged` misses them); acts only on `merged`/`empty`. `unknown` never a candidate; dirty and unpushed protected; work folders **archived, never deleted**; remote never touched. **`autonomy.mode` does not authorize deletion**: `auto` confirms the list too. `--purge-archive <N>d`: separate opt-in pass over `_archive/`, only folders already committed to git.

package/adapters/opencode/commands/flow-work-resume.md

@@ -90,7 +90,7 @@ With what is new (there is already work on disk):
 ## 4. Next step
 
 - An `Unattended:` line → the question is the orchestrator's to bring back: say so, and that answering it here instead means clearing `meta.json.pending` and continuing in this session's mode; the next step itself comes from `phase` as always.
-- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `git.handoff_branch` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
+- Suggest the concrete command from `phase` and `size` — a study whose next step is `build` or `fix`: `meta.json.handoff` set and not `unattended` → `/flow-work-handoff` in its place, **Hand off the study** recommended and **Build here** second where it asks (flow-core §2, a study made for handoff). Interrupted phase (e.g. `build` with an empty artifact) → suggest rerunning it with `/flow-feat-build` or `/flow-bug-fix`.
 - §2.5 found something new → let it inform the suggestion (a contract that arrived after you left may mean rerunning `design` rather than continuing `build`); say why in one line.
 - `meta.json.related_repos` entries not `done` → remind that a **sibling repo still has a pending part** (`<repo>: <scope>`, plus `contract not handed over` when its `contract_handoff` is `pending`); suggest `/flow-feat-start <TICKET>` there. flow only reminds; it never scans or touches the other repo.
 - Do not advance on your own. The user decides.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "flow-workflows",
-  "version": "0.94.1",
+  "version": "0.95.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.94.1",
+  "version": "0.95.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.95.0 — One repo can study some works for handoff and build others here  ·  2026-10-15
+
+**In short**
+- **`--study` on `/flow:feat:start` and `/flow:bug:start`** makes a work a study for someone else to
+  build: its last study phase hands it to `/flow:work:handoff`, as the key alone did until now.
+- **Without the flag, a work is built here**, even in a repo with `git.handoff_branch` set. The key
+  only says where a study is pushed.
+- **Change in behaviour:** a repo that set the key to send every study off now passes `--study` on
+  the works it hands off. Nothing changes in `unattended`.
+
+The key was repo-wide, so a repo whose tickets are sometimes studied for a server and sometimes
+built on the laptop had no way to say "build this one here": in `auto` every plan chained into the
+handoff. The choice now belongs to the work. `start` records it as `meta.json.handoff`, and `design`,
+`plan`, `investigate` and `resume` read the field instead of the key. `--study` with the key empty
+says so in one line and goes on as a work built here.
+
 ## v0.94.1 — An unattended start with a study no longer stops because the container cannot fetch  ·  2026-10-14
 
 **In short**

package/plugins/flow/examples/FLOW.template.md

@@ -96,7 +96,7 @@ Branch and Pull/Merge Request conventions.
                       #   - make database-update
                       #   - make frontend
 
-- `handoff_branch:`   # branch `/flow:work:handoff` pushes a finished study to, holding only that work's folder. `{TICKET}` substituted. Empty = the command refuses: where a study goes is the receiver's convention. e.g. `study/{TICKET}`. Set → the study phases end at `/flow:work:handoff` instead of `build`/`fix` (not in `unattended`); pair it with `autonomy.mode: auto` and the study runs on its own up to the push.
+- `handoff_branch:`   # branch `/flow:work:handoff` pushes a finished study to, holding only that work's folder. `{TICKET}` substituted. Empty = the command refuses: where a study goes is the receiver's convention. e.g. `study/{TICKET}`. It does not decide which works are studies: a work started with `--study` (`/flow:feat:start`, `/flow:bug:start`) ends its study phases at `/flow:work:handoff` instead of `build`/`fix` (not in `unattended`), one started without it is built here. Pair it with `autonomy.mode: auto` and a `--study` work runs on its own up to the push.
 
 ## autonomy
 How much the flow advances on its own vs. stopping to ask you.