@kontourai/flow-agents 3.6.0 → 3.8.0

package/kits/builder/kit.json

@@ -3,7 +3,7 @@
   "id": "builder",
   "name": "Builder Kit",
   "product_name": "Builder Kit",
-  "description": "A Flow Kit for shaping work, breaking it down, building changes, verifying evidence, preparing pull requests, checking merge readiness, and recording learning.",
+  "description": "A Flow Kit for shaping provider-backed work, breaking it down, building changes, verifying evidence, preparing provider change records, checking merge readiness, and recording learning.",
   "flows": [
     {
       "id": "builder.shape",
@@ -13,7 +13,7 @@
     {
       "id": "builder.build",
       "path": "flows/build.flow.json",
-      "description": "Pull ready work through design probing, planning, implementation, verification, pull request readiness, merge readiness, and learning."
+      "description": "Pull ready provider-backed work through design probing, planning, implementation, verification, provider change readiness, merge readiness, and learning."
     },
     {
       "id": "builder.publish-learn",
@@ -48,53 +48,88 @@
     {
       "flow_id": "builder.build",
       "step_id": "pull-work",
-      "skills": ["pull-work"]
+      "skills": ["pull-work"],
+      "expectation_ids": ["selected-work"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "design-probe",
-      "skills": ["pickup-probe"]
+      "skills": ["pickup-probe"],
+      "expectation_ids": ["pickup-probe-readiness", "probe-decisions-or-accepted-gaps"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "plan",
-      "skills": ["plan-work"]
+      "skills": ["plan-work"],
+      "expectation_ids": ["implementation-plan"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "execute",
-      "skills": ["execute-plan"]
+      "skills": ["execute-plan"],
+      "expectation_ids": ["implementation-scope"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "verify",
-      "skills": ["review-work", "verify-work"]
+      "skills": ["review-work", "verify-work"],
+      "expectation_ids": ["clean-critique", "acceptance-criteria", "tests-evidence", "policy-compliance"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "merge-ready",
-      "skills": ["evidence-gate"]
+      "skills": ["evidence-gate"],
+      "expectation_ids": ["merge-readiness"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "pr-open",
       "skills": [],
-      "operations": ["publish-change"]
+      "operations": ["publish-change"],
+      "expectation_ids": ["pull-request-opened"],
+      "artifacts": ["release.json"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "merge-ready-ci",
-      "skills": ["release-readiness"]
+      "skills": ["release-readiness"],
+      "expectation_ids": ["ci-merge-readiness"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "learn",
-      "skills": ["learning-review"]
+      "skills": ["learning-review"],
+      "expectation_ids": ["decision-evidence", "learning-evidence"]
     },
     {
       "flow_id": "builder.build",
       "step_id": "done",
-      "skills": []
+      "skills": [],
+      "expectation_ids": []
+    },
+    {
+      "flow_id": "builder.shape",
+      "step_id": "shape",
+      "skills": ["idea-to-backlog"],
+      "expectation_ids": ["shaped-problem", "shaped-outcome", "shaped-constraints", "shaped-non-goals", "shaped-success", "shaped-risk", "open-decisions"]
+    },
+    {
+      "flow_id": "builder.shape",
+      "step_id": "breakdown",
+      "skills": ["idea-to-backlog"],
+      "expectation_ids": ["slices-defined"]
+    },
+    {
+      "flow_id": "builder.shape",
+      "step_id": "file-issues",
+      "skills": ["idea-to-backlog"],
+      "expectation_ids": ["work-items-filed"]
+    },
+    {
+      "flow_id": "builder.shape",
+      "step_id": "shape-done",
+      "skills": [],
+      "expectation_ids": []
     }
   ],
   "hook_influence_expectations": [
@@ -124,7 +159,7 @@
       ],
       "must_include_actions": [
         "review-work for report-only critique before verify-work",
-        "not count critique.json as verification evidence"
+        "not count report-only critique as verification evidence"
       ]
     },
     {
@@ -135,7 +170,7 @@
       "must_include_guidance": [
         "KIT WORKFLOW ROUTE",
         "activate `deliver`",
-        "--flow-id builder.build",
+        "public `flow-agents workflow` interface",
         "plan-work -> execute-plan -> review-work -> verify-work",
         "release-readiness and learning-review"
       ],
@@ -147,6 +182,25 @@
       ]
     }
   ],
+  "skill_roles": [
+    { "skill_id": "builder.builder-shape", "role": "entrypoint", "flow_id": "builder.shape", "step_ids": [], "artifacts": [], "expectation_ids": [] },
+    { "skill_id": "builder.deliver", "role": "entrypoint", "flow_id": "builder.build", "step_ids": [], "artifacts": [], "expectation_ids": [] },
+    { "skill_id": "builder.fix-bug", "role": "profile", "flow_id": "builder.build", "step_ids": [], "artifacts": [], "expectation_ids": [] },
+    { "skill_id": "builder.tdd-workflow", "role": "profile", "flow_id": "builder.build", "step_ids": [], "artifacts": [], "expectation_ids": [] },
+    { "skill_id": "builder.idea-to-backlog", "role": "step", "flow_id": "builder.shape", "step_ids": ["shape", "breakdown", "file-issues"], "artifacts": ["<slug>--idea-to-backlog.md", "trust.bundle#builder.shape"], "expectation_ids": ["shaped-problem", "shaped-outcome", "shaped-constraints", "shaped-non-goals", "shaped-success", "shaped-risk", "open-decisions", "slices-defined", "work-items-filed"] },
+    { "skill_id": "builder.pull-work", "role": "step", "flow_id": "builder.build", "step_ids": ["pull-work"], "artifacts": ["<slug>--pull-work.md", "trust.bundle#selected-work"], "expectation_ids": ["selected-work"] },
+    { "skill_id": "builder.pickup-probe", "role": "step", "flow_id": "builder.build", "step_ids": ["design-probe"], "artifacts": ["<slug>--pull-work.md", "trust.bundle#pickup-probe"], "expectation_ids": ["pickup-probe-readiness", "probe-decisions-or-accepted-gaps"] },
+    { "skill_id": "builder.plan-work", "role": "step", "flow_id": "builder.build", "step_ids": ["plan"], "artifacts": ["<slug>--plan-work.md", "acceptance.json", "handoff.json", "trust.bundle#implementation-plan"], "expectation_ids": ["implementation-plan"] },
+    { "skill_id": "builder.execute-plan", "role": "step", "flow_id": "builder.build", "step_ids": ["execute"], "artifacts": ["<slug>--deliver.md", "state.json", "trust.bundle#implementation-scope"], "expectation_ids": ["implementation-scope"] },
+    { "skill_id": "builder.review-work", "role": "step", "flow_id": "builder.build", "step_ids": ["verify"], "artifacts": ["trust.bundle#critique"], "expectation_ids": ["clean-critique"] },
+    { "skill_id": "builder.verify-work", "role": "step", "flow_id": "builder.build", "step_ids": ["verify"], "artifacts": ["trust.bundle#acceptance-criteria", "trust.bundle#tests-evidence", "trust.bundle#policy-compliance"], "expectation_ids": ["acceptance-criteria", "tests-evidence", "policy-compliance"] },
+    { "skill_id": "builder.evidence-gate", "role": "step", "flow_id": "builder.build", "step_ids": ["merge-ready"], "artifacts": ["<slug>--evidence-gate.md", "trust.bundle#merge-readiness"], "expectation_ids": ["merge-readiness"] },
+    { "skill_id": "builder.release-readiness", "role": "step", "flow_id": "builder.publish-learn", "step_ids": ["merge-ready-ci"], "artifacts": ["release.json", "trust.bundle#ci-merge-readiness"], "expectation_ids": ["ci-merge-readiness"] },
+    { "skill_id": "builder.learning-review", "role": "step", "flow_id": "builder.publish-learn", "step_ids": ["learn"], "artifacts": ["learning.json", "trust.bundle#decision-evidence", "trust.bundle#learning-evidence"], "expectation_ids": ["decision-evidence", "learning-evidence"] },
+    { "skill_id": "builder.design-probe", "role": "shared-primitive", "step_ids": [], "artifacts": ["ephemeral decision record"], "expectation_ids": [] },
+    { "skill_id": "builder.continue-work", "role": "extension", "step_ids": [], "artifacts": [], "expectation_ids": [] },
+    { "skill_id": "builder.gate-review", "role": "extension", "step_ids": [], "artifacts": ["<slug>--gate-review.md", "gate-review.inquiries.json"], "expectation_ids": [] }
+  ],
   "skills": [
     {
       "id": "builder.builder-shape",
@@ -191,7 +245,7 @@
     {
       "id": "builder.idea-to-backlog",
       "path": "skills/idea-to-backlog/SKILL.md",
-      "description": "Turn raw ideas into shaped, prioritized, executable GitHub issue backlog."
+      "description": "Turn raw ideas into shaped, prioritized, executable provider-backed work items; GitHub is an optional adapter."
     },
     {
       "id": "builder.learning-review",
@@ -211,7 +265,7 @@
     {
       "id": "builder.pull-work",
       "path": "skills/pull-work/SKILL.md",
-      "description": "Select ready GitHub issues from the executable backlog for implementation."
+      "description": "Select ready provider-backed work items from the executable backlog for implementation; GitHub is an optional adapter."
     },
     {
       "id": "builder.release-readiness",

package/kits/builder/skills/builder-shape/SKILL.md

@@ -1,86 +1,86 @@
 ---
 name: "builder-shape"
-description: "Invoke Builder Kit shape from a raw idea or the current conversation context without requiring the user to name idea-to-backlog. Delegates shaping to idea-to-backlog, records the Builder Kit Flow Definition link, and stops at the backlog gate unless GitHub issue sync is explicitly requested."
+description: "Builder Kit shaping entrypoint. Turns a raw idea into a provider-neutral, reviewable backlog proposal and stops before build selection unless the user explicitly continues."
 ---
 
 # Builder Shape
 
-Invoke the Builder Kit `shape` flow for raw product ideas, vague build goals, current conversation context, PRD-like concepts, spikes, prototypes, or work that needs alignment before implementation.
+## Role and Boundary
 
-## Contract
+**Role:** Builder Kit entrypoint for `builder.shape`.
 
-- Product surface: let the user ask for "Builder Kit shape", "builder shape", or "shape this with Builder Kit" without naming `idea-to-backlog`.
-- Proactive suggestion: when a user starts planning a feature, product, PRD, roadmap item, or vague build idea without naming a workflow, briefly suggest Builder Kit shape as the structured path before implementation. Phrase it as an option, not a forced gate, unless the request is too ambiguous to plan responsibly.
-- Delegation: use `kits/builder/skills/idea-to-backlog/SKILL.md` as the shaping primitive. Do not duplicate or replace its workflow, artifact contract, issue shape, or gate rules.
-- Product-level auto-guidance: when the user invokes Builder Kit shape, guide them through `design-probe` alignment and then the `idea-to-backlog` workflow directly; do not require them to type `design-probe` or `idea-to-backlog` as additional skill names.
-- do not require them to type `idea-to-backlog`; Builder Kit shape owns the user-facing route into that primitive.
-- Flow reference: link every Builder Kit shape artifact to the Builder Kit Flow Definition at `kits/builder/flows/shape.flow.json`.
-- Input: start from the user's raw idea, pasted notes, or the current conversation context.
-- Probe/alignment: when the idea, user outcome, constraints, non-goals, success signal, risk, or bundle relationship is unclear, run `design-probe` style alignment before continuing.
-- Default stop: stop at the backlog gate by default. Do not create GitHub issues, sync to a project, or hand off to `pull-work` unless the user explicitly asks for that next step.
-- Boundary: do not run Builder Kit build execution, remote kit install, package extraction, downstream delivery workflows, `plan-work`, `execute-plan`, `review-work`, `verify-work`, `evidence-gate`, or release workflows from this invocation.
-- Compatibility: Direct `idea-to-backlog` usage remains valid and should behave exactly as described in `kits/builder/skills/idea-to-backlog/SKILL.md`.
-- Primitive recovery: if a user invokes `idea-to-backlog` or another primitive with missing shaping context and appears to want the product flow, explain that Builder Kit shape is the entry point and offer to route there.
+Use this surface only when the user explicitly asks to shape an idea with Builder
+Kit, or accepts it after it is offered as an option. It delegates shaping to
+`idea-to-backlog`; it does not implement, select, or deliver work.
+
+`builder.shape` is selected for raw ideas, vague outcomes, PRD-like concepts,
+spikes, and prototypes. It is not a generic routing rule for every planning
+request. Direct `idea-to-backlog` remains a valid standalone primitive.
+
+This entrypoint owns **no step-gate evidence**. `idea-to-backlog` owns its
+shaping artifact and any evidence required by its own contract.
 
 ## Model Routing
 
-When this skill delegates its shaping work (to `idea-to-backlog` / `design-probe`
-alignment), resolve the `delegate-design` role from `.datum/config.json`
-(`npx @kontourai/datum resolve delegate-design --json`) and pass the resolved
-model explicitly — shaping needs design latitude, so it routes to the design
-tier. See `context/contracts/execution-contract.md` § Delegation: Model Routing.
-Fallback: inherit the session model when datum/config is absent, noted in the
-artifact.
-
-## Invocation
-
-Use this skill when the user says things like:
-
-- `Use Builder Kit shape for this idea: ...`
-- `Builder shape the current conversation into backlog candidates.`
-- `Shape this with Builder Kit, but do not create issues yet.`
-- `Run Builder Kit shape and sync GitHub issues only after I confirm.`
-
-When activated:
-
-1. Read `kits/builder/skills/idea-to-backlog/SKILL.md`.
-2. State that Builder Kit shape delegates to `idea-to-backlog` and uses `kits/builder/flows/shape.flow.json`.
-3. Gather the raw idea or current conversation context.
-4. If needed, use `design-probe`: ask one Probe/alignment question at a time before shaping. Prefer questions that clarify user outcome, constraints, non-goals, success criteria, risk, or whether bundled ideas truly belong together.
-5. Create or update the standard `.kontourai/flow-agents/<slug>/<slug>--idea-to-backlog.md` artifact using the `idea-to-backlog` artifact contract.
-6. Add a `builder_kit_shape` or equivalent note in the artifact that links to `kits/builder/flows/shape.flow.json` and records that the product-level Builder Kit shape surface was used.
-7. Stop at `next_gate: Backlog Gate` unless the user explicitly requested GitHub issue sync.
-8. If the user asked for guided Builder Kit continuation, record the expected next step as `pull-work` after issue sync or backlog approval; otherwise record manual mode and stop.
-
-## Artifact Requirements
-
-The artifact must keep the standard `idea-to-backlog` sections:
-
-- `source_ideas`
-- `idea_inventory`
-- `slice_candidates`
-- `bundle_justification`
-- `dependency_map`
-- `phase`
-- `decisions`
-- `opportunity_briefs`
-- `shaped_work`
-- `risk_release_notes`
-- `backlog_links`
-- `parked_or_rejected`
-- `open_questions`
-- `next_gate`
-
-For Builder Kit shape invocations, also include:
-
-- Builder Kit Flow Definition: `kits/builder/flows/shape.flow.json`
-- Explicit issue-sync status, such as `not_requested`, `requested`, or `completed`
-- A backlog-gate decision that says whether the workflow stopped before issue creation
-
-## GitHub Issue Sync
-
-Issue sync is explicit-only.
-
-- If the user did not ask to create or sync issues, set `backlog_links` to `not_requested` or an empty recorded status and stop at the backlog gate.
-- If the user asks to create or sync issues, follow the GitHub issue rules in `kits/builder/skills/idea-to-backlog/SKILL.md`.
-- If provider details are missing, ask for them instead of assuming a GitHub repository, project, labels, milestone, or assignee.
+Resolve `delegate-design` from `.datum/config.json` for shaping and alignment.
+Model choice and reasoning effort follow
+`context/contracts/execution-contract.md`; if the mapping is unavailable,
+inherit the session model and record the fallback.
+
+## Inputs and Providers
+
+Start from the user's raw idea, notes, or current conversation context. Ask
+one focused alignment question at a time when outcome, constraints, non-goals,
+success signal, risk, or the relationship between ideas is unclear.
+
+Describe backlog targets through adapters:
+
+- **Work Item adapter:** the proposed buildable unit and its acceptance context.
+- **Board adapter:** the destination queue or backlog, when one is requested.
+- **Repository adapter:** the repository or product boundary affected by the item.
+
+No adapter is required merely to shape an idea. A GitHub issue or project may
+be a labeled example of a Work Item or Board adapter, never a required
+contract.
+
+## Flow Behavior
+
+1. Derive a safe explicit slug from the selected shape title: lowercase ASCII
+   words separated by single hyphens. Never interpolate raw request text into a
+   shell command, slug, or quoted argument.
+2. Start and inspect the public shape run using the safe slug and a fixed,
+   operator-authored summary:
+
+```bash
+flow-agents workflow start --flow builder.shape \
+  --task-slug <safe-shape-slug> \
+  --summary "Shape the selected work into independently actionable slices."
+flow-agents workflow status --session-dir .kontourai/flow-agents/<safe-shape-slug> --json
+```
+
+3. State that this entrypoint selects `builder.shape` and delegates to
+   `idea-to-backlog`.
+4. Gather and clarify the idea.
+5. Have `idea-to-backlog` produce its normal shaping result, including
+   candidate Work Items, slicing, risks, decisions, and a next-action.
+6. Stop at the backlog decision. Create or synchronize provider records only
+   when the user explicitly requests it and the relevant adapters are known.
+
+Do not duplicate `idea-to-backlog`'s intake, prioritization, slicing, artifact,
+or gate logic. Do not invoke `pull-work`, `plan-work`, `execute-plan`,
+`review-work`, `verify-work`, or release activities from this entrypoint.
+
+## Output Responsibility
+
+The produced result is the standard `idea-to-backlog` shaping report. It must
+identify the selected flow (`builder.shape`), the source ideas, candidate Work
+Items, provider-sync status, decisions, open questions, and the backlog
+decision. This entrypoint creates no step evidence; `idea-to-backlog` records
+the owning trust-bundle slices through the public CLI.
+
+## Standalone and No-Active-Run Behavior
+
+`builder.shape` may run independently of `builder.build`. If a prior shaping
+report exists, use it as context; do not assume it authorizes provider
+synchronization or build execution. If the public shape interface is unavailable,
+report an unsupported-runtime blocker rather than using an internal writer.

package/kits/builder/skills/continue-work/SKILL.md

@@ -1,125 +1,64 @@
 ---
 name: "continue-work"
-description: "Advance a multi-slice work item to its next increment via a fresh-context handoff. Use when one or more slices of a multi-slice issue have landed and the next undone slice should be built. Routes the next slice through pull-work + pickup-probe (never around the gate), restores prior slices from the durable record as precedent, and hands off in a fresh context per ADR 0013."
+description: "Explicit Builder Kit continuation extension. Prepares a fresh-context handoff for the next unfinished increment of a multi-slice Work Item."
 ---
 
 # Continue Work
 
-Advance a multi-slice work item to its **next increment**, in a fresh context, with the already-landed slices as precedent.
+## Role and Boundary
 
-This skill is **orchestration, not new machinery.** It composes existing pieces and must never reimplement them:
+**Role:** explicit continuation extension outside generic routing.
 
-- `pull-work` already owns *selection* plus the `pickup-probe` gate, and already handles "continue / keep going / pick up the next" intents. continue-work routes the chosen slice **through** `pull-work` / `pickup-probe`, never around it.
-- The **resume surface** (#153) owns restoring an item's durable record (`state.json` lifecycle + `handoff.json` next-steps/blockers + plan artifact + `trust.bundle` trust summary) into context. continue-work consumes that surface; it does not re-derive the record.
-- **ADR 0013** establishes `pull-work` as the clean *context-reset* seam: a fresh window per increment, selective compaction, status-gated reuse. continue-work spawns the next increment as a fresh-context workflow seamed at `pull-work`.
-- The **fresh-handoff** pattern (spawn a new context for the next increment) is the delivery mechanism.
+Use only when the user explicitly asks to advance the next unfinished increment
+of a multi-slice Work Item that has prior completed increments. This extension
+does not select a new flow, resume an interrupted increment, or run build
+steps in-line. It prepares a fresh-context handoff that routes the next
+increment through the normal `builder.build` entrypoint.
 
-continue-work ties these together for **one job**: take a multi-slice work item that has at least one slice landed and more remaining, determine the next undone slice, route it through the gate, and hand it off fresh with the prior slices as the model.
+It owns **no step-gate evidence**. `pull-work`, `design-probe`, and the build
+primitives own selection, probe, planning, execution, review, and verification
+evidence.
 
-## When To Use / When Not
+## Inputs and Provider Adapters
 
-**Use** when:
+Use the Work Item adapter for slice status and acceptance context, the Board
+adapter for selection and dependencies, the Repository adapter for local
+history and working agreements, and the Change adapter for prior completed
+increments. GitHub issues and pull requests are optional examples of Work Item
+and Change adapters, not mandatory inputs.
 
-- A multi-slice issue has **at least one slice landed and more remaining** (for example #106), and the request is "continue", "pick up the next slice", "keep going on this issue", or "do the next increment".
+Restore durable context when available: prior plans, handoffs, verified
+outcomes, completed changes, and unresolved blockers. If it is unavailable,
+state the gap and rely on the Work Item and repository history without
+inventing missing facts.
 
-**Do not use** when:
+## Extension Behavior
 
-- The request is **brand-new work** with nothing landed yet — that is selection from the backlog. Route to `pull-work`.
-- The request is to **resume the *same* interrupted slice** after a restart (same in-flight slice, mid-execution, picking up new hooks/logic) — that is the resume surface (#153), which reconstructs `state.json` + `handoff.json` + plan + `trust.bundle` for the *same* increment. continue-work advances to the *next* increment; it does not re-enter an unfinished one.
+1. Confirm this is the next increment, not a restart of the same interrupted
+   increment. Ask one focused question when that boundary is unclear.
+2. Determine the thinnest remaining meaningful slice from the Work Item and
+   completed Change-adapter history.
+3. Build a minimal fresh-context handoff containing the next slice, acceptance
+   context, repository working agreements, relevant prior changes, known
+   blockers, and adapter references.
+4. Hand the new context to `deliver`, which starts or continues `builder.build`
+   and routes the item through its canonical primitives.
 
-For that same-slice case, when a canonical Builder Flow run already exists, restore
-its sidecar/current projection with `flow-agents builder-run recover --session-dir
-.kontourai/flow-agents/<slug>` before following the resume surface. The command
-derives run identity from the session slug and only loads, validates, and projects;
-never invent or supply a run id or step, and use `builder-run sync` separately only
-when recorded evidence should be attached and evaluated.
+Do not repeat the detailed `pull-work` or `design-probe` procedure, attach
+evidence on their behalf, or treat a continuation request as authority to skip
+selection and probe work.
 
-If the boundary is ambiguous (is this the next slice or the same one?), stop and ask one question before routing. Do not silently assume.
+## Output Responsibility
 
-## Boundary (ADR 0014)
+The output is a concise, ephemeral fresh-context handoff delivered to a new
+agent or operator. It creates no persistent artifact, trust slice, or gate
+evidence of its own.
 
-Home is the **Builder Kit** — developer orchestration over issues, slices, and PRs — alongside `pull-work` and `deliver`. The underlying *fresh-handoff primitive* is generic. If a non-developer kit later needs continuation, **graduate the primitive** per ADR 0014; do not fork continue-work into each kit.
+## Standalone and No-Active-Run Behavior
 
-## Inputs
-
-- The multi-slice work item (an issue ref) with at least one slice landed and more remaining.
-- Repository or working directory and the owning kit/kit-dir.
-- The durable record for the item when one exists, restored via the resume surface (#153): `state.json`, `handoff.json` next-steps/blockers, the plan artifact, and a one-line `trust.bundle` summary of what is already verified.
-- The merged PRs and commits that reference the issue (the landed slices), available as `git show <sha>` precedent.
-- `AGENTS.md` "Operating discipline (working agreements)" — the operating agreements that travel with every increment.
-
-## Workflow
-
-### 1. Restore the durable record (resume surface, #153)
-
-Before doing anything else, restore the item's durable record into context through the resume surface (#153) rather than re-deriving it from chat memory: `state.json` lifecycle, `handoff.json` next-steps and blockers, the plan artifact, and a one-line `trust.bundle` summary of what is already verified. This is *restore for context*, not *resume the slice* — continue-work is advancing to the next increment, so already-verified prior slices stay verified and are not re-proven.
-
-If no durable record exists for the item, record that gap and rely on the issue body plus merged PRs/commits as the authoritative history.
-
-If the item was taken over from a stale incumbent (a `reclaimable` selection resumed via pull-work's **Takeover Protocol**, #294 / ADR 0021 §5), restoring the durable record IS the resumption: the deterministic slug points at the incumbent's existing `.kontourai/flow-agents/<slug>/`, and you continue the incumbent's branch (the `resume_branch` from `takeover-preflight`/the supersede output) — never a new branch, never a restarted plan. Takeover is resumption, not restart.
-
-### 2. Determine the next undone slice
-
-From the issue body plus the merged PRs and commits referencing the issue, determine which slices have **landed** and which is the **next undone slice**.
-
-- Read the issue body for the slice list / acceptance breakdown.
-- List merged PRs and commits referencing the issue (`gh pr list --search <issue>`, `git log --grep`) to see which slices are done.
-- The next undone slice is the thinnest remaining meaningful increment. If the remaining work is ambiguous or no longer matches the issue, route back to `idea-to-backlog` instead of inventing scope.
-
-### 3. Route the slice THROUGH pull-work + pickup-probe (the gate, never around it)
-
-Hand the chosen next slice to `pull-work`, then `pickup-probe`. **Never bypass this gate.** A continuation instruction ("continue", "pick up the next") may justify inspecting the queue, but it must not skip per-item pickup Probe evidence — see pull-work's Pickup Gate ("A stale broad continuation instruction … may allow queue inspection but must not bypass per-item pickup Probe evidence") and its post-merge rule ("automatic continuation … cannot enter planning or execution for the next work item until a fresh pickup Probe record exists for that newly selected item").
-
-- `pull-work` enforces board selection, WIP/shepherding, dependency, grouping, freshness (planned-base drift), and worktree logic for the selected slice, and writes the pull-work artifact.
-- `pickup-probe` then challenges the slice against the repository — scope, acceptance quality, provider state, drift, conflict risks — and records the pickup Probe outcome, planning readiness, decisions, unresolved questions, and accepted gaps.
-- continue-work does **not** reimplement either step's logic. It supplies them the next slice and the precedent (prior slices) and consumes their artifacts. The evidence that the gate ran lives in the pull-work / pickup-probe artifact referenced by the handoff (`probe_status`, `probe_artifact_ref`).
-
-Do not enter planning or execution until a fresh pickup Probe record exists for this slice.
-
-### 4. Assemble the minimal handoff
-
-Once the slice passes the gate, assemble the **minimal handoff** — the smallest durable context a fresh agent needs:
-
-- the **slice's spec**: `gh issue view <issue>` (the issue is the spec);
-- the **operating agreements**: `AGENTS.md` "Operating discipline";
-- the **precedent**: the prior slices' merged PRs as the model (`git show` them);
-- the **gate evidence**: the pull-work / pickup-probe artifact ref proving the slice passed the gate.
-
-The minimal template it encodes:
-
-```
-Implement [slice N of #ISSUE] in <repo> — the <kit>.
-Read first: AGENTS.md 'Operating discipline'; gh issue view ISSUE (your slice's spec);
-the prior slices as your model (PRs … — git show them).
-Then: scope → minimal impl reusing existing ops (consume-never-fork) → tests stay green +
-cover new code → PR referencing #ISSUE, <kit-dir> only. Don't merge; get CI green and report.
-```
-
-### 5. Execute in a fresh context (ADR 0013)
-
-Hand the minimal template off into a **fresh context** — either spawn a sub-agent for the next increment, or hand the prompt to the operator for a fresh session. Per ADR 0013, the new increment rebuilds its context from durable artifacts (the issue, AGENTS.md, prior PRs, the gate artifact), not from this conversation's history. The fresh-handoff is the delivery seam: a sharp window for the new slice, continuity carried by the durable system.
-
-The fresh-context agent runs the standard Builder Kit build for its slice (`plan-work` → `execute-plan` → `review-work` → `verify-work`), which it may reach via `deliver`. continue-work does not re-run those primitives in-line; it sets up the handoff and lets the fresh context execute.
-
-### 6. Verify and report — do not merge
-
-After the slice is built:
-
-- Confirm the **boundary held** (only `<kit-dir>` changed) and the **suites are green** (the slice's tests cover the new code and nothing regressed).
-- Report: which slice advanced, the gate evidence (pull-work / pickup-probe artifact), the precedent PRs used, the verification result, and the PR.
-- **Do not merge without authorization.** Get CI green and report back.
-
-## Composition Gate
-
-continue-work has correctly composed the pieces only when:
-
-- the durable record was restored via the resume surface (#153), or a missing-record gap is recorded;
-- the next undone slice was derived from the issue body plus merged PRs/commits, not invented;
-- the slice was routed **through** `pull-work` + `pickup-probe`, with a fresh pickup Probe record (`probe_status`, `probe_artifact_ref`) referenced by the handoff — the gate was not bypassed;
-- the minimal handoff carries the issue spec, `AGENTS.md` operating agreements, and the precedent PRs;
-- the next increment runs in a **fresh context** per ADR 0013;
-- the boundary held, suites are green, and the change is reported without merging.
-
-If any item fails, stop and surface the gap rather than proceeding.
-
-Refs: #106 (proving ground), #153 (resume surface), #168 / ADR 0013 (context lifecycle), #164 (operating agreements), ADR 0014 (core vs domain-kit boundary).
+This extension may run without an active workflow run because it only prepares
+the next handoff. It does not create, recover, or mutate a run. If an active
+run exists, inspect it only through `flow-agents workflow status --session-dir
+<session-dir>` and do not redirect or advance it. For an interrupted current
+increment, route to the run's public resume behavior instead of using this
+extension.