@nklisch/pi-agile-workflow 0.15.3

package/skills/principles/references/models.md

@@ -0,0 +1,191 @@
+# Model Selection & Decision Matrix
+
+> The concrete model-layer companion to the **model-agnostic** dispatch and
+> cross-model policy in `principles/SKILL.md` (Parts IV & VIII) and the
+> "different model class" decision points across the plugin. In-skill prose is
+> deliberately written in capability/role terms; **this file is where those
+> capabilities map to actual models and `peeragent` flags.** Load it whenever a
+> skill says "pick the reviewer", "choose a peer", "set the scanner tier", or
+> "use a different model class".
+
+Model generations move fast — the *families and classes* below are the durable
+abstraction; specific version numbers (e.g. Opus 4.x, GPT-5.x-Codex, Gemini 3.5,
+GLM-5.2) are the current resolution of each class as of writing. Always resolve
+the concrete model against current sources when the choice is load-bearing.
+
+## Contents
+
+1. [Capability axes (the decision vocabulary)](#1-capability-axes-the-decision-vocabulary)
+2. [Model-family cards](#2-model-family-cards)
+3. [Role → capability → model](#3-role--capability--model)
+4. [Host → cross-class peer pairing](#4-host--cross-class-peer-pairing)
+5. [Multi-class review for deep/complex work](#5-multi-class-review-for-deepcomplex-work)
+6. [Two-phase design review: advisory then adversarial](#6-two-phase-design-review-advisory-then-adversarial)
+7. [peeragent invocation cheatsheet](#7-peeragent-invocation-cheatsheet)
+8. [Fallbacks when no peer is reachable](#8-fallbacks-when-no-peer-is-reachable)
+
+---
+
+## 1. Capability axes (the decision vocabulary)
+
+Pick by **what the role needs**, then resolve to a class. These axes are what
+the in-skill prose names; this is what they mean.
+
+- **Blind-spot diversity** — different training produces different errors. The
+  entire value of a cross-model peer is independent blind spots, *not* a more
+  authoritative answer. Two models that share training add little over one.
+- **Reasoning depth** — multi-step deduction, proof-like correctness, holding a
+  large logical structure. Raised by high/xhigh effort tiers; strongest in
+  Opus-class, GPT-5.x-Codex at xhigh, GLM-5.2 at xhigh.
+- **Long-horizon agentic stamina** — sustained self-correcting multi-step tool
+  use over many turns / long autonomous runs. Strongest in Codex, GLM-5.2
+  (built for up-to-8h agentic runs), and Opus-class.
+- **Context window** — how much the model can hold at once. GLM-5.2 (1M),
+  Opus-class (1M), Gemini 3.5 (2M, Deep Think), Sonnet-class (1M beta).
+- **Latency budget** — wall-clock cost. Top-tier reasoning peers (Opus-class,
+  xhigh Codex/GLM) commonly take **10–30 minutes** for large reviews and may be
+  quiet for most of it. Budget for it; do not treat a long quiet period as a hang.
+- **Write fidelity** — code-writing accuracy and instruction-following for
+  production edits. The property that earns a model a *worker* role.
+
+## 2. Model-family cards
+
+**Claude (Anthropic)** — `--agent claude`
+- Tiers: `opus` (deepest reasoning + agentic, 1M context; slowest), `sonnet`
+  (strong coding + speed; 1M beta), `haiku` (fast, near-frontier, cheap).
+- Effort: `high | xhigh` (default `xhigh`).
+- Best roles: `opus` → deep reviewer / adversarial peer / highest-tier worker;
+  `sonnet` → primary worker / scout; `haiku` → leaf tasks, cheap fan-out.
+
+**Codex (OpenAI)** — `--agent codex`
+- Current class: GPT-5.x-Codex (model auto-selected; no `--model` flag).
+- Effort: `medium | high | xhigh` (default `high`).
+- Strengths: top-tier long-horizon agentic coding, multi-step tool use.
+- Best roles: cross-class peer from a Claude/Gemini/GLM host; highest-tier
+  worker for long agentic write paths.
+
+**Gemini (Google)** — `--agent gemini`
+- Model: `gemini-3.5` (2M context, Deep Think mode).
+- Effort: ignored.
+- Best roles: cross-class peer; large-context review where 2M context matters.
+
+**Z.AI GLM 5.2** — `--agent zai`
+- Model: `glm-5.2` only (MoE 744B / 40B-active; stable 1M context; DeepSeek
+  Sparse Attention; built for long-horizon agentic engineering, ~8h runs).
+- Effort: `medium | high | xhigh` (default `high`).
+- Best roles: cross-class peer (distinct training lineage → distinct blind
+  spots); long-horizon agentic worker; highest-tier reviewer at `xhigh`.
+- Note: the peeragent `zai` adapter runs GLM 5.2 **through Pi**, and needs a
+  current peeragent build (`zai` agent). Older cached builds only list
+  `codex|claude|gemini`.
+
+## 3. Role → capability → model
+
+| Role | Needs (capability) | Primary models |
+|---|---|---|
+| Primary worker | write fidelity, agentic stamina | Sonnet-class / Codex high / GLM-5.2 high |
+| Scanner/scout (deep read-only fan-out) | domain inspection, evidence, scoped artifacts | Haiku / Sonnet medium / Sonnet for volume; Opus/Codex xhigh/GLM xhigh for subtle gates |
+| Deep reviewer | reasoning depth, fresh context | Opus-class xhigh / Codex xhigh / GLM-5.2 xhigh |
+| Advisory peer (Phase 1) | blind-spot diversity, augmentation | a **different class** than the host |
+| Adversarial peer (Phase 2) | blind-spot diversity, attack posture | a **different class** than host + than Phase 1 |
+
+## 4. Host → cross-class peer pairing
+
+The rule: the peer must be a **different model class** than the host, or it is
+not cross-model evidence (fall back to a fresh same-class sub-agent instead).
+For each host, several valid peer classes exist — pick by **maximum blind-spot
+diversity**, and for deep work use **two distinct peer classes** (§5).
+
+| Host class | Valid peer classes (any different class) |
+|---|---|
+| Claude | codex · gemini · zai |
+| Codex | claude (opus) · gemini · zai |
+| Gemini | claude (opus) · codex · zai |
+| Z.AI GLM | claude (opus) · codex · gemini |
+
+When the natural pair is unavailable, fall through to the next class; never
+peer with the same class as the host.
+
+## 5. Multi-class review for deep/complex work
+
+For **deep or complex work** — architectural design points, large/risky
+features or epics, the final autopilot completion review, whole-repo scans — a
+single peer is the floor, not the ceiling. **If two different model classes are
+available, use both.** Different training lineages have different blind spots;
+two independent peers catch more than one, and their disagreements are
+themselves signal (re-read both before deciding).
+
+Concretely: pair the two peers across the two review phases in §6 — one class
+runs the **advisory** pass, a *different* class runs the **adversarial** pass.
+That realizes the 2-class rule through the phase ordering and maximizes both
+augmentation diversity and adversarial independence. For routine/small work a
+single peer (or none) remains correct — this escalation is for deep/complex
+scope only.
+
+## 6. Two-phase design review: advisory then adversarial
+
+Designs and reviews are both evaluated in a fixed **two-phase order** —
+**completeness/complementary/advisory first, adversarial second.** Never reverse
+the phases and never skip Phase 1 to jump straight to attack: a design or review
+reviewed only adversarially gets torn apart before anyone checks whether it is
+complete. The two phases have **different loop shapes depending on whether the
+artifact is a design (open) or a review (complete)**:
+
+**Phase 1 — Completeness / Complementary / Advisory.** Augmentation, not
+judgment. Ask what is missing, what alternatives strengthen it, and what
+questions/risks should be weighed.
+- *Design (open artifact, before decisions lock)*: **a single pass.** You don't
+  iterate an open design to convergence. The host chooses and records rationale.
+  This is the default autopilot design-time peer ask.
+- *Review (complete artifact — feature/epic/out-of-band review)*: **a multi-step
+  convergence loop**, not a single ask — the artifact is complete, so iterate
+  until findings stabilize. The ideal is the full `peer-review` convergence loop
+  (≥3 review→refine passes, continue while substantive issues surface, stop on
+  nits, cap ~5); run that loop in the advisory/complementary posture when
+  `peer-review` is available. When only a single peer pass is available, run as
+  many rounds as the mechanism allows and say it did not reach full convergence.
+
+**Phase 2 — Adversarial (after Phase 1 converges or, for designs, completes).**
+Attack posture. Ask a **different** reviewer (ideally a different class than
+Phase 1, per the 2-class rule in §5) what is broken, contradictory, built on a
+false assumption, or will fail in operation. For reviews this is the same
+`peer-review`-style convergence loop applied in the attack posture; for designs
+it is a focused adversarial pass. Verify concrete claims against code/foundation
+docs before accepting or rejecting.
+
+Record both phases in the item body under `## Other agent review`, labeling each
+finding's phase, the reviewer class, and (for reviews) how far the convergence
+loop ran (converged on nits / hit cap / single pass only). Peer failures in
+either phase are non-blocking (fall back to a fresh same-class sub-agent); the
+final autopilot completion review must still clear through at least one
+cross-class pass.
+
+## 7. peeragent invocation cheatsheet
+
+Resolve the wrapper before calling — never assume `peeragent` is on `PATH`
+(`PEERAGENT_BIN` → bundled `bin/peeragent` → bare `peeragent`). Run in the
+host harness's outside-sandbox mode; never `--full-access` for review.
+
+| Target | Flags |
+|---|---|
+| Claude Opus | `--agent claude --model opus --effort xhigh` |
+| Claude Sonnet | `--agent claude --model sonnet --effort high` |
+| Claude Haiku | `--agent claude --model haiku` |
+| Codex | `--agent codex --effort xhigh` (model auto-selected) |
+| Gemini | `--agent gemini` (effort ignored) |
+| Z.AI GLM 5.2 | `--agent zai --effort xhigh` (model fixed glm-5.2) |
+
+Always tell the reviewer **not** to recurse back through peeragent's own
+`peer`/`peer-review` skills or the wrapper — the reviewer is the endpoint.
+
+## 8. Fallbacks when no peer is reachable
+
+When peeragent is unavailable, fails, would be same-class, or the needed class
+isn't reachable: spawn a **fresh max-effort generic sub-agent** at the highest
+class available to the host and prompt it with the review or scanner posture from
+[subagents.md](subagents.md). Give it **only** the artifact + the lens catalog —
+deliberately not the host's own reasoning — so context isolation buys as much
+independence as possible. Label the pass by the model actually selected at spawn
+time: cross-model only if it is a different model class from the caller;
+otherwise same-class / same-harness fresh-context. Independence is degraded but
+not absent.

package/skills/principles/references/subagents.md

@@ -0,0 +1,158 @@
+# Dynamic Subagent Dispatch
+
+Agile-workflow does **not** ship custom subagent definitions for Pi, Claude Code,
+or Codex. The skills are portable; delegation happens by prompting the host's
+existing generic/general-purpose subagent mechanism with a structured brief that
+is tailored to the current item, gate, review, or scan.
+
+Do not assume named agile-workflow roles such as `designer`, `implementor`,
+`reviewer`, `scanner`, or Codex `aw-*` templates exist. Treat design,
+implementation, review, scanner, and exploration as **prompt postures**, not
+installed agent names.
+
+## Host adapters
+
+| Need | Pi | Claude Code | Codex | If unavailable |
+|---|---|---|---|---|
+| Generic delegated worker | `general-purpose` subagent | host generic/task subagent | host generic/task subagent | Do the bounded work inline |
+| Read-only exploration | generic subagent prompted as read-only explorer, or an existing host Explore role if already present | generic/read-only subagent if present | generic/read-only subagent if present | Direct Read/Grep/Glob |
+| Deep scanner/audit | generic subagent prompted with a scanner brief | generic/task subagent prompted with scanner brief | generic/task subagent prompted with scanner brief | Inline scan; record reduced isolation |
+| Fresh-context review | generic subagent prompted as reviewer | generic/task subagent prompted as reviewer | generic/task subagent prompted as reviewer | Inline only for small/low-risk work; otherwise block or ask |
+| Implementation bundle | generic subagent prompted as implementer, with explicit write ownership | generic/task subagent prompted as implementer | generic/task subagent prompted as implementer | Host implements inline |
+
+For Pi, discover available model identifiers before a load-bearing cross-model
+spawn and pass the chosen `model`/thinking level explicitly. For other hosts,
+use their current model-selection surface. Label a delegated pass as
+**cross-model** only when the spawned model is a different model class from the
+caller; otherwise label it **same-harness fresh-context**.
+
+## Dispatch rule
+
+Use a subagent only when it buys breadth, isolation, independent judgment, or
+parallel write ownership. Before spawning, do a local scope-size probe and name
+the unknowns that remain. If you cannot name a distinct unknown or independent
+write bundle, read directly instead.
+
+When you do spawn, record the prompt posture in notes or the item body, e.g.
+`general-purpose subagent prompted as scanner`, not a nonexistent installed role.
+
+## Structured brief skeleton
+
+Build the prompt dynamically from the actual task. Keep the structure; fill only
+sections that matter.
+
+```markdown
+# Agile-workflow delegated task
+
+## Posture
+Act as a <designer | implementer | reviewer | scanner | explorer> for this
+single delegated task. You are a generic subagent prompted into this posture, not
+an installed agile-workflow role.
+
+## Mission
+<One paragraph: item id/path or release/gate/scope, the decision or work needed,
+and why delegation is useful.>
+
+## Inputs
+- Repo root: `<path>`
+- Work item(s): `<id/path>`
+- Stage / release / gate: `<value>`
+- Relevant docs: `<docs/VISION.md, SPEC.md, ARCHITECTURE.md, AGENTS.md, .agents/rules/*.md>`
+- Scope files or ownership: `<paths, globs, or changed-file list>`
+- Prior findings / duplicate-skip list: `<ids or file:line keys>`
+
+## Boundaries
+- Allowed writes: `<none | .work item bodies only | explicit files/globs | report path>`
+- Forbidden writes: `<source code, unrelated items, generated files, etc.>`
+- Do not spawn nested subagents or call peeragent; you are the delegated endpoint.
+- Stay within the named scope. If the scope is wrong, report that instead of expanding silently.
+
+## Grounding steps
+1. Read the item/body/release brief and relevant foundation docs.
+2. Read project instructions and `.agents/rules/*.md` when present.
+3. Inspect only the files needed to satisfy the mission.
+4. Verify concrete claims with file:line evidence before returning findings.
+
+## Output contract
+Return exactly:
+- Summary: `<2-5 bullets>`
+- Evidence: `<file:line citations or commands run>`
+- Result: `<design notes | patch summary | review verdict | findings list | map>`
+- Follow-ups/blockers: `<only if needed>`
+```
+
+## Posture-specific capsules
+
+Add one capsule to the skeleton.
+
+### Designer
+
+Use for drafting `.work` items. The subagent may write only caller-authorized
+`.work` design artifacts. It should ground in foundation docs, capture decisions,
+spawn or propose child items only if explicitly authorized, and advance stage
+only if the caller's skill brief grants that transition.
+
+Required output additions:
+- `Design decisions` with alternatives considered.
+- `Child work` as exact item files to create or a proposal, depending on write authorization.
+- `Stage transition` only when authorized.
+
+### Implementer
+
+Use for a settled implementation bundle. Give exact item ids, ownership paths,
+acceptance criteria, and verification commands. The subagent owns only the
+specified write scope. It must update the item with implementation notes and run
+or report the bounded verification.
+
+Required output additions:
+- `Files changed`.
+- `Verification` with commands and outcomes.
+- `Stage transition/readiness` based on the caller's contract.
+
+### Reviewer
+
+Use when fresh context is the point. Give the artifact, diff range or item path,
+review depth, and whether the reviewer may write `.work` metadata. The reviewer
+should not implement fixes. It may approve, bounce, or list findings only when
+the caller's brief grants that authority.
+
+Required output additions:
+- `Verdict` (`ready`, `needs fixes`, or `blocked`) when authorized.
+- `Findings` with severity, evidence, and required fix.
+- `Accepted limitations` when the review is same-harness rather than cross-model.
+
+### Scanner
+
+Use for release gates, bug domains, deep-code-scan waves, e2e audits,
+perf-scout lenses, and other evidence-generation briefs. The scanner is
+source-read-only unless the caller authorizes a report or finding files. It is
+not a code-search-only explorer and not a fixer.
+
+Required output additions:
+- `Scope audited`.
+- `Findings` in the exact schema the caller provides, each with file:line evidence.
+- `Skipped duplicates` from the provided duplicate-skip list.
+- `No findings` explicitly when nothing survives verification.
+
+### Explorer
+
+Use only to locate code and map ownership/call-sites. The explorer returns a map
+and suggested files to read next; it does not design, review, scan for findings,
+or implement.
+
+Required output additions:
+- `Map` of relevant files/symbols.
+- `Why these files matter`.
+- `Unknowns remaining`.
+
+## Prompt quality checks
+
+Before spawning, verify the brief contains:
+
+- A named posture and mission.
+- The exact scope and allowed writes.
+- The relevant `.work` item or release/gate context.
+- Grounding docs and rules to read.
+- A concrete output schema.
+- A no-recursion/no-peeragent endpoint rule.
+- Model/effort choice sized to risk and scope.

package/skills/prose-author/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: prose-author
+description: >
+  ALWAYS invoke this skill when picking up a feature tagged [prose] at stage:drafting — a
+  no-code-surface deliverable (docs, conventions, rules, research prose, copy, config-as-prose) whose
+  design and implementation collapse into a single inline authoring act. Confirms the brief is a
+  sufficient spec, fleshes the feature body inline if needed, and advances drafting to implementing
+  WITHOUT exploratory sub-agents, a pre-mortem, or a structured question tool design gate. The no-code authoring lane:
+  the design-family routing layer forks [prose] work here the way it forks [refactor]/[perf] to
+  refactor-design/perf-design — but this lane authors, it does not design. Collapses to one inline
+  stride for the common case; large multi-section prose can still flow through drafting to
+  implementing to review as real draft/write/revise steps. Misroutes anything with a real code surface
+  back to feature-design. Pairs with implement's no-coordination inline path.
+---
+
+# Prose-Author
+
+You handle a feature tagged `[prose]` at `stage: drafting` — work whose
+deliverable is **prose with no real code surface** (documentation, an AGENTS.md
+/ convention / rule edit, a research write-up, marketing copy, a changelog, or a
+config file that carries no logic). For this class of work the design pass and
+the implementation collapse into a single inline authoring act: there is no
+interface to pin, no architecture to choose, no integration seam to map. The
+brief *is* the design.
+
+This is the **no-code authoring lane** — not a design step. The design-family
+routing layer (the "am I the right skill" fork that `feature-design` owns)
+forks `[prose]` work to this lane the way it forks `[refactor]`/`[perf]` to
+`refactor-design`/`perf-design`:
+- `epic-design` — `kind: epic`
+- `feature-design` — `kind: feature`, no specialized tag
+- `refactor-design` — `kind: feature` with `tags: [refactor]`
+- `perf-design` — `kind: feature` with `tags: [perf]`
+- `prose-author` (this lane) — `kind: feature` with `tags: [prose]`
+
+Where `feature-design` runs exploratory sub-agents, a pre-mortem, and an
+`structured question tool` design gate to leave `drafting`, `prose-author` does none of
+that — for prose that ceremony has no payoff, because there is no code surface
+to design against. It still advances `drafting → implementing` at the same seam,
+so the stage machine and `autopilot` are unchanged; the lane just authors the
+brief directly instead of designing.
+
+**Collapse by default, graduate when the prose is large.** The common case is a
+single inline authoring stride (`drafting → implementing` here, then inline
+`implement` to `review`). But the lane does not *force* a one-shot: a large
+multi-section deliverable (a long spec, a multi-part guide) can use the shared
+`drafting → implementing → review` stages as real **draft → write → revise**
+steps — an `## Outline` in `drafting`, the writing in `implementing`, a
+coherence/tightening pass at `review`. These are the same advisory stages every
+item has (no new vocabulary, no parallel pipeline) — prose just gets to skip the
+*ceremony*, not the *stages*. Reach for the staged rhythm only when the
+deliverable's size earns it; most prose does not.
+
+## The [prose] black-box test (misroute check)
+
+`[prose]` is a **work-nature** tag, not a domain tag. Apply the test before
+acting: **does this feature have a real code surface or a genuine design
+ambiguity?** A real code surface means a caller-visible interface, types to pin,
+an integration seam, an error path, or an architectural choice between
+approaches. If YES, the item is misrouted — it wants `feature-design`'s design
+pass, not this lane.
+
+Mirror of the `[refactor]` black-box discipline: when the test fails, don't
+muscle through. Strip `prose` from the item's `tags`, append a one-line note
+("Misrouted to prose-author; the work has a real code surface — retagged for
+feature-design"), commit (`prose-author misroute: <id> retagged for
+feature-design`), and return **without advancing the stage**. The caller
+(autopilot or human) reroutes on the next pass.
+
+Domain ≠ nature. A documentation *feature* that ships a docs-site generator has
+a code surface → `feature-design`. A rule rewrite, an AGENTS.md edit, a research
+brief, or release notes → `prose`.
+
+**Config-with-no-logic criterion:** a config file is `[prose]` only when nothing
+parses it as schema — e.g. a docs-site config (MkDocs, Docusaurus YAML),
+`.editorconfig`, `.prettierrc`. A config with a typed or programmatic consumer
+(env files read by a typed loader, OpenAPI specs consumed by a code-generator,
+database migration configs, CI pipeline definitions) has an integration seam and
+real failure paths → NOT `[prose]`; route through `feature-design`.
+
+## Trigger
+
+The agent picks this lane for a feature at `stage: drafting` with
+`tags: [prose, ...]` and no `[refactor]`/`[perf]` tag. Common phrases:
+- "author the docs feature", "this is just prose — advance it"
+- "write up the <convention / rule / copy> feature"
+
+## Invocation modes
+
+| Invocation | Behavior |
+|---|---|
+| `<feature-id>` (default) | Confirm the brief, flesh the body inline if needed, advance `drafting → implementing`. |
+| `<feature-id> --only-questions` | Question-only pass — surface any genuine ambiguity, capture under `## Design decisions`, do NOT advance. Mirrors feature-design's mode; interactive-only. Most prose items surface zero questions. |
+
+## Workflow
+
+### Phase 1: Read the feature item
+
+Read `.work/active/features/<id>.md`. Confirm `kind: feature`, `stage:
+drafting`, and `tags` includes `prose`. If `tags` also includes `refactor` or
+`perf`, that specialized tag wins — log a misroute note and return without
+advancing.
+
+### Phase 2: Apply the black-box test
+
+Run the `[prose]` black-box test above. If the item has a real code surface or a
+genuine architectural ambiguity, misroute it back to feature-design per the
+procedure above and return.
+
+### Phase 3: Ground yourself (light)
+
+Read only what the prose itself must stay consistent with — the parent epic body
+if `parent` is set, the foundation docs (`docs/VISION.md`, `docs/SPEC.md`,
+`docs/ARCHITECTURE.md`) and `AGENTS.md` / `CLAUDE.md` when the deliverable
+touches conventions or project-facing claims, and any sibling doc the feature
+revises. One pass, skim. **Do NOT** spawn exploratory sub-agents — there is no code
+surface to map.
+
+### Phase 4: Confirm the brief is a sufficient spec
+
+The brief from `scope` is usually the whole spec for prose work. Read it and
+decide:
+- **Sufficient as-is** — the deliverable, its target path, and what "done" means
+  are clear. Proceed to Phase 5.
+- **Needs fleshing** — the brief leaves the shape of the prose open (which
+  sections, which file, what claims). Flesh it **inline in the body** as a short
+  `## Outline` (target path + section list + acceptance criteria), then proceed.
+  This is authoring, not a design pass — keep it to what the writer needs. For a
+  large multi-section deliverable the `## Outline` is also the structural draft
+  step that lets the writing and a later revise pass run as distinct strides
+  (see "Collapse by default, graduate when the prose is large" above).
+
+Do NOT run a pre-mortem and do NOT open a `structured question tool` design gate. If a
+genuine directional ambiguity exists (rare for prose), that is the signal the
+item wanted `feature-design` — reconsider the Phase 2 misroute test. The one
+exception: under `--only-questions`, capture the ambiguity and stop.
+
+### Phase 5: Advance stage and commit
+
+1. Edit the feature frontmatter: `stage: drafting → implementing`. The
+   PostToolUse hook bumps `updated:`.
+2. Commit:
+   ```bash
+   git add .work/active/features/<id>.md
+   git commit -m "prose-author: <feature-id>"
+   ```
+
+Child stories are almost never warranted for prose — a single inline authoring
+stride covers it. Spawn one only if the deliverable genuinely splits into
+independent documents with separate acceptance (the feature-design Phase 7
+"when to spawn stories" rule applies, but the bar is rarely met here).
+
+## Handoff
+
+The feature is now at `stage: implementing` with no code-surface design debt.
+The matching implement path is **inline** `/agile-workflow:implement`: prose work
+qualifies for the inline lane on **no-coordination** grounds regardless of size —
+a 600-line convention rewrite is one authoring stride, not an orchestrated
+fan-out. Do not route prose features to `/agile-workflow:implement-orchestrator`
+(agent-spawning + worktrees) just because they exceed a line count; the
+orchestrator's value is parallel coordination, which prose work does not need.
+
+For a large deliverable, the inline `implement` is the **write** stride and
+`review` is a genuine **revise/coherence** pass — not a rubber stamp. For the
+common small case, implement is the one stride that finishes the work and review
+is light.
+
+## Output
+
+In conversation:
+- **Advanced**: `<feature-id>` → `stage: implementing` (or **misrouted**: retagged for feature-design)
+- **Brief**: sufficient as-is, or fleshed with a `## Outline`
+- **Next**: `/agile-workflow:implement <feature-id>` (inline — not the orchestrator)
+
+## Guardrails
+
+- `[prose]` is work-nature, not domain. Verify no real code surface every time —
+  the Phase 2 misroute test is the load-bearing check.
+- No exploratory sub-agents, no pre-mortem, no design `structured question tool` gate. If you
+  reach for any of them, the item probably wanted `feature-design` — misroute it.
+- Never advance past `implementing` — that's `implement` / `review`'s job.
+- The brief / outline lives in the feature body. NEVER create
+  `docs/designs/<name>.md` — agile-workflow uses item-IS-the-work.
+- Prose features implement **inline**, never via the orchestrator. Flag the
+  no-coordination property so the implement step takes the lean path.