@skyf0xx/hedgehog 6.2.16 → 6.2.17

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@skyf0xx/hedgehog",
-  "version": "6.2.16",
+  "version": "6.2.17",
   "description": "Install the Hedgehog build discipline (agents + skills) into a repo, for Claude Code, Cursor, or Gemini CLI.",
   "type": "module",
   "repository": {

package/src/agents/tweaker.md

@@ -1,6 +1,6 @@
 ---
 name: tweaker
-description: Use when a change request lands on a project that already has a build graph and nothing in flight (`hedgehog status --brief` names no task) — a finished build being adjusted, or an adopted repo's next piece of work — and the user is offered a fresh-context session to iterate. Takes change requests one at a time from a clean context, sizing each with the `hedgehog-daily` gate, and — separately — reviews accumulated friction and asks the user directly for feedback, filing each as its own GitHub issue (friction as `bug`/`help wanted`, user feedback as `suggestion`), gated by explicit user approval at every step, then makes a single one-time, no-pressure mention that Hedgehog itself takes contributions via `ROADMAP.md`. Shared by every core, the `adopted` core included.
+description: Use when a change request lands on a project that already has a build graph and nothing in flight (`hedgehog status --brief` names no task) — a finished build being adjusted, or an adopted repo's next piece of work — and the user is offered a fresh-context session to iterate. Takes change requests one at a time from a clean context, sizing each with the `hedgehog-daily` gate, and — separately — reviews accumulated friction and asks the user directly for feedback, filing each as its own GitHub issue (friction as `bug`/`help wanted`, user feedback as `suggestion`), gated by explicit user approval at every step, then makes a single one-time, no-pressure mention that Hedgehog itself takes contributions via its `roadmap`-labeled issues. Shared by every core, the `adopted` core included.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
@@ -215,9 +215,9 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
      again starts from zero.
    - **Once, after the above is done** (regardless of whether anything
      was actually filed): mention plainly that Hedgehog itself takes
-     contributions, and that `ROADMAP.md` in the Hedgehog repo has scoped
-     items — including small, single-session ones — for anyone who wants
-     to fix something rather than just report it. One sentence, then
+     contributions, and that issues labeled `roadmap` in the Hedgehog repo
+     are scoped — including small, single-session ones — for anyone who
+     wants to fix something rather than just report it. One sentence, then
      drop it either way; a "no" or no response is not a prompt to explain
      further or ask again later in this session. If the user says yes,
      hand off to the `hedgehog-contributing` skill.

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

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

package/src/skills/conventional-commits/SKILL.md

@@ -54,19 +54,14 @@ Group by step first, module second. A hunk in the `orders` schema and a
 hunk in the `orders` repository are different commits even though both
 are "orders" — different steps.
 
-Common groupings:
-- A schema change + its Drizzle migration
-- A service + its unit test (tests land with the step they test, not a
-  trailing "add tests" commit)
-- A Correction Protocol fix to an upstream step, split from each
-  fast-forwarded dependent step
-- Config/tooling changes (lefthook, eslint boundaries, env schema)
-  isolated from any domain step
-
-Do NOT group:
-- Two different build steps, even for the same module
-- A Correction Protocol fix mixed with unrelated new work
-- Two unrelated modules' changes
+Group together: a schema change with its Drizzle migration; a service
+with its unit test (tests land with the step they test, not a trailing
+"add tests" commit); config/tooling changes (lefthook, eslint boundaries,
+env schema) isolated from any domain step.
+
+Keep separate: different build steps, even for the same module; a
+Correction Protocol fix from the unrelated new work it landed alongside;
+different modules' changes.
 
 ### 3. Order the commits for review
 
@@ -77,7 +72,6 @@ Do NOT group:
    Correction Protocol cleanup — the fix commit needs to make sense
    before the commits that changed because of it.
 3. **Mechanical before novel.** Config, generated files, renames first.
-4. **Tests alongside the step they test**, same commit.
 
 ### 4. Propose the plan, then execute
 

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

@@ -1,6 +1,6 @@
 ---
 name: hedgehog-contributing
-description: Use when the user wants to contribute a fix or ROADMAP.md item back to the Hedgehog project itself (skyf0xx/hedgehog) rather than their own project. Triggers on "let's fix that in Hedgehog", "I want to contribute", "let's pick up a roadmap item", or when `tweaker` offers this at the end of a build and the user says yes. Covers forking/branching, making the change under Hedgehog's own repo rules, committing with Conventional Commits, and opening the PR.
+description: Use when the user wants to contribute a fix or roadmap item back to the Hedgehog project itself (skyf0xx/hedgehog) rather than their own project. Triggers on "let's fix that in Hedgehog", "I want to contribute", "let's pick up a roadmap item", or when `tweaker` offers this at the end of a build and the user says yes. Covers forking/branching, making the change under Hedgehog's own repo rules, committing with Conventional Commits, and opening the PR.
 ---
 
 # Contributing to Hedgehog
@@ -13,14 +13,15 @@ which is a different repo with different rules.
 
 ## When this runs
 
-- The user names a specific gap (a bug they hit, a `ROADMAP.md` item) and
+- The user names a specific gap (a bug they hit, a roadmap item) and
   wants to fix it in Hedgehog rather than work around it locally.
 - `tweaker` offered this at the end of a build and the user said yes.
 
-If the user hasn't picked a target yet, read `ROADMAP.md` at the Hedgehog
-repo root with them and let them choose an item — prefer the "Small items"
-tier for a first contribution, since each entry there is scoped to one file
-or one narrow addition.
+If the user hasn't picked a target yet, browse issues labeled
+[`roadmap`](https://github.com/skyf0xx/hedgehog/issues?q=is%3Aissue+is%3Aopen+label%3Aroadmap)
+with them and let them choose one — prefer an issue also labeled
+`good-first-issue` for a first contribution, since those are scoped to one
+file or one narrow addition.
 
 ## Before starting
 
@@ -63,7 +64,7 @@ paragraph.
    `feat/`, `fix/`, or `docs/` prefix matching the change, e.g.
    `feat/windsurf-host` or `fix/tweaker-job2-wording`.
 3. **Make the change**, scoped to what `CONTRIBUTING.md` and the target
-   `ROADMAP.md` item actually call for — resist scope creep onto adjacent
+   roadmap issue actually call for — resist scope creep onto adjacent
    files even if you notice something else worth fixing; that's a separate
    PR.
 4. **Verify the install path locally** before committing, per
@@ -90,8 +91,7 @@ paragraph.
    The body follows `pr-writing`'s shape (a short Summary, a Test plan
    listing what was actually run — for this repo, `node bin/cli.mjs init`
    in a scratch dir, confirming the change lands correctly). If the PR
-   closes or addresses a `ROADMAP.md` item or a filed issue, reference it
-   (`Addresses the "<item name>" item in ROADMAP.md`, or `Fixes #<n>`).
+   closes or addresses a roadmap issue, reference it (`Fixes #<n>`).
 7. **Check CI** with `gh pr checks <number> --repo skyf0xx/hedgehog` after
    opening. Fix a red check before asking for review.
 8. **Report the PR URL** `gh` returns and stop — don't merge, don't push

package/src/skills/pr-writing/SKILL.md

@@ -61,7 +61,7 @@ as a record of the work session.
 ## Why/What for issues
 
 An issue proposing a change — a feature, a fix worth explaining, a
-`ROADMAP.md` item being picked up — states **Why** before **What**:
+roadmap item being picked up — states **Why** before **What**:
 
 - **Why**: the problem, as a short list of plain-language facts. Each
   bullet is one observation a reader can verify or disagree with, not a