hstack 0.7.0 → 0.16.0

package/template/.claude/skills/hstack-app-architecture/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-app-architecture
-description: |
-  Use this skill when the engineer wants to produce or refresh `hstack/context/app-architecture.md` — the five-section internal-architecture design (Module Map, Agent Orchestration, Deterministic-vs-LLM Split, State Ownership, Surface Boundaries). The Skill is Phase 3 of `/hstack:greenfield-init`, the app-architecture step of `/hstack:brownfield-init`, or a standalone atom for refreshing a single section. At terminal state the atom auto-scaffolds `hstack/specs/<module>/spec.md` stubs at `status: draft` for each declared module and updates `hstack/config.yaml`'s `surfaces` enum to match Section 5. Examples:
-
-  <example>
-  Context: Phase 3 of greenfield-init opens after data-architecture is current.
-  user: "/hstack:app-architecture"
-  assistant: "Loading product-brief, data-architecture, vision, mvp-scope. Stack-agnostic interview — I won't ask about frameworks here; that's Phase 4. Section 3 (Deterministic-vs-LLM Split) is the load-bearing AI-native decision: per user-facing flow, what's code and what's prompt, with rationale tied to a measurable property."
-  <commentary>
-  Internal architecture is stack-agnostic by design. Section 3 is where AI-native teams most often get architecture wrong by leaving the LLM/code split implicit. The atom forces per-step declaration.
-  </commentary>
-  </example>
-
-  <example>
-  Context: A brownfield repo's modules have evolved; the engineer wants the artifact refreshed against current code.
-  user: "/hstack:app-architecture --mode extract"
-  assistant: "Extract mode. Scanning src/, app/, lib/ via Glob; reading exports and dependencies. Proposing the Module Map from code-evidence. The drift challenge runs at the end of Section 1: does any module own state a persona never interacts with?"
-  <commentary>
-  Extract mode reads code-evidence to propose modules; the engineer confirms or revises. The orphan-module challenge catches modules that have grown beyond their persona-named purpose.
-  </commentary>
-  </example>
+description: Use to produce or refresh `hstack/context/app-architecture.md` — module map, agent orchestration, deterministic-vs-LLM split, state ownership, surface boundaries. Greenfield Phase 3, the brownfield app-architecture step, or a standalone section refresh.
 tools:
   - Read
   - Write
@@ -28,7 +9,7 @@ tools:
   - Glob
   - Bash
   - Task
-  - "{{TODO-SCRIPT: hstack/scripts/validate-spec.ts — frontmatter validator}}"
+  - "node hstack/scripts/validate-spec.mjs — frontmatter validator"
 ---
 
 ## Purpose
@@ -99,11 +80,3 @@ tools:
 
 - **Subagent unreachable.** Persist session state; retry later.
 - **Terminal-state side-effect commit fails partway** (e.g., one stub fails validator). The atom rolls back the in-progress write and halts with the validator error; the engineer fixes or routes through `/hstack:configure`. The artifact stays at `current` only when ALL three side effects land successfully.
-
-## Anti-patterns
-
-- Never name frameworks, ORMs, hosting providers, or specific runtimes in the artifact body or frontmatter. Stack-agnostic is load-bearing for portability across Phase 4 stack decisions.
-- Never write authored content into module-spec stubs. Headers + `status: draft` + body note only.
-- Never let Section 3's per-step declaration collapse to "the AI handles it end-to-end." Each step is named with mechanism + measurable-property rationale.
-- Never bypass the end-of-atom coherence check on section-targeted re-entry.
-- Never write surfaces into `hstack/config.yaml` outside the terminal-state atomic commit.

package/template/.claude/skills/hstack-branch/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-branch
-description: |
-  Use this skill when the engineer needs to check out or create the conventional `change/<change-id>` branch for a specific change-spec — typically because they realized mid-flow that they're on the wrong branch, or because they declined the branch offer at `/hstack:change-new` and want to switch later. One-shot, single-purpose, no subagent invoked. Examples:
-
-  <example>
-  Context: The engineer scaffolded the billing-overage change earlier, declined the branch offer at the time, and has since drafted the spec and ui-brief on main. Now they want to switch before implementing.
-  user: "/hstack:branch 2026-05-billing-overage-warning"
-  assistant: "I'll check whether `change/2026-05-billing-overage-warning` already exists. If yes, check out. If no, create from the current branch and check out. Any uncommitted work is preserved."
-  <commentary>
-  Idempotent: existing branch → checkout; missing branch → create-and-checkout. The Skill never force-deletes, never resets, never loses local work. If there are uncommitted changes that conflict with the target branch, the engineer is warned before the switch.
-  </commentary>
-  </example>
-
-  <example>
-  Context: The engineer wants the branch for whatever the most recently scaffolded change is and doesn't want to type the id.
-  user: "/hstack:branch"
-  assistant: "No id given. I'll detect the most recently scaffolded in-flight change-spec from hstack/specs/changes/, propose its expected branch name, and ask for confirmation before checking out."
-  <commentary>
-  No-arg mode defaults to the latest in-flight change for convenience. The Skill confirms before acting — the default is a guess, not a command.
-  </commentary>
-  </example>
+description: Use to check out or create the conventional `change/<change-id>` branch for a change-spec — when the branch offer at change-new was declined, or you are on the wrong branch. No argument defaults to the latest in-flight change.
 tools:
   - Bash
   - Read
@@ -68,7 +49,8 @@ Before any work:
 
 ## Outputs
 
-- A git branch checkout (existing) or create-and-checkout (new). No artifact writes. No commits.
+- A git branch checkout (existing) or create-and-checkout (new). No artifact writes, no commits, and no push — pushing is hard to reverse and stays the engineer's explicit call.
+- No branch deletion. Cleaning up obsolete `change/*` branches is post-ship hygiene, outside this Skill's domain.
 
 ## Auto-commit triggers
 
@@ -84,7 +66,7 @@ None. Branch operations do not create commits.
 Beyond the kernel's general stop conditions:
 
 - The named `<change-id>` does not correspond to an existing change-spec.
-- The working tree has uncommitted changes that would be lost or conflict on switch. Halt and ask: "Uncommitted changes detected — stash, commit, or discard before switching?" (recommend `/hstack:commit` for the commit path; never auto-stash; never auto-discard).
+- The working tree has uncommitted changes that would be lost or conflict on switch. Halt and ask: "Uncommitted changes detected — stash, commit, or discard before switching?" (recommend `/hstack:commit` for the commit path; never auto-stash, and never discard via `git checkout -- <files>` or any other path-discarding form — stash policy is the engineer's call).
 - The engineer requested a `<base-branch>` that does not exist.
 - The current branch is already the target branch — exit cleanly with the no-op message.
 
@@ -92,12 +74,3 @@ Beyond the kernel's general stop conditions:
 
 - **`git checkout` fails due to conflicting local changes.** Surface the git error; do not retry. The engineer resolves manually.
 - **Branch name collision with an unrelated existing branch.** If `change/<change-id>` exists but points at unrelated history (someone created it manually for another purpose), warn the engineer; do not silently overwrite. Engineer renames the unrelated branch or uses `--from` to specify their intent.
-
-## Anti-patterns
-
-- Never use `git checkout -B` (force-create). Use `git checkout -b` (create or fail) and let the engineer resolve collisions.
-- Never auto-stash. Stash policy is the engineer's call.
-- Never `git checkout -- <files>` or any path-discarding form.
-- Never force-delete a branch. Cleanup of obsolete `change/*` branches is post-ship hygiene, not this Skill's domain.
-- Never push the new branch automatically. Push is hard-to-reverse; the engineer pushes when ready.
-- Never branch from anywhere other than the configured default (typically `main`) unless `--from` is explicit. The kernel's branching convention starts every change from `main`.

package/template/.claude/skills/hstack-brownfield-init/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-brownfield-init
-description: |
-  Use this skill when an engineer is adopting hstack on an **existing repository** (one with source code, documentation, or some product context already in place) and needs to produce `hstack/config.yaml` and populate every required document under `hstack/context/`. For empty repositories (no source yet), use `/hstack:greenfield-init` instead — that orchestrator composes the discovery atoms in elicit mode and ends with `/hstack:scaffold`. Until brownfield-init completes, no other hstack Skill works; every workflow Skill checks for init completion at session start and halts otherwise. Init is structured as discrete mini-sessions of ten-to-fifteen minutes each rather than one long block, so that an interruption costs at most one in-flight field. Mini-sessions for data and app architecture **delegate to the standalone atoms** (`/hstack:data-architecture`, `/hstack:app-architecture`), which can also be re-run later via `/hstack:configure` for enrichment when `/hstack:help` flags a layer as missing. Examples:
-
-  <example>
-  Context: A six-month-old codebase has thin docs and no hstack/. The engineer wants to adopt hstack against the existing source.
-  user: "Start /hstack:brownfield-init on this repo."
-  assistant: "I'll read CLAUDE.md, README, package.json, and the source tree to seed proposals. Then mini-session 0 (config), product context via product-manager (vision, glossary, mvp-scope, personas) reading existing docs in extract+confirm mode. For data-architecture and app-architecture I'll delegate to the standalone atoms running in extract mode against the live schema and src/ tree."
-  <commentary>
-  Brownfield init's distinct mode is extract+confirm against existing sources. Where source docs are thin, the engineer can opt into running /hstack:product-discovery as a follow-up enrichment step after init completes.
-  </commentary>
-  </example>
-
-  <example>
-  Context: Init was started two days ago, three documents were committed, and a session crash dropped the fourth. The engineer wants to resume rather than restart.
-  user: "Resume /hstack:brownfield-init — vision, glossary, and mvp-scope are already done."
-  assistant: "I'll read hstack/.session-state/<session-id>.yaml, confirm which documents are at status `current`, and resume with the next missing one — personas, based on what I see on disk."
-  <commentary>
-  Idempotency is load-bearing here: the Skill reads disk state, recognizes which documents are already terminal, and continues at the next empty mini-session boundary rather than re-running completed interviews.
-  </commentary>
-  </example>
+description: Use to adopt hstack on an existing repository that already has source code or product docs, producing `hstack/config.yaml` and the `hstack/context/` layer by extracting from what is there. Empty repositories use `/hstack:greenfield-init` instead.
 tools:
   - Read
   - Write
@@ -28,7 +9,7 @@ tools:
   - Glob
   - Bash
   - Task
-  - "{{TODO-SCRIPT: hstack/scripts/validate-spec.ts — frontmatter validator run after every confirmed field write}}"
+  - "node hstack/scripts/validate-spec.mjs — frontmatter validator run after every confirmed field write"
   - "{{TODO-SCRIPT: hstack/scripts/init-detect-mcps.sh — probes the consuming repo's Claude Code config for available MCPs and writes hstack/context/mcp-status.md}}"
 ---
 
@@ -50,8 +31,8 @@ Invoke when the consuming repo has no `hstack/config.yaml`, or when `hstack/conf
 Before any work:
 
 - Verify `hstack/` directory exists at the repo root. If not, halt and ask the engineer to confirm they are in the right directory.
-- Read `hstack/CLAUDE.md` (kernel) and `hstack/templates/` — both must be present. If either is missing, halt and ask the engineer to install or restore the hstack source. **The kernel describes the framework, not the consuming repo's product.** Treat it as behavioral rules, never as content to be configured.
-- **Load the consuming-repo context layer.** Read every artifact in the consuming repo (the working directory, NOT `hstack/`) that hints at its product, stack, or design system: `CLAUDE.md`, `README.md`, `package.json`, `docs/` if present, `.claude/agents/` and `.claude/skills/` for sibling tooling. This is the product being configured. Every interview prompt below frames against THIS context, not against `hstack/CLAUDE.md`.
+- Read `hstack/KERNEL.md` (kernel) and `hstack/templates/` — both must be present. If either is missing, halt and ask the engineer to install or restore the hstack source. **The kernel describes the framework, not the consuming repo's product.** Treat it as behavioral rules, never as content to be configured.
+- **Load the consuming-repo context layer.** Read every artifact in the consuming repo (the working directory, NOT `hstack/`) that hints at its product, stack, or design system: `CLAUDE.md`, `README.md`, `package.json`, `docs/` if present, `.claude/agents/` and `.claude/skills/` for sibling tooling. This is the product being configured. Every interview prompt below frames against THIS context, not against `hstack/KERNEL.md`.
 - Probe Claude Code's MCP configuration for the consuming repo and write a draft `hstack/context/mcp-status.md` listing which MCPs are wired (Notion, Linear, GitHub, Figma, Supabase) and which are absent. Run `{{TODO-SCRIPT: hstack/scripts/init-detect-mcps.sh}}` for this; if absent, the Skill produces the file by interviewing the engineer instead.
 - If `hstack/.session-state/` contains a prior init session-state file, read it and confirm with the engineer that resumption is the intent.
 
@@ -59,7 +40,7 @@ If the engineer signals "start fresh, abandon the prior partial init," archive t
 
 ## Orchestration steps
 
-Init is split into discrete mini-sessions, each commitable independently. The order is fixed because later documents reference earlier ones.
+Init is split into discrete mini-sessions, each commitable independently — that structure IS the resumability contract, so it is never collapsed into one long block. The order is fixed because later documents reference earlier ones.
 
 1. **Mini-session 0 — config skeleton.** Every prompt in this mini-session is about THE CONSUMING REPO (not about hstack itself). Interview the engineer for:
    - **Story store** for this repo's user stories — Notion DB, Linear, GitHub Issues, or `hstack/stories/`.
@@ -76,11 +57,11 @@ Init is split into discrete mini-sessions, each commitable independently. The or
 
    Write `hstack/config.yaml` with `schemaVersion: 1`. The `init-status` field starts at `minimal-complete` after this mini-session ends, advancing to `complete` only when every required context document is at `current`. Commit.
 
-2. **Mini-session 1 — vision.** Invoke `product-manager` via the Task tool with `subagent_type: product-manager` and context = [`hstack/CLAUDE.md`, `hstack/templates/vision.md`, any pointer the engineer offers to an existing vision source]. The subagent walks the five vision sections, confirms each, writes `hstack/context/vision.md` at `status: drafted` and advances to `current` at the end. Prompt cleanup of the source per the subagent's contract. Commit.
+2. **Mini-session 1 — vision.** Invoke `product-manager` via the Task tool with `subagent_type: product-manager` and context = [`hstack/KERNEL.md`, `hstack/templates/vision.md`, any pointer the engineer offers to an existing vision source]. The subagent walks the five vision sections, confirms each, writes `hstack/context/vision.md` at `status: drafted` and advances to `current` at the end. Prompt cleanup of the source per the subagent's contract. Commit.
 
 3. **Mini-session 2 — glossary.** Same orchestration with `hstack/templates/glossary.md`. Output: `hstack/context/glossary.md` at `current`. Commit.
 
-4. **Mini-session 3 — mvp-scope.** Same orchestration with `hstack/templates/mvp-scope.md`. Output: `hstack/context/mvp-scope.md` at `current`. Commit.
+4. **Mini-session 3 — roadmap.** Same orchestration with `hstack/templates/roadmap.md`. Output: `hstack/context/roadmap.md` at `current`. When a legacy `mvp-scope.md` exists, `product-manager` offers the extract+confirm conversion (In MVP → Now, v2 → Next, Deferred → Later or Not on the path) and prompts deletion of the legacy file after the roadmap lands. Commit.
 
 5. **Mini-session 4 — personas.** For each persona the engineer names, the `product-manager` subagent runs a persona sub-interview against `hstack/templates/persona.md`, including the challenge prompt "What is this persona explicitly not?" Personas are written to the configured store (typically `hstack/context/personas/<slug>.md`). Commit after each persona individually so partial completion is durable.
 
@@ -90,13 +71,13 @@ Init is split into discrete mini-sessions, each commitable independently. The or
 
 8. **Mini-session 5b — app-architecture (delegated).** The Skill invokes `/hstack:app-architecture --mode extract`. The `app-architect` agent scans `src/`, `app/`, or `lib/` via Glob, reads each module's exports and dependencies, and proposes the Module Map plus the four downstream sections (Agent Orchestration Model, Deterministic-vs-LLM Split, State-Ownership Map, Surface Boundaries). At terminal state the atom auto-scaffolds `hstack/specs/<module>/spec.md` stubs at `status: draft`; subsequent `/hstack:module-spec <module>` invocations reverse-engineer the stubs to `current`. Output: `hstack/context/app-architecture.md` at `current` plus one stub per module. Commit.
 
-7. **Mini-session 6 — infrastructure.** Invoke `spec-author` via the Task tool with `subagent_type: spec-author` and context = [`hstack/CLAUDE.md`, `hstack/templates/infrastructure.md`, `hstack/context/tech-stack.md`, `hstack/context/ci-cd.md`, `hstack/context/data-architecture.md`, any existing infra source the engineer points to — cloud console screenshots, Terraform / Pulumi / CDK files, GitHub Actions YAML, Dockerfile, supabase config]. The subagent walks every H2 section of the template via interview, biasing toward grounded truth-gathering rather than aspirational design. **For engineers unfamiliar with infrastructure concepts, the subagent is expected to explain each section's intent before asking, and to spawn the `researcher` subagent for unfamiliar terms (e.g., "what is point-in-time recovery?", "what does a CDN actually do?") rather than asking the engineer to guess.** This mini-session is interview-heavy and often the longest of init for pre-prod teams. Output: `hstack/context/infrastructure.md` at `current`. The Blast-Radius Matrix must have at least one row before status advances to `current` (INF-03); the Unknowns section must be present even when empty (INF-02). Honest "we don't have this yet" answers are explicitly preferred over fabricated content; the resulting gaps land as tech-debt items in the Known Gaps section. Commit.
+7. **Mini-session 6 — infrastructure.** Invoke `spec-author` via the Task tool with `subagent_type: spec-author` and context = [`hstack/KERNEL.md`, `hstack/templates/infrastructure.md`, `hstack/context/tech-stack.md`, `hstack/context/ci-cd.md`, `hstack/context/data-architecture.md`, any existing infra source the engineer points to — cloud console screenshots, Terraform / Pulumi / CDK files, GitHub Actions YAML, Dockerfile, supabase config]. The subagent walks every H2 section of the template via interview, biasing toward grounded truth-gathering rather than aspirational design. **For engineers unfamiliar with infrastructure concepts, the subagent is expected to explain each section's intent before asking, and to spawn the `researcher` subagent for unfamiliar terms (e.g., "what is point-in-time recovery?", "what does a CDN actually do?") rather than asking the engineer to guess.** This mini-session is interview-heavy and often the longest of init for pre-prod teams. Output: `hstack/context/infrastructure.md` at `current`. The Blast-Radius Matrix must have at least one row before status advances to `current` (INF-03); the Unknowns section must be present even when empty (INF-02). Honest "we don't have this yet" answers are explicitly preferred over fabricated content; the resulting gaps land as tech-debt items in the Known Gaps section. Commit.
 
 8. **Mini-session 7 — threat-model, hardening-checklist, incident-runbook.** The security-context triplet. By this point `infrastructure.md` is at `current`, so the security-reviewer has the operational ground truth it needs to model threats accurately. Author orchestration is per-document:
    - `threat-model.md` and `hardening-checklist.md` are authored by `security-reviewer` via the Task tool with `subagent_type: security-reviewer`. The same subagent that scores per-change security-reviews at change time also authors the slow-changing policy these reviews score against — different cadence, same security framing (bias toward CONCERNS, challenge-driven prompts). Generalist subagents (spec-author, product-manager) are NOT offered here; the security-specific framing is load-bearing.
    - `incident-runbook.md` is authored by `spec-author` from a founder-style interview — kill switches, revocation flows, comms templates are operational content, not threat-modeling.
 
-   `incident-runbook.md` is written with `git-ignored: true` in its frontmatter; the Skill verifies an entry exists in the repo's `.gitignore` before proceeding (creating the entry with confirmation if absent). The Skill warns the engineer at the start of this mini-session that incident-runbook content will not be committed to git and will need an out-of-band sync target named in `hstack/config.yaml`. Commit each context file as it lands.
+   `incident-runbook.md` is written with `git-ignored: true` in its frontmatter; the Skill verifies an entry exists in the repo's `.gitignore` before proceeding (creating the entry with confirmation if absent). The Skill warns the engineer at the start of this mini-session that incident-runbook content will not be committed to git and will need an out-of-band sync target named in `hstack/config.yaml`. Its contents are sensitive: confirm them in summary form rather than pasting them verbatim into the conversation transcript. Commit each context file as it lands.
 
 The Skill maintains `hstack/.session-state/<session-id>.yaml` continuously, updating after every confirmed field write. The state file captures which mini-session is in progress, which fields within it are confirmed, and what the next prompt should be.
 
@@ -105,7 +86,7 @@ The Skill maintains `hstack/.session-state/<session-id>.yaml` continuously, upda
 - `hstack/config.yaml` (status field on the config carries `init-status: minimal-complete` once mini-session 0 ends, advancing to `complete` only when every required context document is at `current`).
 - `hstack/context/vision.md` at `current`.
 - `hstack/context/glossary.md` at `current`.
-- `hstack/context/mvp-scope.md` at `current`.
+- `hstack/context/roadmap.md` at `current`.
 - `hstack/context/personas/<slug>.md` per persona, or sync stubs when the store is Notion / Linear.
 - `hstack/context/tech-stack.md`, `ci-cd.md`, `infrastructure.md`, `threat-model.md`, `hardening-checklist.md` — all at `current`.
 - `hstack/context/data-architecture.md` at `current` (produced by the delegated `/hstack:data-architecture` atom, five-section structure).
@@ -148,11 +129,3 @@ Beyond the kernel's general stop conditions, this Skill halts when:
 - **Subagent unreachable mid-mini-session.** Persist current state; instruct the engineer to retry in a moment.
 - **Notion/Linear/GitHub MCP unreachable but configured as the story store.** Halt and ask the engineer to wire it; do not silently fall back to `hstack/stories/`.
 - **`.gitignore` write refused.** The Skill cannot proceed past mini-session 7's incident-runbook step without it. Halt and surface the issue.
-
-## Anti-patterns
-
-- Never write `hstack/config.yaml` silently from inferred defaults. Every field passes through the engineer's confirmation gate via the `product-manager` subagent.
-- Never collapse the eight mini-sessions into one long block. The mini-session structure is the resumability contract.
-- Never advance `init-status: complete` while any required context document is below `current`.
-- Never write `incident-runbook.md` content to the conversation transcript more than necessary; the file's contents are sensitive and should be confirmed in summary form rather than pasted verbatim.
-- Never re-interview a completed mini-session on resume. Read the disk; trust the prior commit.

package/template/.claude/skills/hstack-change-new/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-change-new
-description: |
-  Use this skill when an engineer wants to start a new change and needs the `hstack/specs/changes/<id>/` folder scaffolded with templates pre-populated, before any spec-author or planner work begins. The Skill validates that the affected module has a current module-spec, derives the change id from the area and slug, scaffolds the folder, and seeds `spec.md` with the canonical template. Examples:
-
-  <example>
-  Context: The engineer is about to start work on the billing overage warning feature and needs the change folder before drafting the spec.
-  user: "/hstack:change-new billing overage-warning"
-  assistant: "I'll scaffold hstack/specs/changes/2026-05-billing-overage-warning/ with spec.md pre-populated from the template. spec-author runs separately when you're ready to fill the fields."
-  <commentary>
-  This Skill does not author content; it produces the empty folder shape so spec-author has a target to write into. Scaffold-only separation keeps the Skill cheap to re-run and idempotent on partial state.
-  </commentary>
-  </example>
-
-  <example>
-  Context: The engineer tries to scaffold a change in an area that has no module-spec yet.
-  user: "/hstack:change-new playbook-runner inline-mode"
-  assistant: "I'll halt — there's no hstack/specs/playbook-runner/spec.md at status current. Run /hstack:module-spec playbook-runner first."
-  <commentary>
-  Scaffolding refuses when the module's baseline doesn't exist. This is a deliberate gate: a change-spec whose `area` points at a nonexistent module-spec fails SP-01 anyway, so the Skill halts before any folder is created rather than producing dead scaffolding.
-  </commentary>
-  </example>
+description: Use to scaffold the `hstack/specs/changes/<id>/` folder and seed `spec.md` from the template at the start of a new change. Scaffolds only — `spec-author` fills the fields, and `/hstack:change-plan` sequences phases much later.
 tools:
   - Read
   - Write
@@ -27,7 +8,7 @@ tools:
   - Grep
   - Glob
   - Bash
-  - "{{TODO-SCRIPT: hstack/scripts/validate-spec.ts — validates the seeded change-spec frontmatter}}"
+  - "node hstack/scripts/validate-spec.mjs — validates the seeded change-spec frontmatter"
 ---
 
 ## Purpose
@@ -64,7 +45,7 @@ Before any work:
 
 4. **Forward-reference reconciliation for `enables` chains.** Grep every existing `hstack/specs/changes/*/spec.md` for the new `<id>` in `enables:` arrays. For each match: the matched (upstream) spec already declares this new (downstream) spec as a Category-B enabler. Per SP-14, write the reciprocal `enabled-by: [<upstream-id>, ...]` array on the newly-seeded spec in the same scaffold commit (this is the atomic-pair guarantee — both halves land together). When no match exists, leave `enabled-by: []`. Read-only on the upstream spec — its `enables` array was already written when the upstream was authored; no edit there. This is a mechanical operation per the kernel's Mechanical-operations section; no subagent is invoked. Surface the reconciliation to the engineer: "Detected upstream spec(s) declaring `enables: [<id>]` — populating `enabled-by` reciprocally."
 
-5. **Validate.** Run `{{TODO-SCRIPT: hstack/scripts/validate-spec.ts}}` against the seeded file. Validation at `status: draft` is permissive — empty arrays and empty prose are allowed at draft — but the universal floor (FM-01) must pass.
+5. **Validate.** Run `node hstack/scripts/validate-spec.mjs <path>` against the seeded file. Validation at `status: draft` is permissive — empty arrays and empty prose are allowed at draft — but the universal floor (FM-01) must pass.
 
 6. **Offer branch creation.** Run `git branch --show-current`. If the current branch is `main` (or the configured default), ask the engineer: "You're on `<current-branch>`. Convention is one branch per change-spec — create `change/<id>` from here and check out before the scaffold commits? [Y/n/type-different-name]". Default Yes. On confirmation, run `git checkout -b change/<id>` BEFORE step 7 so the scaffold commit lands on the correct branch from the start. If the engineer declines or names a different branch, honor the choice and continue on the chosen branch. If the current branch is anything other than the configured default (i.e., already on a feature branch), do nothing — the engineer has a deliberate branching strategy and the Skill respects it.
 
@@ -77,7 +58,7 @@ The Skill does not invoke any subagent. Scaffolding is mechanical and the engine
 ## Outputs
 
 - New directory `hstack/specs/changes/<id>/`.
-- New file `hstack/specs/changes/<id>/spec.md` at `status: draft`, with frontmatter populated to the floor and prose sections empty.
+- New file `hstack/specs/changes/<id>/spec.md` at `status: draft`, with frontmatter populated to the floor and prose sections empty. Every subsequent status transition is owned by the authoring subagents, never by this Skill.
 
 ## Auto-commit triggers
 
@@ -101,11 +82,3 @@ Beyond the kernel's general stop conditions:
 
 - **Validator fails on the seeded spec.** The template itself is broken — halt and surface as a hstack installation issue.
 - **`git config user.name` returns empty and `hstack/config.yaml` has no default owner.** Halt and ask the engineer for their owner handle.
-
-## Anti-patterns
-
-- Never write prose content into the seeded `spec.md` beyond the template's existing prompts. The Skill scaffolds; `spec-author` authors.
-- Never derive the id from anything other than the current month, the area, and the slug. Hand-rolled ids break the kebab-case + chronological-prefix convention that other Skills depend on.
-- Never scaffold under an area whose module-spec is absent. The precondition is hard.
-- Never modify an existing change folder. Reruns are no-ops or refusals, never overwrites.
-- Never advance `status` past `draft` from this Skill. Subsequent transitions are owned by the authoring subagents.

package/template/.claude/skills/hstack-change-plan/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-change-plan
-description: |
-  Use this skill when a change-spec is at `status: ready-to-plan` (with its conditional upstream artifacts also at terminal status) and needs `plan.md` drafted as atomic phases. The Skill orchestrates the `planner` subagent. Examples:
-
-  <example>
-  Context: The billing-overage change-spec is at ready-to-plan, the ui-brief is drafted, the figma-handoff is ready, and the engineer is about to start implementation.
-  user: "/hstack:change-plan 2026-05-billing-overage-warning"
-  assistant: "I'll invoke planner with the change-spec, ui-brief, figma-handoff. Atomic phases with per-phase verifier expectations and a rollback strategy."
-  <commentary>
-  The planner is the only authoring path for plan.md. The Skill enforces that upstream conditional artifacts (ui-brief, figma-handoff for ui; data-review for db) are at terminal status before invoking — otherwise the planner halts.
-  </commentary>
-  </example>
-
-  <example>
-  Context: A change touching ui and db is at ready-to-plan but data-review has not been run yet.
-  user: "/hstack:change-plan 2026-06-knowledge-citations"
-  assistant: "I'll halt — surfaces includes db and data-review.md is missing. Run /hstack:data-review first."
-  <commentary>
-  The conditional upstream gate is hard. Skipping the data-review and producing a plan against an unscored data layer produces a plan that the implementer would refuse to act on anyway.
-  </commentary>
-  </example>
+description: Use when a change-spec is at `ready-to-plan` with `test-plan.md` and every conditional upstream artifact terminal, and needs `plan.md` decomposed into atomic phases. Distinct from `/hstack:change-new`, which only scaffolds the folder.
 tools:
   - Read
   - Write
@@ -28,7 +9,7 @@ tools:
   - Glob
   - Bash
   - Task
-  - "{{TODO-SCRIPT: hstack/scripts/validate-spec.ts — validates plan frontmatter and PL-01..PL-05}}"
+  - "node hstack/scripts/validate-spec.mjs — validates plan frontmatter and PL-01..PL-05"
 ---
 
 ## Purpose
@@ -39,6 +20,12 @@ tools:
 
 Invoke when the change-spec reaches `status: ready-to-plan`, `test-plan.md` is at terminal status, and any conditional upstream artifacts required by the spec's `surfaces` are at terminal status. Re-invoke when the change-spec, the test-plan, or any conditional upstream artifact changes shape in ways that invalidate the existing plan.
 
+When not to invoke — the conditional upstream gate is hard, and each miss has one remedy:
+
+- `surfaces` includes `db` and `data-review.md` is missing or non-terminal → halt; run `/hstack:data-review <change-id>` first. Planning against an unscored data layer produces a plan the implementer would refuse to act on anyway.
+- `surfaces` includes `ui` and `ui-brief.md` is not at `drafted` or `figma-handoff.md` is not at `ready` → halt; run `/hstack:ui-brief <change-id>` and get the handoff from the cofounder first.
+- `test-plan.md` is missing or non-terminal → halt; run `/hstack:test-plan <change-id>` first.
+
 ## Inputs
 
 - `<change-id>` (required, positional): the change-spec id.
@@ -54,12 +41,13 @@ Before any work:
 - When `surfaces` includes `db`: verify `data-review.md` at `status: passed` or `concerns-acknowledged`. Halt otherwise.
 - Verify the relevant module-spec at `status: current`.
 - Read `hstack/context/tech-stack.md` (loaded by `planner` for pinned runtime constraints).
+- Read `hstack/context/roadmap.md` for the plan's Roadmap Alignment line. Advisory, never a precondition: missing or stale (`status` ≠ `current`, or `updated` > 90 days) yields `n/a — roadmap stale/missing (<detail>)` in that line — no halt.
 
 The security-review is not a planner precondition — security-review and the plan can be produced in either order, since neither depends on the other's content (the implementer reads both at session start). The test-plan, by contrast, IS a planner precondition: the planner's phase ordering and per-phase Test Strategy entries reference test-plan sections, so the test-plan must already be terminal.
 
 ## Orchestration steps
 
-1. **Invoke `planner`.** Use the Task tool with `subagent_type: planner` and context = [kernel, `hstack/templates/plan.md`, change-spec, test-plan, ui-brief and figma-handoff if applicable, data-review if applicable, module-spec, tech-stack]. The subagent walks the four plan sections — Phase Overview, Per-Phase Detail, Cross-Phase Risks, Rollback. Per-phase Test Strategy entries point at test-plan sections rather than re-stating tests inline.
+1. **Invoke `planner`.** Use the Task tool with `subagent_type: planner` and context = [kernel, `hstack/templates/plan.md`, change-spec, test-plan, ui-brief and figma-handoff if applicable, data-review if applicable, module-spec, tech-stack, roadmap when present]. The subagent walks the five plan sections — Roadmap Alignment (one honest line, per the planner contract: information for the human, never a gate), Phase Overview, Per-Phase Detail, Cross-Phase Risks, Rollback. Per-phase Test Strategy entries point at test-plan sections rather than re-stating tests inline.
 
 2. **Phase decomposition.** Per the `planner` contract, typical plans hold 4–8 phases; > 12 phases requires an `oversized-plan-justification` frontmatter field. Each phase has a `step-id`, one-line summary, `depends-on` list, Files Touched (subset of `change-spec.in-scope`), Test Strategy, Risk sentence, and Verifier Expectations.
 
@@ -71,7 +59,7 @@ The security-review is not a planner precondition — security-review and the pl
 
 6. **Leave `steps-completed: []`.** Per architecture amendment A3 and the planner's contract, `steps-completed` is owned by the implementer; the planner never populates it.
 
-7. **Validate.** Run `{{TODO-SCRIPT: hstack/scripts/validate-spec.ts}}` — PL-01 (parent-change matches), PL-02 (phase count), PL-03 (steps-completed entries match plan phase ids), PL-04 (Files Touched is subset of in-scope), PL-05 (status advance gating).
+7. **Validate.** Run `node hstack/scripts/validate-spec.mjs <path>` — PL-01 (parent-change matches), PL-02 (phase count), PL-03 (steps-completed entries match plan phase ids), PL-04 (Files Touched is subset of in-scope), PL-05 (status advance gating).
 
 8. **Transition.** When the validator passes, `planner` advances status from `draft` to `ready`. Auto-commit fires.
 
@@ -84,6 +72,16 @@ The security-review is not a planner precondition — security-review and the pl
 - Status transition to `draft` after the Phase Overview table lands.
 - Status transition to `ready` at end of authoring. Commit message: `plan(<change-id>): ready`.
 
+## Session boundary
+
+`change-plan` is a natural session cut: the auto-commit above left `plan.md` on disk, so the conversation holds nothing the next phase needs. The cut-notice format, the kickoff-prompt template and the context-block rules are in `KERNEL.md` § Session boundaries; this Skill's two variables are:
+
+```
+HSTACK-CUT: change-plan complete — cut recommended before implement.
+```
+
+and the next command, `/hstack:implement <first-phase-id> <change-id>`.
+
 ## Idempotency contract
 
 - Re-running on an existing `ready` plan without spec changes: the subagent reads the existing plan as the proposal layer; identical re-confirmation is a no-op.
@@ -108,12 +106,3 @@ Beyond the kernel's general stop conditions:
 - **`ui-brief.md` exists at `draft` rather than `drafted`.** Halt; the brief is incomplete.
 - **Validator fails PL-04.** The planner halts immediately at the offending phase; the engineer either reshapes the phase or amends in-scope.
 - **`planner` halts on cross-phase risk surfacing an invariant gap.** Halt; the engineer amends the change-spec via `spec-author`, then re-runs this Skill.
-
-## Anti-patterns
-
-- Never write code. Plans are prose plus YAML.
-- Never silently accept a non-terminal upstream artifact.
-- Never invent invariants or modify the change-spec's Invariants section — that is `spec-author`'s domain.
-- Never write `steps-completed` values; the field belongs to the implementer.
-- Never produce a multi-phase plan with empty Cross-Phase Risks without exercising the challenge prompt.
-- Never write a rollback section with a plausible-sounding default the engineer did not endorse.

package/template/.claude/skills/hstack-commit/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-commit
-description: |
-  Use this skill when the engineer wants to commit work by hand using the same Commitizen format hstack subagents use for auto-commits — so the git log reads uniformly whether a phase landed through `/hstack:implement` or you fixed a typo manually. Pushed only on explicit confirmation. Examples:
-
-  <example>
-  Context: The engineer made a small cleanup edit between hstack workflow phases and wants to commit it without polluting the git history with a divergent message format.
-  user: "/hstack:commit"
-  assistant: "I'll read git status, walk you through which files to stage (specific paths over `-A`), show the diff, propose a Commitizen-format commit message, and commit on your confirmation. Push is a separate confirmation."
-  <commentary>
-  The Skill is for human-driven commits outside the hstack subagent flow. It's not used by subagents — they have their own auto-commit logic embedded in their session-start protocols. The format match is the value: same git log shape whether the commit came from an agent or a human.
-  </commentary>
-  </example>
-
-  <example>
-  Context: A pre-commit hook fails on the first attempt and the engineer is tempted to bypass.
-  user: "The hook is failing because of an unrelated lint error. Can we just --no-verify?"
-  assistant: "No — the kernel forbids hook bypass. I'll investigate the failing hook with you, fix the underlying issue, then re-attempt the commit cleanly."
-  <commentary>
-  Defense in depth on the kernel's forbidden-tools list: the Skill refuses --no-verify and other hook-bypass flags. Same rule the implementer subagent enforces. Hooks fail for a reason; investigating beats bypassing.
-  </commentary>
-  </example>
+description: Use to commit hand-made edits in the same Commitizen format hstack subagents use for their auto-commits. For work outside a subagent flow only — subagents auto-commit at status transitions on their own.
 tools:
   - Bash
   - Read
@@ -65,7 +46,7 @@ Before any work:
 4. **Draft a Commitizen-format commit message.** Following the format codified for hstack:
    - Format: `<type>(<scope>): <summary>`
    - `<type>` is one of: `feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `style`, `perf`, `ci`
-   - `<scope>` names the area being touched. For commits inside hstack-governed code, prefer the change-id, the area, the Skill name, or the artifact type (e.g., `change-plan`, `billing`, `implement`, `data-review`). For non-hstack commits in the same repo, use the natural area (e.g., `auth`, `orchestrator`, `webhooks`).
+   - `<scope>` names the area actually touched — never an invented or aspirational one. For commits inside hstack-governed code, prefer the change-id, the area, the Skill name, or the artifact type (e.g., `change-plan`, `billing`, `implement`, `data-review`). For non-hstack commits in the same repo, use the natural area (e.g., `auth`, `orchestrator`, `webhooks`). When the change spans several unrelated areas, no single honest scope exists — propose splitting into multiple commits.
    - `<summary>` ≤ 72 characters, imperative present tense ("add" not "added"), no trailing period.
    - Body (optional): the "why" rather than the "what". For commits inside hstack workflow, name the related change-id or artifact. For status transitions, name the transition explicitly.
    - **Never add "Generated with Claude Code" or similar attribution.** The user's global rule.
@@ -73,9 +54,11 @@ Before any work:
 
 5. **Confirm and commit.** Show the proposed commit message to the engineer. On confirmation, run `git commit -m "<subject>" -m "<body>"` (HEREDOC for multi-line bodies). Honor every git hook — `--no-verify`, `--no-gpg-sign`, and other bypass flags are forbidden.
 
-6. **Verify the commit landed.** Run `git log -1 --format='%h %s'` and surface the result.
+6. **Kernel rules still apply.** Committing by hand does not relax the kernel's database-workflow or forbidden-tools rules. A `service_role` key, a `supabase db push` against a remote project, or any other kernel-forbidden artifact is forbidden on this path exactly as it is on the subagent path.
 
-7. **Push (only with explicit confirmation).** Push is hard-to-reverse and visible to others — never auto-push. If `--push` was provided, ask for confirmation in the conversation; if not provided, end without pushing. When pushing, use the current branch's tracked upstream (no `--force`, no force-with-lease without per-invocation authorization, no push to `main` if the current branch is `main` without explicit confirmation).
+7. **Verify the commit landed.** Run `git log -1 --format='%h %s'` and surface the result.
+
+8. **Push (only with explicit confirmation).** Push is hard-to-reverse and visible to others — never auto-push. If `--push` was provided, ask for confirmation in the conversation; if not provided, end without pushing. When pushing, use the current branch's tracked upstream (no `--force`, no force-with-lease without per-invocation authorization, no push to `main` if the current branch is `main` without explicit confirmation).
 
 ## Outputs
 
@@ -100,6 +83,7 @@ Beyond the kernel's general stop conditions:
 - A pre-commit hook fails. Investigate and fix the underlying issue — do NOT bypass with `--no-verify`. If the fix requires out-of-scope edits (when committing inside an hstack-governed change), halt and surface as a scope-amendment situation.
 - The proposed commit message exceeds 72 characters on the summary line. Re-draft.
 - A destructive push operation is requested (`--force`, force-with-lease, push to `main`) without explicit per-invocation authorization in the current conversation. Halt and confirm.
+- `git commit --amend` would rewrite a commit that has already been pushed. Halt and confirm per-invocation; amending published history is not a default.
 - The engineer requested `--push` but the current branch has no upstream. Halt and ask which remote / branch to push to.
 
 ## Failure modes
@@ -108,15 +92,3 @@ Beyond the kernel's general stop conditions:
 - **`gpg-sign` configured but signing key unavailable.** Surface the gpg error; do NOT bypass with `--no-gpg-sign`. Engineer fixes their gpg config and re-runs.
 - **`git push` rejected (non-fast-forward).** Surface the rejection; recommend `git pull --rebase` then re-attempt; never propose `--force` without explicit authorization.
 - **Empty commit attempted.** If `git add` left the index empty (e.g., every staged change was already committed), halt with the empty-commit message; do not use `--allow-empty` without engineer confirmation.
-
-## Anti-patterns
-
-- Never use `git add -A` silently. Default to staging by named path; sweep only with explicit engineer confirmation.
-- Never use `--no-verify`, `--no-gpg-sign`, or any hook-bypass flag.
-- Never use `git commit --amend` to modify a published (pushed) commit without explicit per-invocation authorization. The system prompt's safety rule applies.
-- Never auto-push. Push is a separate, explicit, per-invocation decision.
-- Never use `git push --force` or `--force-with-lease` without explicit per-invocation authorization in the current conversation.
-- Never add "Generated with Claude Code" or any AI-attribution footer to the commit message. The user's global rule forbids it.
-- Never invent a `<scope>` that doesn't reflect what was actually touched. If the change spans multiple unrelated areas, propose splitting into multiple commits.
-- Never commit a file whose name matches the sensitive-pattern list without explicit engineer confirmation.
-- Never bypass the kernel's database-workflow or forbidden-tools rules even when committing manually — `service_role` keys, `supabase db push` against remote, etc., are forbidden regardless of the commit path.

package/template/.claude/skills/hstack-configure/SKILL.md

@@ -1,25 +1,6 @@
 ---
 name: hstack-configure
-description: |
-  Use this skill when an engineer needs to update `hstack/config.yaml` after init has already completed, re-run the interview for a single product-context document, or migrate the schema-version when hstack itself ships a structural change. This is the editor counterpart to `hstack-init`; it never bootstraps from nothing and never advances the global `init-status` field. Examples:
-
-  <example>
-  Context: The team has decided to move their personas store from `hstack/context/personas/` to a Notion database now that the Notion MCP is wired up.
-  user: "Re-configure hstack to use the Notion personas store."
-  assistant: "I'll run /hstack:configure and walk the personas-store config field. Existing personas in hstack/context/personas/ stay on disk as sync stubs pointing at the new Notion records."
-  <commentary>
-  Configure is the right entry point because init has already produced a complete config; the change is scoped to one field and its downstream side effects. Re-running init would re-interview every product-context document, which is wasted work.
-  </commentary>
-  </example>
-
-  <example>
-  Context: An hstack point release introduces a new required frontmatter field on `change-spec.md` and bumps `schemaVersion` from 1 to 2.
-  user: "Run /hstack:configure --migrate."
-  assistant: "I'll detect the schema-version delta, walk through the field-level migration plan, and re-stamp every existing artifact's frontmatter under the new schema."
-  <commentary>
-  Migration is the one mode of configure that can touch many files at once. The Skill plans the migration first, presents the planned edits to the engineer, and executes only on confirmation — never silently rewrites artifact frontmatter.
-  </commentary>
-  </example>
+description: Use to edit a `hstack/config.yaml` field after init has completed, re-run the interview for one product-context document, or migrate artifacts when an hstack release bumps the schema-version. Never bootstraps from nothing.
 tools:
   - Read
   - Write
@@ -28,7 +9,7 @@ tools:
   - Glob
   - Bash
   - Task
-  - "{{TODO-SCRIPT: hstack/scripts/validate-spec.ts — validates frontmatter after every migration write}}"
+  - "node hstack/scripts/validate-spec.mjs — validates frontmatter after every migration write"
   - "{{TODO-SCRIPT: hstack/scripts/migrate-schema.ts — applies declarative migration steps between schema-version values}}"
 ---
 
@@ -42,7 +23,7 @@ Invoke when the engineer wants to change a config field after init has completed
 
 ## Inputs
 
-- `--interview <doc-name>` (optional): re-run the conversational interview for one of `vision`, `glossary`, `mvp-scope`, `personas`, `data-architecture`, `tech-stack`, `ci-cd`, `infrastructure`, `threat-model`, `hardening-checklist`, `incident-runbook`.
+- `--interview <doc-name>` (optional): re-run the conversational interview for one of `vision`, `glossary`, `roadmap`, `personas`, `data-architecture`, `tech-stack`, `ci-cd`, `infrastructure`, `threat-model`, `hardening-checklist`, `incident-runbook`.
 - `--migrate` (optional): detect the gap between `hstack/config.yaml`'s `schemaVersion` and the version declared by the current hstack release, and apply the declarative migration steps.
 - No flag: open an interactive config editor that walks the engineer through `hstack/config.yaml` field by field, confirming or correcting each.
 
@@ -53,7 +34,7 @@ Invoke when the engineer wants to change a config field after init has completed
 Before any work:
 
 - Verify `hstack/config.yaml` exists and contains a valid `init-status: complete` value. If init has not completed, halt and surface the message to run `hstack-init` first.
-- Read `hstack/CLAUDE.md` (kernel) and `hstack/templates/`.
+- Read `hstack/KERNEL.md` (kernel) and `hstack/templates/`.
 - For `--interview <doc-name>`: verify the named document template exists under `hstack/templates/` and the corresponding instance exists under `hstack/context/`. Read the existing instance's current state to seed the interview.
 - For `--migrate`: read the current `hstack/config.yaml schemaVersion` and the target version declared by the installed hstack release. If they match, halt with a "no migration needed" message.
 
@@ -68,8 +49,8 @@ Before any work:
 ### `--interview <doc-name>` mode
 
 1. Read the existing `hstack/context/<doc-name>.md`.
-2. Invoke the doc's canonical author via Task with `subagent_type` set per the routing table below. Context = [kernel, template, existing instance]. The subagent walks the document's fields, treating the existing values as the proposal layer and the engineer's responses as accept-or-correct. The routing must match the authoring agent used by `hstack-init` for the same document — same author at init time and at refresh time, different cadence:
-   - `vision`, `glossary`, `mvp-scope`, `personas`, `data-architecture`, `tech-stack`, `ci-cd` → `product-manager`.
+2. Invoke the doc's canonical author via Task with `subagent_type` set per the routing table below. This Skill orchestrates; it never authors document content itself. Context = [kernel, template, existing instance]. The subagent walks the document's fields, treating the existing values as the proposal layer and the engineer's responses as accept-or-correct. The routing must match the authoring agent used by `hstack-init` for the same document — same author at init time and at refresh time, different cadence:
+   - `vision`, `glossary`, `roadmap`, `personas`, `data-architecture`, `tech-stack`, `ci-cd` → `product-manager`.
    - `infrastructure`, `incident-runbook` → `spec-author`.
    - `threat-model`, `hardening-checklist` → `security-reviewer`.
 3. Updated document is written incrementally per the kernel's per-field write rule. Status moves to `drafted` if it had been `current`, then back to `current` at the end. Prompt source-cleanup per the subagent's contract.
@@ -79,7 +60,7 @@ Before any work:
 
 1. Read `hstack/scripts/migrate-schema.ts` (or its current location) for the declarative migration steps between the current and target `schemaVersion`. Each step names: which artifact types it touches, which frontmatter fields it adds/renames/removes, and any prose-section structural changes.
 2. Run a dry-run scan over `hstack/` and produce a written migration plan that lists every artifact file the migration would touch and the specific edits per file. Present the plan to the engineer for confirmation.
-3. On confirmation, execute the migration step by step. After each artifact file is edited, run `{{TODO-SCRIPT: hstack/scripts/validate-spec.ts}}` against it; if validation fails, halt and surface the failure rather than continuing.
+3. On confirmation, execute the migration step by step. After each artifact file is edited, run `node hstack/scripts/validate-spec.mjs <path>` against it; if validation fails, halt and surface the failure rather than continuing.
 4. Update `hstack/config.yaml`'s `schemaVersion` to the target value on a successful migration. Commit.
 
 For destructive or ambiguous migrations (renames of frontmatter fields, status enum changes), the Skill presents each ambiguity to the engineer rather than guessing.
@@ -116,11 +97,3 @@ Beyond the kernel's general stop conditions:
 - **`migrate-schema.ts` absent or malformed.** Halt and surface as a hstack installation issue.
 - **Validator failure on a migrated artifact.** Halt the migration; previous artifacts are already committed and represent a stable partial state.
 - **Subagent halts mid-interview.** Persist current state; partial fields are already written per the kernel's incremental-write rule.
-
-## Anti-patterns
-
-- Never silently advance `schemaVersion` without a corresponding migration run.
-- Never write context document content without invoking `product-manager`. This Skill orchestrates; it does not author.
-- Never edit per-change artifacts (specs, plans, reviews) from this Skill. Those belong to their authoring subagents.
-- Never apply a `--migrate` plan without the engineer's explicit confirmation of the dry-run output.
-- Never re-run `hstack-init` semantics from this Skill. If the engineer wants to start over, they delete and re-init explicitly.