@ikon85/agent-workflow-kit 0.27.1 → 0.28.0

package/.agents/skills/ask-matt/SKILL.md

@@ -53,7 +53,7 @@ Prefer the smallest depth that produces a clear next action.
 - **Deep:** `/grill-with-docs` followed by `/to-prd` and `/to-issues` when
   terminology, contracts, rollout order, or ownership are still uncertain.
 - **Medium:** `/to-issues` for a ready artefact that needs slicing.
-- **Light:** direct `/tdd` for a small, well-understood change.
+- **Light:** direct `/implement` for a small, well-understood change.
 - **Gate:** insert `/verify-spike` or `/decision-gate` before any depth level
   when a slice hinges on an unresolved fact or trade-off.
 
@@ -75,7 +75,7 @@ A starting situation that generates work, then merges onto the main flow.
 - **Something's broken** → **`/diagnose`**. For the hard ones: the bug that resists a first glance, the intermittent flake, the regression between two known-good states. Refuses to theorise until it has a **tight feedback loop** — one command that already goes red on *this* bug — then fixes with a regression test. Its post-mortem hands off to **`/improve-codebase-architecture`** when the finding is that there's no good seam.
 - **A huge, foggy effort too big for one agent session** — a greenfield build or a sprawling feature where the way from here to the destination isn't yet visible, and it's still **pre-spec** (before any grill or PRD) → **`/wayfinder`** (user-invoked). It charts a **shared map** of investigation slices on the tracker and resolves them one at a time — producing **decisions, not deliverables** — until the fog lifts and the route is clear, then merges onto the main flow at **`/to-prd`** (or, if the effort turned out small enough, straight to **`/implement`**). Where `/grill-with-docs` sharpens an idea you can hold in one session, wayfinder is for the one you can't. Once an undertaking has already resolved into several independently-shippable waves, `/scale-check` → `/to-waves` stays the primary route.
 - **A backlog to cluster** → **`/board-to-waves`**. Groups an existing board into themed waves when you need to *find* the next wave rather than start fresh.
-- **A whole wave to LAND** → **`/orchestrate-wave`**. When a wave anchor (file-disjoint slices, specs already locked) is ready to build, verify and land end-to-end — often AFK: it dispatches an implementer per slice in its own worktree, integrates serially, verifies centrally, and lands the wave. The execute-and-land node of the wave ladder (`scale-check` → `to-waves`/`board-to-waves` → `orchestrate-wave`). A single slice just goes to `/tdd`.
+- **A whole wave to LAND** → **`/orchestrate-wave`**. When a wave anchor (file-disjoint slices, specs already locked) is ready to build, verify and land end-to-end — often AFK: it dispatches an implementer per slice in its own worktree, integrates serially, verifies centrally, and lands the wave. The execute-and-land node of the wave ladder (`scale-check` → `to-waves`/`board-to-waves` → `orchestrate-wave`). A single slice just goes to `/implement`.
 
 ## Cross-model review (Codex)
 

package/.agents/skills/grill-me/SKILL.md

@@ -48,7 +48,7 @@ Once all decisions are made (plan locked, before sign-off/handoff) and the sessi
 
 ## Re-grill reconcile — execute-ready (Wave 26)
 
-Applies when you **re-grill an issue that already exists** (a leaf of a grilled epic, or a child of an anchor) — the most common re-grill path, since campaign HITL slices route via `/grill-me → /tdd`. Goal: the rooted sub-graph comes out **execute-ready**, never silent drift. (grill-me has no docs layer — CONTEXT.md/ADR don't apply; core rules identical to grill-with-docs §"Re-Grill Reconcile".)
+Applies when you **re-grill an issue that already exists** (a leaf of a grilled epic, or a child of an anchor) — the most common re-grill path, since campaign HITL slices route via `/grill-me → /implement`. Goal: the rooted sub-graph comes out **execute-ready**, never silent drift. (grill-me has no docs layer — CONTEXT.md/ADR don't apply; core rules identical to grill-with-docs §"Re-Grill Reconcile".)
 
 1. **Read parent-anchor decisions FIRST** — fetch the anchor body + its PRD/key decisions, take the seam decision **from there**. Do not re-derive the architecture from the leaf (lesson: a leaf whose central decision was never read got re-litigated through question rounds). For an atomic leaf, its own body/PRD is the reference.
 2. **Check the leaf for internal contradiction**: a body that contradicts itself ("no new UI" + "build a name field") or the anchor decision → **no execute**. Likewise a leaf that says *"final cut depends on #X"* via `<!-- final-cut-depends-on: #X -->` where **#X is closed** without resolving the cut.

package/.agents/skills/grill-with-docs/SKILL.md

@@ -136,6 +136,6 @@ Triggers when you **re-grill an issue that already exists in the graph** (a leaf
 2. **Check the leaf for internal contradiction** (Fix B): a body that contradicts itself ("no new UI" + "build a name field") or the anchor decision → **no execute**. Likewise a leaf that says *"final cut depends on #X"* via `<!-- final-cut-depends-on: #X -->` where **#X is closed** without resolving the cut.
 3. **On drift/contradiction:** update the affected issue(s), re-stamp `plan_revision`, set the correct bucket. An internal contradiction → set the leaf to **HITL** (remove `ready-for-agent`, add the `headings.vorBau` heading — board profile `docs/agents/board-sync.md`; <project> currently `## Vor Bau zu klären`); the drift-guard then blocks a build-handoff via `target_buildable`. So the contradiction flows through existing machinery — no semantic heuristic in the hook.
 4. **Audit, non-blocking:** `python3 scripts/execute-ready-check.py --issue <n> --mode audit` → visible two-liner. The **blocking** net is the drift-guard at handoff (`.claude/hooks/drift-guard.py`).
-5. **Global `-codex` variant** can't change the repo → leave a pointer note ("reconcile the issues + re-stamp plan_revision, repo-side"); real enforcement = the repo hook. **Honest bound:** the hook fires at the handoff/session boundary, not at a "grill-exit" event; a same-session global-codex grill → direct `/tdd` (no handoff) is a documented residual (global follow-up).
+5. **Global `-codex` variant** can't change the repo → leave a pointer note ("reconcile the issues + re-stamp plan_revision, repo-side"); real enforcement = the repo hook. **Honest bound:** the hook fires at the handoff/session boundary, not at a "grill-exit" event; a same-session global-codex grill → direct `/implement` (no handoff) is a documented residual (global follow-up).
 
 **Markers used here** (HTML comments, grep-able): `<!-- guard-ack: #<n> r<N> reason:<text> by-user -->` (deliberate handoff override), `<!-- final-cut-depends-on: #<n> -->`, `<!-- handoff-intent: build|grill -->`, `<!-- guard-legacy -->` (grandfathered legacy-anchor → warn not block). **Canonical table of all markers:** module docstring of `scripts/execute-ready-check.py`.

package/.agents/skills/kit-update/SKILL.md

@@ -40,6 +40,18 @@ release contain the same artifact.
    conflict manually; never auto-merge, delete a local edit, or silently choose
    the incoming copy.
 
+   For each conflicted kit-shipped file, always ask the user whether the local
+   edit is a generic improvement or project-specific; never decide or act
+   automatically. For a generic improvement, offer to file an issue in the
+   public kit repository and keep the local edit in place as a bridge until a
+   kit release containing the improvement lands. Before running
+   `gh issue create --repo <owner>/agent-workflow-kit`, show a sanitized preview
+   of the exact title and body with consumer identifiers and secrets stripped,
+   then require the user's explicit approval. The consumer user does not need
+   to be a kit maintainer. For a project-specific edit, recommend
+   `npx @ikon85/agent-workflow-kit@latest own <path>` so future updates treat
+   that path as consumer-owned.
+
 4. If a candidate is interrupted, discard its reported stage directory or
    resume the transaction through the update API's `resumeFrom` option. Do not
    copy staged files into the consumer by hand.

package/.agents/skills/orchestrate-wave/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: orchestrate-wave
-"description": "Use when the user hands you a whole WAVE / cluster of pre-planned, file-disjoint slices and wants you to ORCHESTRATE building, verifying AND landing it end-to-end — often AFK / \"ultracode\". Triggers: \"orchestriere Welle #N\" (or any wording that delegates wave-landing responsibility to you), \"ultracode diese Welle / diesen Cluster\", or a wave-anchor issue (a cluster/umbrella issue with file-disjoint sub-issues whose specs are already locked) handed over to land. NOT for a single slice (just `tdd` it), NOT for finding/clustering a wave (that's `board-to-waves`), NOT for planning specs (that's `grill-with-docs`/`to-issues`)."
+"description": "Use when the user hands you a whole WAVE / cluster of pre-planned, file-disjoint slices and wants you to ORCHESTRATE building, verifying AND landing it end-to-end — often AFK / \"ultracode\". Triggers: \"orchestriere Welle #N\" (or any wording that delegates wave-landing responsibility to you), \"ultracode diese Welle / diesen Cluster\", or a wave-anchor issue (a cluster/umbrella issue with file-disjoint sub-issues whose specs are already locked) handed over to land. NOT for a single slice (just `implement` it), NOT for finding/clustering a wave (that's `board-to-waves`), NOT for planning specs (that's `grill-with-docs`/`to-issues`)."
 ---
 
 # Orchestrate Wave
@@ -40,6 +40,10 @@ you must NOT paraphrase.
   - **Plan-level error** (integration/verify reveals a wrong LOCKED decision, not a
     slice bug): STOP the wave. No improvised redesign AFK — keep worktrees intact,
     report findings + options.
+  - **On ANY wave STOP/abort:** if this run planted the active-wave claim, remove
+    exactly that claim as part of shutdown. Never delete a claim marker observed
+    during a preflight collision, nor any sibling/foreign wave marker — those are
+    owned by another run. A stale marker owned by this run would block a safe retry.
 - **Routing = one axis: how expensive is a wrong result to catch?** Mechanically
   caught (test/screenshot/lint) → default tier at medium/low effort; plausible-but-
   wrong / subtle logic / architecture → top tier at high effort + main-thread
@@ -64,19 +68,30 @@ you must NOT paraphrase.
    **once** that `/setup-workflow` plus project maintenance fill the layer (the
    commands/tunnel/login can't be guessed). Never treat an empty heading as a
    verify recipe.
-3. **Wave worktree**: reuse the planning worktree (never re-create; the handoff
+3. **Preflight — refuse a wave already in flight, otherwise claim it.** Before
+   dispatch, inspect all three same-machine collision signals: **(a)** an existing
+   `wave-active/<anchor>` tag; **(b)** any slice branch ahead of the wave's current
+   base (`git rev-list --count <base>..<slice-branch>` > 0); **(c)** uncommitted
+   changes in any slice worktree (`git -C <worktree> status --porcelain` non-empty).
+   A hit not created by this run means another session may be building the wave:
+   **STOP**, report the exact tag/branch/worktree, and do not touch it. If clean,
+   record that this run owns the claim and plant a LOCAL annotated tag:
+   `git tag -a wave-active/<anchor> -m "orchestrating since <UTC timestamp>;
+   slices: <slice-branches>"`. It is local coordination state — never push it.
+4. **Wave worktree**: reuse the planning worktree (never re-create; the handoff
    points there). Bring its branch to current `main`:
    `git -C <wave> merge --ff-only origin/main` (if your repo guards destructive
    git, ff-merge is the safe path — not `reset --hard`). Install dependencies with
    your package manager after (the lockfile may have moved). A gitignored plan doc
    survives the merge.
-4. **Run project setup steps (`§Setup`)** the later verify needs — e.g. a DB
+5. **Run project setup steps (`§Setup`)** the later verify needs — e.g. a DB
    tunnel or service the live-verify depends on. Absent layer → start whatever your
    live-verify environment requires before Phase 4.
 
 **Done when:** anchor + every sub-issue + plan read · project layer probed
-(filled → project recipe; stub/absent → generic + one-time warning) · wave branch
-ff'd to `origin/main` + deps installed · project setup steps running.
+(filled → project recipe; stub/absent → generic + one-time warning) · preflight
+clean + this run's local claim planted · wave branch ff'd to `origin/main` + deps
+installed · project setup steps running.
 
 ## Phase 1 — Disjointness recon (the load-bearing step)
 
@@ -108,6 +123,13 @@ Zero merge conflicts later depends entirely on getting this right.
   "X already exists in `<file>` — do NOT add it, consume only." (Real case: all 14
   sub-issues claimed the same registry adds + 4 contradictions — hub expanded to
   own all 20 keys, batch merged conflict-free.)
+- **Retirement slices require a valid topological deletion order.** Before
+  dispatching slices that delete a legacy cluster, map every to-delete module's
+  production importers and build the cluster's internal import graph. Order the
+  deletions so no pending slice imports a module already removed; zero remaining
+  production importers is the behavior-neutral proof. If mutually dependent
+  deletions form a cycle, separate each-slice-green steps are impossible: combine
+  the whole cycle into ONE atomic slice instead of landing dangling imports.
 
 **Done when:** FILE→SLICES table exists · every ≥2-slice file has exactly ONE
 owning slice · disjoint waves cut in dependency order · every dependent contract
@@ -225,15 +247,19 @@ checks pass · console 0/0 · DB outcome value compared.
 - **`Closes #N` needs the keyword before EACH issue, one per line** — `Closes #a,
   #b` only closes the first. Anchor → `Part of #<anchor>`, never `closes`
   (premature close).
-- **Anchor tracker: `python3 scripts/board-sync.py anchor-sync <anchor#>`** — first
-  `--dry-run`, review the diff, then write; gate symbol + stable cells of freshly
-  appended rows by hand. Mandatory at EVERY slice event: PR-create AND merge.
+- **Anchor tracker sync is mandatory at EVERY slice event (PR-create AND merge).**
+  Use the project-layer command from `§Landing`: dry-run first, review the diff,
+  then write; preserve gate symbols and stable cells of freshly appended rows.
+  Absent a filled layer, use the tracker's native parent/table reconciliation.
 - **Stacked follow-up PRs** that build on the unmerged wave: base on the **wave
-  branch** (not main) — the platform auto-retargets them when the wave PR merges.
-  Note the merge order in the body.
-- New issues via `scripts/board-sync.py` (never bare `gh issue create`); write
-  multi-paragraph PR/issue bodies via `--body-file` (an inline body with backticks
-  can crash the shell).
+  branch** (not main) and note the merge order in every PR body. **Do NOT rely on
+  auto-retarget:** deleting the merged base branch can close its stacked child.
+  Either merge the child before deleting the base, or expect the close and open a
+  FRESH PR from the child's still-existing head branch against the final base.
+  Keep any deploy/release/manual gate in the documented merge order.
+- New issues go through the project-layer board command (`§Landing`; never a bare
+  tracker-create call that skips the board). Write multi-paragraph bodies through
+  a body file so shell metacharacters cannot alter them.
 
 **Done when:** PR(s) open with correct `Closes`/`Part of` lines · anchor-sync
 written · merge order documented.
@@ -243,19 +269,40 @@ written · merge order documented.
 - Stop the dev server(s) you started, by port (`lsof -ti:<port> | xargs kill` —
   your own processes, targeted by the worktree's assigned ports, never blind).
   Remove temp verify scripts (a login helper, DB-check scripts).
+- **Remove only this run's claim marker.** If this run planted
+  `wave-active/<anchor>`, delete that exact local tag after success or abort. Never
+  delete a claim marker observed during a preflight collision or any other
+  `wave-active/*` marker; ownership, not a broad pattern, authorizes cleanup.
 - **Before removing any slice worktree, read its `ANNAHMEN.md`** (an assumptions
   log, gitignored at worktree-root) and propagate each build-time assumption marker
   to the sibling issue it carries. A hand-driven multi-PR / migration landing does
   NOT run `wrapup`'s assumption-propagation step — this is the only place it
   happens; `worktree remove` deletes the log.
-- **Post-merge:** run `anchor-sync` again; verify every leaf issue actually closed
-  (the same checks `wrapup` runs, by hand when landing outside `wrapup`). The
-  anchor closes manually — a parent is not auto-closed on sub-issue completion.
-- A skill edited during the wave → run `codex-adapter-sync` (lives in
-  `.agents/skills/`) in the SAME PR — the mirror-presence-parity lint is a
-  pre-PR gate and blocks a dual-surface skill PR without its mirror.
+- **Post-merge completion sync:** use `§Landing` to reconcile the anchor again and
+  verify every leaf actually closed. Then read the anchor's `Closing Conditions`,
+  `Done when`, and acceptance criteria and make an explicit closure decision:
+  - **No open manual gate:** close the anchor, set its project completion status to
+    the configured done role, and re-read the board item to verify both states.
+    Closing the tracker issue alone is not proof that its workflow field changed.
+  - **Open manual gate:** ask the user in the main thread, naming the exact gate and
+    condition. Confirmation follows the close/status/verify path above; otherwise
+    leave the anchor open and add exactly one completion marker explaining the
+    remaining gate and close condition.
+- **Program propagation:** resolve the anchor's native parent with the
+  project-layer command from `§Landing`. If the parent is a Program-PRD, run the
+  project-layer program sync after the anchor decision. On closure, set the
+  anchor's completion status first so the program can observe the completed wave;
+  run program sync again after close even if landing ran it earlier. If a manual
+  gate remains open, propagation may refresh the program but must not claim wave
+  completion. Absent a filled layer, use equivalent tracker-native parent lookup,
+  completion-field update, re-read, and program propagation commands.
+- A skill edited during the wave → sync its dual-surface mirror in the SAME PR
+  using the tool named by `§Landing` when present; mirror parity remains a pre-PR
+  gate.
 - Leave slice worktrees for the user to inspect, or note they're
   post-merge-removable.
 
-**Done when:** no orphan process · ANNAHMEN propagated · anchor reconciled + leaf
-closes verified · final report lists landed/pulled slices as **X of Y**.
+**Done when:** no orphan process · this run's claim removed · ANNAHMEN propagated ·
+anchor reconciled + leaf closes verified · anchor closure decided and documented ·
+Program-PRD propagation completed or explicitly skipped · final report lists
+landed/pulled slices as **X of Y**.

package/.agents/skills/orchestrate-wave/references/builder-contract.md

@@ -51,12 +51,14 @@ invocation for each in this prompt so the builder cannot guess a wrong one.
 2. Commit your ONE commit on the slice branch FIRST — before any longer verify
    (verify-then-forget-to-commit leaves the orchestrator hand-committing your
    worktree). Do NOT push. Do NOT `--no-verify` (pre-commit hooks must pass).
-3. Run the commands above. Never end your turn with a background command still
-   running.
+3. Run the commands above IN THE FOREGROUND — never background a test/gate
+   command. Use a generous foreground timeout for a long suite and wait for every
+   completed command result. Never end your turn while a command is still running.
 
 ## Report back (concise)
-Files touched · decisions taken · test results (exact output) · commit SHA ·
-STOP items · what the orchestrator should visually verify.
+Files touched · decisions taken · test results (exact completed command results
+and exit status) · commit SHA · STOP items · what the orchestrator should visually
+verify.
 ```
 
 Orchestrator notes:

package/.agents/skills/retro/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: retro
-disable-model-invocation: true
+disable-model-invocation: false
 "description": "Use when the user explicitly asks for a retro after a session with PR-activity. Analyzes session friction and proposes concrete config mutations (Memory/Skill/CLAUDE.md/Hook) with per-patch approval. No file is written — findings live in the mutated config."
 ---
 
@@ -114,6 +114,25 @@ For **every** friction point (user-reported AND self-found), the agent analyzes:
 
 If the user's description in step 2a is ambiguous, the agent may ask **ONE** clarifying outcome question — e.g. "where was it most annoying — during setup, mid-work, or during cleanup?". Never multiple-choice with memory names, hook paths, or config classes.
 
+### 3a. Mechanical enforcement check (before target + weight)
+
+Before placing a finding on the target/weight ladder, ask for every finding:
+
+> **"Could a machine decide this — with a grep, parser, test, hook, or CI gate?"**
+
+- **Yes, within the current patch:** implement the enforcement. Supporting prose
+  may explain the rule, but prose alone does not resolve a machine-checkable
+  finding.
+- **Yes, but enforcement is too expensive for the current patch:** propose the
+  prose change **plus a tracked enforcement issue** and state the **explicit
+  trade-off** (why enforcement is deferred, what failure remains possible, and
+  when the issue should fire). Do not present the prose-only half as complete.
+- **No:** record why judgment is required, then continue to the target/weight
+  ladder.
+
+This check prevents detection without enforcement: a rule that a machine can
+decide should not depend on a future reader remembering a sentence.
+
 ### 3b. Determine target + weight (threshold ladder)
 
 Before formulating a patch in step 4, place **every** friction point on the threshold ladder. **Weight** = how durable/far-reaching the rule is (drives the visible patch line in step 4 + the user's approval depth). **Target** = where the patch physically goes.
@@ -137,6 +156,10 @@ Before formulating a patch in step 4, place **every** friction point on the thre
 
 **A GitHub issue is NOT a weight tier.** A real follow-up = work to track → `python3 scripts/board-sync.py create` (step-4 table), **orthogonal** to the ladder; its "weight" follows the follow-up scope. The ladder classifies **config patches**, not "turn it into a ticket".
 
+**Kit-repo routing target (always ask; never automatic).** When a finding lands on a kit-shipped file (a consumer-manifest entry with kit origin), ask whether the improvement is generic or project-specific. For a generic improvement, offer to file a lightweight issue against the public kit repo: a title plus a short body that states the finding, affected file, and why it is generic. For a project-specific improvement, recommend `own` (keep it consumer-owned). The consumer user does not need to be the kit maintainer.
+
+Before any `gh issue create --repo <owner>/agent-workflow-kit` runs, show the user a **sanitized preview** of the exact title and body with consumer identifiers and secrets stripped. Create the issue only after the user explicitly approves that exact text; if the title or body changes, show the revised preview and ask again. This approval is additional to the per-patch approval in step 5.
+
 **Target missing in the project — separate two cases cleanly:**
 - **(a) Tier skill missing entirely** (e.g. a foreign project without `spec-self-critique`): no durable spec-time gate exists. **Memory is NOT a substitute** — passive recall doesn't catch a recurring spec defect before building. Report honestly: *"this project has no durable target for this tier"* + propose a `/setup-workflow` follow-up. **No fake guard via memory.**
 - **(b) Skill exists, project-layer file missing** (`docs/agents/skills/<skill>.md`): **create / append** — that is the normal retro-sink behavior that `spec-self-critique` step 0 expects anyway. **No** downgrade.

package/.agents/skills/scale-check/SKILL.md

@@ -119,7 +119,7 @@ One behavior, already clear enough to build — no PRD, no slicing.
 
 ```
 Small change: <one-sentence behavior>.
-`tdd` — one behavior at a time, red → green → refactor. No PRD, no decomposition.
+`implement` — build directly, one behavior at a time (red → green → refactor). No PRD, no decomposition.
 ```
 
 ### Bug (something that used to work)
@@ -134,7 +134,7 @@ Bug: <what's broken — expected vs. actual>.
 ```
 scale-check: verdict=<Program | Feature | Direct-Slice | Bug>
   criteria tripped=<C1,C2,… | none | n/a (bug/direct)>
-  route=<program grill → to-prd → to-waves (all waves execute-ready by default) | grill-with-docs → to-prd → to-issues | tdd | diagnose>
+  route=<program grill → to-prd → to-waves (all waves execute-ready by default) | grill-with-docs → to-prd → to-issues | implement | diagnose>
   start-prompt: <the paste-ready block above, filled in>
 ```
 

package/.agents/skills/setup-workflow/SKILL.md

@@ -27,6 +27,7 @@ This is a prompt-driven skill, not a deterministic script. Explore, present what
 | `.github/workflows/agent-workflow-kit-update.yml` | optional tested Kit update pull request for GitHub consumers (Section A2) |
 | `docs/agents/census.md` | optional-census choice, paths, state, and safe disable contract seeded from [census.md](./census.md) (Section A3) |
 | `docs/agents/workflow-capabilities.json` + capability assets | consumer-owned Worktree Lifecycle, Memory Lifecycle, Workflow Advisories, and Safety Guardrails choices (Sections A4–A7) |
+| `.claude/settings.json` | additive activation of the advisory kit-origin Edit/Write hint (Section A8) |
 
 ## Idempotency contract — read before writing anything
 
@@ -57,7 +58,7 @@ Read the current state; don't assume. For every target file, read its first line
 - `CONTEXT.md`, `CONTEXT-MAP.md`, `docs/adr/` — domain-doc layout.
 - `docs/agents/`, `docs/agents/skills/`, `docs/conventions/` — prior output of this skill.
 - `docs/agents/census.md`, `.census/profile.json`, `.census/active.json` — an existing census choice or consumer-owned census to adopt.
-- `docs/agents/workflow-capabilities.json`, `.claude/settings.json`, `git config --get core.hooksPath` — existing capability choices/profile plus Worktree Lifecycle, Workflow Advisories, and Safety Guardrails wiring to adopt.
+- `docs/agents/workflow-capabilities.json`, `.claude/settings.json`, `git config --get core.hooksPath` — existing capability choices/profile plus Worktree Lifecycle, Workflow Advisories, Safety Guardrails, and kit-origin hint wiring to adopt.
 - `.memory/active/`, `.memory/archive/`, and `.memory/receipts/` — consumer-owned Memory Lifecycle policies or recovery evidence to adopt without normalization.
 - `gh auth status` (if GitHub) — is `gh` authenticated, and with which scopes?
 
@@ -243,6 +244,42 @@ The seed's reference consumer uses the parity-on profile. Other consumers are
 opt-in/manual: never copy its package-manager, path, shim, surface, or outage
 decisions without repository evidence and user confirmation.
 
+### 2g. Section A8 — Advisory kit-origin edit hint (non-interactive)
+
+> The shipped kit-origin hook asks the upstream-or-own question before an agent
+> Edit/Write changes a file recorded with `origin: "kit"` in the consumer
+> manifest. It is advisory only: it never blocks, reads the manifest once, uses
+> no network, and silently fails open when the manifest cannot be read. Shell
+> redirection, formatters, and IDE edits are knowingly outside its coverage; the
+> skills remain the rule's primary carrier.
+
+Activate the shipped hook by reconciling this exact entry into
+`.claude/settings.json`:
+
+```json kit-origin-edit-hook-settings
+{
+  "matcher": "Edit|Write",
+  "hooks": [
+    {
+      "type": "command",
+      "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/kit-origin-edit-hint.py\""
+    }
+  ]
+}
+```
+
+This is an additive, idempotent settings edit, not a settings rewrite:
+
+1. Missing settings → create `{ "hooks": { "PreToolUse": [<entry>] } }`.
+2. Existing valid settings → preserve every consumer key, matcher, command,
+   hook event, ordering, and formatting byte-for-byte; append only `<entry>` to
+   `hooks.PreToolUse`.
+3. If any existing hook already contains the exact command above, do nothing,
+   regardless of its surrounding matcher. A rerun must be byte-identical.
+4. Unreadable/invalid settings, or a non-object `hooks` / non-array
+   `PreToolUse`, are consumer-owned conflicts: leave the file untouched and
+   report the skipped activation. Never replace or normalize them.
+
 ### 3. Section B — Triage labels
 
 > When `triage` processes an incoming issue it applies labels (or your tracker's equivalent). It needs strings you've actually configured, or it creates duplicates.
@@ -341,6 +378,12 @@ Do not copy templates with shell commands or edit the capability profile by
 hand. Report `seeded · adopted · skipped`; do not print memory contents or
 receipt contents.
 
+For `.claude/settings.json`, run the Section A8 reconciliation on fresh and
+already-initialized consumers. Report `activated · already active · skipped
+(consumer-owned conflict)`. Do not make the hook conditional on an optional
+capability choice: its self-filtering, fail-open behavior keeps it inert except
+for matching kit-origin Edit/Write events.
+
 For the **`## Workflow`**, **`## Agent skills`**, and **`## Prod`** blocks, reconcile per section in **both** CLAUDE.md and AGENTS.md that exist:
 
 - If **both** files exist → write/update the block in **both** (keep them coherent — Codex is a first-class surface).

package/.agents/skills/setup-workflow/workflow-overview.md

@@ -11,12 +11,12 @@ Use this section as the entry-point map for agent-assisted work. The individual
 - **Existing plan, PRD, or ready issue:** use `to-issues` to split it into independently buildable tracer-bullet slices.
 - **A Program-PRD with a wave plan:** use `to-waves` to unfold it into named wave stubs + slice leaves on the board, after a chat preview gate that shows the whole plan before any write.
 - **A backlog of open issues needs clustering into themed waves:** use `board-to-waves`.
-- **A whole wave anchor (file-disjoint slices, specs already locked) to build, verify and land end-to-end — often AFK:** use `orchestrate-wave` — it dispatches implementers per slice, integrates serially, verifies centrally, and lands. (A single slice just goes to `tdd`.)
+- **A whole wave anchor (file-disjoint slices, specs already locked) to build, verify and land end-to-end — often AFK:** use `orchestrate-wave` — it dispatches implementers per slice, integrates serially, verifies centrally, and lands. (A single slice just goes to `implement`.)
 - **Bugs or requests piling up that you didn't create:** use `triage` to move them into agent-ready issues.
 - **Bug or regression:** use `diagnose` to reproduce, minimize, hypothesize, instrument, fix, and regression-test.
 - **A design question needs a runnable answer (state, business logic, a UI you have to see):** spike it with `prototype`, then fold what you learned back in.
-- **Multi-session build from a PRD or issue:** use `implement` to drive `tdd` end-to-end, one red-green slice at a time.
-- **Implementation slice:** use `tdd` for one behavior at a time: RED, GREEN, then refactor.
+- **Multi-session build from a PRD or issue:** use `implement` to drive the build end-to-end, one red-green slice at a time.
+- **Implementation slice:** use `implement` for one behavior at a time: RED, GREEN, then refactor.
 - **Build or refresh a project-local census:** use `census-update` to scan facts, resolve ambiguous decisions one at a time, and transactionally activate a counted census.
 - **Preview or restore consumer-owned memories:** use `memory-lifecycle` to classify every configured path without writing, then apply an explicitly approved collision-safe restore with a content-free receipt.
 - **Finished slice:** use `wrapup` to prepare the branch, PR, and cleanup steps your repo expects.
@@ -27,11 +27,11 @@ Use this section as the entry-point map for agent-assisted work. The individual
 
 ## Routing Rule
 
-Prefer the smallest workflow that produces a clear next action. A tiny fix can go straight to `tdd`; a cross-cutting feature should become a PRD and then slices before implementation. When a skill reports missing project context, run `setup-workflow` again and fill only the missing stub.
+Prefer the smallest workflow that produces a clear next action. A tiny fix can go straight to `implement`; a cross-cutting feature should become a PRD and then slices before implementation. When a skill reports missing project context, run `setup-workflow` again and fill only the missing stub.
 
 ## Depth Ladder
 
-- **Light:** direct `tdd` for a small, well-understood change.
+- **Light:** direct `implement` for a small, well-understood change.
 - **Medium:** `to-issues` for a ready artefact that needs slicing.
 - **Deep:** `grill-with-docs` followed by `to-prd` and `to-issues` when terminology, contracts, rollout order, or ownership are still uncertain.
 - **Gate:** insert `verify-spike` or `decision-gate` before any depth level when a slice hinges on an unresolved fact or trade-off.

package/.agents/skills/tdd/SKILL.md

@@ -60,6 +60,8 @@ Before writing any code:
 
 - [ ] Confirm with user what interface changes are needed
 - [ ] Confirm with user which behaviors to test (prioritize)
+- [ ] Find the nearest existing tests for those behaviors
+- [ ] Assign exactly one test-delta decision per behavior
 - [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
 - [ ] Design interfaces for [testability](interface-design.md)
 - [ ] List the behaviors to test (not implementation steps)
@@ -69,34 +71,81 @@ Ask: "What should the public interface look like? Which behaviors are most impor
 
 **You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
 
-### 2. Tracer Bullet
-
-Write ONE test that confirms ONE thing about the system:
+### 2. Existing-Test-First Decision
+
+TDD does not imply a new test file or a growing test count. Start at the nearest
+existing behavioral test. For each planned behavior, record exactly one of these
+test-delta decisions:
+
+- **REUSE** — the existing public-behavior test already protects the change.
+- **EXTEND** — add the missing boundary to the nearest suite or parameter table.
+- **REPLACE** — establish equivalent protection at a smaller or more stable level,
+  then retire the duplicate.
+- **NEW** — only for a distinct, previously unprotected risk; name the plausible
+  defect it catches.
+- **RETIRE** — the behavior or contract is intentionally gone or already replaced;
+  delete its obsolete test.
+- **NO-NEW-TEST** — a behavior-neutral refactor or removal without a durable
+  negative contract.
+
+Do not create a new test file until the nearest existing owner has been inspected
+and rejected with a reason. A feature, source file, component, method, or
+acceptance-criterion line is not itself a test boundary.
+
+Every executable new behavior and bug fix must begin with a failing assertion.
+REUSE and NO-NEW-TEST never bypass this RED-first invariant. For a `REUSE`
+candidate, run the existing assertion before implementation: if the requested
+behavior is executable and the assertion is already green, an already-green
+assertion does not prove the requested change; choose `EXTEND`, or choose `NEW`
+after rejecting the nearest owner. `NO-NEW-TEST` is limited to behavior-neutral
+work and removals without a durable absence contract.
+
+For removals, delete the tests that specified the retired behavior. Add or keep a
+negative assertion (`404`, forbidden, hidden) only when absence itself is a durable
+security, API, or compatibility promise. Permanent skipped executable tests are
+retired or moved to a runbook or issue, not parked in the green suite.
+
+### Worked decision matrix
+
+| Behavior situation | Decision | Feedback proof |
+|---|---|---|
+| An existing regression test reproduces the bug | REUSE | Existing assertion is RED, then the minimal fix makes it GREEN |
+| The nearest suite lacks one requested boundary | EXTEND | Added assertion is RED, then the minimal change makes it GREEN |
+| A broad duplicate can become a stable focused check | REPLACE | Equivalent protection is proven before the duplicate is removed |
+| A distinct risk has no suitable owner after documented inspection | NEW | New assertion is RED and names the plausible defect it catches |
+| The specified behavior is intentionally removed | RETIRE | Obsolete test is removed with the obsolete behavior |
+| An internal refactor preserves all observable behavior | NO-NEW-TEST | Relevant existing suite is GREEN before and after the change |
+
+### 3. First Feedback Cycle
+
+Pick ONE behavior and use its decision's feedback loop:
 
 ```
-RED:   Write test for first behavior → test fails
-GREEN: Write minimal code to pass → test passes
+REUSE, executable change: existing assertion → RED → minimal code → GREEN
+EXTEND/NEW:              assertion in nearest suite → RED → minimal code → GREEN
+REUSE, neutral change:  relevant suite GREEN → small refactor → stays GREEN
+REPLACE:                 prove equivalent protection → remove duplicate → GREEN
+RETIRE:                  remove obsolete behavior and its obsolete test → GREEN
+NO-NEW-TEST:             relevant suite GREEN → behavior-neutral change → stays GREEN
 ```
 
-This is your tracer bullet - proves the path works end-to-end.
+The RED-to-GREEN cycle is the tracer bullet for each executable new behavior or
+bug fix. It proves the path end to end without automatically creating another
+test file.
 
-### 3. Incremental Loop
+### 4. Incremental Loop
 
-For each remaining behavior:
-
-```
-RED:   Write next test → fails
-GREEN: Minimal code to pass → passes
-```
+Repeat one behavior at a time, using the matching feedback loop above.
 
 Rules:
 
 - One test at a time
+- Prefer extending the existing owner or parameter matrix over adding a sibling file
 - Only enough code to pass current test
 - Don't anticipate future tests
 - Keep tests focused on observable behavior
 
-### 4. Refactor
+### 5. Refactor
 
 After all tests pass, look for [refactor candidates](refactoring.md):
 
@@ -114,7 +163,12 @@ After all tests pass, look for [refactor candidates](refactoring.md):
 [ ] Test describes behavior, not implementation
 [ ] Test uses public interface only
 [ ] Test would survive internal refactor
+[ ] Exactly one test-delta decision is recorded for this behavior
+[ ] NEW names the distinct plausible defect; a new file has a justified owner boundary
 [ ] Code is minimal for this test
 [ ] No speculative features added
 [ ] Wave slice: a flipped/new assumption affecting an unbuilt sibling issue → log it to ANNAHMEN.md (worktree root; wrapup Step 0c reads it)
 ```
+
+At handoff, list every behavior and its one decision, then report the counted
+test delta: `Reused X · Extended Y · New Z · Replaced/retired W`.

package/.agents/skills/to-issues/SKILL.md

@@ -54,7 +54,7 @@ Even when the slices were already cut upstream (a grill/PRD slice table), do NOT
 - **Seam ownership check (Fix A):** does any slice **replace/unify/retire a central mechanism**? If yes, it MUST be its own 🧊 grill-needed slice — NOT hidden in a behavior-preserving naming/tweak leaf. A byte-neutral slice does not discharge the seam.
 - **Blast-radius threshold:** for each slice, estimate the blast radius (~N files, from recon/grep — not a guess; workflow slices count SKILL.md + adapter mirrors + tests). **≥ 10 estimated files OR not estimable → check for a split.** If the slice stays deliberately large, it MUST be 🧊 **grill-needed** (HITL) with a "why indivisible" justification **in the issue body** — a guideline, not a hard block, but the deviation lives in the body, not in the agent's head. (Incident: a slice cut too coarse ballooned to 34 prod files at execute-recon, an emergency in-build split — no gate at the cut existed.) (Terminology note: this blast radius is a **slice estimate** — ~N files for this one cut — not a project-owned rollout-completeness census (e.g. an-style, code-derived "X of Y" census over all surfaces of a cross-cutting concept, if your repo runs one).)
 <!-- mirror-xform:start codex-escalation -->
-- **Gate type + sequencing (Retro):** every slice that is **not** a clean AFK build gets a gate tag — 🧭 **Design Grill** (a decision with alternatives, hard-to-reverse, ADR-worthy → `grill-with-docs`), 🔬 **Verify Spike** (a pure fact question, read-only), 📐 **Trade-off/Research** (a concrete trade-off choice OR "needs more research", **below** the grill threshold — read-only research + a documented trade-off in the issue), 📝 **Review Note** (a finding, **not** a build slice). A gate slice (🧭/🔬/📐) is cut as its **own slice**, sequenced **before** its dependent build slice, and blocks it (gate-before-build — published as a **native blocking edge** (§5a step 5), visible in the mirrored "Blocked by" section + table order). "Needs a decision / open call / research gap" while cutting → gate slice, **never** a blind AFK `/tdd`. (🔬 **Verify Spike** runs via the `verify-spike` skill — read-only fact question, throwaway harness, verdict as ADR/comment, the throwaway deleted. 📐 **Trade-off/Research** runs via the `decision-gate` skill — options + criteria, read-only research/measurement, a documented trade-off table, a reasoned decision as ADR/comment; throwaway measurement code deleted.)
+- **Gate type + sequencing (Retro):** every slice that is **not** a clean AFK build gets a gate tag — 🧭 **Design Grill** (a decision with alternatives, hard-to-reverse, ADR-worthy → `grill-with-docs`), 🔬 **Verify Spike** (a pure fact question, read-only), 📐 **Trade-off/Research** (a concrete trade-off choice OR "needs more research", **below** the grill threshold — read-only research + a documented trade-off in the issue), 📝 **Review Note** (a finding, **not** a build slice). A gate slice (🧭/🔬/📐) is cut as its **own slice**, sequenced **before** its dependent build slice, and blocks it (gate-before-build — published as a **native blocking edge** (§5a step 5), visible in the mirrored "Blocked by" section + table order). "Needs a decision / open call / research gap" while cutting → gate slice, **never** a blind AFK `/implement`. (🔬 **Verify Spike** runs via the `verify-spike` skill — read-only fact question, throwaway harness, verdict as ADR/comment, the throwaway deleted. 📐 **Trade-off/Research** runs via the `decision-gate` skill — options + criteria, read-only research/measurement, a documented trade-off table, a reasoned decision as ADR/comment; throwaway measurement code deleted.)
 <!-- mirror-xform:end -->
 - **🧭-vs.-📐 discriminator:** if the decision replaces/unifies/retires a **central seam**, is a **one-way door** (hard/costly to reverse), or a **schema migration** → 🧭 Design Grill (ADR-worthy, see Seam Ownership above). Otherwise — a **bounded choice between concrete options**, easily revised → 📐 Trade-off/Research.
 - **Absence-before-build (Retro):** a slice cut as "build feature/page/endpoint/flow X" (or a gate "X gap unclear") MUST cite an **existence grep** — *absent* (`grep <pattern> = 0` across route **and** UI **and** repo) OR *partial* (`exists @<file>, gap = <Y>`). A hedge ("current state unclear → verify during build") is **not** a valid slice state: the check is cheap (minutes), so it happens **at the cut**, not deferred into a gate. (Incident: a gate was cut for a feature that greps already showed built — the gap was deferred instead of resolved.)
@@ -302,7 +302,7 @@ Reference the blocking ticket(s), or "None - can start immediately".
 <!-- mirror-xform:start codex-escalation -->
 ```
 Welle <N> · Slice <X> (<closes #x | refs #<prd#>, Parent #<prd#>>). Read #<prd#> for decisions.
-Start skill: 🧭 Design Grill → /grill-with-docs · 🔬 Verify Spike → /verify-spike · 📐 Trade-off/Research → /decision-gate · AFK → /tdd · HITL → /grill-me → /tdd. Recommended model: <Model [Effort]>.
+Start skill: 🧭 Design Grill → /grill-with-docs · 🔬 Verify Spike → /verify-spike · 📐 Trade-off/Research → /decision-gate · AFK → /implement · HITL → /grill-me → /implement. Recommended model: <Model [Effort]>.
 Worktree: your project's worktree helper, or `git worktree add`
 Scope (<N> files) — REQUIRED FIELD, blast-radius estimate at cut time; the build session checks it against its own recon findings, >2x deviation → STOP:
 - <concrete file + change>

package/.agents/skills/verify-spike/SKILL.md

@@ -17,7 +17,7 @@ This is the "Verify First" rule with a runnable harness behind it: when you cann
 | "Which of these options, given these trade-offs?" / "I need to research this before I can choose." (bounded, sub-grill) | `decision-gate` |
 | "Does this design / state model / UI feel right?" (open-ended) | `prototype` |
 | "Why is this broken / slow?" (root-cause of a known defect) | `diagnose` |
-| "Build this behaviour, test-first." (new feature/fix) | `tdd` |
+| "Build this behaviour, test-first." (new feature/fix) | `implement` |
 
 If the question is really "what should this be", it is not a verify-spike — those are open, not yes/no.
 

package/.agents/skills/wrapup/SKILL.md

@@ -29,9 +29,21 @@ Hard stop (the only pure precondition): not in a feature worktree / on `main`
 
 ### 2 · Retro gate (blocking, optional retro-exit — before anything is committed)
 One reminder, not a merge confirmation:
-> "Already ran a retro? **(a)** yes / continue → landing now. **(b)** you want one first → clean abort here, run `/retro`, then `/wrapup` again — repo-file patches then travel in this PR."
+> "Already ran a retro? **(a)** yes / continue → landing now. **(b)** you want one first → the retro starts now; afterwards, invoke `/wrapup` again — repo-file patches then travel in this PR."
 
-(b) → exit cleanly, touch nothing (a skill can't pause/resume another skill). **Never auto-run `/retro`.** The answer materializes as the mandatory `**Retro:**` PR-body line in step 4 — that's recording, not a second question. Why the gate lives here: in a foreign project this is the only portable retro touchpoint; a project-local "offer retro before PR" convention usually answers it already.
+(b) → **invoke the `retro` skill immediately in this run.** Retro is
+model-invocable and non-deploying, and every mutation still has its own approval
+gate. After retro finishes, **land nothing in this run**. Require a **fresh
+explicit `/wrapup` invocation** because retro may have changed the exact diff
+that the next merge authorization covers.
+
+General chaining rule: automatically chain only into a **model-invocable**,
+**non-deploying** workflow. If the named target is user-only, deploys, or
+depends on an external action, **return control to the user** and **state the
+reason**. A forward chain never carries wrapup's merge/deploy authorization
+into another run.
+
+The answer materializes as the mandatory `**Retro:**` PR-body line in step 4 — that's recording, not a second question. Why the gate lives here: in a foreign project this is the only portable retro touchpoint; a project-local "offer retro before PR" convention usually answers it already.
 
 ### 3 · Commit (only if the tree is dirty)
 Judgment first, then the guarded commit:

package/.claude/hooks/drift-guard.py

@@ -48,8 +48,11 @@ GUARD_ACK_RE = re.compile(r"<!--\s*guard-ack:\s*#?\d+\s+r\d+\s+reason:.+\bby-use
 # Load the shared checker (hyphenated filename → importlib). Repo root = parents[2].
 _CHECKER_PATH = Path(__file__).resolve().parents[2] / "scripts" / "execute-ready-check.py"
 _CENSUS_MODULE_PATH = Path(__file__).resolve().parents[2] / "scripts" / "census" / "index.mjs"
-CENSUS_BRIDGE_TIMEOUT_SECONDS = 15
-CENSUS_PROOF_TIMEOUT_MS = 5_000
+# Production repositories can need more than the former five-second proof and
+# fifteen-second bridge budgets. Keep the default proof comfortably below the
+# outer bridge so a hung repository-local proof still cannot wedge the hook.
+CENSUS_BRIDGE_TIMEOUT_SECONDS = 30
+CENSUS_PROOF_TIMEOUT_MS = 12_000
 
 _CENSUS_SCAN = r"""
 import { readFileSync } from 'node:fs';