@vegastack/skills 0.7.0 → 0.9.0

package/README.md

@@ -14,10 +14,10 @@ npx @vegastack/skills add architect
 | `architect` | Architecture advisor: the locked stack and lean-first principles as evidence-distilled decision tables, dated source-verified platform facts, a per-project `.vegastack/arch.md` profile with repo-wins drift detection, and an advisory-only review discipline |
 | `skill-maintainer` | Encodes the Agent Skills standards (Claude Code, Codex, Hermes, agentskills.io) for creating, updating, and releasing skills in a skills repo |
 | `skillify` | Turns a feature or workflow into a complete skill conforming to the VegaStack skills contract, or audits an existing one |
-| `dev-setup` | Bootstraps a project for the issue-driven dev workflow: profile, AGENTS.md section, labels, decision register |
+| `dev-setup` | Bootstraps any project, greenfield included, for the issue-driven dev workflow: stack-playbook-drafted profile, AGENTS.md section, labels, guards, decision register |
 | `dev-intake` | Turns ideas, brainstorms, and SOWs into agent-ready GitHub issues with recorded user approval |
 | `dev-implement` | Implements an approved issue end to end, dark: preflight, claim, build, test, review, evidence in the issue |
-| `dev-ship` | Opens the PR and merges, each only on the user's explicit word |
+| `dev-ship` | Opens the PR, merges, and runs the project's Ship runbook, each only on the user's explicit word |
 
 ## Commands
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vegastack/skills",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "description": "Installer and verifier for VegaStack Agent Skills (Claude Code, Codex, and Hermes)",
   "license": "MIT",
   "type": "module",

package/skill/dev-implement/SKILL.md

@@ -1,41 +1,47 @@
 ---
 name: dev-implement
-description: Implement an approved GitHub issue end to end without further user input. Use when given an issue to build - "do issue 12", "implement" plus an issue URL or number, "pick up the next ready issue", "go dark on" an issue - when returning to apply corrections the user left on a for-you issue, or when the user directly asks in chat for a quick fix or small change. Runs preflight, claims the issue, builds on a task branch, tests, gets independent review, and posts one evidence comment in the issue. Not for writing or approving issues (dev-intake), not for creating PRs or merging (dev-ship).
+description: Implement an approved GitHub issue end to end without further user input. Use when given an issue to build - "do issue 12", "implement" plus an issue URL or number, "pick up the next ready issue", "go dark on" an issue - when returning to apply corrections the user left on a for-operator issue, or when the user directly asks in chat for a quick fix or small change. Runs preflight, claims the issue, builds on a task branch, tests, gets independent review, and posts one evidence comment in the issue. Not for writing or approving issues (dev-intake), not for creating PRs or merging (dev-ship).
 ---
 
 # dev-implement
 
 One issue, one session, end to end: preflight → claim → build dark → verify → review → evidence in the issue → stop. The user reads the result in the issue on their own time; nothing here creates a PR or merges — those are `dev-ship`, on the user's word.
 
-Nearest neighbor: `dev-intake` writes the brief this skill executes; if the issue turns out to need decisions, that's intake work — hand it back via `needs-you`, don't guess. `.vegastack/dev.md` missing → run `dev-setup` first. Read dev.md before anything; its knobs (review, ui-evidence, tests, branch, stop-list) govern this whole skill.
+Nearest neighbor: `dev-intake` writes the brief this skill executes; if the issue turns out to need decisions, that's intake work — hand it back via `needs-operator`, don't guess. `.vegastack/dev.md` missing → run `dev-setup` first. Read dev.md before anything; its knobs (review, ui-evidence, tests, branch, stop-list) govern this whole skill.
 
 ## Direct requests
 
-The gates exist to stop agent-invented authority, never to slow the user down. When the user directly asks in chat for a change ("fix this typo", "bump that timeout"), their words are the approval — do it, verify it, and report; no issue required. Offer to record an issue when the change is material enough that its brief or evidence will matter later. Everything below is the path for issue-driven work.
+The gates exist to stop agent-invented authority, never to slow the user down. When the user directly asks in chat for a change ("fix this typo", "bump that timeout"), their words are the approval — do it, verify it, and report; no issue required. Branch as `<type>/<slug>` (no issue segment); the changelog rule below applies unchanged when the change is behavior-changing; shipping still goes through dev-ship's words, with the chat request standing in for the approval and the report for the evidence comment. Offer to record an issue when the change is material enough that its brief or evidence will matter later. Everything below is the path for issue-driven work.
 
 ## Preflight — all must hold, or stop and say which failed
 
 - `gh auth status` works and the issue's repo matches dev.md.
 - The issue is open, labeled `ready`, and carries the recorded approval comment (`Approved by … : "…"`). A label without the comment is not approval.
 - No open blockers (issue dependencies) and no other assignee — an assigned or `working` issue belongs to someone else. A claim from a dead session is released only by the user: take over a `working` issue only when they explicitly hand it to you.
-- Read the complete brief, plus parent issue and milestone for context. If the brief leaves a material decision open — including an unresolved Assumptions entry — do not start: label `needs-you`, comment the smallest question that unblocks it, stop.
-- Re-verify the brief against reality before coding: its cited touch points against the current code (things drift between approval and execution), and volatile dependency claims when stale or version-sensitive. Reality contradicting the brief is a stop — label `needs-you` with the discrepancy; an approved brief is never a license to improvise past what's actually there.
+- Read the complete brief, plus parent issue and milestone for context. If the brief leaves a material decision open — including an unresolved Assumptions entry — do not start: label `needs-operator`, comment the smallest question that unblocks it, stop.
+- Re-verify the brief against reality before coding: its cited touch points against the current code (things drift between approval and execution), and volatile dependency claims when stale or version-sensitive. Reality contradicting the brief is a stop — label `needs-operator` with the discrepancy; an approved brief is never a license to improvise past what's actually there.
 
 ## Claim and branch
 
-Assign yourself, swap `ready` → `working`. Branch from the default branch: `<type>/<issue-number>-<short-slug>` (type from dev.md: feat, fix, docs, chore, refactor).
+Assign yourself, swap `ready` → `working`. Branch from the default branch per dev.md's `branch:` knob — the knob is the only source of the pattern and its type list.
 
 ## Build — dark
 
-No progress updates, no questions. A spike the brief flagged runs first — its result opens the evidence comment and shapes the rest of the build. Decide routine things yourself: file layout, helpers, fixtures, and root-cause fixes inside the issue's change areas. The brief's out-of-scope section and the dev.md stop-list bound you; hitting a stop condition (scope change, new dependency, spending, destructive/production action, unresolvable blocker) ends dark mode — post one `needs-you` comment stating the smallest decision needed with your recommendation, and stop.
+No progress updates, no questions. A spike the brief flagged runs first — its result opens the evidence comment and shapes the rest of the build. Decide routine things yourself: file layout, helpers, fixtures, and root-cause fixes inside the issue's change areas. The brief's out-of-scope section and the dev.md stop-list bound you; hitting a stop condition (scope change, new dependency, spending, destructive/production action, unresolvable blocker) ends dark mode — post one `needs-operator` comment stating the smallest decision needed with your recommendation, and stop.
 
 Honesty over green: a failing test gets fixed at the root or reported as failing. Weakening a test, an assertion, or acceptance to pass is a cover-up, and cover-ups surface at review with interest.
 
+## Changelog — before hand-back
+
+Every behavior-changing branch carries its changelog entry per dev.md's `changelog:` knob; a ship-time guard catches misses, but don't rely on it. `changesets` → write `.changeset/<slug>.md` directly (frontmatter `"<package-name>": <bump>` from the brief's version-impact line, plus a one-paragraph summary — the changeset CLI prompt is interactive, never invoke it here). `keep-a-changelog` / `pubspec+changelog` → one bullet under `## [Unreleased]` (Added/Changed/Fixed/Removed subsection as fits); no CHANGELOG.md yet → create it in the same branch with the skeleton (`# Changelog` + `## [Unreleased]`). `none` → skip. Docs the brief names as affected get updated in the same branch.
+
 ## Verify
 
 - Run the tests dev.md requires (`tests: required` → every changed behavior has a test that runs and passes; `logic-only` → content/config tweaks may skip). Record commands and results for the evidence comment.
 - A `risky` issue gets focused security, failure, and recovery checks on top of the required tests.
-- UI changed and `ui-evidence: playwright` → capture screenshots of the key states and flows, push them to the evidence repo (dev.md `evidence-repo`) under `<repo>/<issue-number>/`, and link them. Links, not embeds — private-repo images don't render inline in issues. Evidence repo missing or unreachable → name the local file paths in the evidence comment and say so; the hand-back never blocks on it.
+- When dev.md has a `## Verify` runbook, follow it — run the app and smoke-check the flows it names; that live result belongs in the evidence comment alongside the test output. Verify is pre-merge only; post-release checks live in `## Ship` and belong to dev-ship.
+- UI changed and `ui-evidence: playwright` → capture screenshots of the key states and flows and upload them to the shared evidence repo (dev.md `evidence-repo`) under `<this-repo-name>/<issue-number>/<timestamp>-<name>.png` — via the contents API so the repo is never cloned: `base64 < <file> | tr -d '\n' | gh api -X PUT repos/<evidence-repo>/contents/<path> -f message="evidence #<issue>" -F content=@-` (piped stdin, so large screenshots never hit argv limits; timestamped names keep re-captures from colliding; a 409 from a concurrent upload just means retry). Link them in the evidence comment — links, not embeds; private-repo images don't render inline in issues. Evidence repo missing or unreachable → name the local file paths and say so; the hand-back never blocks on it.
+- dev.md's Ship or Verify section is an empty TODO while release/deploy machinery visibly exists → finish this issue normally, then suggest re-running dev-setup so detection can fill it.
 
 ## Independent review — per the dev.md knob
 
@@ -50,13 +56,15 @@ Honesty over green: a failing test gets fixed at the root or reported as failing
 **Done:** what changed, in behavior terms
 **Tests:** <command> → <result summary>
 **Review:** <mode> — <findings fixed / none / disputed with reason>
+**Changelog:** <entry added / none, with reason>     (when the knob is not `none`)
 **UI evidence:** <links>            (when applicable)
+**Decision:** <one line in the register format>     (only a dark-mode choice that passes dev.md's Decisions test — a proposal; dev-ship records it after naming it in the merge confirmation)
 **Not done / limits:** the honest list
 Branch: <name> @ <short-sha>
 ```
 
-Post it, swap `working` → `for-you`, unassign nothing, stop. Later corrections update this same comment — a stack of stale result comments hides the current truth.
+Post it, swap `working` → `for-operator`, unassign nothing, stop. Later corrections update this same comment — a stack of stale result comments hides the current truth.
 
 ## Corrections loop
 
-The user's comments on a `for-you` issue are the new frontier: apply them, re-verify what they touch, update the evidence comment, back to `for-you`. Their corrections never need re-approval ceremony unless they change scope — then it's `needs-you` and dev-intake's recording rule.
+The user's comments on a `for-operator` issue are the new frontier: apply them, re-verify what they touch, update the evidence comment, back to `for-operator`. Their corrections never need re-approval ceremony unless they change scope — then it's `needs-operator` and dev-intake's recording rule.

package/skill/dev-implement/refresh/REFRESH.md

@@ -1,3 +1,3 @@
 # Refresh contract — dev-implement
 
-Evergreen: this skill asserts no version pins, vendor mechanism names beyond long-stable `gh` subcommands, numeric vendor limits, or dated facts — its content is workflow discipline (preflight, claiming, dark-mode bounds, review modes, the evidence-comment contract), all versionless. Harness mechanics are tracked by `dev-setup`'s registry. Revisit if a future edit introduces a volatile fact.
+Evergreen: this skill asserts no version pins, vendor mechanism names beyond long-stable `gh` subcommands and the GitHub contents API shape (deliberately treated as durable), numeric vendor limits, or dated facts — its content is workflow discipline (preflight, claiming, dark-mode bounds, review modes, the evidence-comment contract), all versionless. Harness mechanics are tracked by `dev-setup`'s registry. Revisit if a future edit introduces a volatile fact.

package/skill/dev-intake/SKILL.md

@@ -32,7 +32,7 @@ Work the design the way a joint product-and-tech review would; each round's answ
 
 1. **Product** — who this is for, the observable outcome, what's in and out of scope now, how it splits into slices or phases, priority.
 2. **Behavior** — primary and alternate flows, rules, permissions, validations, edge and failure cases; for UI, the states, components, and copy.
-3. **Technical** — only the choices that are genuinely the user's: approach trade-offs, data and interface implications, integrations, migration; recommend one and say why. Routine implementation stays the implementer's.
+3. **Technical** — only the choices that are genuinely the user's: approach trade-offs, data and interface implications, integrations, migration; recommend one and say why. When the project versions releases (dev.md `changelog:` knob), settle the intended version impact (patch/minor/major) here — the brief records it and dev-implement's changelog entry starts from it. Routine implementation stays the implementer's.
 4. **Quality and risk** — what proves it works (test cases, acceptance), what earns the `risky` label, what should stop a dark run beyond the standing stop-list.
 
 These are the brief template's sections in interview form — a question exists only where reading the material, the codebase, and sensible defaults cannot fill a section.
@@ -50,13 +50,13 @@ Every issue body follows [brief-template](references/brief-template.md): Outcome
 
 ## Labels and approval
 
-- A new issue starts at `needs-you`. Add `risky` when it touches security, money, user data, or production.
+- A new issue starts at `needs-operator`. Add `risky` when it touches security, money, user data, or production. (Label names come from dev.md's `labels:` knob; the defaults are used throughout this skill family's prose.)
 - Approval is only the user's explicit words — "approved", "go ahead", clearly tied to this issue, in chat or on the issue. Labels, silence, or the passage of time never create approval.
-- Record it once: comment `Approved by <user> on <date>: "<their words>"`, then swap `needs-you` → `ready`. That comment is what dev-implement's preflight looks for.
+- Record it once: comment `Approved by <user> on <date>: "<their words>"`, then swap `needs-operator` → `ready`. That comment is what dev-implement's preflight looks for.
 - An issue with an unconfirmed entry in its Assumptions section cannot go `ready` — the recorded approval covers the ledger the user saw, so resolve every entry (confirmed, corrected, or moved to a spike) first.
-- An issue that settles a material cross-cutting decision records it as one comment starting `Decision:` — dev-ship appends that line to the project's decision register at merge.
+- An issue that settles a directional decision — one that passes the Decisions test in `.vegastack/dev.md` — records it as one comment starting `Decision:`, in the register's line format; dev-ship appends it at merge after naming it in the merge confirmation. A decision that stands regardless of the issue's fate may go into the register immediately on the user's explicit yes in the same conversation — note "recorded" on the comment so dev-ship doesn't append it twice. Choices that fail the test are brief content, never register lines.
 - The user edits or corrects a draft → apply, and summarize what changed since they last read it.
 
 ## After approval
 
-An approved issue that later needs a material change flips back to `needs-you` with one comment naming what changed; the new approval is recorded the same way. Small wording fixes that change no behavior don't reopen anything.
+An approved issue that later needs a material change flips back to `needs-operator` with one comment naming what changed; the new approval is recorded the same way. Small wording fixes that change no behavior don't reopen anything.

package/skill/dev-intake/references/brief-template.md

@@ -28,6 +28,11 @@ user-facing text. Responsive and keyboard behavior when it matters.
 The chosen technical approach in a few lines: which parts of the codebase change,
 new/changed interfaces or schemas, data migrations. Routine choices (file names,
 helpers, fixtures) stay the implementer's — don't specify them.
+Name the docs and changelog surfaces this change must update (README section, user
+docs, the changelog entry's gist).
+**Version impact:** patch | minor | major, one-line reason — only when the project
+versions releases (dev.md `changelog:` knob); dev-implement's changelog entry or
+changeset starts from this line.
 
 ## Tests and acceptance
 
@@ -54,3 +59,4 @@ their evidence. Delete the section once every entry is resolved.
 - Concrete over abstract: "rejects amounts over 10,000 with error E402" beats "validates input".
 - Evidence over confidence: touch points name real file paths; a dependency capability claim carries the doc check and its date; what couldn't be verified goes to Assumptions, never stated as fact.
 - The brief binds the agent, so ambiguity is a bug in the brief — if two readings exist, the interview wasn't done.
+- A `Decision:` comment exists only for a choice that passes the Decisions test in `.vegastack/dev.md` — feature requests and implementation details never qualify; they are brief content, not register lines.

package/skill/dev-setup/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: dev-setup
-description: Bootstrap a project for issue-driven agent development. Use when asked to "set up the dev workflow", "bootstrap this project for agents", "install the dev workflow here", or invoked as dev-setup; also run automatically when dev-intake, dev-implement, or dev-ship find no .vegastack/dev.md in the project. Creates the project profile, the AGENTS.md dev section plus CLAUDE.md import, the five workflow labels on the GitHub repo, and the decision register. Not for architecture profiles or advice (that is architect and .vegastack/arch.md), not for authoring skills, not for repos without git.
+description: Bootstrap a project for issue-driven agent development — existing repo or brand-new empty directory. Use when asked to "set up the dev workflow", "bootstrap this project for agents", "install the dev workflow here", "set up this new project", or invoked as dev-setup; also run automatically when dev-intake, dev-implement, or dev-ship find no .vegastack/dev.md in the project. Detects the stack and drafts its native release, changelog, and guard conventions; creates the project profile, the AGENTS.md dev section plus CLAUDE.md import, the workflow labels, and the decision register; offers release-guard workflows and the decision-capture hook on the user's yes. Not for architecture profiles or advice (that is architect and .vegastack/arch.md), not for authoring skills, not for general CI or app scaffolding.
 ---
 
 # dev-setup
 
-Re-runnable bootstrap that gives a project everything the dev workflow needs: a profile file holding the knobs, a thin AGENTS.md section that both Claude Code and Codex read, the GitHub labels, and the decision register. The other dev skills call this automatically when `.vegastack/dev.md` is missing, then continue with their original request.
+Re-runnable bootstrap that gives a project everything the dev workflow needs: a profile file holding the knobs and runbooks, a thin AGENTS.md section that both Claude Code and Codex read, the GitHub labels, and the decision register. The other dev skills call this automatically when `.vegastack/dev.md` is missing, then continue with their original request.
 
 Nearest neighbor: `architect` owns `.vegastack/arch.md` (architecture facts and advice); dev-setup owns `.vegastack/dev.md` (workflow facts and knobs). When arch.md exists, point dev.md at it for stack facts instead of duplicating them.
 
@@ -19,30 +19,36 @@ Facts are your job; decisions are the user's. Gather these silently and present
 | gh authenticated | `gh auth status` |
 | stack and commands | package.json scripts, lockfiles, framework configs |
 | web app (UI evidence relevant) | framework dependencies (next, react, vue, …) |
-| existing files | AGENTS.md, CLAUDE.md, `.vegastack/dev.md`, `.vegastack/arch.md`, docs/decisions.md |
+| release/changelog machinery | match signals against [stack-playbooks](references/stack-playbooks.md) — the matched playbook drafts the `## Ship` runbook, the `changelog:` knob, and the guards to offer |
+| environments and run commands | CI/deploy configs, env examples (names only), dev/start scripts — these draft `## Environments` and `## Verify` |
+| existing files | AGENTS.md, CLAUDE.md, `.vegastack/dev.md`, `.vegastack/arch.md`, the decision register |
 | existing labels | `gh label list` |
 
-Not a git repo, or no origin remote: stop and say exactly what is missing. A half-installed workflow is worse than none.
+Not a git repo, or no origin remote → this is a **greenfield run, not an error**: follow the greenfield playbook in [stack-playbooks](references/stack-playbooks.md) — interview for the intended stack, offer `git init` and `gh repo create` each on its own yes, and render dev.md from the chosen playbook's conventions with TODO lines where machinery doesn't exist yet. A declined remote skips labels and records the TODO plainly.
 
 ## Step 2 — The interview
 
 Ask with your harness's question tool — AskUserQuestion in Claude Code, `request_user_input` in Codex where the mode allows it (availability details: [harness-facts](references/harness-facts.md)). When no question tool is available (headless run, gated mode), write the defaults, mark every unconfirmed knob `# TODO confirm`, and say so in your reply — a wrong invented preference costs more than a TODO.
 
-**Round A — confirm the detected facts** in one compact summary (repo, stack, commands, web app or not). Ask only about what detection could not fill.
+**Round A — confirm the detected facts** in one compact summary (repo, stack, commands, web app or not, matched playbook). Ask only about what detection could not fill.
 
-**Round B — the four workflow knobs**, recommended default first:
+**Round B — the workflow knobs**, recommended default first:
 
 1. Review of finished work: **subagent** · cross-agent (Codex↔Claude) · cross-agent only on `risky` issues
 2. Proof for UI work: **playwright screenshots** · none
-3. Gates: **3** (approve → PR → merge as separate user words) · 2 (approve → one "ship it" covers PR and merge)
+3. Gates: **3** (approve → PR → merge as separate user words) · 2 (approve → one "ship it" covers PR and merge) · 1 (direct-to-main for single-operator projects: the ship word merges locally and pushes, no PR — everything else unchanged)
 4. Tests: **required for every change** · required for logic changes only
 
 **Round C — only when the situation exists:**
 
+- Playbook matched → show the drafted `## Ship` runbook (each step `auto:`, `ask:`, or `guard:` — every `guard:` line carries its runnable command inline), the `changelog:` convention, and the `release:` knob (per-merge or on-request) for confirmation; a keep-a-changelog convention with no CHANGELOG.md yet → offer to seed the skeleton; no machinery → "Ship: merge only" and move on
+- Guards drafted → offer to write their CI backstop steps into the project's workflow files (the local `guard:` lines run without CI); each file on the user's yes — release guards only, never general CI
+- Environments or run commands detected → confirm the drafted `## Environments` and `## Verify` bullets
+- Evidence repo (`ui-evidence: playwright`) → default is the owner's **shared** `<owner>/dev-review-evidence`; if it doesn't exist, offer `gh repo create <owner>/dev-review-evidence --private --add-readme` + the layout/retention README — created once, every project points at it. An org naming policy that rejects the name → pick the closest compliant name with the user and record it in the knob (the name is a knob value, not a contract)
+- Decision-capture hook → offer the Stop-hook from [harness-facts](references/harness-facts.md) for the harnesses in use; hook files and settings wiring are written only on the user's explicit yes, merging into existing hook config, never overwriting
 - AGENTS.md already has content → append the marked section (default) or show a merge proposal first
 - CLAUDE.md already has content → add the `@AGENTS.md` import as its first line (default) or move its content into AGENTS.md and leave only the import
-- Evidence repo for UI screenshots → default `<owner>/dev-review-assets`; offer to create it (`gh repo create --private`) if missing
-- Different label names or a different decision-register path, if the user brings it up
+- Different label names, `gates: 1` with branch protection on the default branch (it blocks direct pushes — surface the conflict), or a different decision-register path, if the situation or the user brings it up
 
 Everything else — merge style, branch naming, the stop-and-ask list — takes its documented default straight into dev.md. The profile is plain text the user can edit anytime; the interview is a convenience, not the source of truth.
 
@@ -50,11 +56,12 @@ Everything else — merge style, branch naming, the stop-and-ask list — takes
 
 | Target | Action |
 |---|---|
-| `.vegastack/dev.md` | render [dev-profile template](assets/dev-profile.md.template) with the answers |
+| `.vegastack/dev.md` | render [dev-profile template](assets/dev-profile.md.template) with the answers — the project's single canonical process doc (short directional bullets; Ship/Verify/Environments/Design drafted from the playbook, Decisions test included, placeholders deleted, TODO lines where machinery is absent) |
 | `AGENTS.md` | create it, or insert/replace only the block between `<!-- vsk-dev:start -->` and `<!-- vsk-dev:end -->` using the [agents-section template](assets/agents-section.md.template); content outside the markers is the user's and stays untouched |
 | `CLAUDE.md` | ensure its first line is `@AGENTS.md` — Claude Code does not read AGENTS.md natively and needs this import ([harness-facts](references/harness-facts.md)); create the file when absent |
-| labels | `gh label create <name> --color <hex> --description "<text>"`, skipping ones that exist: `needs-you` FBCA04 (waiting on the user) · `ready` 0E8A16 (approved, agent may start) · `working` 1D76DB (claimed by an agent) · `for-you` 5319E7 (result awaiting user review) · `risky` B60205 (security, money, data, or production) |
-| decision register | create the file the `decisions:` knob names (default `docs/decisions.md`) with a two-line header and one example entry, when missing; a project with an existing register keeps it and the knob points there |
+| labels | `gh label create <name> --color <hex> --description "<text>"` for the names the `labels:` knob records, skipping ones that exist; default names and creation colors: `needs-operator` FBCA04 (waiting on the user) · `ready` 0E8A16 (approved, agent may start) · `working` 1D76DB (claimed by an agent) · `for-operator` 5319E7 (result awaiting user review) · `risky` B60205 (security, money, data, or production) |
+| decision register | create the file the `decisions:` knob names (default `.vegastack/decisions.md`) when missing, with a two-line header stating the format: `- DD-MM-YYYY (github-username) — the decision` (username via `gh api user -q .login`, fallback `git config user.name`); a project with an existing register keeps it and the knob points there |
+| guard workflows / hook files | only the ones the user said yes to in Round C |
 
 ## Step 4 — Report
 
@@ -62,4 +69,4 @@ One summary: what was created, what was skipped and why, what remains TODO. When
 
 ## Re-runs
 
-Re-running is safe and is how knobs get revisited: show what differs per target and change only what the user confirms. The marked block is the only part of AGENTS.md this skill owns. Hand edits inside dev.md win — read them and keep them; the templates are for creation, not for resetting.
+Re-running is safe and is how knobs get revisited and empty sections get filled: diff fresh detection against the existing dev.md, show what differs per target, and change only what the user confirms — propose the delta, never reset. The other dev skills send the user here when they notice an empty Ship/Verify section next to newly present machinery. The marked block is the only part of AGENTS.md this skill owns. Hand edits inside dev.md win — read them and keep them; the templates are for creation, not for resetting.

package/skill/dev-setup/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "dev-setup"
-  short_description: "Bootstrap a repo for the issue-driven dev workflow"
+  short_description: "Bootstrap any repo, greenfield included, for the issue-driven dev workflow"
   default_prompt: "Use $dev-setup to bootstrap this project's dev workflow."

package/skill/dev-setup/assets/agents-section.md.template

@@ -3,7 +3,11 @@
 
 Read `.vegastack/dev.md` for this project's stack, commands, and workflow knobs.
 
-Work flows through GitHub issues. An issue labeled `ready` carries the user's recorded approval and a complete brief — implement it end to end per the `dev-implement` skill, post the evidence in the issue, and hand it back with `for-you`. Start only on `ready` issues. These five labels are the whole workflow vocabulary — use them and no others: `needs-you` (waiting on the user) → `ready` (approved) → `working` (claimed by an agent) → `for-you` (result awaiting user review); `risky` flags security, money, data, or production work.
+Work flows through GitHub issues. An issue labeled `ready` carries the user's recorded approval and a complete brief — implement it end to end per the `dev-implement` skill, post the evidence in the issue, and hand it back with `for-operator`. Start only on `ready` issues. The workflow vocabulary is the labels dev.md's `labels:` knob names (defaults: `needs-operator` waiting on the user → `ready` approved → `working` claimed by an agent → `for-operator` result awaiting review; `risky` flags security, money, data, or production) — use them and no others.
 
-The user holds the gates: they approve the issue, say the word for a PR, and say a separate word to merge (see `gates` in dev.md). Material decisions get one dated line in the decision register dev.md names (`decisions:` knob).
+**Nothing ships without the operator's explicit instruction** — no push to the default branch, merge, tag, publish, or deploy on green checks, schedules, or standing approvals alone. The `gates` knob in dev.md changes how many of those actions one instruction covers, never whether an instruction is needed. Behavior changes carry their changelog entry per dev.md's `changelog:` knob before hand-back; after merge, the `## Ship` runbook in dev.md says what happens next and which steps need the operator's word.
+
+Directional decisions — see `## Decisions` in dev.md for what qualifies — get one dated line in the register dev.md names. When any session, skill-driven or not, settles a choice that passes that test, propose the line and add it only on the user's yes.
+
+dev.md is the project's self-maintained handbook: when a gotcha, surprise, or repeated instruction surfaces in any run, propose one line for the right dev.md section that would have prevented it — fold into existing lines, never append a log — and add it on the user's yes.
 <!-- vsk-dev:end -->

package/skill/dev-setup/assets/dev-profile.md.template

@@ -1,23 +1,59 @@
 # Dev profile — {{owner/repo}}
 
+This file is the project's handbook and its only process document: short directional bullets, not prose. Skills read the section they need. When reality disagrees with a line, fix the line; when a gotcha or repeated instruction surfaces, fold ONE line into the right section — never append a log. A section left as TODO because its machinery didn't exist yet: re-run dev-setup detection when the machinery appears.
+
 repo: {{owner/repo}} · default branch {{branch}}
 stack: {{one line, or "see .vegastack/arch.md"}}
 commands: test `{{test}}` · build `{{build}}` · dev `{{dev}}`
+authority: {{ordered — e.g. "CONTRIBUTING.md → this file → skill defaults"; delete the line when this file is the only process doc}}
 
 ## Knobs
 
 review: subagent            # subagent | cross-agent | cross-agent-risky
 ui-evidence: playwright     # playwright | none
-evidence-repo: {{owner}}/dev-review-assets
-gates: 3                    # 3 = approve/PR/merge · 2 = approve/ship
+evidence-repo: {{owner}}/dev-review-evidence   # shared across projects; this project's folder = repo name; delete the line when ui-evidence is none
+gates: 3                    # 3 = approve/PR/merge · 2 = approve + one "ship it" · 1 = direct-to-main, ship word merges locally and pushes, no PR
 tests: required             # required | logic-only
 merge: squash
-branch: <type>/<issue>-<slug>   # type: feat | fix | docs | chore | refactor
-decisions: docs/decisions.md
+branch: <type>/<issue>-<slug>   # type: feat | fix | docs | chore | refactor — the only place this list lives
+labels: needs-operator ready working for-operator risky
+changelog: {{changesets | keep-a-changelog | pubspec+changelog | none (reason)}}
+decisions: .vegastack/decisions.md
+release: on-request         # per-merge = Ship runbook runs as part of shipping · on-request = only when the operator says "release"
+
+## Ship — what happens after merge, in order
+
+Line prefixes: `auto:` (agent just does it) · `ask:` (operator's word first) · `guard:` (deterministic check run locally at this position, its runnable command inline on the line; the CI copy is the backstop).
+
+- {{playbook-drafted release steps for the detected stack}}
+- {{guard: lines from the playbook}}
+- {{post-release verification — how to see the release/deploy landed}}
+- {{rollback one-liner from the playbook}}
+- {{versioning policy in 1–2 bullets when the project has one; delete the section's placeholders — "Ship: merge only" is a valid runbook}}
+
+## Verify — how to see it working (pre-merge)
+
+- {{start: command · URL}}
+- {{the flows worth smoke-checking after a change}}
+
+## Environments
+
+- {{environments and their targets; which the agent may touch}}
+- {{where secret NAMES are defined — values never appear in this file}}
+
+## Design
+
+- {{pointers: design system / component rules / .vegastack/arch.md / UI conventions}}
+
+## Decisions
+
+Record a decision only when it is directional — it steers work beyond this issue: a real alternative was rejected; it constrains work not yet written; and no dev.md line, lint rule, or guard can enforce it instead (if one can, write the rule). Feature requests, one-off fixes, and routine implementation choices never qualify. Every entry needs the user's explicit yes. One line in the register (`decisions:` knob), append-only, no other metadata:
+
+- DD-MM-YYYY (github-username) — the decision
 
 ## Stop and ask
 
-Dark execution ends and the user decides when work would involve: a change of scope or product behavior, a significant new dependency or runtime, spending money, anything destructive or touching production, or a blocker the brief cannot resolve.
+Dark execution ends and the operator decides when work would involve: a change of scope or product behavior, a significant new dependency or runtime, spending money, anything destructive or touching production, or a blocker the brief cannot resolve. Nothing ships without the operator's explicit instruction — see the AGENTS.md dev section.
 
 ## Project rules
 

package/skill/dev-setup/references/harness-facts.md

@@ -8,6 +8,7 @@ Verified mechanics of the two harnesses this workflow targets. Everything here i
 - `CLAUDE.local.md` in the project root loads after CLAUDE.md and is meant to be gitignored — leave it alone; it is the user's personal file. <!-- source: CC-MEMORY -->
 - Project skills load from `.claude/skills/<name>/SKILL.md`; personal skills from `~/.claude/skills/`. <!-- source: CC-SKILLS -->
 - The structured question tool is **AskUserQuestion**. It is unavailable in non-interactive runs (`claude -p`); a configurable timeout can auto-submit pre-selected options. <!-- source: CC-TOOLS -->
+- Hooks live in settings files (`.claude/settings.json` project-level) under a `hooks` key mapping event names to command entries. The `Stop` event fires when Claude finishes a turn; its stdin JSON includes `session_id`, `stop_hook_active`, and `last_assistant_message`; a hook keeps the agent going by emitting `{"decision": "block", "reason": "…"}` (or exit 2 with the reason on stderr) — `reason` is shown to the agent. `SessionEnd` cannot block. `SubagentStop` is a separate event — leave it unwired so subagents don't fire nudges. <!-- source: CC-HOOKS -->
 
 ## Codex
 
@@ -15,6 +16,31 @@ Verified mechanics of the two harnesses this workflow targets. Everything here i
 - Skills load from `.agents/skills/` in each directory from the working directory up to the repo root, plus `~/.agents/skills/` for the user. Frontmatter requires only `name` and `description`; an optional `agents/openai.yaml` adds display metadata and invocation policy. <!-- source: CODEX-SKILLS -->
 - The structured question tool is **`request_user_input`** — collaboration-mode-gated (available in Plan mode; elsewhere it fails fast with a clear error, and it is not available to subagents). Community posts mention an "ask_user_question"/"clarify" tool; that is a proposal, not a shipped tool — do not design against it. <!-- source: CODEX-SKILLS -->
 - Non-interactive mode is `codex exec`: fully unattended, human-input tools unavailable, AGENTS.md discovery unchanged. <!-- source: CODEX-EXEC -->
+- Codex has lifecycle hooks too: configured in `~/.codex/hooks.json` / `<repo>/.codex/hooks.json` (or inline `[hooks]` tables in config.toml); project-local hooks load only when the repo's `.codex/` layer is trusted, and older Codex versions gate the engine behind a features flag. Its `Stop` event mirrors Claude Code's: stdin JSON with `stop_hook_active` and `last_assistant_message`, `{"decision": "block", "reason": "…"}` or exit 2 to continue the turn, `SubagentStop` separate. <!-- source: CODEX-HOOKS -->
+
+## Decision-capture Stop hook (optional, offered in Round C)
+
+Because both Stop contracts match, one shared script serves both harnesses. Write it to `.vegastack/hooks/decision-nudge.sh` and wire it as `sh .vegastack/hooks/decision-nudge.sh` (no exec bit needed). Only on the user's explicit yes, and only the `Stop` event. The wiring shape is doubly nested — matcher groups each holding their own `hooks` array — identical in Claude Code's `.claude/settings.json` and Codex's `<repo>/.codex/hooks.json` (merge into existing hook config, never overwrite): <!-- source: CC-HOOKS --> <!-- source: CODEX-HOOKS -->
+
+```json
+{ "hooks": { "Stop": [ { "hooks": [ { "type": "command", "command": "sh .vegastack/hooks/decision-nudge.sh" } ] } ] } }
+```
+
+```sh
+#!/bin/sh
+# Nudge at most once per session, and only when the last message smells directional.
+command -v jq >/dev/null 2>&1 || exit 0        # no jq -> no nudge, never break the harness
+input=$(cat)
+[ "$(printf '%s' "$input" | jq -r '.stop_hook_active')" = "true" ] && exit 0
+marker="${TMPDIR:-/tmp}/vsk-decision-nudge-$(printf '%s' "$input" | jq -r '.session_id')"
+[ -e "$marker" ] && exit 0
+printf '%s' "$input" | jq -r '.last_assistant_message // ""' \
+  | grep -qiE 'decided|chose|instead of|convention|from now on|standardi[sz]|switch(ed|ing)? to' || exit 0
+: > "$marker"
+printf '%s' '{"decision":"block","reason":"Before finishing: if this session settled a directional choice (the Decisions test in .vegastack/dev.md), propose one dated register line and ask the user to confirm; otherwise finish."}'
+```
+
+The marker lives under the OS temp dir, never inside the repo. The prose instruction in the AGENTS.md dev section is the portable base on both harnesses; this hook is a deterministic nudge on top, not a replacement.
 
 ## What this means for the dev skills
 

package/skill/dev-setup/references/stack-playbooks.md

@@ -0,0 +1,124 @@
+# Stack playbooks
+
+Detection-to-draft mapping for Step 1 and Round C: match the signals, propose the matching draft for `.vegastack/dev.md`, confirm with the user. Every draft is a starting proposal — the user's edits win. Mechanism names here are long-stable; anything version- or vendor-volatile lives in [harness-facts](harness-facts.md) under the refresh contract. Non-GitHub hosting is out of scope for this workflow — the issue/label machinery is GitHub-native.
+
+Each playbook fills the same six slots: **detect** (file signals) · **ship draft** (runbook lines) · **changelog** (the `changelog:` knob value and what dev-implement adds per change) · **version identity** (the one place a version lives) · **guards** (from the library below) · **rollback** (one line for `## Ship`).
+
+## npm package (published)
+
+- **Detect:** `.changeset/config.json`, or a publish workflow / `"private": false` package.json with a registry config.
+- **Ship draft:**
+  - `auto: apply pending changesets (changeset version) and refresh the lockfile, commit as chore: release <version>`
+  - `ask: tag v<version> and push — the tag triggers the publish pipeline`
+  - `guard: tag matches the package version` · `guard: changelog has an entry for the tagged version`
+  - `auto: confirm the registry shows the new version; report old → new`
+- **Changelog:** `changesets`. Per behavior-changing branch, dev-implement writes `.changeset/<slug>.md` **directly** — frontmatter `"<package-name>": <patch|minor|major>` (from the brief's version-impact line) plus a one-paragraph summary. `changeset add` (the bare `changeset` prompt) is interactive; never invoke it in a dark run — `changeset version` at release time is the only CLI use. The release changelog is changesets-written — never hand-edited.
+- **Version identity:** `package.json` `version`, changesets-managed. Monorepos: identity is per-package; changesets handles multiple packages natively — the guard reads the released package's manifest. A private workspace root carries **no** version field (nothing maintains it; delete it rather than let it drift).
+- **Guards:** changeset-presence (PR-time) · tag↔version · changelog-entry.
+- **Rollback:** `Rollback is roll-forward: revert on main, release previous-good as a new patch, deprecate the bad version on the registry.`
+
+## Node web app (deployed, not published — Next.js, Vite, Express, …)
+
+- **Detect:** framework config (`next.config.*`, `vite.config.*`, …) with a deploy workflow, platform config (wrangler/Vercel/Netlify), or Dockerfile — and no publish machinery.
+- **Ship draft:**
+  - `auto: move the [Unreleased] changelog entries under a new dated version heading, commit`
+  - `ask: deploy to production (<the project's deploy command or pipeline>)`
+  - `guard: changelog has an entry for the version being released` (when the app versions releases; date-based releases skip the version guard)
+  - `auto: smoke-check the deployed URL against the Verify flows; report`
+- **Changelog:** `keep-a-changelog`. Per behavior-changing branch, dev-implement adds one bullet under `## [Unreleased]` (Added/Changed/Fixed/Removed subsection as fits).
+- **Version identity:** `package.json` `version` + the changelog heading, when the project versions releases at all; many apps release by date/deploy — then the changelog heading is the identity and no manifest bump exists.
+- **Guards:** changelog-entry; tag↔version only when the project tags releases.
+- **Rollback:** `Rollback is redeploying the previous known-good build/revision via the platform; a code fix rolls forward through the normal flow.`
+
+## Flutter app
+
+- **Detect:** `pubspec.yaml` with a `flutter:` section.
+- **Ship draft:**
+  - `auto: bump pubspec version (semver + incremented build number), move [Unreleased] changelog entries under the new version, commit`
+  - `ask: build and submit the store release / trigger the release pipeline`
+  - `guard: tag matches the pubspec version` · `guard: changelog has an entry for the version`
+  - `auto: report submitted version + build number`
+- **Changelog:** `pubspec+changelog` — keep-a-changelog `CHANGELOG.md` (also the source for store release notes), with the version bump living in `pubspec.yaml`.
+- **Version identity:** `pubspec.yaml` `version: x.y.z+build` — semver plus a build number the stores require to strictly increase.
+- **Guards:** tag↔version (pubspec read) · changelog-entry.
+- **Rollback:** `Stores do not roll back a released binary: halt the staged rollout if still in progress, then roll forward with a fixed build.`
+
+## Python (package or app)
+
+- **Detect:** `pyproject.toml`.
+- **Ship draft:**
+  - `auto: bump [project] version, move [Unreleased] changelog entries under it, commit`
+  - `ask: tag v<version> and push — tag triggers the publish/deploy pipeline`
+  - `guard: tag matches the pyproject version` · `guard: changelog has an entry for the version`
+- **Changelog:** `keep-a-changelog`.
+- **Version identity:** `pyproject.toml` `[project] version` (a project pinning it elsewhere names that place in dev.md instead — one place only).
+- **Guards:** tag↔version (pyproject read) · changelog-entry.
+- **Rollback:** `Roll forward: yank the bad release on the index if supported, publish previous-good as a new patch.`
+
+## Go module
+
+- **Detect:** `go.mod`.
+- **Ship draft:**
+  - `auto: move [Unreleased] changelog entries under the new version, commit`
+  - `ask: tag v<version> and push — the tag IS the release for module consumers`
+  - `guard: changelog has an entry for the tagged version`
+- **Changelog:** `keep-a-changelog`.
+- **Version identity:** the git tag `vX.Y.Z` — Go modules carry no manifest version, so no tag↔version guard exists or is needed.
+- **Guards:** changelog-entry.
+- **Rollback:** `Roll forward and add a retract directive for the bad version in go.mod, released as a new patch.`
+
+## Generic / none of the above
+
+- **Detect:** none of the signals matched.
+- **Ship draft:** `Ship: merge only` — a valid runbook.
+- **Changelog:** `keep-a-changelog` if the user wants a history; otherwise `none (<reason>)`. A project with an existing convention that matches no knob value records `none (<its convention>)` — the knob never silently mismatches reality.
+- **Version identity / guards / rollback:** none until machinery appears; sections render their TODO line and the self-heal rule covers the rest.
+
+## Guard library
+
+Each guard is one small shell block with **two uses**: a `guard:` line in `## Ship` that dev-ship runs locally at its runbook position (fast feedback), and the same block as a CI step (the backstop that actually blocks a bad publish — order it **before** the publish step, and offer to write it on the user's yes). Render every `guard:` line in dev.md with its runnable command inline, variables bound (dev-ship reads dev.md, not this file — a guard without its command is an improvisation invitation). Adapt paths/commands per the stack; never offer a guard whose machinery the project lacks.
+
+**changelog-entry** — fail when the changelog has no section for the version. Handles both heading styles (`## 1.2.3` changesets, `## [1.2.3]` keep-a-changelog):
+
+```sh
+awk -v ver="$VERSION" '
+  $0 == "## " ver || index($0, "## [" ver "]") == 1 { inside = 1; next }
+  inside && /^## / { exit }
+  inside && /^\[.*\]:/ { next }
+  inside { print }
+' "$CHANGELOG" | grep -q '[^[:space:]]' \
+  || { echo "no changelog entry for $VERSION in $CHANGELOG"; exit 1; }
+```
+
+(The `^\[.*\]:` skip keeps keep-a-changelog's trailing link-reference block from counting as entry content.)
+
+**tag↔version** — fail when the tag disagrees with the manifest:
+
+```sh
+# VERSION per stack ($TAG is the tag being created locally, or $GITHUB_REF_NAME in CI):
+#   npm:     node -p "require('./package.json').version"
+#   Flutter: sed -n 's/^version:[[:space:]]*"\{0,1\}\([0-9][^+" ]*\).*/\1/p' pubspec.yaml
+#   Python:  python3 -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])"   # tomllib needs Python >= 3.11; older: tomli
+[ "v$VERSION" = "$TAG" ] || { echo "tag $TAG != manifest version $VERSION"; exit 1; }
+```
+
+**changeset-presence** (npm stacks, PR-time) — fail when a behavior-changing branch carries no changeset:
+
+```sh
+npx changeset status --since "origin/$DEFAULT_BRANCH"   # or bunx, per the project's runner
+```
+
+Blind spot: `changeset status` sees changed **workspace packages** only — content outside any package (docs, repo tooling) is invisible to it, so the evidence comment's `**Changelog:**` line stays the human check.
+
+## Greenfield playbook
+
+No git repo or no origin remote is a greenfield run, not an error. Detection has nothing to read, so the interview supplies intent:
+
+1. Ask the intended stack (offer the playbook list above) and whether the project will publish, deploy, or neither — this picks the draft conventions up front.
+2. Offer, each on its own yes: `git init` (default branch `main`) · `gh repo create <owner>/<name> --private` + first push · a stack-appropriate `.gitignore`.
+3. Scaffolding the app itself (create-next-app, flutter create, …) is **not** this skill's job — name the conventional command for the chosen stack and leave running it to the user (or `architect` guidance).
+4. Render dev.md from the chosen playbook's conventions; every section whose machinery doesn't exist yet gets its `TODO — re-run dev-setup when it appears` line. Declined remote → skip labels, record the TODO, and say what was skipped.
+
+## Decision-capture hooks
+
+The Stop-hook recipe (both harnesses), its wiring, and the hook API facts live in [harness-facts](harness-facts.md) — volatile vendor surface under the refresh contract. Offer it in Round C; write hook files only on the user's explicit yes.

package/skill/dev-setup/refresh/REFRESH.md

@@ -4,10 +4,10 @@ Instructions for the scheduled refresh agent (and any human running a manual ref
 
 ## What this skill claims
 
-- **Durable rules** (SKILL.md, assets): the detect-then-ask discipline, the interview rounds and knobs, the marked-section AGENTS.md contract, the label set, the defaults-plus-TODO fallback. Versionless; the refresh agent NEVER edits these — if evidence invalidates one, open an issue quoting it.
-- **Volatile facts**: everything in `references/harness-facts.md` — Claude Code memory/import/skill/question-tool mechanics and Codex AGENTS.md/skills/question-tool/exec mechanics. That file is the only refresh-tracked file; its sentences carry `<!-- source: SOURCE-ID -->` markers matching the registry.
+- **Durable rules** (SKILL.md, assets): the detect-then-ask discipline, the interview rounds and knobs, the marked-section AGENTS.md contract, the default label set, the defaults-plus-TODO fallback. Versionless; the refresh agent NEVER edits these — if evidence invalidates one, open an issue quoting it.
+- **Volatile facts**: everything in `references/harness-facts.md` — Claude Code memory/import/skill/question-tool/hooks mechanics and Codex AGENTS.md/skills/question-tool/exec/hooks mechanics, plus the shared Stop-hook recipe. That file is the only refresh-tracked file; its sentences carry `<!-- source: SOURCE-ID -->` markers matching the registry. `references/stack-playbooks.md` carries only long-stable mechanism names (changesets and its `status`/`version` CLI, keep-a-changelog, store release flows, `gh` subcommands and flags like `--add-readme`, the GitHub contents API shape) — deliberately treated as durable, no pins; if one drifts, open an issue rather than editing in a refresh run.
 
 ## How to refresh
 
-1. Run the shared runner against this registry; on drift, read the changed page and propose edits to the marked sentences in `references/harness-facts.md` — and to the three harness-mechanism mentions in SKILL.md that mirror it (the two question tools in Step 2, the `@AGENTS.md` import in Step 3) — in the same PR as the registry update.
+1. Run the shared runner against this registry; on drift, read the changed page and propose edits to the marked sentences in `references/harness-facts.md` — and to the harness-mechanism mentions in SKILL.md that mirror it (the two question tools in Step 2, the `@AGENTS.md` imports in Round C and Step 3, the Round C Stop-hook offer) — in the same PR as the registry update.
 2. Never auto-apply harness behavior changes; a human reviews — these facts change what dev-setup writes into user projects.

package/skill/dev-setup/refresh/sources.json

@@ -126,6 +126,52 @@
       "checksum": "44aa6d490f4567c0b1fb064deab642bfac590f0e721228e0c53fe738db191026",
       "retrievedAt": "2026-08-27T08:19:24.132Z"
     },
+    {
+      "id": "CC-HOOKS",
+      "service": "Claude Code hooks (Stop event, settings.json wiring, block/reason contract)",
+      "kind": "official-docs",
+      "stability": "vendor-docs",
+      "thresholdDays": 14,
+      "critical": false,
+      "urls": {
+        "primary": "https://code.claude.com/docs/en/hooks.md"
+      },
+      "versionDetection": {
+        "type": "manual-review"
+      },
+      "topics": [
+        "claude-code-hooks"
+      ],
+      "affected": [
+        "references/harness-facts.md",
+        "SKILL.md"
+      ],
+      "checksum": "936bd443066df08a514972673358e102fd23b80bee9a289d3d53a1ed8aca1a64",
+      "retrievedAt": "2026-08-27T14:41:39.189Z"
+    },
+    {
+      "id": "CODEX-HOOKS",
+      "service": "Codex hooks (hooks.json locations, trust gating, Stop event contract)",
+      "kind": "official-docs",
+      "stability": "vendor-docs",
+      "thresholdDays": 14,
+      "critical": false,
+      "urls": {
+        "primary": "https://learn.chatgpt.com/docs/hooks.md"
+      },
+      "versionDetection": {
+        "type": "manual-review"
+      },
+      "topics": [
+        "codex-hooks"
+      ],
+      "affected": [
+        "references/harness-facts.md",
+        "SKILL.md"
+      ],
+      "checksum": "430f2d85a4791dc695bcdc063193c225343104a342e8adf80a544ab87ae4223d",
+      "retrievedAt": "2026-08-27T14:41:39.189Z"
+    },
     {
       "id": "CODEX-EXEC",
       "service": "Codex non-interactive mode (codex exec)",

package/skill/dev-ship/SKILL.md

@@ -1,33 +1,44 @@
 ---
 name: dev-ship
-description: Create the pull request and merge for a finished issue, each only on the user's explicit word. Use when the user says "make the PR", "open a pull request" for an issue, "ship it", "merge it", "merge issue 12", or asks to close out a reviewed issue. Verifies the issue is at for-you with evidence, links the PR to the issue, and squash-merges on the separate merge instruction. Not for implementing issues (dev-implement) or writing and approving them (dev-intake).
+description: Create the pull request and merge for a finished issue, each only on the user's explicit word, then run the project's Ship runbook — releases, guards, deploys. Use when the user says "make the PR", "open a pull request" for an issue, "ship it", "merge it", "merge issue 12", "release", "release everything since the last tag", or asks to close out a reviewed issue, merge a bot PR, or roll back a bad release (roll-forward). Verifies the issue is at for-operator with evidence and its changelog entry, links the PR to the issue, merges on the separate merge instruction, and records approved decisions. Not for implementing issues (dev-implement) or writing and approving them (dev-intake).
 ---
 
 # dev-ship
 
-Two gates, each one sentence from the user, each spent when used: their words asking for a PR authorize the PR and nothing more; their words asking to merge authorize the merge. With `gates: 2` in `.vegastack/dev.md`, one "ship it" covers both — that's the only case where they combine. Passing checks, PR permissions, and the calendar authorize nothing by themselves.
+Gates spent only by the user's words: their words asking for a PR authorize the PR and nothing more; their words asking to merge authorize the merge. The dev.md `gates` knob sets how many actions one word covers — `3` keeps PR and merge as separate words, `2` lets one "ship it" cover both, `1` is direct-to-main (the ship word merges locally and pushes; no PR object, everything else identical). Passing checks, PR permissions, and the calendar authorize nothing by themselves.
 
-Nearest neighbor: `dev-implement` produces the `for-you` issue with its evidence comment; ship packages and lands it. Corrections found here go back through implement's corrections loop.
+Nearest neighbor: `dev-implement` produces the `for-operator` issue with its evidence comment; ship packages and lands it. Corrections found here go back through implement's corrections loop.
 
 ## Gate 1 — the PR
 
 On the user's PR instruction:
 
-- Verify the issue is at `for-you` with the evidence comment present, and the branch is pushed. Not there yet → say what's missing instead of creating a premature PR.
+- Verify the issue is at `for-operator` with the evidence comment present, and the branch is pushed. Not there yet → say what's missing instead of creating a premature PR.
+- Verify the changelog state matches the evidence comment's `**Changelog:**` line: a behavior-changing branch carries its entry per dev.md's `changelog:` knob (changesets: a `.changeset/*.md` in the diff; keep-a-changelog: the diff adds lines to CHANGELOG.md), while `none` with a reason that holds up (docs-only, test-only) is fine. An unexplained miss → corrections loop, not a PR.
 - `gh pr create` from the task branch: title from the issue, body is `Closes #<n>` plus a link to the evidence comment — the issue holds the report; the PR links it rather than duplicating it.
 - No draft PRs unless the user asks for one.
-- If required checks fail on the PR, that's implement work: hand the failures to the corrections loop, update the evidence comment, and tell the user.
+- If required checks fail on the PR, that's implement work: hand the failures to the corrections loop, update the evidence comment, and tell the user. Under `gates: 2` the standing ship word holds once checks are green again — unless the fix changed behavior, which goes back to the user (same rule as a merge conflict).
+- A direct chat change (dev-implement's no-issue path) ships on the same words: the chat request stands in for the recorded approval, the PR body carries the evidence instead of linking an issue comment, and the changelog rule applies unchanged.
 - User corrections left on the PR itself flow through the same corrections loop on the same branch — the PR updates with the push; nothing gets recreated.
 
+With `gates: 1` there is no PR: the same verifications run, then the ship word triggers the merge below directly ([runbook](references/runbook.md) has the mechanics).
+
 ## Gate 2 — the merge
 
-On the user's separate merge instruction:
+On the user's merge instruction:
 
 - Re-check that the PR head is still the revision the evidence comment names and checks are green — a branch that moved since review gets re-verified before it lands.
+- Pending `Decision:` lines exist (issue comments, or the evidence comment's `**Decision:**` line) → name them in the merge confirmation — "merging will record: …" — so the operator's word demonstrably covers them; never append on inferred consent. On the word, append each to the register dev.md names (`decisions:` knob) in its `- DD-MM-YYYY (github-username) — …` format; the register is append-only and this is its moment.
 - A merge conflict with the default branch is corrections work: update the branch, re-verify what the update touched, and the standing merge instruction holds once checks are green again — unless the update changed behavior, which goes back to the user.
-- Merge per the dev.md `merge` knob (default `gh pr merge --squash`). `Closes #<n>` closes the issue; confirm both happened.
-- If the issue carries a `Decision:` comment (the dev-intake convention), append its one dated line to the register dev.md names (`decisions:` knob) now — the register is append-only and this is its moment.
+- Merge per the dev.md `merge` knob (default `gh pr merge --squash`; `gates: 1` merges locally per the same knob and pushes). `Closes #<n>` closes the issue; confirm both happened.
+- A bot PR (Renovate, Dependabot) has no issue or evidence comment and merging it is still shipping: green checks qualify it, only the operator's explicit word — per PR or per named batch — merges it; majors and security advisories get named before their word is acted on.
+
+## After the merge — the Ship runbook
+
+Merge is not the end when dev.md has a `## Ship` section: follow its steps in order — `auto:` lines you just do, `ask:` lines wait for the operator's word, `guard:` lines are deterministic checks you run locally at their position (their CI copies are the backstop). With `release: per-merge`, the runbook is part of shipping the issue; with `release: on-request`, it runs only when the operator says "release" (covering everything merged since the last one). Report each step's outcome; a failing step — guard included — stops the sequence and goes to the operator, never skipped past. Execution detail, release batching, direct-to-main, bot PRs, and rollback: [runbook](references/runbook.md).
+
+Rollback is never a force-push: follow the Ship section's rollback line — roll forward through the normal flow. A gotcha here (a step that surprised you, an instruction the operator had to repeat) is one proposed line folded into the runbook; a directional gotcha that passes dev.md's Decisions test is a register proposal instead, on the user's yes.
 
 ## Report
 
-One short confirmation each gate: what was created or merged, the link, and anything that still needs the user (failing check, moved head, missing evidence). When a gate's condition isn't met, the answer is what's missing — the gate itself never gets skipped to be helpful.
+One short confirmation each gate: what was created or merged, the link, decisions recorded, and anything that still needs the user (failing check, failing guard, moved head, missing evidence or changelog entry). When a gate's condition isn't met, the answer is what's missing — the gate itself never gets skipped to be helpful.

package/skill/dev-ship/agents/openai.yaml

@@ -1,4 +1,4 @@
 interface:
   display_name: "dev-ship"
-  short_description: "Open the PR and merge, each on the user's word"
+  short_description: "PR, merge, and release runbook, each on the user's word"
   default_prompt: "Use $dev-ship to create the PR or merge this issue's work."

package/skill/dev-ship/references/runbook.md

@@ -0,0 +1,36 @@
+# Runbook execution
+
+How dev-ship runs a dev.md `## Ship` section and the ship situations the gates themselves don't spell out.
+
+## Line prefixes
+
+- `auto:` — do it, report the outcome.
+- `ask:` — stop and wait for the operator's word for that step; the word that opened the gate does not cover an `ask:` line.
+- `guard:` — a deterministic check. Run its command locally at this position in the runbook order; the CI copy of the same guard is the backstop and stays authoritative for anything that publishes. A failing guard stops the sequence exactly like a failing `auto:` step.
+
+A failing step stops the runbook at that step: report what failed and what remains unrun, hand the failure to the operator (or to dev-implement's corrections loop when it's code), and never skip ahead. A gotcha — a step that surprised you or an instruction the operator had to repeat — is one proposed line folded into the runbook; if the gotcha is directional rather than operational, it's a decision-register candidate instead (on the user's yes, per dev.md `## Decisions`).
+
+## Release batching (`release: on-request`)
+
+"Release" covers everything merged since the last release. Enumerate it: `git log <last-tag>..HEAD --oneline` (no tags yet → everything since the first commit). Before running the release steps, check completeness — every behavior-changing merge in that range has its changelog entry per the `changelog:` knob. A missing entry is corrections work on a fresh branch, not a reason to hand-write the release record.
+
+## Direct-to-main (`gates: 1`)
+
+The ship word authorizes: merge the task branch onto the default branch locally per the `merge:` knob, push, done — no PR object. Everything else is unchanged: the issue must be `for-operator` with its evidence comment, guards run, the changelog entry must exist. Closing the issue: with `merge: squash`, put `Closes #<n>` in the squash commit message; with any other merge style there is no new commit to carry it — after pushing, close explicitly with `gh issue close <n> --comment "merged to <default> as <sha>"`. Either way, confirm the issue actually closed. Branch protection that blocks direct pushes breaks this mode — dev-setup checks at setup time; if it bites later, tell the operator rather than working around it.
+
+## Decisions under compressed gates
+
+With `gates: 2` or `1`, the ship word arrives before decisions could be named. Pending `Decision:` lines still get their own naming: acknowledge the word, state "merging will record: …", and act on the operator's confirmation — a decision is never covered by a word that didn't name it. This costs one extra exchange only when decisions are pending. A PR closed without merging hands its pending `Decision:` lines back to the operator (they may stand independently of the implementation's fate) — they are never silently dropped.
+
+## Bot PRs (Renovate, Dependabot, …)
+
+A bot PR has no issue, no brief, no evidence comment — and merging it is still shipping. Green checks qualify it; only the operator's explicit word merges it, per PR or per an explicitly named batch ("merge this Renovate batch"). No standing approval exists: a knob, a schedule, or past practice never merges a bot PR. Red-flag updates (majors, security advisories) get named to the operator before their merge word is acted on.
+
+## Rollback and hotfix
+
+- Rollback is never a force-push or history rewrite. Follow the Ship section's rollback line — the shape is always roll-forward: revert or fix on the default branch through the normal flow, release/deploy the good state as a new version.
+- A hotfix is a normal issue at higher priority: brief (short is fine), approval, implement, evidence, ship. Urgency compresses the words, never removes them.
+
+## Guard failure at ship time
+
+A local `guard:` failure (missing changelog entry, tag/version mismatch) means the branch or release prep is incomplete: route it to dev-implement's corrections loop, get the evidence comment updated, then resume at the failed step. Never edit release artifacts inline just to get past a guard.

package/skill/dev-ship/refresh/REFRESH.md

@@ -1,3 +1,3 @@
 # Refresh contract — dev-ship
 
-Evergreen: this skill asserts no version pins, vendor mechanism names beyond long-stable `gh` subcommands, numeric vendor limits, or dated facts — its content is the two-gate discipline, all versionless. Revisit if a future edit introduces a volatile fact.
+Evergreen: this skill asserts no version pins, numeric vendor limits, or dated facts — its content (SKILL.md and `references/runbook.md`) is the gate discipline and runbook-execution mechanics: long-stable `git`/`gh` subcommands only, everything else read from the project's dev.md at run time. Revisit if a future edit introduces a volatile fact.

package/skill/skill-maintainer/SKILL.md

@@ -5,7 +5,7 @@ description: Maintainer skill for the vegastack-skills repository itself. Use wh
 
 # VegaStack Skill Maintainer
 
-Maintenance skill for this repository. Every change under `skills/` must satisfy the per-skill contract and the tri-harness standards below. Obey them in your own edits; enforce them in review. When a rule here disagrees with `CONTRIBUTING.md` or `docs/policies/` at the repo root, those win — then fix this skill.
+Maintenance skill for this repository. Every change under `skills/` must satisfy the per-skill contract and the tri-harness standards below. Obey them in your own edits; enforce them in review. When a rule here disagrees with `CONTRIBUTING.md` or `.vegastack/dev.md` at the repo root, those win — then fix this skill.
 
 ## Operating rules
 
@@ -26,7 +26,7 @@ Maintenance skill for this repository. Every change under `skills/` must satisfy
 | new skill: should-it-exist gate, scaffolding, the 8-item contract audit, behavioral evals | the `skillify` skill |
 | release, rename, deprecate, rollback mechanics | [release ops](references/release-ops.md) |
 | this skill's own freshness contract | [REFRESH](refresh/REFRESH.md), [sources](refresh/sources.json) |
-| authoritative repo policy | `CONTRIBUTING.md`, `docs/policies/content-versioning.md`, `docs/policies/release-and-rollback.md` at the repo root |
+| authoritative repo policy | `CONTRIBUTING.md` and `.vegastack/dev.md` at the repo root (release runbook, content semver, rollback) |
 
 ## Workflow: scaffold a new skill
 
@@ -37,7 +37,7 @@ Maintenance skill for this repository. Every change under `skills/` must satisfy
 
 ## Workflow: update or maintain
 
-- **Content versioning.** New rules/references and new recorded decisions are MINOR; weakening a normative rule, removing or renaming a skill, or breaking a per-project profile format is MAJOR; factual refreshes (pins, URLs, checksums) are PATCH (`docs/policies/content-versioning.md`).
+- **Content versioning.** New rules/references and new recorded decisions are MINOR; weakening a normative rule, removing or renaming a skill, or breaking a per-project profile format is MAJOR — except pre-1.0 with zero deployed profile consumers, where a profile-format break may ship MINOR per a recorded decision; factual refreshes (pins, URLs, checksums) are PATCH (the content-semver bullet in `.vegastack/dev.md`; detail in [release-ops](references/release-ops.md)).
 - **Tag volatile claims.** Any sentence carrying a vendor version, mechanism name, or numeric budget gets a source marker comment mapping to an ID in that skill's `refresh/sources.json`, and the registry entry's `affected` list must name the reference it lives in. Untagged volatile facts rot silently.
 - **Description budgets.** Stay within 1024 chars and keep triggers in the first sentence: Codex truncates its skill list at 2% of the context window / 8,000 chars, Claude Code truncates a skill's always-loaded listing at 1,536 chars — the tail of a long description is the first thing lost.
 - **Packaged-file changes.** Any add/remove/rename of a packaged file must update that skill's `packages/cli/packaging.json` entry in the same PR.
@@ -48,7 +48,7 @@ Full playbook in [release ops](references/release-ops.md). Short form: a rename
 
 ## Workflow: release
 
-Changeset lands with the PR → maintainer runs `bunx changeset version`, `bun install`, commits → tags `v<version>` → tag-driven pipeline runs check, tag↔version guard, npm trusted publishing, SBOM, GitHub release. Two decoupled version identities — **package version** (npm, changesets) and **foundation version** (content contract for deployed profiles) — must never be conflated; bumping the package must never invalidate a deployed profile. Rollback is roll-forward (publish previous-good as a new patch) plus `npm deprecate` of the bad version; unpublish only within 72 hours and only in addition. Details: [release ops](references/release-ops.md).
+Changeset lands with the PR → maintainer runs `bunx changeset version`, `bun install`, commits → tags `v<version>` → tag-driven pipeline runs check, tag↔version guard, npm trusted publishing, SBOM, GitHub release. One version identity: the package version covers the installer and every bundled skill's content snapshot — there is no separate content-contract version, and bumping the package must never invalidate a deployed per-project profile. Rollback is roll-forward (publish previous-good as a new patch) plus `npm deprecate` of the bad version; unpublish only within 72 hours and only in addition. Details: [release ops](references/release-ops.md).
 
 ## Workflow: portability check
 

package/skill/skill-maintainer/references/release-ops.md

@@ -1,6 +1,6 @@
 # Release, rename, and rollback operations
 
-Condensed operational playbook. The authoritative policies live at the repo root — `docs/policies/release-and-rollback.md` and `docs/policies/content-versioning.md` — and this file must never contradict them; when in doubt, they win.
+The expanded release/rename/rollback detail behind the `## Ship` runbook and content-semver bullet in `.vegastack/dev.md` at the repo root. dev.md is the canonical process doc and wins on any disagreement; this file only elaborates it and must never contradict it.
 
 ## Semver for skill content
 
@@ -23,8 +23,8 @@ profile carries a schema version to validate against.
 
 ## Release flow (tag-driven)
 
-1. Every PR that changes released behavior lands with a changeset (`bunx changeset`) whose bump follows the table above.
-2. Maintainer, at release time: `bunx changeset version` (applies changesets to `packages/cli/package.json` and the changelog), then `bun install` so `bun.lock` does not go stale, commit. Root `CHANGELOG.md` gets a human-readable entry for every release.
+1. Every PR that changes released behavior lands with a changeset — a `.changeset/<slug>.md` written directly, since the `changeset` add prompt is interactive (`bunx changeset version` at release time is the only CLI use) — whose bump follows the table above.
+2. Maintainer, at release time: `bunx changeset version` (applies changesets to `packages/cli/package.json` and the changelog), then `bun install` so `bun.lock` does not go stale, commit. The release record is `packages/cli/CHANGELOG.md`, changesets-written — never by hand; the root `CHANGELOG.md` is the frozen pre-0.3.0 record pointing there.
 3. Tag the release commit `v<version>`, push the tag.
 4. The release workflow runs on the tag: `bun run check`, tag↔version guard, `npm publish` via trusted publishing (OIDC, token-free, provenance by default; idempotently skipped if already on the registry), SBOM, GitHub release. Never pass `--provenance` explicitly — it conflicts with trusted-publishing config.
 

package/skill/skill-maintainer/refresh/REFRESH.md

@@ -4,7 +4,7 @@ Instructions for the scheduled refresh agent (and any human running a manual ref
 
 ## What this skill claims
 
-- **Durable content** (`SKILL.md` workflows and operating rules, `references/release-ops.md`): repo process, derived from `docs/policies/*` — the refresh agent NEVER edits these. If a policy doc changes, that is a normal human PR, not a refresh.
+- **Durable content** (`SKILL.md` workflows and operating rules, `references/release-ops.md`): repo process, elaborating `.vegastack/dev.md` — the refresh agent NEVER edits these. If the process changes, that is a normal human PR, not a refresh.
 - **Volatile standards claims**: sentences marked `<!-- source: SOURCE-ID -->` inside `references/standards.md`. These carry the tri-harness standards — discovery paths, frontmatter rules, numeric context budgets, install surfaces. They are the compliance basis of every skill in this repo, so **all standards changes are semantic drift requiring a human-reviewed PR**: the agent may propose edits to marked sentences only, in the same PR as the registry update that evidences the change, and a maintainer must review before merge. The hard-limits table in `SKILL.md` mirrors several marked sentences; update it in the same PR (this is the one sanctioned SKILL.md touch, and only when a mirrored number changed).
 - **Volatile layer** (the only file the agent edits freely): `refresh/sources.json` — the source registry and staleness snapshot (checksums, retrieval times).
 

package/skill-integrity.json

@@ -24,47 +24,49 @@
     },
     "dev-implement": {
       "files": {
-        "SKILL.md": "7a3f700cb116b9ad70596851536c74794497f780b0a79626fa44658556eaa005",
+        "SKILL.md": "af85df8c37745552001110191a3954976333c7767556fe03cd1f63423e9254a9",
         "agents/openai.yaml": "1abab383deca54d32749fd9156f9a6211fe96e02e0166dc8a16ff8459ac31b74",
-        "refresh/REFRESH.md": "013d7f667e489a08bbe12768ca2093fc305113920c1e510b5e96ba335af8de48",
+        "refresh/REFRESH.md": "7b854109d897b78b3055bf1ab89517afdca65c12eb65a4d009141e3ee11cf58f",
         "refresh/sources.json": "7bd883e5b3512e236a909ad6ff20c97f3555785867c31fd728256c7c2c514c74"
       }
     },
     "dev-intake": {
       "files": {
-        "SKILL.md": "1b9bdabf2c5aae56d3511972b2800f0328ac07d91dbfa7b23ea3c76dc37ed0f3",
+        "SKILL.md": "50318e312c73220f5940110f144ce47dfa4d2191321d5ccfff23814090e689b1",
         "agents/openai.yaml": "5473d2d3efffc518c07dfa8e6788c6535a5054ceca696119c5856ad265ef5581",
-        "references/brief-template.md": "c09e6b7964ad524d5c5bad11206df200dea6ab3d72d23bb950b21a2f11b1263a",
+        "references/brief-template.md": "98662ec19bca5785a2a9b49aa070ca1d05f1317ea7cc610f913886a11efabcc8",
         "refresh/REFRESH.md": "bb5265cee98c243c775c3e5fbc59de4b84ab54e828f3290d7c19e47291d66f71",
         "refresh/sources.json": "7bd883e5b3512e236a909ad6ff20c97f3555785867c31fd728256c7c2c514c74"
       }
     },
     "dev-setup": {
       "files": {
-        "SKILL.md": "6fda960bcb0c729c5acac8edfa0e1f40b2f72178c3323f31a77c3e6cdb73b741",
-        "agents/openai.yaml": "0b53bece25736b0dfbe990c05973f06d83905bfd6314d36fe64ae23d46393941",
-        "assets/agents-section.md.template": "615b1b69a62ccca351a00cc85435fc663ad6c35a478ddcff6e1ecc777a35f342",
-        "assets/dev-profile.md.template": "6a586ff63af64098252a4910eb093db9139d66ed849a30cdb5c1af158806db6d",
-        "references/harness-facts.md": "cabecde6ad6d2a2aa16ad1f6acdb57fd47c335948e734938cb0f7fdb27e085e6",
-        "refresh/REFRESH.md": "9d5eef2ee900819120334ae9cf7dfc591d33bdeef241bbab6653c11c10ecff30",
-        "refresh/sources.json": "1c8c5ebd22472b4c88630e3f626986b0aad97da367e122c4c7cd3f9677f41948"
+        "SKILL.md": "1b7ad5c64074c8eec35313a19dd50c821fe1b14ffb8366129480c14148c082d1",
+        "agents/openai.yaml": "be790c04fdf910e71642cfadf1a7c07c217bf7fad18581610feb4c31a79651f2",
+        "assets/agents-section.md.template": "591479cd2beacd5bc80457625fb1e67bf41947f6c2df326a52f0789fa455e8ec",
+        "assets/dev-profile.md.template": "eca122d2b8816728243eb40f8d7f41e4a79b55a59a0b6e2ea3b5461df0bb1ee2",
+        "references/harness-facts.md": "2be1d81f6a616d40dc865aaeefaf53c61bc13ade4ba1de8fb406c520bf15be40",
+        "references/stack-playbooks.md": "112227283dc52e8c215a84b3e97ffb4e07c2b43c6567ae9cdd37985ce7740139",
+        "refresh/REFRESH.md": "debda6ab96e899dd7e38309f714e9d65a3fbc53fd8ca68b8156f1348226c87b9",
+        "refresh/sources.json": "3deab13addeff1d8c6aac17955694c914064a9eba89eb4c833163448b2351497"
       }
     },
     "dev-ship": {
       "files": {
-        "SKILL.md": "18af2ac434b0b5b7b9f04fb32b5558337234d83aa910e06c1ce463f7cf45f722",
-        "agents/openai.yaml": "4eae616fb85e1e637a73a0aec5b132c644bf9bbc33d3958525c65c8db59ca87f",
-        "refresh/REFRESH.md": "4c6b46b211604006da943604845127a1f9939cf7e5e31d941452ba02d05db7c9",
+        "SKILL.md": "2938dadc743e03a3113ae15a971e376cd72ccfc6ffca4646d80e6fc701e6c621",
+        "agents/openai.yaml": "8f18cfd505131557eb4c9f7b7f54e9069f787be4c162403fc30253eed49a06ea",
+        "references/runbook.md": "d8ca232f2abd2bd69c2dbdde0eabf22ff47841fa44036b2553a132367d04441b",
+        "refresh/REFRESH.md": "06894b54fcbde12d3b5804523f20d5544ba1a18bb5e36960caa4f98454c6203e",
         "refresh/sources.json": "7bd883e5b3512e236a909ad6ff20c97f3555785867c31fd728256c7c2c514c74"
       }
     },
     "skill-maintainer": {
       "files": {
-        "SKILL.md": "d0ee972f67301fcb65973496a5d3f328866f78b8a68aaa528dc1a6a2c229a30f",
+        "SKILL.md": "0947155a4e7c87d6f200a1e565013beac8e3093b17e3216d6901a20be863bb21",
         "agents/openai.yaml": "0b89d4e6416cf20b448f5322f3d7433cfde333d2b4a05b42ed53db3759701fb4",
-        "references/release-ops.md": "710a2cd61269106e49623dde970f89026915f99910b6a87dfb377f448fef7dd0",
+        "references/release-ops.md": "9fe9a09c37c803c3c9a6cfb3f41a523c365fa09b4a30fb431db7af14f03ed7b3",
         "references/standards.md": "3646d0dd0560a87b333f70febf670b093c89b35111132cdb641b763bf184b02f",
-        "refresh/REFRESH.md": "7f355694ca24a9bb12f4044570559383cea60680921f476cafd5441ec869f91e",
+        "refresh/REFRESH.md": "3955bff5f0a14c83336a73cdbd07ba18d9398996934af87fac4454206cd14023",
         "refresh/sources.json": "cf38cdf8123a50ea7ef2d1466a87faa648c12e5bc90d9ee9b6ae45632e7d0800"
       }
     },