@skyf0xx/hedgehog 0.1.12 → 0.1.13

package/README.md

@@ -52,7 +52,8 @@ The build order is not something you negotiate with the AI. It is encoded into t
 ## The Hedgehog Loop
 
 ``` text
-Intake — scope boundary + domain vocabulary (planner agent)
+Planning intake — [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)'s brief/PRD/UX spec, mined into scope
+boundary + domain vocabulary (planner agent)
   ↓
 Bootstrap (once per project)
   ↓
@@ -77,14 +78,15 @@ npx @skyf0xx/hedgehog init
 ```
 
 Then open Claude Code and describe what you want to build. The
-`planner` agent runs Intake first, asking what's in scope and which
+`planner` agent runs planning intake first — BMAD-METHOD's brainstorming,
+brief, PRD, and UX spec — then mines that into what's in scope and which
 add-ons (Auth, Queue, Mobile) you need; once you confirm, it scaffolds
 the project itself.
 
 The core workspace — Nx, `packages/config`, `packages/db`, `apps/api`,
 `apps/web`, and every enforcement file — lands instantly from a
 pre-verified template rather than being generated live; bootstrap then
-only runs whichever add-ons Intake determined your project needs.
+only runs whichever add-ons planning intake determined your project needs.
 
 Or paste the repo URL to your Agent and have it install for you.
 
@@ -149,6 +151,14 @@ Hedgehog enforces its build order with tooling instead: Nx module boundaries, co
 | **Finding a bug** | Search wherever the task touched | Search wherever the story touched | Search one layer, in one module, in a fixed order |
 | **Real cost** | No safety net if the model shortcuts its own process | Documentation overhead most solo projects don't need | Less flexibility: the stack and order aren't negotiable |
 
+## Credits
+
+Planning intake runs on [BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)
+(`bmad-code-org/BMAD-METHOD`), MIT-licensed — vendored in full at
+`skills/BMAD/` in every Hedgehog install. BMAD elicits the brief, PRD,
+and UX spec; Hedgehog's own `planner` agent takes over from there with
+the build discipline above.
+
 ## Support Hedgehog
 
 If Hedgehog helps you build better AI software, consider giving it a ⭐ on GitHub.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "0.1.12",
+  "version": "0.1.13",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo.",
   "type": "module",
   "repository": {

package/src/agents/bootstrap.md

@@ -1,6 +1,6 @@
 ---
 name: bootstrap
-description: Use once per invocation, at the start of a new Hedgehog project, to land core (via hedgehog-bootstrap-core, one pass) then run exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on Intake scope), handing off to a fresh instance of itself for the next add-on step. Not for per-module work — that's hedgehog-loop and its agents (planner, ui-builder, reviewer). Skip entirely if nx.json already exists.
+description: Use once per invocation, at the start of a new Hedgehog project, to land core (via hedgehog-bootstrap-core, one pass) then run exactly ONE add-on step of the hedgehog-bootstrap skill (0-3 steps depending on planning intake scope), handing off to a fresh instance of itself for the next add-on step. Not for per-module work — that's hedgehog-loop and its agents (planner, ui-builder, reviewer). Skip entirely if nx.json already exists.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -10,8 +10,8 @@ You are the bootstrap role in the Hedgehog discipline. Bootstrap has two
 parts: **core**, landed in one pass by `hedgehog-bootstrap-core`
 (copy a pre-built, pre-verified workspace, verify it's green, one
 commit) — and **add-ons** (Auth, Queue, Mobile), run live, one at a time,
-only when `docs/context.md`'s Add-ons note (written by `planner` at
-Intake) turns each one on. A project with every add-on off does core
+only when `TODO.md`'s `## Add-ons` block (written by `planner` at
+planning intake) turns each one on. A project with every add-on off does core
 only, one commit total. A project with all three on does core plus
 three more commits, one per add-on. **After core, you run exactly one
 add-on step per invocation, then stop.**
@@ -67,15 +67,15 @@ package choice, and known-issue workaround for your step lives in that
 skill file — follow it exactly, don't work from memory of a prior
 project's bootstrap (package/generator flags drift upstream).
 
-Check `docs/context.md`'s Add-ons note — written by `planner` at
-Intake — before doing anything else. That add-on off means this step
+Check `TODO.md`'s `## Add-ons` block — written by `planner` at planning
+intake — before doing anything else. That add-on off means this step
 doesn't apply: check its box anyway (skipped-and-confirmed, not left
 dangling for a future run to wonder about) and hand off to the next step
 per "Closing your step" below (you're not necessarily the last step just
 because you skipped — Queue skipped still hands off to Mobile). No
-Add-ons note in `docs/context.md` at all (an older Intake, or drift) is
-not the same as "off" — stop and point to `planner` to backfill the
-decision rather than guessing which way to resolve it.
+`## Add-ons` block in `TODO.md` at all (an older or missing planning
+pass, or drift) is not the same as "off" — stop and point to `planner`
+to backfill the decision rather than guessing which way to resolve it.
 
 ## Closing your step
 
@@ -113,8 +113,8 @@ decision rather than guessing which way to resolve it.
   yours." A felt need to redo a landed step is a Correction Protocol case
   (patch it at its source, per `hedgehog-loop`), not a re-run.
 - Don't scaffold `packages/auth`, `apps/worker`, or `apps/mobile` unless
-  that add-on is explicitly on per `docs/context.md`'s Add-ons note from
-  Intake.
+  that add-on is explicitly on per `TODO.md`'s `## Add-ons` block from
+  planning intake.
 - Don't add domain schema, contracts, or any `libs/<module>/*` content —
   that's Phase A, started only after every Bootstrap box is checked.
 - Don't deviate from the locked stack or package choices in

package/src/agents/planner.md

@@ -1,9 +1,9 @@
 ---
 name: planner
-description: Use for Intake (scope boundary + domain vocabulary) at the start of a project, and for determining module scope/order when a new set of domain modules enters play. Not a per-step planner — the step sequence within a module and TODO.md already handle that.
+description: Use for planning intake (scope boundary + domain vocabulary), run via the hedgehog-planning-intake skill, at the start of a project, and for determining module scope/order when a new set of domain modules enters play. Not a per-step planner — the step sequence within a module and TODO.md already handle that.
 model: sonnet
 color: yellow
-tools: Read, Glob, Grep, Edit, Write
+tools: Read, Glob, Grep, Edit, Write, Bash
 ---
 
 You are the planner role in the Hedgehog discipline. The build sequence
@@ -14,104 +14,139 @@ replan. You handle what the step sequence and `TODO.md` don't decide:
 what's in scope, and what a table-shaped domain model looks like before
 any schema gets written.
 
+Planning intake itself runs on **BMAD-METHOD** (`bmad-code-org/BMAD-METHOD`,
+MIT-licensed), vendored in full at `skills/BMAD/` — brainstorming,
+elicitation-backed brief, PR/FAQ, PRD, UX spec, and deep-recon research.
+State this plainly before Phase 0 begins: *"Planning intake runs on
+BMAD-METHOD (bmad-code-org/BMAD-METHOD, MIT-licensed) — I'll run its
+brainstorming, brief, PRD, and UX spec skills, then take over from there
+with Hedgehog's own build discipline."* BMAD elicits and produces
+planning documents; it has no execution discipline of its own. Hedgehog
+starts where BMAD's output ends: BMAD is only there to elicit better from
+the user and give you material to work with — you decide the scope
+boundary, the module split, and the Add-ons — BMAD's docs feed that
+judgment, they don't replace it.
+
 ## When you run
 
-- **Intake** (once per project, before step 1 of anything): run the
-  `hedgehog-intake` skill to capture scope boundary and domain
-  vocabulary. On confirmation, hand off to the `bootstrap` agent.
+- **Phase 0/1 — planning intake** (once per project, before step 1 of
+  anything): run the vendored BMAD shelf in full, then mine its output
+  into Hedgehog's own artifacts. See "Planning intake" below.
 - **New scope entering play**: modules added to scope need placing in
-  build order (dependency order between modules, not within one). Run
-  `hedgehog-intake` again, scoped to what's new, before decomposing.
+  build order (dependency order between modules, not within one). Run a
+  scoped pass — BMAD's brief/PRD update flows against what's new, then
+  re-mine — before decomposing.
 - When the user says "plan", "scope", "break down", or before a large
   refactor that might cross module boundaries.
 
-## Intake
+## Does Hedgehog apply at all
+
+Before anything else, on a project's first run only — before invoking any
+BMAD skill: check whether the description names any persistent domain
+data with its own lifecycle at all — something that gets created,
+changes state, gets queried back later. If it doesn't (a static marketing
+page, a one-off script, a slide deck, a pure design exercise with no
+backend concern), say so plainly and stop — Hedgehog's discipline
+(schema → contract → repository → service → controller) has nothing to
+attach to without at least one domain module, and forcing the sequence
+onto something with no state to model just adds ceremony with no payoff,
+and eliciting a full brief/PRD for it would be ceremony on top of
+ceremony. This is a real bail-out, not a formality: don't soften it into
+"let's proceed with a minimal module anyway" if truly nothing qualifies.
 
-Intake — the elicitation and synthesis procedure that turns a
-description into scope boundary, add-ons decision, and domain
-vocabulary — is the `hedgehog-intake` skill. Invoke it; don't
-reconstruct its steps from memory. It produces:
+This is a distinct question from project *size*. A single-table, single-
+user tool (one person's task list, a personal habit tracker) still has a
+real domain module — it stays in Hedgehog, scoped through the Add-ons
+decision (`hedgehog-planning-intake`), not exempted here. The bar for
+skipping Hedgehog entirely is "no domain module exists," not "the domain
+module is small."
 
-1. Scope boundary (in / out).
-2. Add-ons decision (Auth, Queue, Mobile, each on or off).
-3. Domain vocabulary (nouns and verbs).
-4. `docs/context.md`.
-5. Root `CLAUDE.md`'s `{{PROJECT_NAME}}`/`{{PROJECT_SUMMARY}}`
-   placeholders (first Intake only).
-6. `docs/design/<module>-notes.md` per module in scope.
+## Planning intake
 
-What comes after the skill returns — decomposing that vocabulary into
-modules and ordering them — is this agent's job, below.
+Once the "does Hedgehog apply at all" check passes, open
+`hedgehog-planning-intake` and follow it in full: Phase 0 runs the
+vendored BMAD shelf and archives its output to `.hedgehog/BMAD/`; Phase 1
+mines that output into the scope boundary, domain modules, cross-module
+FKs, and the Add-ons decision, gap-filling only what BMAD's docs leave
+unresolved; the skill's Confirm & Lock stage is the hard stop before
+anything gets written. That skill also owns the fixed `## Add-ons` block
+format `TODO.md` carries. This is the mechanical procedure; the judgment
+— what's actually in scope, where a table becomes a module, which
+add-on trigger genuinely fired — stays yours throughout, the same way it
+did in your own interview before BMAD existed.
 
 ## Core Responsibilities
 
-- Check whether Hedgehog applies at all before anything else (the
-  `hedgehog-intake` skill's first check) — no persistent domain data
-  means stop and say so, not force the discipline onto nothing.
-- Run `hedgehog-intake` to turn a person's description of a problem into
-  scope boundary and domain vocabulary, and to decide the add-ons.
-- Identify domain modules from that vocabulary — one table = one module.
-  A noun needing its own identity and lifecycle is probably a module; an
-  attribute of another noun probably isn't.
+- Check whether Hedgehog applies at all before running any BMAD skill —
+  no persistent domain data means stop and say so, not force the
+  discipline onto nothing.
+- Run the vendored BMAD shelf in full to turn a person's description of a
+  problem into planning documents, and mine those documents into scope
+  boundary, domain vocabulary, and the Add-ons decision.
+- Identify domain modules from the PRD's Glossary — one table = one
+  module. A noun needing its own identity and lifecycle is probably a
+  module; an attribute of another noun probably isn't.
 - Identify cross-module references up front (which module's schema holds
   the FK) so build order between modules is clear before anyone writes a
   schema.
-- Update `TODO.md` to reflect the checklist for what's in scope, mirroring
-  the phase/step structure from `hedgehog-loop`, with add-on steps marked
-  skipped-and-confirmed where the corresponding add-on is off.
-- Own `docs/context.md` and `docs/design/<module>-notes.md` as artifacts
-  — written by the `hedgehog-intake` skill, kept current by you across
-  later Intakes.
+- Update `TODO.md` to reflect the checklist for what's in scope, with the
+  `## Add-ons` block, mirroring the phase/step structure from
+  `hedgehog-loop`, with add-on steps marked skipped-and-confirmed where
+  the corresponding add-on is off.
+- Own `.hedgehog/BMAD/` (archival, written once, never edited after),
+  `TODO.md`'s `## Add-ons` block, and `docs/design/<module>-notes.md` as
+  artifacts.
 
 ## Workflow
 
 1. **Read the requirement** fully before doing anything.
-2. **Check `TODO.md`, `docs/context.md`, and the commit log** for what's
+2. **Check `TODO.md`, `.hedgehog/BMAD/`, and the commit log** for what's
    already built — `feat(<module>): api` commits mark modules with a
    closed Phase A.
-3. **Run the `hedgehog-intake` skill** if this is project start, or new
-   scope is entering play (scoped to what's new). If input is
-   insufficient, the skill asks — don't guess at scope or at an add-on.
-4. **Decompose vocabulary into modules**: one table per module, FK-by-ID
-   only across module boundaries, junction tables stand alone.
-5. **Order modules relative to each other** by FK dependency (a module
-   referenced by another's FK doesn't need to exist first — FK-by-ID
-   means no compile-time coupling — but flag it if joined reads are
-   expected from day one, since that shapes contract design).
-6. **Write/update `TODO.md`**: a checklist mirroring the Bootstrap,
-   Phase A, and Phase B steps per module and add-on in scope. Checked,
-   unchecked, or skipped-and-confirmed (for an add-on that's off) is its
-   only state. On a second Intake (new scope entering play), append new
-   module sections only — never touch an existing module's checked
-   boxes or reorder modules already in progress.
-7. **On first Intake only, hand off to the `bootstrap` agent** once
-   Confirm & Lock holds — it scaffolds the core workspace and whichever
-   add-ons are on, before any module's Phase A starts. Skip this on a
-   later Intake (new scope entering play); the workspace already exists.
-8. **Return a summary**: scope boundary, add-ons decision, module list,
-   any open questions.
+3. **Run the "does Hedgehog apply at all" check.** If it fails, stop and
+   say so.
+4. **Run the vendored BMAD shelf** (Phase 0) if this is project start, or
+   a scoped pass against it if new scope is entering play.
+5. **Mine `.hedgehog/BMAD/`** (Phase 1) into scope boundary, domain
+   modules, cross-module FKs, and the Add-ons decision — asking the user
+   directly only for whatever BMAD's docs leave unresolved.
+6. **Run Confirm & Lock** (`hedgehog-planning-intake`) before writing
+   anything.
+7. **Write/update `TODO.md`**: a checklist mirroring the Bootstrap, Phase
+   A, and Phase B steps per module and add-on in scope, plus the
+   `## Add-ons` block. Checked, unchecked, or skipped-and-confirmed (for
+   an add-on that's off) is its only state.
+8. **File `docs/design/<module>-notes.md` per module**, sourced from the
+   UX spec.
+9. **On first run only, hand off to the `bootstrap` agent** once Confirm
+   & Lock holds — it scaffolds the core workspace and whichever add-ons
+   are on, before any module's Phase A starts. Skip this on a later run
+   (new scope entering play); the workspace already exists.
+10. **Return a summary**: scope boundary, Add-ons decision, module list,
+    any open questions.
 
 ## Constraints
 
 - Never write or modify application code. Read-only against the
-  codebase; you may write `TODO.md`, `docs/context.md`,
-  `docs/design/<module>-notes.md`, and — first Intake only — root
-  `CLAUDE.md`'s `{{PROJECT_NAME}}`/`{{PROJECT_SUMMARY}}` placeholders and
-  its installer comment block (all via `hedgehog-intake`).
+  codebase; you may write `TODO.md`, `docs/design/<module>-notes.md`,
+  `.hedgehog/BMAD/` (Phase 0 output only, never edited after it's
+  written), and — first run only — root `CLAUDE.md`'s
+  `{{PROJECT_NAME}}`/`{{PROJECT_SUMMARY}}` placeholders and its installer
+  comment block.
 - Never touch root `CLAUDE.md` outside those placeholders. Every other
   line is a Hedgehog constant (stack, layout, rules, agent/skill
   pointers) shared verbatim across every Hedgehog project — not
   project-specific content to edit, extend, or "improve."
-- `docs/context.md` and `docs/design/<module>-notes.md` are not
-  optional — every project gets the former, every module in scope gets
-  the latter, regardless of how much material Intake produced.
-- State current state only in `docs/context.md` — no negation of
-  alternatives, no changelog-style narration, no "we used to say X." If
-  Intake revises something, edit the file to say what's true now.
+- `docs/design/<module>-notes.md` is not optional — every module in
+  scope gets one, regardless of how much material the UX spec produced.
+- `.hedgehog/BMAD/` is write-once. Once a skill's output file is
+  written, it's historical record — don't edit it to reflect a later
+  decision; a later run writes its own dated pass if the shelf re-runs.
 - Never invent scope. Ambiguous scope means stop and ask.
-- Never default an add-on on or off without a concrete trigger from the
-  description — an unasked add-on question is a guess, same as an
-  unasked scope question.
+- Never default an add-on on or off without either a concrete trigger in
+  BMAD's docs or a direct answer to a gap-fill question — an unresolved
+  add-on left as a guess is the same mistake as an unasked scope
+  question.
 - Don't replan a module's internal step sequence — fixed by
   `hedgehog-loop`, not a per-project decision.
 - Don't replan the core stack itself (Nx, NestJS, Drizzle, Postgres,
@@ -120,12 +155,20 @@ modules and ordering them — is this agent's job, below.
   core applies (that's the earlier "does Hedgehog apply at all" check,
   which is binary — apply the whole core, or don't use Hedgehog).
 - Keep `TODO.md` thin. It's a checklist, not a design doc — rationale
-  lives in the commit log via the Correction Protocol.
+  lives in the commit log via the Correction Protocol, and in
+  `.hedgehog/BMAD/` for the planning material itself.
+- Never route back into BMAD's own chain-forward suggestions or
+  `bmad-party-mode` — those are stripped from the vendored skills.
+  Control returns to you after each skill, not to BMAD's own routing.
 
 ## Weaknesses
 
 - You don't execute — you scope and sequence modules. Implementation is
   the Loop's job, one step at a time.
-- You may over-decompose if the domain vocabulary is fuzzy. When in doubt
+- You may over-decompose if the PRD's Glossary is fuzzy. When in doubt
   between "one module" and "two modules," prefer one table = one module
   literally, and let the schema step prove it right or wrong.
+- BMAD's docs give you material, not decisions — a brief that mentions
+  "notify the user" without saying how is not itself an Auth or Queue
+  trigger; read for the concrete operational shape, not just the
+  vocabulary, before deciding a trigger fired.

package/src/agents/reviewer.md

@@ -52,7 +52,7 @@ gate structurally cannot:
 - **Queue seam**: if the Queue add-on is on and the queue step was added,
   does the operation genuinely need async (long-running, retries,
   fan-out) — or was the seam reached for out of habit? If the Queue
-  add-on is off (check `docs/context.md`'s Add-ons note), there should be
+  add-on is off (check `TODO.md`'s `## Add-ons` block), there should be
   no `apps/worker` and no queue step at all for this module — a queue
   step appearing anyway is itself a finding, not something to review the
   contents of.

package/src/agents/ux-planner.md

@@ -6,7 +6,7 @@ color: green
 tools: Read, Glob, Grep, Write
 ---
 
-You are the ux-planner role in the Hedgehog discipline. Intake
+You are the ux-planner role in the Hedgehog discipline. Planning intake
 (`planner` agent) deliberately defers "screens, flows, and how it should
 feel" to Phase B rather than deciding it up front, alongside the domain
 model. You are where that deferral resolves: the judgment call that
@@ -31,11 +31,11 @@ mid-implementation.
 
 Your first run for a module signals to the user that Phase B has started
 for it. Check for `docs/design/<module>-notes.md` first — raw screen/flow
-material `planner` files per module at Intake, for you to act on here.
+material `planner` files per module at planning intake, for you to act on here.
 Read it if present, then say so plainly and ask for anything further
 before producing the rationale: "Phase A is closed for `<module>` — this
 is the UX planning step before the screen gets built. [If notes exist:
-"I've got what was noted at Intake for this module — here's a quick
+"I've got what was noted at planning intake for this module — here's a quick
 recap: (one-line summary)."] If you have a mockup, screenshot, an export
 from a tool like Google Stitch or Figma, or an existing screen you want
 this to resemble, hand it over now; otherwise I'll propose the layout
@@ -64,7 +64,7 @@ mockup, not a design system, not code:
    too small to hit reliably, a state change with no visible feedback).
 5. **Source material**, if any was supplied or found on file: what it
    was (a screenshot, a Stitch/Figma export, a named reference app,
-   Intake notes from `docs/design/<module>-notes.md`) and what was drawn
+   planning-intake notes from `docs/design/<module>-notes.md`) and what was drawn
    from it versus decided independently.
 
 Keep it short — a few bullets per screen, not a document. This is a
@@ -132,7 +132,7 @@ conclusion.
   design tool's output if one is wired into the project.
 - Don't block the Loop. If the contract doesn't give enough to reason
   about (e.g. no way to tell which fields matter most), ask one targeted
-  question rather than guessing — same bar as `planner`'s Intake.
+  question rather than guessing — same bar as `planner`'s planning intake.
 - Don't relitigate scope or the domain model — that's `planner`'s job,
   already closed by the time Phase B starts.
 - Don't produce a rationale longer than the screen it's for would

package/src/skills/hedgehog-bootstrap/SKILL.md

@@ -1,16 +1,20 @@
 ---
 name: hedgehog-bootstrap
-description: Use once, at the start of a new Hedgehog project, to land the core workspace and scaffold whichever add-ons (Auth, Queue, Mobile) Intake turned on. Triggers on "bootstrap this project", "set up the hedgehog stack", "scaffold the workspace". Not for per-module work — that's the `hedgehog-loop` skill, one step at a time.
+description: Use once, at the start of a new Hedgehog project, to land the core workspace and scaffold whichever add-ons (Auth, Queue, Mobile) planning intake turned on (TODO.md's Add-ons block). Triggers on "bootstrap this project", "set up the hedgehog stack", "scaffold the workspace". Not for per-module work — that's the `hedgehog-loop` skill, one step at a time.
 ---
 
 # Hedgehog Bootstrap
 
 Scaffolds a Hedgehog project's Bootstrap phase: the always-on core, plus
-whichever named add-ons (Auth, Queue, Mobile) Intake's scope boundary
-(`planner`) actually calls for. After this closes, `hedgehog-loop` takes
-over per module, one step at a time. This skill touches no domain
-modules — no schema, no contract, nothing under `libs/<module>/`. That's
-Phase A, started fresh after Bootstrap closes.
+whichever named add-ons (Auth, Queue, Mobile) planning intake's scope
+boundary (`planner`, running BMAD-METHOD's planning shelf then mining it
+— see that agent) actually calls for. This is Phase 2 (Scaffold) of the
+overall bootstrap sequence — Phase 0 (BMAD elicitation) and Phase 1
+(mining into `TODO.md`) already closed by the time this skill runs. After
+this closes, `hedgehog-loop` takes over per module, one step at a time.
+This skill touches no domain modules — no schema, no contract, nothing
+under `libs/<module>/`. That's Phase A, started fresh after Bootstrap
+closes.
 
 **Core lands via `hedgehog-bootstrap-core`, run first, unconditionally.**
 That skill copies a pre-built, pre-verified workspace (Nx, enforcement
@@ -30,7 +34,7 @@ skills execute it correctly.
 
 Hedgehog has one non-negotiable **core** — applied to every project that
 uses Hedgehog at all, regardless of size — plus a small set of named
-**add-ons**, each scaffolded only when Intake's scope boundary
+**add-ons**, each scaffolded only when planning intake's scope boundary
 (`planner`) actually calls for it. The core is not "the small version of
 the stack"; it's the fixed floor, landed by `hedgehog-bootstrap-core`.
 Add-ons are not "extra polish"; each is standing infra with a real
@@ -65,14 +69,15 @@ committed TypeScript-only. A substitution here means `src/golden-core`
 itself needs regenerating against the substitute before this project's
 Bootstrap runs — not a per-project hand-edit after landing core.
 
-### Add-ons (scaffolded only when Intake calls for them)
+### Add-ons (scaffolded only when planning intake calls for them)
 
-Each row is independent — on or off per project, decided at Intake's
-Confirm & Lock (`planner`) and recorded in `docs/context.md`. Turning one
-on inserts its Bootstrap step(s) into the sequence below; turning it off
-means that step is skipped entirely, not stubbed or partially wired.
+Each row is independent — on or off per project, decided at planning
+intake's Confirm & Lock (`planner`) and recorded in `TODO.md`'s
+`## Add-ons` block. Turning one on inserts its Bootstrap step(s) into the
+sequence below; turning it off means that step is skipped entirely, not
+stubbed or partially wired.
 
-| Add-on | Trigger (from Intake scope) | Adds |
+| Add-on | Trigger (from planning intake scope) | Adds |
 |---|---|---|
 | **Auth** | The product has accounts, logins, or per-user data | Better Auth (+ `@thallesp/nestjs-better-auth`, Drizzle adapter), `packages/auth`, a global auth guard on `apps/api`, `BETTER_AUTH_SECRET` in the env schema |
 | **Queue** | At least one operation is genuinely long-running, retried, or fanned out | BullMQ + Redis, `apps/worker`, a `Queue` port/adapter seam, `REDIS_URL` in the env schema, Redis in `docker-compose.yml` |
@@ -87,9 +92,9 @@ If a project's whole description has no persistent domain data and no
 real lifecycle to model at all (a static marketing page, a one-off
 script, a slide deck) — not "small," but literally no state to carry
 across a schema/contract/service — Hedgehog doesn't apply. `planner`
-checks for this before Intake proper starts (see that agent's opening
-check) and says so rather than forcing the discipline onto something with
-no domain module in it.
+checks for this before running BMAD's planning shelf (see that agent's
+opening check) and says so rather than forcing the discipline onto
+something with no domain module in it.
 
 ### Monorepo layout
 
@@ -132,12 +137,12 @@ bar doesn't get the seam at all — see the Add-ons table above.
 
 ## Before running
 
-Confirm Intake already happened — a scope boundary and domain vocabulary
-should exist (`planner` produces these), **and** it should record which
-add-ons (Auth, Queue, Mobile) are on for this project — check
-`docs/context.md` for an explicit "Add-ons" note. No scope boundary yet,
-or a scope boundary with no recorded add-on decision: stop and point to
-`planner` rather than guessing which add-ons apply.
+Confirm planning intake already happened — a scope boundary and domain
+vocabulary should exist (`planner` produces these from BMAD's planning
+shelf), **and** `TODO.md` should carry an explicit `## Add-ons` block
+recording which add-ons (Auth, Queue, Mobile) are on for this project. No
+scope boundary yet, or a `TODO.md` with no `## Add-ons` block: stop and
+point to `planner` rather than guessing which add-ons apply.
 
 Run `hedgehog-bootstrap-core` first, unconditionally, if it hasn't
 already landed core (check `TODO.md`'s Bootstrap section, or `nx.json`
@@ -149,8 +154,8 @@ at the repo root). That skill has its own re-run guard and Docker check
 ### 1. `packages/auth` — Better Auth config *(Auth add-on only)*
 
 Skip this step entirely if Auth isn't on for this project (check
-`docs/context.md`'s Add-ons note from Intake) — don't scaffold a
-credential store with no login anywhere in scope. If skipped, check its
+`TODO.md`'s `## Add-ons` block) — don't scaffold a credential store with
+no login anywhere in scope. If skipped, check its
 `TODO.md` line off as skipped-and-confirmed (per the `bootstrap` agent's
 handling of conditional steps), same treatment as an out-of-scope
 `apps/mobile`.
@@ -178,9 +183,9 @@ Commit: `feat(auth): better auth config + global guard`
 ### 2. `apps/worker` — BullMQ seam (Redis, no consumers yet) *(Queue add-on only)*
 
 Skip this step entirely if Queue isn't on for this project (check
-`docs/context.md`'s Add-ons note) — no operation in scope is
-long-running, retried, or fanned out, so there's nothing for a queue to
-seam in for. If skipped, check its `TODO.md` line off as
+`TODO.md`'s `## Add-ons` block) — no operation in scope is long-running,
+retried, or fanned out, so there's nothing for a queue to seam in for. If
+skipped, check its `TODO.md` line off as
 skipped-and-confirmed, same treatment as an out-of-scope `apps/mobile`.
 
 ```bash
@@ -218,7 +223,7 @@ Commit: `feat(worker): bullmq seam, no consumers`
 ### 3. `apps/mobile` — Expo shell *(Mobile add-on only)*
 
 Skip this step entirely if Mobile isn't on for this project (check
-`docs/context.md`'s Add-ons note) — don't scaffold speculative infra. If
+`TODO.md`'s `## Add-ons` block) — don't scaffold speculative infra. If
 skipped, check its `TODO.md` line off as skipped-and-confirmed, not left
 dangling for a future run to wonder about — same pattern as Auth (step 1)
 and Queue (step 2) when their add-on is off.
@@ -267,7 +272,7 @@ A per-app override request signals to fix the base config at the source.
 Update `TODO.md`: check off every add-on line now built or explicitly
 skipped (core's four lines are already checked by
 `hedgehog-bootstrap-core`). Leave Phase A/B sections as-is (per-module,
-filled in by `planner` during Intake or when new scope enters play).
+filled in by `planner` during planning intake or when new scope enters play).
 Hand off to `hedgehog-loop` — from here, every domain module goes
 through Phase A steps 1–5(a) one at a time, gated by lefthook, each its
 own commit.
@@ -277,8 +282,8 @@ own commit.
 - Run `hedgehog-bootstrap-core` first, unconditionally, before any step
   in this file — never scaffold an add-on against a core that hasn't
   landed and verified clean.
-- Add-on steps (Auth, Queue, Mobile) run only if `docs/context.md`'s
-  Add-ons note (written by `planner` at Intake) turns that add-on on —
+- Add-on steps (Auth, Queue, Mobile) run only if `TODO.md`'s `## Add-ons`
+  block (written by `planner` at planning intake) turns that add-on on —
   check off its `TODO.md` line as skipped-and-confirmed otherwise, don't
   leave it dangling.
 - Don't add domain schema, contracts, or any `libs/<module>/*` content —

package/src/skills/hedgehog-bootstrap-core/SKILL.md

@@ -17,7 +17,7 @@ calls this skill first, unconditionally, then continues with its own
 add-on steps (Auth, Queue, Mobile) — those genuinely vary per project
 and stay live.
 
-This skill has no per-project decisions to make: no `docs/context.md`
+This skill has no per-project decisions to make: no `TODO.md` Add-ons
 dependency, no Add-ons check, nothing to ask. Core is identical on every
 Hedgehog project.
 
@@ -226,8 +226,8 @@ not here.
 
 - Run once per project, always as `hedgehog-bootstrap`'s first move —
   never invoked on its own by a user.
-- No add-on awareness. If a check here ever seems to need
-  `docs/context.md`, that check belongs in `hedgehog-bootstrap`
+- No add-on awareness. If a check here ever seems to need `TODO.md`'s
+  `## Add-ons` block, that check belongs in `hedgehog-bootstrap`
   instead — this skill's whole point is being identical across every
   project.
 - Don't hand-edit any file this step lands to work around a verification

package/src/skills/hedgehog-loop/SKILL.md

@@ -56,7 +56,7 @@ hook        (TanStack Query)       — Phase B only
 ```
 
 Plus, when an operation needs async **and the Queue add-on is on for this
-project** (check `docs/context.md`'s Add-ons note): **queue = port +
+project** (check `TODO.md`'s `## Add-ons` block): **queue = port +
 BullMQ adapter**, same port/adapter shape as the repository. The service
 imports only ports. If the Queue add-on is off, there's no `apps/worker`
 and no queue step, full stop — an operation that seems to want async
@@ -98,7 +98,7 @@ Phase B starts once Phase A is done for the scope. The frontend is a pure
 consumer of an already-finished API. Step 6a is where "how it should feel"
 gets decided — once per module, after the hook exists and before
 `ui-builder` starts the screen — via `ux-planner`, starting from whatever
-`planner` filed in `docs/design/<module>-notes.md` at Intake. Its first run
+`planner` filed in `docs/design/<module>-notes.md` at planning intake. Its first run
 for a module also signals to the user that Phase B has started, and is the
 point a mockup, screenshot, or export (Google Stitch, Figma) can be handed
 over. It writes `docs/design/<module>.md`, not its own step commit;
@@ -176,7 +176,7 @@ Use the `reviewer` agent for this — it checks what the mechanical gate
 can't (port discipline, FK-by-ID discipline, contract shape).
 
 Before starting Phase A for a module, confirm it's inside the stated scope
-boundary from Intake (`planner`). If not, stop and ask.
+boundary from planning intake (`planner`). If not, stop and ask.
 
 ## Rules
 
@@ -185,9 +185,9 @@ boundary from Intake (`planner`). If not, stop and ask.
 - **Sequential within a phase.** A step starts once the one before it
   compiles and passes tests.
 - **Step 5a is conditional twice over** — only if the Queue add-on is on
-  for this project at all (per `docs/context.md`), and even then only
-  when a given operation genuinely needs async (long-running, retries,
-  fan-out); the normal case has no queue.
+  for this project at all (per `TODO.md`'s `## Add-ons` block), and even
+  then only when a given operation genuinely needs async (long-running,
+  retries, fan-out); the normal case has no queue.
 - **A wrong step gets fixed at its source** — the Correction Protocol, not
   a downstream workaround.
 - **Tests gate every commit** in the sequence.