@ikon85/agent-workflow-kit 0.29.1 → 0.31.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (52) hide show
  1. package/.agents/skills/board-to-waves/SKILL.md +14 -0
  2. package/.agents/skills/code-review/SKILL.md +22 -3
  3. package/.agents/skills/codex-adapter-sync/SKILL.md +134 -72
  4. package/.agents/skills/kit-update/SKILL.md +21 -1
  5. package/.agents/skills/local-ci/SKILL.md +16 -0
  6. package/.agents/skills/project-release/SKILL.md +18 -0
  7. package/.agents/skills/security-audit/SKILL.md +18 -0
  8. package/.agents/skills/setup-workflow/SKILL.md +39 -2
  9. package/.agents/skills/spec-self-critique/SKILL.md +16 -7
  10. package/.agents/skills/to-issues/SKILL.md +13 -1
  11. package/.agents/skills/to-prd/SKILL.md +14 -0
  12. package/.agents/skills/to-waves/SKILL.md +16 -2
  13. package/.agents/skills/triage/SKILL.md +24 -0
  14. package/.agents/skills/verify-spike/SKILL.md +20 -1
  15. package/.agents/skills/wrapup/SKILL.md +26 -4
  16. package/.claude/skills/board-to-waves/SKILL.md +14 -0
  17. package/.claude/skills/code-review/SKILL.md +22 -3
  18. package/.claude/skills/kit-update/SKILL.md +21 -1
  19. package/.claude/skills/local-ci/SKILL.md +16 -0
  20. package/.claude/skills/project-release/SKILL.md +18 -0
  21. package/.claude/skills/security-audit/SKILL.md +18 -0
  22. package/.claude/skills/setup-workflow/SKILL.md +39 -2
  23. package/.claude/skills/skill-manifest.json +46 -0
  24. package/.claude/skills/spec-self-critique/SKILL.md +16 -7
  25. package/.claude/skills/to-issues/SKILL.md +13 -1
  26. package/.claude/skills/to-prd/SKILL.md +14 -0
  27. package/.claude/skills/to-waves/SKILL.md +16 -2
  28. package/.claude/skills/triage/SKILL.md +24 -0
  29. package/.claude/skills/verify-spike/SKILL.md +20 -1
  30. package/.claude/skills/wrapup/SKILL.md +26 -4
  31. package/README.md +41 -0
  32. package/agent-workflow-kit.package.json +71 -31
  33. package/package.json +1 -1
  34. package/scripts/kit-update-pr.mjs +14 -1
  35. package/scripts/kit-update-pr.test.mjs +21 -0
  36. package/scripts/readiness.mjs +215 -0
  37. package/scripts/test_codex_adapter_sync_contract.py +154 -0
  38. package/scripts/test_retro_wrapup_contract.py +17 -0
  39. package/scripts/test_skill_optional_readiness.py +171 -0
  40. package/scripts/test_skill_portability_lint.py +57 -18
  41. package/scripts/test_skill_readiness_contract.py +139 -0
  42. package/scripts/test_skill_readiness_preflight.py +180 -0
  43. package/scripts/test_skill_required_readiness.py +233 -0
  44. package/scripts/test_skill_setup_workflow_seeds.py +22 -0
  45. package/src/cli.mjs +10 -2
  46. package/src/commands/init.mjs +3 -1
  47. package/src/commands/uninstall.mjs +5 -1
  48. package/src/commands/update.mjs +65 -8
  49. package/src/lib/bundle.mjs +7 -0
  50. package/src/lib/manifest.mjs +26 -2
  51. package/src/lib/updateCandidate.mjs +116 -2
  52. package/src/lib/updateReconcile.mjs +3 -1
@@ -14,6 +14,30 @@ Every comment or issue posted to the issue tracker during triage **must** start
14
14
  > *This was generated by AI during triage.*
15
15
  ```
16
16
 
17
+ ## Required readiness preflight
18
+
19
+ Before reading from or writing to the issue tracker, labels, or board, run:
20
+
21
+ ```sh
22
+ node scripts/readiness.mjs check --skill triage --json
23
+ ```
24
+
25
+ Treat the result as authoritative. A `ready` verdict is silent: continue with
26
+ the existing triage flow and all of its confirmation gates. For a `blocked`
27
+ verdict, stop without querying or mutating the issue tracker and report
28
+ `Triage unavailable`, the exact state (`missing`, `pending`, `not-applicable`,
29
+ or `invalid`), and the matching recovery path:
30
+
31
+ - `issueTracker` → run `/setup-workflow`, then fill
32
+ `docs/agents/issue-tracker.md`.
33
+ - `managedBoard` → run `/setup-workflow`, then configure
34
+ `docs/agents/board-sync.md`; `not-applicable` means this board-driven skill is
35
+ unavailable, not partially usable.
36
+ - `triageLabels` → run `/setup-workflow`, then fill
37
+ `docs/agents/triage-labels.md`.
38
+
39
+ Never guess a tracker, label, board, field, status, or fallback workflow.
40
+
17
41
  ## Reference docs
18
42
 
19
43
  - [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
@@ -21,10 +21,29 @@ This is the "Verify First" rule with a runnable harness behind it: when you cann
21
21
 
22
22
  If the question is really "what should this be", it is not a verify-spike — those are open, not yes/no.
23
23
 
24
+ ## Readiness preflight — first
25
+
26
+ <!-- readiness:optional-preflight:start -->
27
+ Before framing or running the spike, run this once from the project root:
28
+
29
+ ```bash
30
+ node scripts/readiness.mjs check --skill verify-spike --json
31
+ ```
32
+
33
+ - `ready`: continue without a readiness message. Ready is silent.
34
+ - `degraded`: keep the generic empirical spike active, omit only the inactive block `projectPlacement`, and emit exactly one concise summary: `Readiness degraded — inactive block projectPlacement (verifySpikeLayer: <state>). Run /setup-workflow, configure docs/agents/skills/verify-spike.md, then rerun this skill.`
35
+ - `blocked`: stop before continuing and report the non-ready required capability plus the exact `/setup-workflow` recovery path.
36
+ - Invalid is always visible: include the `invalid` capability state in the single summary and never treat it as an opt-out. Do not emit separate warnings later in the workflow.
37
+ <!-- readiness:optional-preflight:end -->
38
+
39
+ <!-- readiness:block projectPlacement -->
40
+ When `projectPlacement` is active, read `docs/agents/skills/verify-spike.md` and follow its project-specific harness-placement and import rules.
41
+ <!-- readiness:end -->
42
+
24
43
  ## Steps
25
44
 
26
45
  1. **Frame one falsifiable question.** Write it down as a single sentence with a yes/no answer and the exact version/context it is scoped to — e.g. "Does `customType.mapFromDriverValue` run on `drizzle-orm@1.0.0-rc.3` + node-postgres?". Name what a YES vs a NO looks like in the output *before* you run anything.
27
- 2. **Build the smallest harness that forces the answer.** Borrow the feedback-loop toolkit from `diagnose` Phase 1 — a one-call throwaway script, a fixture replay, a tiny HTTP/curl probe, a headless-browser assertion. Pick the cheapest one that touches the real thing (real lib version, real runtime, the actual DB read). One command to run; locate it in a clearly-throwaway path (`scratch/`, `*.spike.ts`). If a project layer exists at `docs/agents/skills/verify-spike.md`, follow its harness-placement/import rules — some repos need spikes inside a package dir so real imports resolve.
46
+ 2. **Build the smallest harness that forces the answer.** Borrow the feedback-loop toolkit from `diagnose` Phase 1 — a one-call throwaway script, a fixture replay, a tiny HTTP/curl probe, a headless-browser assertion. Pick the cheapest one that touches the real thing (real lib version, real runtime, the actual DB read). One command to run; locate it in a clearly-throwaway path (`scratch/`, `*.spike.ts`).
28
47
  3. **Run it and capture the proof.** Keep the raw output — the value, the error, the stack, the HTTP status. The verdict is only as good as the evidence pasted under it.
29
48
  4. **Record the verdict durably, with its evidence inline.** Yes/No + the proof (output snippet / `file:line` / version) + the date + the scope it was checked at. Sink it where the decision lives: an ADR, the issue body, the plan, or a PR comment. A verdict without inline evidence is just an unverified claim — keep the proof attached so a later reader does not have to re-run the spike to trust it.
30
49
  5. **Delete the harness.** The *answer* is the only keeper. Remove the spike code (or fold the proven fact into real code) so nothing throwaway rots in the repo.
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  name: wrapup
3
3
  disable-model-invocation: true
4
- "description": "Use ONLY when the user types /wrapup. Session-end \"land & clean\" for a finished feature/fix worktree — merges the open PR (= triggers prod deploy), kills the worktree dev server, removes the worktree + local branch, and fast-forwards the main checkout so main is current again, then sweeps merged-branch leftovers (local + stale remote whose PR is merged). If the slice isn't landed yet, it first makes it landable (Step 0): commits a dirty tree (after an .env/secret check), pushes, and opens the PR — reusing one if it already exists. User-triggered only (never auto-invoke, never hook). Aborts hard only on: not in a feature worktree, a detected .env/secret, a rejected push, a conflicting PR, or red (FAILURE) checks."
4
+ "description": "Use ONLY when the user types /wrapup. Session-end \"land & clean\" for a finished feature/fix worktree — merges the open PR, kills the worktree dev server, removes the worktree + local branch, and fast-forwards the main checkout so main is current again, then sweeps merged-branch leftovers (local + stale remote whose PR is merged). If the slice isn't landed yet, it first makes it landable (Step 0): commits a dirty tree (after an .env/secret check), pushes, and opens the PR — reusing one if it already exists. User-triggered only (never auto-invoke, never hook). Aborts hard only on: not in a feature worktree, a detected .env/secret, a rejected push, a conflicting PR, or red (FAILURE) checks."
5
5
  ---
6
6
 
7
7
  # wrapup — land PR & tear down worktree
@@ -10,7 +10,11 @@ Trigger: user types `/wrapup` (optionally with a PR number). **Manual only** —
10
10
 
11
11
  ## ⚠ Spec context
12
12
 
13
- **Merging to `main` = prod deploy.** The agent never deploys on its own — the user's `/wrapup` input IS the explicit merge+deploy authorization for that run. Never call this skill from a hook, another skill, or autonomously. Deploy banner before the merge, no y/n confirmation (deliberate); the pre-flight hard stops are non-negotiable.
13
+ The user's `/wrapup` input IS the explicit landing authorization for that run.
14
+ It authorizes the normal merge flow whether Prod readiness is ready or degraded;
15
+ it never authorizes the agent to invent or configure a deploy target. Never call
16
+ this skill from a hook, another skill, or autonomously. There is no second merge
17
+ confirmation; the pre-flight hard stops are non-negotiable.
14
18
 
15
19
  ## Execution model — script does mechanics, the agent does judgment
16
20
 
@@ -27,6 +31,17 @@ python3 scripts/wrapup-land.py preflight
27
31
  ```
28
32
  Hard stop (the only pure precondition): not in a feature worktree / on `main` — the script exits 1. The report carries everything the later steps need: dirty files, `.env` hits, secret-grep hits, issue + parent (leaf vs. anchor slice), existing PR + whether its body has a `**Retro:**` line, parsed `ANNAHMEN.md` drift lines, profile values (`retro_values`, `vor_bau`, remote-sweep switch).
29
33
 
34
+ Then run:
35
+
36
+ ```bash
37
+ node scripts/readiness.mjs check --skill wrapup --json
38
+ ```
39
+
40
+ `prodTarget: ready` activates only `deployReport` below. `pending` or `missing`
41
+ omits that block, emits exactly one concise note — `Prod readiness is pending or missing; deploy reporting omitted.` — and landing continues normally.
42
+ `invalid` means malformed or divergent Prod evidence: STOP and report the
43
+ conflicting instruction surfaces; never choose a target on the user's behalf.
44
+
30
45
  ### 2 · Retro gate (blocking, optional retro-exit — before anything is committed)
31
46
  One reminder, not a merge confirmation:
32
47
  > "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."
@@ -72,10 +87,17 @@ One call covers: push → PR create/reuse (+ drift markers merged into the body)
72
87
  STOP → diagnose in the main conversation, fix, re-run `land` (an already-merged PR resumes at teardown).
73
88
 
74
89
  ### 6 · Post-merge (agent)
75
- - **Deploy banner**, one line: `⚠ PR #<pr> merged → main deploys (~7 min live).`
76
90
  - **Sibling propagation:** for each `drift_markers` entry in the land report, append the note to the target issue's `vor_bau` section + re-stamp its `plan_revision`. Log-based markers → **write directly, then show what was written where** (mandatory report — visibility moved from a pre-gate into the report, decision 2026-07-06); fallback candidates the user hasn't confirmed yet → confirm first. Program context widens the target set to unbuilt wave-stubs/leaves and the Program-PRD itself — same append-only mechanism. **Exception:** appends to the Program-PRD or unbuilt wave-stubs do **not** re-stamp `plan_revision` — that stays reserved for structural wave-plan edits via the `to-waves` escalation path; a mere drift note must not stale-block published stubs.
77
91
  - **Anchor close:** report says `anchor_complete: true` → `gh issue close <anchor> -c "Wave complete — all slices merged via PR #<pr>."` and verify board status Done. The guard keeps anchors away from every auto-close — this verified close is the only close path; without it the anchor stays silently open after the last slice. **Then re-run the upward propagation**: the land-time `program-sync` ran BEFORE this close, so on a wave-completing slice the Wellenplan still shows 🔄 and the Phasen-Gate stays unchecked — after the board shows Done, run `python3 scripts/board-sync.py program-sync <program-prd#>` once more (the report's `program_sync.program` names it; skip when the report says the parent is not a program). Board auto-rules can lag the close (Close→Done race) — verify Done first, that's what the token reads.
78
- - **Report**, concise, from the land JSON: PR merged · issue close (auto/manual) · worktree removed · branch deleted · sweep counts local/remote · anchor synced + complete/pending · program propagation (`program_sync`: Wellenplan refreshed / gates checked / skipped) · propagation writes (what → where) · `main` at `<sha>` · deploy running.
92
+ - **Report**, concise, from the land JSON: PR merged · issue close (auto/manual) · worktree removed · branch deleted · sweep counts local/remote · anchor synced + complete/pending · program propagation (`program_sync`: Wellenplan refreshed / gates checked / skipped) · propagation writes (what → where) · `main` at `<sha>`.
93
+
94
+ <!-- readiness:block deployReport -->
95
+ - **Deploy-aware report:** read the coherent `## Prod` block; before merging,
96
+ state the configured deploy trigger and expected outcome. After merge, report
97
+ the configured target and its actual known state. Do not claim a deployment
98
+ is running or live unless the configured trigger and observed evidence prove
99
+ it; keep unknown timing explicit.
100
+ <!-- readiness:end -->
79
101
 
80
102
  ## Out of scope
81
103
  - Live-verify / DoD: must happen **before** `/wrapup` — this skill lands, it does not verify.
@@ -21,6 +21,20 @@ description: >-
21
21
 
22
22
  **Survey the board → cluster open issues by theme → anchor stub issues.** Systematizes how Welle F came about: first look at what's open and what fits together, then form thematic waves. Result lands durably as an anchor issue on the board (GitHub = SSOT), not as a chat list.
23
23
 
24
+ <!-- readiness:required-preflight:start -->
25
+ ## 0. Required readiness preflight
26
+
27
+ This is the first executable workflow step. From the project root, before any remote write or other `gh`/`board-sync.py` command, run this read-only check:
28
+
29
+ ```bash
30
+ node scripts/readiness.mjs check --skill board-to-waves --json
31
+ ```
32
+
33
+ - `verdict=ready`: continue with the existing workflow without announcing the check. **Ready is silent.**
34
+ - `verdict=blocked`: `STOP` before any mutation. Report every required capability as `<capability>=<state>` so `missing`, `pending`, and `invalid` remain distinct, then give exactly one recovery path: **Run `/setup-workflow`, then rerun `/board-to-waves`.** Do not fall back to bare tracker or board commands.
35
+ - `managedBoard=not-applicable`: `STOP` and report that `/board-to-waves` is **inapplicable** for a project that deliberately has no managed board. This is a terminal project decision, not invalid evidence and not a partially active mode.
36
+ <!-- readiness:required-preflight:end -->
37
+
24
38
  ## Pipeline Position
25
39
 
26
40
  ```
@@ -16,7 +16,26 @@ A code-review compares one diff against **two independent axes** — Standards a
16
16
  | "Why is this broken / slow?" (root-cause of a known defect) | `diagnose` |
17
17
  | "Clean this up — reuse, simplify, cut waste." (no bug-hunting) | a dedicated simplification pass |
18
18
 
19
- ## Preflight (fail-fast, before either axis starts)
19
+ ## Readiness preflight first
20
+
21
+ <!-- readiness:optional-preflight:start -->
22
+ Before the diff preflight or either review axis, run this once from the project root:
23
+
24
+ ```bash
25
+ node scripts/readiness.mjs check --skill code-review --json
26
+ ```
27
+
28
+ - `ready`: continue without a readiness message. Ready is silent.
29
+ - `degraded`: keep the generic two-axis review active, omit only the inactive block `projectEnrichment`, and emit exactly one concise summary: `Readiness degraded — inactive block projectEnrichment (codeReviewLayer: <state>). Run /setup-workflow, configure docs/agents/code-review.md, then rerun this skill.`
30
+ - `blocked`: stop before continuing and report the non-ready required capability plus the exact `/setup-workflow` recovery path.
31
+ - Invalid is always visible: include the `invalid` capability state in the single summary and never treat it as an opt-out. Do not emit separate warnings later in the workflow.
32
+ <!-- readiness:optional-preflight:end -->
33
+
34
+ <!-- readiness:block projectEnrichment -->
35
+ When `projectEnrichment` is active, read `docs/agents/code-review.md` first. Apply its project-specific guidance about which sources count and how this method relates to adjacent tools already running in the environment.
36
+ <!-- readiness:end -->
37
+
38
+ ## Diff preflight (fail-fast, before either axis starts)
20
39
 
21
40
  1. **Fixed point** — whatever the requester names: a SHA, branch, tag, `main`, `HEAD~N`. Missing → ask; do not guess.
22
41
  2. **Three-dot diff against the merge-base** — `git diff <fixed-point>...HEAD` (three dots, not two — two dots diffs tip-to-tip and pulls in unrelated upstream changes), plus the commit list: `git log <fixed-point>..HEAD --oneline`.
@@ -24,7 +43,7 @@ A code-review compares one diff against **two independent axes** — Standards a
24
43
 
25
44
  ## Axis 1 — Standards
26
45
 
27
- **Sources.** This repo's own documented conventions: a root convention file (`CLAUDE.md`/`AGENTS.md`/`CONTRIBUTING.md` — whichever this repo uses), any per-package convention files in a monorepo, a `docs/conventions/` folder. If `docs/agents/code-review.md` exists (this skill's project layer, seeded by `/setup-workflow`), read it first — it names exactly which sources count here and how this method relates to any other review tooling already running in this environment. Absent that file, gather the sources yourself from the repo root before reviewing.
46
+ **Sources.** This repo's own documented conventions: a root convention file (`CLAUDE.md`/`AGENTS.md`/`CONTRIBUTING.md` — whichever this repo uses), any per-package convention files in a monorepo, and a `docs/conventions/` folder. Gather these generic sources from the repo root before reviewing.
28
47
 
29
48
  **Plus a Fowler-smell baseline** (*Refactoring*, ch. 3) — applies even when the repo documents nothing. Each smell is a **judgment call** (flag as "possible X"), never a hard violation:
30
49
 
@@ -61,4 +80,4 @@ A code-review compares one diff against **two independent axes** — Standards a
61
80
 
62
81
  ## Relationship to adjacent review tooling
63
82
 
64
- This skill governs one thing: a diff/branch/PR review split into Standards vs. Spec. It is not the only review-shaped tool an environment may have — a pre-code plan-review loop, a security-specific audit, a pure reuse/simplification pass, or a dedicated reviewer subagent can all coexist with it; each stays its own axis, not a replacement for this one. If this repo has seeded `docs/agents/code-review.md`, it names the concrete adjacent tools and how they relate; absent that, treat any other review tool you find as complementary unless it explicitly says otherwise.
83
+ This skill governs one thing: a diff/branch/PR review split into Standards vs. Spec. It is not the only review-shaped tool an environment may have — a pre-code plan-review loop, a security-specific audit, a pure reuse/simplification pass, or a dedicated reviewer subagent can all coexist with it; each stays its own axis, not a replacement for this one. Without active project enrichment, treat any other review tool you find as complementary unless it explicitly says otherwise.
@@ -34,12 +34,30 @@ release contain the same artifact.
34
34
  `npm test` command there, and activates only a verified candidate. A staging
35
35
  or verification failure leaves the installed tree byte-identical.
36
36
 
37
+ The staged candidate also adopts the current readiness schema without
38
+ invoking `setup-workflow`: it preserves explicit readiness decisions and
39
+ legacy project evidence, and seeds only newly introduced safe project-layer
40
+ stubs whose destinations are absent. Those generated consumer-owned paths
41
+ are destination-race checked and activate or roll back in the same
42
+ transaction as kit files and the consumer manifest. Never create project
43
+ data, infer an external fact, or manufacture `pending`/`not-applicable` to
44
+ make a capability appear ready.
45
+
37
46
  3. Read the terminal report. `aktuell` proves a second run found no upstream
38
47
  delta. A conflict report names and counts every category and leaves every
39
48
  consumer file untouched. Follow its recommendation and resolve each named
40
49
  conflict manually; never auto-merge, delete a local edit, or silently choose
41
50
  the incoming copy.
42
51
 
52
+ Read all four availability categories alongside the file delta: newly
53
+ available skill core, newly degraded optional blocks, newly blocked skill
54
+ core, and still unresolved capability states. Missing readiness for genuinely
55
+ new behavior does not block a compatible kit update; only that behavior stays
56
+ unavailable. A compatible update must stop if it would make previously
57
+ available skill core unavailable. `--yes` answers only package reconciliation
58
+ questions and never supplies a readiness decision. Automated update pull
59
+ requests carry the same availability summary and remain manual-merge only.
60
+
43
61
  For each conflicted kit-shipped file, always ask the user whether the local
44
62
  edit is a generic improvement or project-specific; never decide or act
45
63
  automatically. For a generic improvement, offer to file an issue in the
@@ -74,4 +92,6 @@ release contain the same artifact.
74
92
  The update API reports `checking -> preview/awaiting_decision -> staging ->
75
93
  verifying -> applied | conflicted | failed | aborted`. `conflicted`, `failed`,
76
94
  and `aborted` never authorize partial activation. The existing manifest,
77
- three-way diff, and atomic-write seams remain the source of truth.
95
+ three-way diff, and atomic-write seams remain the source of truth. A failure
96
+ also names its transaction phase and whether consumer state stayed unchanged or
97
+ was rolled back.
@@ -20,6 +20,22 @@ live in the **project layer** for this skill (its `docs/agents/skills/local-ci.m
20
20
  seeded as an empty stub by `/setup-workflow` and filled per project). This
21
21
  skeleton names the two profiles generically; run the two your project layer names.
22
22
 
23
+ ## Required readiness preflight
24
+
25
+ Before running a guard, hook, test, or any other project command, run:
26
+
27
+ ```sh
28
+ node scripts/readiness.mjs check --skill local-ci --json
29
+ ```
30
+
31
+ Treat the result as authoritative. A `ready` verdict is silent: continue with
32
+ the existing gate and its safety rules. For a `blocked` verdict, stop without
33
+ running any guessed command and report `Local CI unavailable`, the
34
+ `localCiRecipe` state (`missing`, `pending`, `not-applicable`, or `invalid`),
35
+ and one recovery path: run `/setup-workflow`, then fill
36
+ `docs/agents/skills/local-ci.md` with the project's exact commands. Never infer
37
+ commands from package scripts, hooks, CI configuration, or another repository.
38
+
23
39
  ## When
24
40
 
25
41
  - **Before opening ANY PR** → run the full local gate. Red → fix it, or defer a
@@ -9,6 +9,24 @@ Prepare a consumer-owned multi-package release through the kit's shared
9
9
  SemVer, preview, and transactional apply engine. This skill changes only the
10
10
  profiled version files. It does not commit, tag, push, publish, or merge.
11
11
 
12
+ ## Required readiness preflight
13
+
14
+ Before previewing a release or changing any version file, run:
15
+
16
+ ```sh
17
+ node scripts/readiness.mjs check --skill project-release --json
18
+ ```
19
+
20
+ Treat the result as authoritative. A `ready` verdict is silent and hands
21
+ execution to `scripts/project-release.mjs`; the helper remains the authority
22
+ for preview, confirmation, validation, and transactional apply. For a
23
+ `blocked` verdict, stop without invoking that helper or changing files and
24
+ report `Project Release unavailable`, the `projectReleaseProfile` state
25
+ (`missing`, `pending`, `not-applicable`, or `invalid`), and one recovery path:
26
+ run `/setup-workflow`, then fill the `projectRelease` section in
27
+ `docs/agents/workflow-capabilities.json`. Never infer packages, version files,
28
+ tag prefixes, or versions.
29
+
12
30
  ## Profile contract
13
31
 
14
32
  Read `docs/agents/workflow-capabilities.json`. The consumer owns this file and
@@ -13,6 +13,24 @@ generic runbook structure ships as a template you copy and fill:
13
13
  your actual stack, and keep it as the checklist single source of truth. Read your
14
14
  filled runbook first.
15
15
 
16
+ ## Required readiness preflight
17
+
18
+ Before reading application code, creating a tracking issue, launching either
19
+ model, or writing audit scratch files, run:
20
+
21
+ ```sh
22
+ node scripts/readiness.mjs check --skill security-audit --json
23
+ ```
24
+
25
+ Treat the result as authoritative. A `ready` verdict is silent: continue with
26
+ the existing two-model procedure and all human approval gates. For a `blocked`
27
+ verdict, stop without starting an audit or mutating repository or remote state
28
+ and report `Security Audit unavailable`, the `securityAuditRunbook` state
29
+ (`missing`, `pending`, `not-applicable`, or `invalid`), and one recovery path:
30
+ run `/setup-workflow`, then fill `docs/agents/skills/security-audit.md` and the
31
+ project runbook it references. Never guess the stack, security scope, commands,
32
+ tracking anchor, or board wiring.
33
+
16
34
  **Scope guard:** code + config only. Infrastructure (firewall, exposed ports,
17
35
  TLS, SSH, backups) is audited **separately** — an exposed database port beats any
18
36
  code fix. Keep the two audits apart.
@@ -331,7 +331,36 @@ Seed `## Workflow` from [workflow-overview.md](./workflow-overview.md) when the
331
331
 
332
332
  > `wrapup` and live-verify reference where this project deploys (host, command, URL). It lives in the `## Prod` block of CLAUDE.md/AGENTS.md, not a separate file.
333
333
 
334
- Ask for the deploy target in plain terms (where does this ship, how is it deployed, what's the live URL?). Record it for the `## Prod` block (Write step). If the user has no deploy target, skip — do not invent one.
334
+ First run `node scripts/readiness.mjs check --skill wrapup --json`. If
335
+ `prodTarget` is `ready`, adopt the evidence, clear any superseded pending
336
+ decision with `node scripts/readiness.mjs decision clear prodTarget`, and do
337
+ not ask again. Malformed or divergent `## Prod` evidence is `invalid`: leave
338
+ all instruction files untouched, show the conflict, and stop this section
339
+ until the user resolves it.
340
+
341
+ For a missing or pending target, ask where this ships, how it is deployed, and
342
+ what the live URL is. Offer only the bounded choices permitted by the readiness
343
+ catalog:
344
+
345
+ - **Configure now** — collect a non-empty host/platform, deploy command or
346
+ trigger, and live URL. Preview the exact local `## Prod` replacement for
347
+ every applicable existing Claude/Codex instruction surface and obtain
348
+ approval before writing it. Any external mutation retains its own separate
349
+ preview and approval; approving the local block never approves repository,
350
+ hosting, DNS, or deployment changes.
351
+ - **Configure later** — run
352
+ `node scripts/readiness.mjs decision set prodTarget pending`; create or alter
353
+ no `## Prod` block, and report exactly:
354
+ `wrapup.deployReport omitted (prodTarget pending)`.
355
+ - **Not applicable** — offer only when the manifest catalog entry has
356
+ `allowNotApplicable: true`; record it with `readiness.mjs decision set` and
357
+ deactivate the dependent block (or the whole skill when the declaration
358
+ requires the capability). `prodTarget` does not permit this choice, so never
359
+ offer it for Prod.
360
+
361
+ Ready and terminal `not-applicable` choices are not re-asked. A pending choice
362
+ remains deliberately retryable so a later `setup-workflow` run can take the
363
+ Configure-now path. Never invent a deploy target.
335
364
 
336
365
  ### 8b. Section H — Size-Profil (optional LoC-offender gate, non-interactive)
337
366
 
@@ -391,6 +420,14 @@ For the **`## Workflow`**, **`## Agent skills`**, and **`## Prod`** blocks, reco
391
420
  - If **neither** exists → ask the user which surface(s) to create (**default `CLAUDE.md`**), then write there.
392
421
  - If a `## Workflow` block already exists → skip it; this block is often repo-specific.
393
422
  - If an `## Agent skills` / `## Prod` block already exists → update its contents in-place; never duplicate or clobber surrounding user content.
423
+ - For Configure now, apply the approved `## Prod` preview to every applicable
424
+ existing surface as one coherent local change. Preserve each file's
425
+ `## Workflow` and `## Agent skills` blocks byte-for-byte, including spacing,
426
+ and leave all unrelated setup blocks untouched. Re-read every written Prod
427
+ body and run `node scripts/readiness.mjs check --skill wrapup --json`; all
428
+ surfaces must agree and `activeBlocks` must be exactly `["deployReport"]`.
429
+ Only then clear a prior `prodTarget` decision. A partial write is not ready:
430
+ restore the previewed surface set before reporting the section complete.
394
431
 
395
432
  `## Workflow` block:
396
433
 
@@ -411,7 +448,7 @@ Use [workflow-overview.md](./workflow-overview.md) verbatim as the generic seed.
411
448
  [one-line summary — single- or multi-context]. See `docs/agents/domain.md`.
412
449
  ```
413
450
 
414
- `## Prod` block (only if Section F produced a deploy target):
451
+ `## Prod` block (only if Section G's Configure-now path produced a deploy target):
415
452
 
416
453
  ```markdown
417
454
  ## Prod
@@ -1,8 +1,37 @@
1
1
  {
2
2
  "schema_version": 1,
3
3
  "description": "Public skill classification and publishing SSOT.",
4
+ "readiness": {
5
+ "contractVersion": 1,
6
+ "capabilities": {
7
+ "issueTracker": { "evidence": { "type": "sentinel", "paths": ["docs/agents/issue-tracker.md"], "allowLegacy": true } },
8
+ "triageLabels": { "evidence": { "type": "sentinel", "paths": ["docs/agents/triage-labels.md"], "allowLegacy": true } },
9
+ "managedBoard": { "allowNotApplicable": true, "evidence": { "type": "board-profile", "paths": ["docs/agents/board-sync.md"] } },
10
+ "specCompleteness": { "evidence": { "type": "sentinel", "paths": ["docs/conventions/spec-completeness.md"], "allowLegacy": true } },
11
+ "localCiRecipe": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/local-ci.md"], "allowLegacy": true } },
12
+ "projectReleaseProfile": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "validator": "project-release" } },
13
+ "securityAuditRunbook": { "evidence": { "type": "runbook-reference", "paths": ["docs/agents/skills/security-audit.md"], "allowLegacy": true } },
14
+ "prodTarget": { "evidence": { "type": "prod-section", "paths": ["CLAUDE.md", "AGENTS.md"] } },
15
+ "orchestrateWaveRecipe": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/orchestrate-wave.md"], "allowLegacy": true } },
16
+ "specCritiqueLayer": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/spec-self-critique.md"], "allowLegacy": true } },
17
+ "codeReviewLayer": { "evidence": { "type": "sentinel", "paths": ["docs/agents/code-review.md"], "allowLegacy": true } },
18
+ "verifySpikeLayer": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/verify-spike.md"], "allowLegacy": true } },
19
+ "auditSkillsLayer": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/audit-skills.md"], "allowLegacy": true } },
20
+ "worktreeRecoveryLayer": { "evidence": { "type": "sentinel", "paths": ["docs/agents/skills/git-worktree-recover.md"], "allowLegacy": true } },
21
+ "domainDocs": { "evidence": { "type": "sentinel", "paths": ["docs/agents/domain.md"], "allowLegacy": true } },
22
+ "censusChoice": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["census"] } },
23
+ "memoryLifecycle": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["memoryLifecycle"] } },
24
+ "worktreeLifecycle": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["worktreeLifecycle"] } },
25
+ "workflowAdvisories": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["workflowAdvisories"] } },
26
+ "safetyGuardrails": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["safetyGuardrails"] } },
27
+ "workflowSummary": { "evidence": { "type": "nonempty", "paths": ["CLAUDE.md", "AGENTS.md"] } },
28
+ "locProfile": { "evidence": { "type": "json", "paths": ["docs/agents/max-lines-allowlist.json"] } },
29
+ "kitOriginHint": { "evidence": { "type": "json", "paths": ["docs/agents/workflow-capabilities.json"], "required": ["kitOriginHint"] } }
30
+ }
31
+ },
4
32
  "skills": {
5
33
  "to-prd": {
34
+ "readiness": { "required": ["issueTracker", "managedBoard"] },
6
35
  "class": "generic",
7
36
  "publish": true,
8
37
  "entryPoint": true,
@@ -13,6 +42,7 @@
13
42
  "provenance": "matt-pocock"
14
43
  },
15
44
  "to-issues": {
45
+ "readiness": { "required": ["issueTracker", "managedBoard", "specCompleteness"] },
16
46
  "class": "generic",
17
47
  "publish": true,
18
48
  "entryPoint": true,
@@ -51,6 +81,7 @@
51
81
  "provenance": "own"
52
82
  },
53
83
  "wrapup": {
84
+ "readiness": { "optionalBlocks": { "deployReport": "prodTarget" } },
54
85
  "class": "generic",
55
86
  "publish": true,
56
87
  "entryPoint": true,
@@ -61,6 +92,7 @@
61
92
  "provenance": "own"
62
93
  },
63
94
  "verify-spike": {
95
+ "readiness": { "optionalBlocks": { "projectPlacement": "verifySpikeLayer" } },
64
96
  "class": "generic",
65
97
  "publish": true,
66
98
  "entryPoint": true,
@@ -81,6 +113,7 @@
81
113
  "provenance": "own"
82
114
  },
83
115
  "spec-self-critique": {
116
+ "readiness": { "optionalBlocks": { "projectEnrichment": "specCritiqueLayer" } },
84
117
  "class": "generic",
85
118
  "publish": true,
86
119
  "surfaces": [
@@ -90,6 +123,7 @@
90
123
  "provenance": "own"
91
124
  },
92
125
  "code-review": {
126
+ "readiness": { "optionalBlocks": { "projectEnrichment": "codeReviewLayer" } },
93
127
  "class": "generic",
94
128
  "publish": true,
95
129
  "surfaces": [
@@ -118,6 +152,7 @@
118
152
  "provenance": "own"
119
153
  },
120
154
  "board-to-waves": {
155
+ "readiness": { "required": ["issueTracker", "managedBoard"] },
121
156
  "class": "generic",
122
157
  "publish": true,
123
158
  "entryPoint": true,
@@ -138,6 +173,7 @@
138
173
  "provenance": "own"
139
174
  },
140
175
  "to-waves": {
176
+ "readiness": { "required": ["issueTracker", "managedBoard", "specCompleteness"] },
141
177
  "class": "generic",
142
178
  "publish": true,
143
179
  "entryPoint": true,
@@ -187,6 +223,7 @@
187
223
  "provenance": "matt-pocock"
188
224
  },
189
225
  "triage": {
226
+ "readiness": { "required": ["issueTracker", "managedBoard", "triageLabels"] },
190
227
  "class": "vendored",
191
228
  "publish": true,
192
229
  "entryPoint": true,
@@ -327,6 +364,7 @@
327
364
  "provenance": "own"
328
365
  },
329
366
  "audit-skills": {
367
+ "readiness": { "optionalBlocks": { "projectChecks": "auditSkillsLayer" } },
330
368
  "class": "generic",
331
369
  "publish": true,
332
370
  "entryPoint": false,
@@ -337,6 +375,7 @@
337
375
  "provenance": "own"
338
376
  },
339
377
  "local-ci": {
378
+ "readiness": { "required": ["localCiRecipe"] },
340
379
  "class": "generic",
341
380
  "publish": true,
342
381
  "entryPoint": false,
@@ -347,6 +386,10 @@
347
386
  "provenance": "own"
348
387
  },
349
388
  "orchestrate-wave": {
389
+ "readiness": {
390
+ "required": ["issueTracker", "managedBoard"],
391
+ "optionalBlocks": { "projectRecipe": "orchestrateWaveRecipe" }
392
+ },
350
393
  "class": "generic",
351
394
  "publish": true,
352
395
  "entryPoint": true,
@@ -357,6 +400,7 @@
357
400
  "provenance": "own"
358
401
  },
359
402
  "git-worktree-recover": {
403
+ "readiness": { "optionalBlocks": { "projectRecovery": "worktreeRecoveryLayer" } },
360
404
  "class": "generic",
361
405
  "publish": true,
362
406
  "entryPoint": false,
@@ -367,6 +411,7 @@
367
411
  "provenance": "own"
368
412
  },
369
413
  "security-audit": {
414
+ "readiness": { "required": ["securityAuditRunbook"] },
370
415
  "class": "generic",
371
416
  "publish": true,
372
417
  "entryPoint": false,
@@ -388,6 +433,7 @@
388
433
  "provenance": "own"
389
434
  },
390
435
  "project-release": {
436
+ "readiness": { "required": ["projectReleaseProfile"] },
391
437
  "class": "generic",
392
438
  "publish": true,
393
439
  "entryPoint": true,
@@ -11,15 +11,24 @@ A portable, structural self-review pass over a freshly written spec/plan. The **
11
11
 
12
12
  - After a spec was written/edited (a `SPEC.md` / `PLAN.md`, or a spec/design doc), BEFORE the user-review gate.
13
13
 
14
- ## Step 0Project-layer probe
14
+ ## Readiness preflightfirst
15
15
 
16
- First, check whether a project layer exists: from the project root, look for `docs/agents/skills/spec-self-critique.md`.
16
+ <!-- readiness:optional-preflight:start -->
17
+ Before any other step, run this once from the project root:
17
18
 
18
- - **Present** → **full pass**: run the 12 generic checks AND apply the per-point enrichment that file defines (incidents, grep patterns, extra sub-checks).
19
- - **Absent** **base pass**: run the 12 generic checks only, then add this one-line warning to the summary:
20
- > ⚠ No project layer found (`docs/agents/skills/spec-self-critique.md`) — only the generic base checks ran. `/setup-workflow` creates the layer; it fills in project-specific content via `/retro`.
19
+ ```bash
20
+ node scripts/readiness.mjs check --skill spec-self-critique --json
21
+ ```
22
+
23
+ - `ready`: continue without a readiness message. Ready is silent.
24
+ - `degraded`: keep the generic 12-point critique active, omit only the inactive block `projectEnrichment`, and emit exactly one concise summary: `Readiness degraded — inactive block projectEnrichment (specCritiqueLayer: <state>). Run /setup-workflow, configure docs/agents/skills/spec-self-critique.md, then rerun this skill.`
25
+ - `blocked`: stop before continuing and report the non-ready required capability plus the exact `/setup-workflow` recovery path.
26
+ - Invalid is always visible: include the `invalid` capability state in the single summary and never treat it as an opt-out. Do not emit separate warnings later in the workflow.
27
+ <!-- readiness:optional-preflight:end -->
21
28
 
22
- > **Routing keep this skeleton clean.** Project-specific checks, incidents, and grep patterns belong in the project layer (`docs/agents/skills/spec-self-critique.md`), **NOT here**. `/retro` appends new project-specific lore to the project layer, never into this generic skeleton.
29
+ <!-- readiness:block projectEnrichment -->
30
+ When `projectEnrichment` is active, read `docs/agents/skills/spec-self-critique.md` and apply its per-point enrichment, including project-specific incidents, grep patterns, conventions, and extra sub-checks. Project-specific checks belong in that layer, **not here**; `/retro` appends new project-specific lore there rather than into this generic skeleton.
31
+ <!-- readiness:end -->
23
32
 
24
33
  ## Altitude — a portable kit concept
25
34
 
@@ -63,7 +72,7 @@ Self-Critique complete — <N> corrections:
63
72
  - ...
64
73
  ```
65
74
 
66
- or, if none were needed: `Self-Critique complete — no corrections needed.` (append the Step-0 layer-absent warning if it applied). THEN ask the user-review question.
75
+ or, if none were needed: `Self-Critique complete — no corrections needed.` THEN ask the user-review question.
67
76
 
68
77
  ## The 12-point checklist
69
78
 
@@ -9,7 +9,19 @@ description: Break a plan, spec, or PRD into independently-grabbable issues on t
9
9
 
10
10
  Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
11
11
 
12
- The issue tracker and triage label vocabulary should have been provided to you — run `/setup-workflow` if not.
12
+ <!-- readiness:required-preflight:start -->
13
+ ## 0. Required readiness preflight
14
+
15
+ This is the first executable workflow step. From the project root, before any remote write or other `gh`/`board-sync.py` command, run this read-only check:
16
+
17
+ ```bash
18
+ node scripts/readiness.mjs check --skill to-issues --json
19
+ ```
20
+
21
+ - `verdict=ready`: continue with the existing workflow without announcing the check. **Ready is silent.**
22
+ - `verdict=blocked`: `STOP` before any mutation. Report every required capability as `<capability>=<state>` so `issueTracker`, `managedBoard`, and `specCompleteness` failures — including distinct `missing`, `pending`, and `invalid` states — stay visible, then give exactly one recovery path: **Run `/setup-workflow`, then rerun `/to-issues`.** Do not fall back to bare tracker or board commands.
23
+ - `managedBoard=not-applicable`: `STOP` and report that `/to-issues` is **inapplicable** for a project that deliberately has no managed board. This is a terminal project decision, not invalid evidence and not a partially active mode.
24
+ <!-- readiness:required-preflight:end -->
13
25
 
14
26
  ## Process
15
27
 
@@ -10,6 +10,20 @@ description: "Turn a locked plan (PLAN.md in the worktree, conversation context,
10
10
 
11
11
  Takes an **already-locked plan** and publishes it as a **Draft-PRD issue**. **Never invents requirements** — only synthesizes what's already decided. Pipeline: `board-to-waves → grill(-with-docs) → to-prd → to-issues`. The **grill sits upstream**; to-prd writes the PRD after the grill. **Slicing + promotion to an anchor (cluster/Wave, child link) = `to-issues`** (future), not here.
12
12
 
13
+ <!-- readiness:required-preflight:start -->
14
+ ## 0. Required readiness preflight
15
+
16
+ This is the first executable workflow step. From the project root, before any remote write or other `gh`/`board-sync.py` command, run this read-only check:
17
+
18
+ ```bash
19
+ node scripts/readiness.mjs check --skill to-prd --json
20
+ ```
21
+
22
+ - `verdict=ready`: continue with the existing workflow without announcing the check. **Ready is silent.**
23
+ - `verdict=blocked`: `STOP` before any mutation. Report every required capability as `<capability>=<state>` so `missing`, `pending`, and `invalid` remain distinct, then give exactly one recovery path: **Run `/setup-workflow`, then rerun `/to-prd`.** Do not fall back to bare tracker or board commands.
24
+ - `managedBoard=not-applicable`: `STOP` and report that `/to-prd` is **inapplicable** for a project that deliberately has no managed board. This is a terminal project decision, not invalid evidence and not a partially active mode.
25
+ <!-- readiness:required-preflight:end -->
26
+
13
27
  Board constants (project node, field/status IDs) + helpers live **consumer-side**: read `docs/agents/board-sync.md` from the project root + use the helper `scripts/board-sync.py` (missing → `/setup-workflow` scaffolds the project layer). Issue body **always** via `--body-file` (inline `--body` with backticks/parens crashes bash).
14
28
 
15
29
  ## 1. Input — source-agnostic