@skyf0xx/hedgehog 6.2.5 → 6.2.7

package/README.md

@@ -192,6 +192,18 @@ Bundle
 Join
 ```
 
+### Copywriting
+
+Copy is drafted and revised against a mechanical gate instead of prompting alone:
+
+``` text
+Brief
+  ↓
+Draft ⇄ zod validation()
+  ↓ pass
+Ship
+```
+
 ### Anything else
 
 A CLI, a library, a browser extension, a data pipeline, etc. gets its build order.

package/README.zh-CN.md

@@ -192,6 +192,18 @@ Bundle
 Join
 ```
 
+### 文案写作
+
+文案的撰写与修改会经过一道机械化的关卡，而不是仅靠提示词：
+
+``` text
+Brief
+  ↓
+Draft ⇄ zod validation()
+  ↓ pass
+Ship
+```
+
 ### 其他任意类型
 
 CLI、库、浏览器扩展、数据管道等，都会拥有各自的构建顺序。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "6.2.5",
+  "version": "6.2.7",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "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 the workspace for whichever core `planner` selected at Phase 0 — the first real workspace this project gets, since `init` with no explicit core flag lands the shared agents/skills/build-graph payload and leaves the workspace to bootstrap. Reads the chosen core's own bootstrap skill, installed from that core's package, and follows it: how many steps Bootstrap takes and what each one lands are that skill's to state, not this agent's. Not for per-phase/per-module work — that's the core's own loop skill and its agents. Skip entirely if the core's workspace already exists, per the already-ran check the core's bootstrap skill opens with.
+description: Use once per invocation, at the start of a new Hedgehog project, to land the workspace for whichever core `planner` selected at Phase 0 — the first real workspace this project gets, since `init` with no explicit core flag lands the shared agents/skills/build-graph payload and leaves the workspace to bootstrap. Reads the chosen core's own bootstrap skill, installed from that core's package, and follows it: how many steps Bootstrap takes and what each one lands are that skill's to state, not this agent's. Not for per-phase/per-module work — that's the core's own loop skill and its agents. Skip entirely if the core's workspace already exists, per the already-ran check the core's bootstrap skill opens with. Never dispatched for copywriting — that core ships no bootstrap skill; `init --copywriting` lands its whole workspace at install time, and its own planning intake runs `hedgehog plan` directly instead of handing off here.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash

package/src/agents/planner.md

@@ -21,7 +21,9 @@ You run on two paths, and Workflow step 2 decides which:
 
 - **First run** (the graph holds no intents): **Phase 0 — core
   selection**, the gate below, then **Phase 1 — planning intake** in the
-  shape the chosen core defines, then the `bootstrap` handoff.
+  shape the chosen core defines, then the `bootstrap` handoff — except
+  copywriting, which has no bootstrap skill and whose planning intake
+  runs `hedgehog plan` itself; see step 9.
 - **Re-entry** (the graph already holds intents): new scope entering play
   on a project that's already been built or is mid-build, on a core with
   a module axis to add an intent to (full-stack-app, authored). The core
@@ -88,7 +90,8 @@ memory of what a core is. Read every entry before choosing; the first
 plausible match is not the answer until the rest have been ruled out.
 A core whose `when` fits and whose `flag` is listed is chosen by name
 and handed to `bootstrap`, which installs that core's package and
-follows the bootstrap skill it ships.
+follows the bootstrap skill it ships — except copywriting, which ships
+no bootstrap skill; see step 9.
 
 **Before matching against `when` paragraphs, ask up to three
 clarifying questions if the description alone doesn't already settle
@@ -259,6 +262,25 @@ the first-run shape; on re-entry, run `hedgehog-planning-intake`'s
   owns `.hedgehog/chain/00-brief.md` and this core's own Confirm & Lock
   stage; `.hedgehog/BMAD/` is written by the shared Phase 0 in
   `hedgehog-planning-intake`.
+- **`copywriting`** → open `hedgehog-copywriting-loop`'s planning-intake
+  section and follow it: it opens with `hedgehog-planning-intake`'s
+  Phase 0 (the same vendored BMAD shelf `full-stack-app` runs, in full,
+  archived to `.hedgehog/BMAD/` — the same skill, not a separate copy of
+  its steps), then does its own mining into a draft brief (what's being
+  written, the audience, the register), the copywriting counterpart to
+  `hedgehog-planning-intake`'s Phase 1 (domain modules and an Add-ons
+  decision on full-stack-app). The mined draft is shown back at this
+  core's own Confirm & Lock stage, pre-filled from BMAD's output, for
+  the user to accept or correct. State the same BMAD attribution as
+  full-stack-app before that Phase 0 begins. `hedgehog-copywriting-loop`
+  owns `.hedgehog/copy/00-brief.md` and this core's own Confirm & Lock
+  stage; `.hedgehog/BMAD/` is written by the shared Phase 0 in
+  `hedgehog-planning-intake`. This core's own Confirm & Lock runs
+  `hedgehog plan` itself and does not hand off to `bootstrap` — its
+  workspace (`scripts/check-copy/` and `core.yaml`) is already fully
+  installed by `init --copywriting`, before planning intake ever starts,
+  and this core ships no bootstrap skill. Step 9 below does not apply to
+  it; the core's own loop skill picks up from here directly.
 - **`deepseek-harness`** → no BMAD shelf runs on this core, and none of
   `hedgehog-planning-intake` applies. Intake is mechanical, owned
   entirely by `hedgehog-dsh-loop`'s own Planning intake section: confirm
@@ -473,6 +495,10 @@ as full-stack-app's Auth/Queue/Mobile trio.
    run**, don't run `plan` yet — no core is installed until step 9's
    `bootstrap` handoff lands one, and `plan` requires `core.yaml` to
    exist. Leave the written intents `proposed` and continue to step 8.
+   **Copywriting is the one exception**: its own Confirm & Lock (see the
+   core-specific procedures above) already ran `hedgehog plan` as part
+   of step 6, since its `core.yaml` is on disk before planning intake
+   ever starts — nothing left to defer here.
 8. **Commit planning intake's output as one commit** — not on the
    adoption re-entry path, where `hedgehog-adopt` already committed its
    own work as `chore(planning): adopt change` (step 2). Elsewhere:
@@ -488,18 +514,22 @@ as full-stack-app's Auth/Queue/Mobile trio.
    only). Write these with the `no-history-in-output` skill: current
    state only, no narration of the intake conversation. This is planning
    intake's own unit of work, landed before `bootstrap` touches anything.
-9. **First run only, and not on the brownfield path — hand off to the
-   `bootstrap` agent** once the commit lands. It scaffolds the chosen
-   core's workspace (and, for full-stack-app, whichever add-ons are on;
-   for pwa-app, whichever of sync/remote entities is on) before any build
-   step starts. Once that workspace exists, `core.yaml` exists too — this
-   is the point at which the `hedgehog plan` step 7 deferred on a first
-   run can finally succeed. `bootstrap` runs it before closing (see
-   `bootstrap.md`'s "Closing Bootstrap"), so the intents planner wrote are
-   compiled into tasks before the core's loop skill picks anything up. On
-   re-entry on any other core the workspace already exists and step 7
-   already ran `plan`: hand straight to that core's loop skill instead,
-   which picks the new work up from `hedgehog next`.
+9. **First run only, not on the brownfield path, and not on
+   copywriting — hand off to the `bootstrap` agent** once the commit
+   lands. It scaffolds the chosen core's workspace (and, for
+   full-stack-app, whichever add-ons are on; for pwa-app, whichever of
+   sync/remote entities is on) before any build step starts. Once that
+   workspace exists, `core.yaml` exists too — this is the point at which
+   the `hedgehog plan` step 7 deferred on a first run can finally
+   succeed. `bootstrap` runs it before closing (see `bootstrap.md`'s
+   "Closing Bootstrap"), so the intents planner wrote are compiled into
+   tasks before the core's loop skill picks anything up. On re-entry on
+   any other core the workspace already exists and step 7 already ran
+   `plan`: hand straight to that core's loop skill instead, which picks
+   the new work up from `hedgehog next`. **On copywriting**, first run or
+   not, there is no `bootstrap` handoff at all — its own Confirm & Lock
+   already ran `plan` (see the core-specific procedures above); hand
+   straight to `hedgehog-copywriting-loop` instead.
 10. **Return a summary**: which core (naming it as authored or adopted,
     if it is), the intents added (or subject statement, for
     landing-page), any open questions.

package/src/db/plan.mjs

@@ -5,11 +5,11 @@
 //
 // full-stack-app and pwa-app: one task per layer per intent (an intent is
 // a domain module — see the core definition's `{module}` placeholder).
-// landing-page, deepseek-harness, and authored (whether designed from
-// scratch or adopted onto an existing repo): one task per phase/layer, no
-// module axis. All are the same operation — walk a core definition's layer
-// chain once per intent — because a linear chain is the degenerate case of
-// the layer graph (spec: MVP scope item 5).
+// landing-page, copywriting, deepseek-harness, and authored (whether
+// designed from scratch or adopted onto an existing repo): one task per
+// phase/layer, no module axis. All are the same operation — walk a core
+// definition's layer chain once per intent — because a linear chain is
+// the degenerate case of the layer graph (spec: MVP scope item 5).
 //
 // Layer cardinality: a layer marked `once: true` in the core definition
 // opts out of that per-intent multiplication and compiles a single task

package/src/hosts/capabilities.mjs

@@ -13,6 +13,7 @@ export const AGENT_CAPABILITY = {
   // Build and scaffold: read, write, and run commands.
   'backend-eng': 'full',
   bootstrap: 'full',
+  'copy-writer': 'full',
   'front-end-eng': 'full',
   'harness-eng': 'full',
   'landing-builder': 'full',

package/src/hosts/gemini/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "hedgehog",
-  "version": "6.2.5",
+  "version": "6.2.7",
   "description": "Hedgehog build discipline: ordered, tested, verified build steps.",
   "contextFileName": "GEMINI.md"
 }

package/src/registry/cores.json

@@ -51,6 +51,15 @@
       "language": "typescript",
       "repository": "https://github.com/skyf0xx/hedgehog-core-adopted",
       "selects_when": "The description is about bringing Hedgehog's discipline to a codebase that already exists, rather than building something new — the repo already has real source files, or the user says so explicitly: \"adopt this repo\", \"add Hedgehog to my existing project\", \"I want scope/verify enforcement on my changes here\". Not chosen by matching a `when` paragraph the way a shipped core is: hedgehog-adopt reads the repo read-only, proposes a linear-chain .hedgehog/core.yaml whose verify commands are the repo's own, and writes only .hedgehog/ — never a workspace, never a stack migration. This is the core most often confused with authored: adopted brings discipline to an existing repo, while authored designs and scaffolds a workspace from scratch for something being built new — route here only when the work is landing on a codebase that already exists."
+    },
+    {
+      "name": "copywriting",
+      "flag": "--copywriting",
+      "package": "@skyf0xx/hedgehog-core-copywriting",
+      "version": "^0.1.1",
+      "language": "typescript",
+      "repository": "https://github.com/skyf0xx/hedgehog-core-copywriting",
+      "selects_when": "The description asks for a piece of writing or prose to be written or fixed as its own deliverable — marketing copy, a product announcement, UI microcopy strings, docs prose, an email, a pitch, an article, an essay, a blog post, or any other standalone written piece — with no page, app, or other artifact being built around it. Concrete signals: \"write an article about X\", \"write copy for X\", \"help me write a blog post\", \"make this sound less like AI\", \"fix this copy\", \"improve this writing\", \"draft a product announcement\", a request to run text through an AI-tell or humanizer check. Not just marketing/product framing — any standalone prose request qualifies, articles and essays included. The core drafts against `checkCopy()`, a real script running deterministic AI-tell and prose-quality checks (banned vocabulary, passive voice, readability score, sentence-length variance), not an agent's own self-review — a piece of writing ships because the script exited 0. This is the core most often confused with landing-page: landing-page's own copy skill still owns copy that's part of a full page build (headline, hero, section copy sequenced through that core's Chain Method); route here only when the writing is the entire ask, not one stage of a larger build."
     }
   ]
 }

package/src/registry/index.mjs

@@ -1,9 +1,10 @@
 // Core package registry. One entry per Hedgehog core — full-stack-app,
-// pwa-app, landing-page, deepseek-harness, and authored — naming the npm
-// package that ships its agents, skills, and (for the first four) scaffold,
-// plus the CLI flag `hedgehog init` accepts for it and the prose `planner`
-// reads aloud in Phase 0 to choose one. A fixed table, one entry per core,
-// discovered by name or flag rather than convention.
+// pwa-app, landing-page, copywriting, deepseek-harness, and authored —
+// naming the npm package that ships its agents, skills, and (for the
+// first five) scaffold, plus the CLI flag `hedgehog init` accepts for it
+// and the prose `planner` reads aloud in Phase 0 to choose one. A fixed
+// table, one entry per core, discovered by name or flag rather than
+// convention.
 //
 // `authored` carries no flag — it is never selected off a fixed list at
 // install time. hedgehog-core-design chooses it during planning (from-scratch

package/src/skills/hedgehog-planning-intake/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hedgehog-planning-intake
-description: Use on any core for first-run planning intake — Phase 0 runs the vendored BMAD-METHOD planning shelf, shared by every core, and Phase 1 (mining `04-prd.md` into intent records plus the Add-ons/sync-and-remote-entities decision) is full-stack-app's and pwa-app's shared procedure — identical mechanics, a different decision at step 5/8. Phase 0 also defines compressed intake, the path a user's explicit "just build it" choice takes on full-stack-app, pwa-app, and authored cores: one batched round of questions in place of the shelf, writing the same archive at the same path so Phase 1, `ux-planner`, and the Re-entry pass all keep their documented source. Also use for the Re-entry pass, which mines new scope into additional intents without re-running the shelf, on any core with a module axis to add an intent to (full-stack-app, pwa-app, authored) — landing-page has none, so its own new-scope path runs through `hedgehog-landing-loop`'s Correction Protocol instead. Invoked by the `planner` agent, which decides the path; don't run standalone. landing-page runs this skill's Phase 0 on first run, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1. An authored core runs this skill's Phase 0, then `hedgehog-core-design`, then this skill's Phase 1 mining against the designed layer sequence. A brownfield adoption (`hedgehog-adopt`) never runs this skill's shelf at all — the drivers BMAD elicits are already settled facts of a repo that already exists.
+description: Use on any core for first-run planning intake — Phase 0 runs the vendored BMAD-METHOD planning shelf, shared by every core, and Phase 1 (mining `04-prd.md` into intent records plus the Add-ons/sync-and-remote-entities decision) is full-stack-app's and pwa-app's shared procedure — identical mechanics, a different decision at step 5/8. Phase 0 also defines compressed intake, the path a user's explicit "just build it" choice takes on full-stack-app, pwa-app, and authored cores: one batched round of questions in place of the shelf, writing the same archive at the same path so Phase 1, `ux-planner`, and the Re-entry pass all keep their documented source. Also use for the Re-entry pass, which mines new scope into additional intents without re-running the shelf, on any core with a module axis to add an intent to (full-stack-app, pwa-app, authored) — landing-page has none, so its own new-scope path runs through `hedgehog-landing-loop`'s Correction Protocol instead. Invoked by the `planner` agent, which decides the path; don't run standalone. landing-page runs this skill's Phase 0 on first run, then mines the same archive through `hedgehog-landing-loop`'s own planning-intake section, that core's counterpart to this skill's Phase 1. copywriting runs this skill's Phase 0 the same way, then mines the same archive through `hedgehog-copywriting-loop`'s own planning-intake section into a what/audience/register brief — no module axis, so its own new-scope path runs through that loop's Correction Protocol rather than the Re-entry pass below. An authored core runs this skill's Phase 0, then `hedgehog-core-design`, then this skill's Phase 1 mining against the designed layer sequence. A brownfield adoption (`hedgehog-adopt`) never runs this skill's shelf at all — the drivers BMAD elicits are already settled facts of a repo that already exists.
 ---
 
 # Hedgehog Planning Intake
@@ -11,12 +11,15 @@ every core) and mining its output. On full-stack-app and pwa-app that
 mining is this skill's own Phase 1, into intent records written via
 `hedgehog intent
 add`; on landing-page it's `hedgehog-landing-loop`'s planning-intake
-section, into a subject/audience/job statement. This is the mechanics
+section, into a subject/audience/job statement; on copywriting it's
+`hedgehog-copywriting-loop`'s planning-intake section, into a
+what/audience/register brief. This is the mechanics
 `planner` calls once its Phase 0 core-selection check has picked a core —
 the interpretive judgment (which Feature becomes which intent, Confirm &
 Lock either way) belongs to `planner`; this skill (Phase 0, and Phase 1 on
-full-stack-app and pwa-app) and `hedgehog-landing-loop` (landing-page's
-own mining) are the fixed procedures that judgment runs inside.
+full-stack-app and pwa-app), `hedgehog-landing-loop` (landing-page's own
+mining), and `hedgehog-copywriting-loop` (copywriting's own mining) are
+the fixed procedures that judgment runs inside.
 
 That shelf run is a **first run**, once per project. When new scope
 enters play later on a core with a module axis (full-stack-app, pwa-app,