@ikon85/agent-workflow-kit 0.31.0 → 0.32.1

package/.agents/skills/audit-skills/SKILL.md

@@ -23,6 +23,35 @@ skills the other steps rely on drift, and nothing fixes them unless a recipe doe
 Not for: rewriting a domain skill's content on demand (that is the skill itself),
 or auditing application code (a code review or a diagnosis does that).
 
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before enumerating skills, launching research subagents, or editing any skill,
+run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill audit-skills --json
+```
+
+- `ready`: continue silently with the generic audit and the active
+  `projectChecks` block.
+- `degraded`: keep the generic audit active, omit only `projectChecks`, and emit
+  exactly one concise summary: `Readiness degraded — inactive block
+  projectChecks (auditSkillsLayer: <state>). Run /setup-workflow, configure
+  docs/agents/skills/audit-skills.md, then rerun this skill.`
+- `blocked`: stop before continuing and report the non-ready required capability
+  plus the exact `/setup-workflow` recovery path.
+- Invalid evidence is always visible in that one summary; never interpret it as
+  an opt-out or invent project checks.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectChecks -->
+When `projectChecks` is active, read
+`docs/agents/skills/audit-skills.md` and apply its concrete class assignments,
+project-specific guard commands, and drift checks in addition to the generic
+recipe below.
+<!-- readiness:end -->
+
 ## Standing guards (run without this audit)
 
 Two automatic nets catch the most common drift classes before an audit — this
@@ -31,7 +60,7 @@ recipe complements them, it does not replace them:
 1. **A skill-sync test** — for any un-guessable enumeration a skill documents (a
    status→bucket map, a design-token list), a test parses the value out of the
    SKILL.md and asserts equality with the code constant. Drift breaks the build.
-   Your project layer names the concrete tests.
+   Run the concrete tests available in the repository.
 2. **The drift-hint hook** (`.claude/hooks/skill-drift-hint.py`) + a per-skill
    `SOURCES.txt`: at SessionStart it flags any skill whose declared source file
    is newer in git than its SKILL.md.
@@ -79,8 +108,9 @@ plus the `SOURCES.txt` files. Sort every skill into one of three classes:
    scripts or hooks with no `SOURCES.txt` and no hook net. No hook warns, so
    re-check them manually each audit.
 
-Your project layer assigns each concrete skill to a class — a completeness gate
-catches the next new skill that would otherwise stay invisible.
+Derive each concrete skill's class from the manifest, its `SOURCES.txt`, and the
+repository surfaces — a completeness gate catches the next new skill that would
+otherwise stay invisible.
 
 ### 2. Audit in parallel — one subagent per skill
 
@@ -129,8 +159,7 @@ alongside the Claude source), sync the mirror in the **same** change — otherwi
 the second surface rots silently. Mirror the body, but preserve each surface's
 own frontmatter: a mirror's `description` may be deliberately condensed, so never
 blind-copy the whole file over it. A `SOURCES.txt` is a plain anchor list and can
-be mirrored verbatim. Your project layer names the surfaces and the exact
-transform.
+be mirrored verbatim. Use the repository's declared surfaces and exact transform.
 
 ## Done
 

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

@@ -72,6 +72,35 @@ proof is still open for state resolution even when Git tracking lets the base
 scan enumerate it. Overrides are report input only and are never passed into
 scanning, fingerprinting, verification, or state resolution.
 
+## Durable enforcement
+
+An activated census is a durable consumer contract, not a one-time activation
+check. Before activating a candidate or reporting an unchanged census as
+`current`, derive the complete set of every `localScanners[].test` from the
+profile and inspect the repository's documented local CI and pre-push paths.
+
+Reuse one existing shared project-local census check entry point when the
+repository has one. Otherwise add the smallest such entry point through the
+repository's established script mechanism; do not create a second census
+engine or duplicate scanner logic. It must execute every declared focused test,
+and both local CI and pre-push must transitively reach that same entry point.
+Add or extend an executable wiring test that fails when either durable path or
+any declared scanner test becomes unreachable; matching prose or a bare grep is
+not sufficient proof.
+
+Keep enforcement reconciliation idempotent. An already complete wiring graph
+is a no-write result. Mark only the narrow gate block added for this lifecycle
+with the repository's existing managed marker, or with
+`agent-workflow-kit:census` when no marker convention exists; that block is the
+kit-owned census wiring. Preserve surrounding consumer-owned gate logic.
+
+Missing or partial durable wiring is a failed candidate verification. If the
+repository has no safe documented gate seam, ask one bounded wiring question
+and stop before activation. On a scanner-test or wiring-proof failure, report
+`failed`, discard the candidate when safe, and confirm that the previous active
+census bytes are unchanged. Never report `current` from activation-time test
+success alone.
+
 ## Workflow
 
 1. **Check.** Read the local profile and active census, if present. Report a
@@ -95,8 +124,9 @@ scanning, fingerprinting, verification, or state resolution.
    and a focused passing test for that pattern. Run that test before rescanning.
 6. **Verify a candidate.** Build the candidate from the fresh scan and recorded
    decisions. Fail verification when any surface or behavior remains `offen`,
-   when a required local scanner test fails, or when the candidate fingerprints
-   do not describe the current repository.
+   when a required local scanner test fails, when durable enforcement or its
+   executable wiring test is incomplete, or when the candidate fingerprints do
+   not describe the current repository.
 7. **Activate.** Call `activateCensus` with a real verifier so it stages, verifies,
    and atomically swaps under its local lock. On `CensusTransactionError`, report
    `updating` or `failed` and keep the previous active census authoritative.
@@ -137,4 +167,5 @@ Return only the useful audit trail:
 - surface coverage `X of Y`;
 - separate behavior overview;
 - visible `nicht relevant` justifications and active override, if any; <!-- language-census: ok -->
-- local scanner tests run and the transaction/no-write result.
+- local scanner tests run, durable local-CI/pre-push reachability, and the
+  transaction/no-write result.

package/.agents/skills/git-worktree-recover/SKILL.md

@@ -20,11 +20,36 @@ discipline and its guards) didn't stop it.
 
 ## Precondition
 
-If your project has a prevention layer — a SessionStart warning on active
-worktrees, a pre-edit guard that blocks edits on the wrong branch — this skill
-handles the case where that layer did NOT prevent a misplaced commit. Your project
-layer names those guards (`docs/agents/skills/git-worktree-recover.md`, seeded as
-an empty stub by `/setup-workflow`).
+This generic recovery remains usable whether or not the project has prevention
+guards or a custom worktree setup command.
+
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before assessing refs or moving a branch, run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill git-worktree-recover --json
+```
+
+- `ready`: continue silently with generic recovery and the active
+  `projectRecovery` block.
+- `degraded`: keep generic reflog recovery active, omit only
+  `projectRecovery`, and emit exactly one concise summary: `Readiness degraded
+  — inactive block projectRecovery (worktreeRecoveryLayer: <state>). Run
+  /setup-workflow, configure docs/agents/skills/git-worktree-recover.md, then
+  rerun this skill.`
+- `blocked`: stop before continuing and report the non-ready required capability
+  plus the exact `/setup-workflow` recovery path.
+- Invalid evidence is always visible in that one summary; never interpret it as
+  an opt-out or invent a project command.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectRecovery -->
+When `projectRecovery` is active, read
+`docs/agents/skills/git-worktree-recover.md` and apply its named prevention
+guards and exact worktree setup command around the generic recovery below.
+<!-- readiness:end -->
 
 ---
 
@@ -124,16 +149,12 @@ it.
 
 ## Phase 5 — Set up a worktree
 
-Set the recovered branch up cleanly in its own worktree. If your project has a
-worktree-setup command, use it (it typically runs `git worktree add`, installs
-deps and copies env files); otherwise:
+Set the recovered branch up cleanly in its own worktree. The generic fallback is:
 
 ```bash
 git worktree add <path> <recovered-branch>
 ```
 
-Your project layer names the exact command and what it copies.
-
 **Verify after setup:**
 
 ```bash

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

@@ -43,11 +43,25 @@ release contain the same artifact.
    data, infer an external fact, or manufacture `pending`/`not-applicable` to
    make a capability appear ready.
 
+   Readiness-schema adoption also keeps the Claude and Codex instruction
+   surfaces compatible. When exactly one applicable instruction surface has a
+   non-empty `## Prod` section and another has no such section, the staged
+   candidate mirrors the same section body into the missing surface. This
+   narrow migration is previewed as `migrated`, destination-race checked,
+   idempotent, and covered by the same verification and rollback transaction.
+   It may create a missing instruction file, but it never rewrites an existing
+   `## Prod` body. Empty, malformed, or divergent sections are named as
+   conflicts and leave every consumer file untouched. This migration belongs
+   to `kit update`; do not rerun `setup-workflow` after an ordinary update.
+   Readiness JSON diagnoses only the affected path and problem category
+   (`missing-file`, `missing-section`, `empty-section`, or
+   `divergent-section`); it never echoes consumer content.
+
 3. Read the terminal report. `aktuell` proves a second run found no upstream
-   delta. A conflict report names and counts every category and leaves every
-   consumer file untouched. Follow its recommendation and resolve each named
-   conflict manually; never auto-merge, delete a local edit, or silently choose
-   the incoming copy.
+   delta or pending readiness migration. A conflict report names and counts
+   every category and leaves every consumer file untouched. Follow its
+   recommendation and resolve each named conflict manually; never auto-merge,
+   delete a local edit, or silently choose the incoming copy.
 
    Read all four availability categories alongside the file delta: newly
    available skill core, newly degraded optional blocks, newly blocked skill

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

@@ -13,13 +13,46 @@ correctly, AFK. Subagents BUILD; **you** integrate + verify + land.
 The anchor, its sub-issues and the locked plan doc contain the verbatim contracts
 you must NOT paraphrase.
 
-> **Phase 0 probes a project layer.** Concrete tooling — exact test/verify
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before reading from the issue tracker, claiming a wave, creating worktrees, or
+making any local or remote mutation, run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill orchestrate-wave --json
+```
+
+- `ready`: continue silently with the required tracker/board context and the
+  active `projectRecipe` block.
+- `degraded`: required tracker and managed-board evidence is ready, so keep the
+  complete generic orchestration fallback active, omit only `projectRecipe`,
+  and emit exactly one concise summary: `Readiness degraded — inactive block
+  projectRecipe (orchestrateWaveRecipe: <state>); using the generic
+  orchestration fallback. Run /setup-workflow, configure
+  docs/agents/skills/orchestrate-wave.md, then rerun this skill.`
+- `blocked`: `STOP` before tracker access, dispatch, claims, worktrees, or other
+  mutation. Report `issueTracker=<state>` and `managedBoard=<state>`, then give
+  exactly one recovery path: **Run `/setup-workflow`, then rerun
+  `/orchestrate-wave`.** Never fall back to bare tracker or board commands.
+- `managedBoard=not-applicable`: `STOP` and report that `/orchestrate-wave` is
+  inapplicable without a managed board. This is a terminal project decision,
+  not invalid evidence and not a partially active mode.
+- Invalid evidence is always visible and never treated as an opt-out.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectRecipe -->
+> **Phase 0 consumes the active project recipe.** Concrete tooling — exact test/verify
 > commands, a DB/tunnel setup, a headless login recipe, brand checks, deploy
 > lockstep — is project-specific and lives in a **project layer** this skill reads
 > at runtime, not in this skeleton. The skeleton names the layer's sections
 > (`§Setup`, `§Builder Commands`, `§Builder Hard Rules`, `§Integration Suites`,
 > `§Verify Recipe`, `§Headless Login`, `§Landing`) and falls back to generic
 > instructions when the layer is absent. See **Phase 0**.
+>
+> When `projectRecipe` is active, read the filled project layer before applying
+> any phase-specific command below.
+<!-- readiness:end -->
 
 ## Standing rules (all phases)
 
@@ -59,15 +92,11 @@ you must NOT paraphrase.
 1. **Read everything**: the anchor body, every sub-issue body (each has a Handoff
    block: scope, blast-radius, live-verify, PR line), and the locked plan /
    plan-review doc in the planning worktree (file-exact).
-2. **Probe the project layer.** Read the project layer doc for this skill (the
-   consumer's `docs/agents/skills/orchestrate-wave.md` or the path your project
-   uses). If its `§`-sections carry **filled** content, follow the project recipe
-   wherever a phase below points at a `§`-section. If the file is only a
-   `setup-workflow` sentinel stub (empty headings, no real content) or absent,
-   treat the layer as **ABSENT** → use the generic fallback in each phase and warn
-   **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.
+2. **Select exact commands or the generic fallback.** If the readiness result
+   activated `projectRecipe`, use the loaded filled recipe wherever a phase below
+   points at a `§`-section. Otherwise use each phase's generic fallback; the
+   preflight's single degraded summary is the only warning. Never guess a project
+   command, tunnel, login, or verify recipe.
 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
@@ -88,10 +117,10 @@ you must NOT paraphrase.
    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) · preflight
-clean + this run's local claim planted · wave branch ff'd to `origin/main` + deps
-installed · project setup steps running.
+**Done when:** anchor + every sub-issue + plan read · readiness result consumed
+(active `projectRecipe` → exact recipe; inactive → generic fallback) · collision
+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)
 

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

@@ -66,13 +66,20 @@ delegates this route to the shipped `census-update` contract and its focused
 `scripts/test_census_update_contract.test.mjs` proof; it does not reproduce
 activation, snapshots, or enforcement. Setup itself never calls `activateCensus`.
 
-Disable follows the ordered contract: remove the kit-owned hook, remove the
-kit-owned gate, then atomically replace only the profile's `enabled` value with
-`false`, preserving unknown keys, and verify `disabled` through
-`resolveCensusState`. Enforcement removal must finish before any profile
-mutation. Treat the choice document, local scanners, their tests, the profile,
-and the active snapshot as consumer-owned evidence. List those files and ask
-for separate deletion approval; without that approval, retain them.
+Activation owns durable enforcement: every focused test declared by the active
+profile must remain transitively reachable through one shared project-local
+census check entry point from both local CI and pre-push. `census-update`
+reconciles that narrow kit-owned census wiring idempotently and requires an
+executable wiring proof before it can report `current`; setup does not pre-wire
+the optional bootstrap state.
+
+Disable follows the ordered contract: remove only the kit-owned census wiring
+(including the kit-owned hook and gate block), then atomically replace only the
+profile's `enabled` value with `false`, preserving unknown keys, and verify
+`disabled` through `resolveCensusState`. Enforcement removal must finish before
+any profile mutation. Treat the choice document, local scanners, their tests,
+the profile, and the active snapshot as consumer-owned evidence. List those
+files and ask for separate deletion approval; without that approval, retain them.
 Setup never deletes consumer-owned files as part of disable.
 
 ## Setup report

package/.claude/skills/audit-skills/SKILL.md

@@ -23,6 +23,35 @@ skills the other steps rely on drift, and nothing fixes them unless a recipe doe
 Not for: rewriting a domain skill's content on demand (that is the skill itself),
 or auditing application code (a code review or a diagnosis does that).
 
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before enumerating skills, launching research subagents, or editing any skill,
+run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill audit-skills --json
+```
+
+- `ready`: continue silently with the generic audit and the active
+  `projectChecks` block.
+- `degraded`: keep the generic audit active, omit only `projectChecks`, and emit
+  exactly one concise summary: `Readiness degraded — inactive block
+  projectChecks (auditSkillsLayer: <state>). Run /setup-workflow, configure
+  docs/agents/skills/audit-skills.md, then rerun this skill.`
+- `blocked`: stop before continuing and report the non-ready required capability
+  plus the exact `/setup-workflow` recovery path.
+- Invalid evidence is always visible in that one summary; never interpret it as
+  an opt-out or invent project checks.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectChecks -->
+When `projectChecks` is active, read
+`docs/agents/skills/audit-skills.md` and apply its concrete class assignments,
+project-specific guard commands, and drift checks in addition to the generic
+recipe below.
+<!-- readiness:end -->
+
 ## Standing guards (run without this audit)
 
 Two automatic nets catch the most common drift classes before an audit — this
@@ -31,7 +60,7 @@ recipe complements them, it does not replace them:
 1. **A skill-sync test** — for any un-guessable enumeration a skill documents (a
    status→bucket map, a design-token list), a test parses the value out of the
    SKILL.md and asserts equality with the code constant. Drift breaks the build.
-   Your project layer names the concrete tests.
+   Run the concrete tests available in the repository.
 2. **The drift-hint hook** (`.claude/hooks/skill-drift-hint.py`) + a per-skill
    `SOURCES.txt`: at SessionStart it flags any skill whose declared source file
    is newer in git than its SKILL.md.
@@ -79,8 +108,9 @@ plus the `SOURCES.txt` files. Sort every skill into one of three classes:
    scripts or hooks with no `SOURCES.txt` and no hook net. No hook warns, so
    re-check them manually each audit.
 
-Your project layer assigns each concrete skill to a class — a completeness gate
-catches the next new skill that would otherwise stay invisible.
+Derive each concrete skill's class from the manifest, its `SOURCES.txt`, and the
+repository surfaces — a completeness gate catches the next new skill that would
+otherwise stay invisible.
 
 ### 2. Audit in parallel — one subagent per skill
 
@@ -129,8 +159,7 @@ alongside the Claude source), sync the mirror in the **same** change — otherwi
 the second surface rots silently. Mirror the body, but preserve each surface's
 own frontmatter: a mirror's `description` may be deliberately condensed, so never
 blind-copy the whole file over it. A `SOURCES.txt` is a plain anchor list and can
-be mirrored verbatim. Your project layer names the surfaces and the exact
-transform.
+be mirrored verbatim. Use the repository's declared surfaces and exact transform.
 
 ## Done
 

package/.claude/skills/census-update/SKILL.md

@@ -72,6 +72,35 @@ proof is still open for state resolution even when Git tracking lets the base
 scan enumerate it. Overrides are report input only and are never passed into
 scanning, fingerprinting, verification, or state resolution.
 
+## Durable enforcement
+
+An activated census is a durable consumer contract, not a one-time activation
+check. Before activating a candidate or reporting an unchanged census as
+`current`, derive the complete set of every `localScanners[].test` from the
+profile and inspect the repository's documented local CI and pre-push paths.
+
+Reuse one existing shared project-local census check entry point when the
+repository has one. Otherwise add the smallest such entry point through the
+repository's established script mechanism; do not create a second census
+engine or duplicate scanner logic. It must execute every declared focused test,
+and both local CI and pre-push must transitively reach that same entry point.
+Add or extend an executable wiring test that fails when either durable path or
+any declared scanner test becomes unreachable; matching prose or a bare grep is
+not sufficient proof.
+
+Keep enforcement reconciliation idempotent. An already complete wiring graph
+is a no-write result. Mark only the narrow gate block added for this lifecycle
+with the repository's existing managed marker, or with
+`agent-workflow-kit:census` when no marker convention exists; that block is the
+kit-owned census wiring. Preserve surrounding consumer-owned gate logic.
+
+Missing or partial durable wiring is a failed candidate verification. If the
+repository has no safe documented gate seam, ask one bounded wiring question
+and stop before activation. On a scanner-test or wiring-proof failure, report
+`failed`, discard the candidate when safe, and confirm that the previous active
+census bytes are unchanged. Never report `current` from activation-time test
+success alone.
+
 ## Workflow
 
 1. **Check.** Read the local profile and active census, if present. Report a
@@ -95,8 +124,9 @@ scanning, fingerprinting, verification, or state resolution.
    and a focused passing test for that pattern. Run that test before rescanning.
 6. **Verify a candidate.** Build the candidate from the fresh scan and recorded
    decisions. Fail verification when any surface or behavior remains `offen`,
-   when a required local scanner test fails, or when the candidate fingerprints
-   do not describe the current repository.
+   when a required local scanner test fails, when durable enforcement or its
+   executable wiring test is incomplete, or when the candidate fingerprints do
+   not describe the current repository.
 7. **Activate.** Call `activateCensus` with a real verifier so it stages, verifies,
    and atomically swaps under its local lock. On `CensusTransactionError`, report
    `updating` or `failed` and keep the previous active census authoritative.
@@ -137,4 +167,5 @@ Return only the useful audit trail:
 - surface coverage `X of Y`;
 - separate behavior overview;
 - visible `nicht relevant` justifications and active override, if any; <!-- language-census: ok -->
-- local scanner tests run and the transaction/no-write result.
+- local scanner tests run, durable local-CI/pre-push reachability, and the
+  transaction/no-write result.

package/.claude/skills/git-worktree-recover/SKILL.md

@@ -26,11 +26,36 @@ discipline and its guards) didn't stop it.
 
 ## Precondition
 
-If your project has a prevention layer — a SessionStart warning on active
-worktrees, a pre-edit guard that blocks edits on the wrong branch — this skill
-handles the case where that layer did NOT prevent a misplaced commit. Your project
-layer names those guards (`docs/agents/skills/git-worktree-recover.md`, seeded as
-an empty stub by `/setup-workflow`).
+This generic recovery remains usable whether or not the project has prevention
+guards or a custom worktree setup command.
+
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before assessing refs or moving a branch, run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill git-worktree-recover --json
+```
+
+- `ready`: continue silently with generic recovery and the active
+  `projectRecovery` block.
+- `degraded`: keep generic reflog recovery active, omit only
+  `projectRecovery`, and emit exactly one concise summary: `Readiness degraded
+  — inactive block projectRecovery (worktreeRecoveryLayer: <state>). Run
+  /setup-workflow, configure docs/agents/skills/git-worktree-recover.md, then
+  rerun this skill.`
+- `blocked`: stop before continuing and report the non-ready required capability
+  plus the exact `/setup-workflow` recovery path.
+- Invalid evidence is always visible in that one summary; never interpret it as
+  an opt-out or invent a project command.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectRecovery -->
+When `projectRecovery` is active, read
+`docs/agents/skills/git-worktree-recover.md` and apply its named prevention
+guards and exact worktree setup command around the generic recovery below.
+<!-- readiness:end -->
 
 ---
 
@@ -130,16 +155,12 @@ it.
 
 ## Phase 5 — Set up a worktree
 
-Set the recovered branch up cleanly in its own worktree. If your project has a
-worktree-setup command, use it (it typically runs `git worktree add`, installs
-deps and copies env files); otherwise:
+Set the recovered branch up cleanly in its own worktree. The generic fallback is:
 
 ```bash
 git worktree add <path> <recovered-branch>
 ```
 
-Your project layer names the exact command and what it copies.
-
 **Verify after setup:**
 
 ```bash

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

@@ -43,11 +43,25 @@ release contain the same artifact.
    data, infer an external fact, or manufacture `pending`/`not-applicable` to
    make a capability appear ready.
 
+   Readiness-schema adoption also keeps the Claude and Codex instruction
+   surfaces compatible. When exactly one applicable instruction surface has a
+   non-empty `## Prod` section and another has no such section, the staged
+   candidate mirrors the same section body into the missing surface. This
+   narrow migration is previewed as `migrated`, destination-race checked,
+   idempotent, and covered by the same verification and rollback transaction.
+   It may create a missing instruction file, but it never rewrites an existing
+   `## Prod` body. Empty, malformed, or divergent sections are named as
+   conflicts and leave every consumer file untouched. This migration belongs
+   to `kit update`; do not rerun `setup-workflow` after an ordinary update.
+   Readiness JSON diagnoses only the affected path and problem category
+   (`missing-file`, `missing-section`, `empty-section`, or
+   `divergent-section`); it never echoes consumer content.
+
 3. Read the terminal report. `aktuell` proves a second run found no upstream
-   delta. A conflict report names and counts every category and leaves every
-   consumer file untouched. Follow its recommendation and resolve each named
-   conflict manually; never auto-merge, delete a local edit, or silently choose
-   the incoming copy.
+   delta or pending readiness migration. A conflict report names and counts
+   every category and leaves every consumer file untouched. Follow its
+   recommendation and resolve each named conflict manually; never auto-merge,
+   delete a local edit, or silently choose the incoming copy.
 
    Read all four availability categories alongside the file delta: newly
    available skill core, newly degraded optional blocks, newly blocked skill

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

@@ -21,13 +21,46 @@ correctly, AFK. Subagents BUILD; **you** integrate + verify + land.
 The anchor, its sub-issues and the locked plan doc contain the verbatim contracts
 you must NOT paraphrase.
 
-> **Phase 0 probes a project layer.** Concrete tooling — exact test/verify
+## Readiness preflight — first
+
+<!-- readiness:optional-preflight:start -->
+Before reading from the issue tracker, claiming a wave, creating worktrees, or
+making any local or remote mutation, run this once from the project root:
+
+```bash
+node scripts/readiness.mjs check --skill orchestrate-wave --json
+```
+
+- `ready`: continue silently with the required tracker/board context and the
+  active `projectRecipe` block.
+- `degraded`: required tracker and managed-board evidence is ready, so keep the
+  complete generic orchestration fallback active, omit only `projectRecipe`,
+  and emit exactly one concise summary: `Readiness degraded — inactive block
+  projectRecipe (orchestrateWaveRecipe: <state>); using the generic
+  orchestration fallback. Run /setup-workflow, configure
+  docs/agents/skills/orchestrate-wave.md, then rerun this skill.`
+- `blocked`: `STOP` before tracker access, dispatch, claims, worktrees, or other
+  mutation. Report `issueTracker=<state>` and `managedBoard=<state>`, then give
+  exactly one recovery path: **Run `/setup-workflow`, then rerun
+  `/orchestrate-wave`.** Never fall back to bare tracker or board commands.
+- `managedBoard=not-applicable`: `STOP` and report that `/orchestrate-wave` is
+  inapplicable without a managed board. This is a terminal project decision,
+  not invalid evidence and not a partially active mode.
+- Invalid evidence is always visible and never treated as an opt-out.
+<!-- readiness:optional-preflight:end -->
+
+<!-- readiness:block projectRecipe -->
+> **Phase 0 consumes the active project recipe.** Concrete tooling — exact test/verify
 > commands, a DB/tunnel setup, a headless login recipe, brand checks, deploy
 > lockstep — is project-specific and lives in a **project layer** this skill reads
 > at runtime, not in this skeleton. The skeleton names the layer's sections
 > (`§Setup`, `§Builder Commands`, `§Builder Hard Rules`, `§Integration Suites`,
 > `§Verify Recipe`, `§Headless Login`, `§Landing`) and falls back to generic
 > instructions when the layer is absent. See **Phase 0**.
+>
+> When `projectRecipe` is active, read the filled project layer before applying
+> any phase-specific command below.
+<!-- readiness:end -->
 
 ## Standing rules (all phases)
 
@@ -67,15 +100,11 @@ you must NOT paraphrase.
 1. **Read everything**: the anchor body, every sub-issue body (each has a Handoff
    block: scope, blast-radius, live-verify, PR line), and the locked plan /
    plan-review doc in the planning worktree (file-exact).
-2. **Probe the project layer.** Read the project layer doc for this skill (the
-   consumer's `docs/agents/skills/orchestrate-wave.md` or the path your project
-   uses). If its `§`-sections carry **filled** content, follow the project recipe
-   wherever a phase below points at a `§`-section. If the file is only a
-   `setup-workflow` sentinel stub (empty headings, no real content) or absent,
-   treat the layer as **ABSENT** → use the generic fallback in each phase and warn
-   **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.
+2. **Select exact commands or the generic fallback.** If the readiness result
+   activated `projectRecipe`, use the loaded filled recipe wherever a phase below
+   points at a `§`-section. Otherwise use each phase's generic fallback; the
+   preflight's single degraded summary is the only warning. Never guess a project
+   command, tunnel, login, or verify recipe.
 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
@@ -96,10 +125,10 @@ you must NOT paraphrase.
    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) · preflight
-clean + this run's local claim planted · wave branch ff'd to `origin/main` + deps
-installed · project setup steps running.
+**Done when:** anchor + every sub-issue + plan read · readiness result consumed
+(active `projectRecipe` → exact recipe; inactive → generic fallback) · collision
+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)