@skyf0xx/hedgehog 6.1.2 → 6.1.4

package/bin/cli.mjs

@@ -41,7 +41,7 @@ import {
   reapExpiredLeases,
 } from '../src/db/claim.mjs';
 import { readyTasks, formatReady } from '../src/db/ready.mjs';
-import { graphStatus, formatStatus } from '../src/db/status.mjs';
+import { graphStatus, formatStatus, inFlightTasks, formatBrief } from '../src/db/status.mjs';
 import { boundaryState, formatBoundary, formatPosition, formatHandoff } from '../src/db/boundary.mjs';
 import { commitGateStatus, formatCommitGate } from '../src/db/gate.mjs';
 import { detectDrift, recompileTasks, formatRecompile } from '../src/db/drift.mjs';
@@ -559,6 +559,7 @@ ${bold('Usage')}
   npx @skyf0xx/hedgehog verify <task-id> --owner <owner>   run scope + verify checks, commit on pass
   npx @skyf0xx/hedgehog status                    graph overview: counts by status, ready list, in flight,
                                                    and any drift from core.yaml
+  npx @skyf0xx/hedgehog status --brief            one line: what is in flight, and nothing else
   npx @skyf0xx/hedgehog ready                     preview which ready tasks are claimable now vs held back
   npx @skyf0xx/hedgehog quiesce                   report whether anything is still in flight
   npx @skyf0xx/hedgehog boundary                  is this a moment to clear context? exits 0 only if it is,
@@ -2529,7 +2530,18 @@ async function coreWarningLines() {
   ];
 }
 
-async function statusCommand() {
+// `--brief` answers one question — is anything `building` or
+// `verifying` — and prints one line. It exists because `hedgehog-daily`
+// asks that question before every change request, including the ones
+// that end in a two-line edit, and the full report below costs a core
+// load, a drift comparison, a readiness simulation, an override scan,
+// a commit-gate probe and an update check to answer it. The default
+// report is unchanged: this adds a cheaper question, it does not
+// replace the existing one, and a "yes" here is the cue to read the
+// full report.
+async function statusCommand(args = []) {
+  const brief = args.includes('--brief');
+
   await ensureDb();
 
   if (!(await exists(DB_PATH))) {
@@ -2538,6 +2550,21 @@ async function statusCommand() {
     return;
   }
 
+  if (brief) {
+    const db = openDb();
+    let inFlight;
+    try {
+      // Same reaping contract as the full report — a dead agent's
+      // expired lease must not read as in-flight work on either path.
+      reapExpiredLeases(db);
+      inFlight = inFlightTasks(db);
+    } finally {
+      db.close();
+    }
+    console.log(formatBrief(inFlight));
+    return;
+  }
+
   // Drift needs the core definition to compare against. A project
   // without one yet (deferred install, pre-bootstrap) simply gets the
   // status it always got; an unparseable one is reported but never
@@ -3514,7 +3541,7 @@ async function main() {
   }
 
   if (cmd === 'status') {
-    await statusCommand();
+    await statusCommand(args.slice(1));
     return;
   }
 

package/package.json

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

package/src/agents/reviewer.md

@@ -18,7 +18,12 @@ commit — the gate already covers that.
 - **A transition check the core's loop skill defines** — the point where
   one phase or layer closes and the next opens. That skill names when it
   calls you and what it wants confirmed; read it rather than assuming a
-  fixed boundary.
+  fixed boundary. Mechanically, that point is where a layer's
+  `verify_radius` is wider than its own `scope`, or the layer is
+  `exclusive: true` (`core.yaml`) — a join or integration point, where a
+  boundary violation would otherwise ship unreviewed. A layer whose
+  radius equals its scope needs no visit from you; the loop skill's own
+  phrasing of "where" is that fact stated in the core's own vocabulary.
 - **Correction Protocol**: when a downstream step reveals an upstream step
   was wrong. Review the patch and its fast-forwarded dependents together,
   as one unit.

package/src/agents/tweaker.md

@@ -1,27 +1,29 @@
 ---
 name: tweaker
-description: Use once a core's build is complete (every task in the build graph `complete`) and the user is offered a fresh-context session to iterate. Takes post-build tweak requests one at a time from a clean context, and — separately — reviews accumulated build 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 with a Stop Condition — not the `adopted` core, which has none; there, new change-work goes straight through `hedgehog-adopt` and `hedgehog-authored-loop` instead.
+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.
 model: sonnet
 color: green
 tools: Read, Glob, Grep, Edit, Write, Bash
 ---
 
 You are the tweaker role in the Hedgehog discipline. You exist for the
-session after a build finishes: the core's own loop skill has run to its
-Stop Condition, `hedgehog status` shows every task `complete`, and the user
-now wants to adjust something — a color, a copy line, a button's
-behavior — without carrying the entire build's context into the
+session with no build in flight: `hedgehog status --brief` names no task,
+and the user now wants to change something — a color, a copy line, a
+button's behavior, or the next piece of work on a repo Hedgehog was
+adopted into — without carrying a whole build's context into the
 conversation. You start from a cleared context on purpose. Re-read the
 friction log (`hedgehog friction list`) and the commit log rather than
 expecting anything to be remembered.
 
-**Not for the `adopted` core (`.hedgehog/core.yaml` written by
-`hedgehog-adopt`).** That core has no Stop Condition and no "build
-finished" moment for you to follow — adoption is the permanent way
-change lands, not a project with an end. A request there is just the
-next unit of change-work: it goes through `hedgehog-adopt`'s "Adding the
-first (or next) change-work" and `hedgehog-authored-loop`, not through
-this agent.
+**Every core reaches you, the `adopted` core included.** You size a
+request rather than assuming it: `hedgehog-daily` reads the installed
+core's own `.hedgehog/core.yaml`, which every core has. On an adopted
+repo, a small single-layer change stops at that gate's tweak exit and is
+made and committed here; anything above that line routes onward to
+`hedgehog-adopt`'s "Adding the first (or next) change-work" and
+`hedgehog-authored-loop`, per job 1's change-work and re-plan exits
+below. Adoption is the permanent way change lands on that repo, so both
+paths stay live there indefinitely — you are not an epilogue.
 
 You have two separate jobs. Don't blend them:
 
@@ -29,23 +31,25 @@ You have two separate jobs. Don't blend them:
    way any other Hedgehog change is (read the relevant code, make the
    smallest correct change, verify it, commit it).
 2. **Review the friction log, and separately ask the user for
-   feedback**, once, at the start of your first run for this build, and
-   — for each real friction pattern and each piece of user feedback
-   actually given — walk the user through turning it into its own GitHub
-   issue against the Hedgehog repo itself (`skyf0xx/hedgehog`), never the
+   feedback**, once per batch of accumulated friction, and — for each
+   real friction pattern and each piece of user feedback actually
+   given — walk the user through turning it into its own GitHub issue
+   against the Hedgehog repo itself (`skyf0xx/hedgehog`), never the
    user's own project repo. Friction-sourced issues get `bug` and
    `help wanted`; user-feedback-sourced issues get `suggestion`.
 
-Job 2 runs once per build, not once per tweak session. If the friction
-log is empty or has already been reviewed (see Constraints), skip
-straight to job 1.
+Job 2 is triggered by the log, not by the session: it runs when at least
+three rows have been logged since the last `reviewed:` marker (see
+Constraints). Below that, skip straight to job 1 — a stray entry or two
+is not a batch worth interrupting the user for, and it stays in the log
+for the review that does fire.
 
 ## Stack (locked)
 
 None of its own — you work inside whichever core's stack is already
-installed (a shipped core's, or the stack an authored core's
-`.hedgehog/core-design.md` names — the `adopted` core never reaches you,
-per the note above), editing the same files the core's own build agents
+installed (a shipped core's, the stack an authored core's
+`.hedgehog/core-design.md` names, or the existing repo's own stack on an
+adopted core), editing the same files the core's own build agents
 would. `gh` (GitHub CLI) for issue creation only, and only against
 `skyf0xx/hedgehog`, never the project's own remote.
 
@@ -53,44 +57,46 @@ would. `gh` (GitHub CLI) for issue creation only, and only against
 
 ### Job 1 — Tweak requests
 
-**In:** a user request to change something already built (copy, a
+**In:** a user request to change something that already exists (copy, a
 style, a piece of behavior), the existing codebase, the commit log.
 **Out:** the change, verified and committed, same conventional-commit
-discipline as the rest of the build (`fix(<scope>): <what>` or
+discipline as the rest of the project (`fix(<scope>): <what>` or
 `style(<scope>): <what>`, whichever fits).
 
-A tweak is a small, targeted edit to something that already exists —
-not a new module, not a new phase, not scope growth. If a request turns
-out to be either of those, say so and route it onward — a completed
-build is extendable, not sealed, and the user should not hear "no" where
-the answer is "that's a different session." Two destinations, and which
-one applies depends on whether the core has a module axis to hang new
-work on:
+**Size every request with the `hedgehog-daily` skill.** That skill owns
+the tweak / change-work / re-plan decision and its conditions, and it
+reads them against the installed core's own `.hedgehog/core.yaml` — run
+it rather than judging the size here. Nothing here is sealed, so a
+request above the tweak line gets routed, not refused.
 
-- **New scope on a module axis** routes to `planner`, which runs
-  `hedgehog-planning-intake`'s **Re-entry pass**: it adds intents for the
-  new work without re-running planning from scratch, and without
-  disturbing anything already built.
-- **Everything else** routes to the **Correction Protocol's post-build
-  entry**, in the core's own loop skill, which re-runs whichever phases
-  the change reaches and rebuilds the artifact.
+What each exit means for you:
 
-A core with no module axis has no intent for `planner` to add, so new
-work there is the second case, not the first — and the locked planning
-artifact that governs it (the brief, the design rationale, the layer
-sequence) is never rewritten to accommodate new scope. When that artifact
-genuinely no longer holds, the request is a different project and belongs
-in its own, not an edit to this one; say so rather than routing it. The
-core's own loop skill states which artifact governs and what the test is.
+- **Tweak** — make it here, per that skill's tweak exit and this file's
+  Workflow step 3.
+- **Change-work** — route it onward. On a module axis, that is `planner`
+  running `hedgehog-planning-intake`'s **Re-entry pass**, which adds
+  intents for the new work without re-running planning from scratch and
+  without disturbing anything already built. On the `adopted` core, that
+  is `hedgehog-adopt`'s "Adding the first (or next) change-work" and
+  `hedgehog-authored-loop`, which own change-work on that repo. A core
+  with neither a module axis nor the `adopted` core's own routing has no
+  intent for `planner` to add, so it goes to the **Correction Protocol's
+  post-build entry** in the core's own loop skill instead, which re-runs
+  whichever phases the change reaches and rebuilds the artifact.
+- **Re-plan** — the locked planning artifact no longer holds. Route to
+  `planner`'s re-entry pass, or, where that artifact's failure means the
+  request is a different project rather than an extension of this one,
+  say so plainly instead of routing. Never rewrite that artifact to
+  accommodate new scope.
 
 ### Job 2 — Friction review, user feedback, and issue suggestion
 
 **In:** `hedgehog friction list` (see "Friction log" below) — the
 running list of things that went wrong, caused repeated back-and-forth,
-or were implied by user feedback during the build, logged live by
+or were implied by user feedback while work was landing, logged live by
 whichever agent hit the friction, or by the orchestrating session
 itself, via `hedgehog friction add` — plus a direct question to the user
-asking whether they have any feedback on the build itself, separate from
+asking whether they have any feedback on working this way, separate from
 what the friction log shows.
 **Out:** one suggested Hedgehog GitHub issue per real, distinct friction
 pattern the log actually shows (labeled `bug` and `help wanted`), and
@@ -137,24 +143,26 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
 
 ## Workflow
 
-1. **Run `hedgehog status`** and check the recent commit log to confirm
-   the build actually reached its Stop Condition (every task
-   `complete`) — you're not the right agent for a build still in
-   progress.
-2. **First run only for this build** (see Constraints for how to tell):
-   run `hedgehog friction list` in full, and separately ask the user
-   directly whether they have any feedback on the build. Treat these as
+1. **Run `hedgehog status --brief`** and check the recent commit log.
+   One line, and if it names any task, work is in flight: stop — that
+   belongs to the core's own loop skill, not to you. Nothing named is
+   your entry condition, on every core.
+2. **When the friction log has a batch to review** (see Constraints for
+   how to tell): run `hedgehog friction list` in full, and separately ask
+   the user directly whether they have any feedback. Treat these as
    two independent sources feeding the same show → edit → approve →
    create sequence, each pattern/item tagged with the label its source
    determines.
-   - **Friction source.** If the log is empty: tell the user plainly
-     there's no friction on record. If it has entries: run **Detect** —
-     look for explicit user feedback about the discipline itself (not
-     the product), feedback that implies a discipline gap even where it
-     wasn't stated as a complaint, or the same kind of friction
-     recurring across different entries. A single one-off entry with no
-     recurrence and no explicit-or-implied "this should be different"
-     from the user is not a pattern; it stays in the log and move on.
+   - **Friction source.** Run **Detect** over the unreviewed rows — the
+     ones logged after the last `reviewed:` marker, which are the batch
+     that woke this job. Look for explicit user feedback about the
+     discipline itself (not the product), feedback that implies a
+     discipline gap even where it wasn't stated as a complaint, or the
+     same kind of friction recurring across different entries. A single
+     one-off entry with no recurrence and no explicit-or-implied "this
+     should be different" from the user is not a pattern; it stays in
+     the log and move on. A batch that yields no pattern at all is a
+     real outcome — say so plainly rather than manufacturing one.
      Group entries that trace to the same underlying gap into one
      pattern — don't count them as separate patterns just because
      they're separate log entries. The friction hotspots under
@@ -168,7 +176,7 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
      correlate so you know how much of the log the ranking covers. Each
      resulting issue is labeled `bug` and `help wanted`.
    - **User-feedback source.** Ask the user plainly whether they have any
-     feedback on the build — what went well, what didn't, anything
+     feedback on the work so far — what went well, what didn't, anything
      they'd want the discipline to do differently. If they say no or give
      nothing usable: note "no feedback given" and move on. If they give
      feedback, split it into distinct items the same way as friction
@@ -181,7 +189,8 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
    - Run **Ask permission to review**: state plainly how many distinct
      patterns and how many feedback items were found (as separate
      counts) and ask whether the user wants to see them. A "no" here ends
-     job 2 for this build — don't re-offer later in the same session.
+     job 2 for this batch — log the reviewed marker and don't re-offer
+     later in the same session.
    - If yes, **show exactly what will be shared, one item at a time**:
      the literal issue title and body, verbatim, as it would be filed —
      not a paraphrase of it. Include the repo it targets
@@ -201,8 +210,9 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
      approval on one issue is never approval for another.
    - Once every detected pattern and feedback item has been shown
      (created, edited-then-created, or declined), log the reviewed
-     marker (see Constraints) so this doesn't re-run on the next tweak
-     session for the same build.
+     marker (see Constraints). That marker is what closes this batch:
+     the rows it follows are reviewed, and the count that wakes job 2
+     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
@@ -211,11 +221,11 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
      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.
-3. **Job 1, every run**: take the user's tweak request, read the actual
-   code it touches (not a summary), make the change, verify it with the
-   touched layer's own `verify` command from `.hedgehog/core.yaml` —
-   matching whatever the core's own loop skill already gates on — and
-   commit it as its own small conventional commit.
+3. **Job 1, every run**: run the `hedgehog-daily` skill on the user's
+   request. On its tweak exit, make the change there — read the actual
+   code it touches (not a summary), edit, verify with the touched layer's
+   own `verify` command from `.hedgehog/core.yaml`, commit as its own
+   small conventional commit. On either other exit, route as above.
 4. **Repeat step 3** for as many tweaks as the user has, one at a time —
    don't batch unrelated tweaks into one commit.
 
@@ -243,7 +253,7 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
   split a single pattern into multiple issues just because multiple
   entries mention it.
 - A pattern that doesn't clear the "real pattern" bar (Workflow, step 2)
-  stays in the log for a future build's review — don't manufacture an
+  stays in the log for a later batch's review — don't manufacture an
   issue just to have something to show. The same applies to feedback:
   don't manufacture a suggestion issue when the user said they had none.
 - Friction-sourced issues are always labeled `bug` and `help wanted`;
@@ -253,18 +263,23 @@ discipline as `.hedgehog/BMAD/`. A later related incident is its own new
   `hedgehog friction add "reviewed: <date>, issues: <url[, url...] or
   none filed>"` (no `--task`) rather than a separate state file — one
   table, append-only, same as the rest of this file's discipline. Job 2's
-  first-run check is: does `hedgehog friction list` already end with a
-  `reviewed:` row logged after every other row currently in the log?
+  wake-up check reads that marker out of `hedgehog friction list`: count
+  the rows logged after the last `reviewed:` row (every row, when there
+  is none yet), and run job 2 only at **three or more**. The floor is
+  what makes the trigger a property of the log rather than of the
+  session — a project with no build boundary to hang "once" on still
+  gets exactly one review per accumulated batch, and a single stray
+  entry never interrupts a one-line fix.
 - Never edit or delete a prior row in the `friction` table — it's
   write-once per row, same as `.hedgehog/BMAD/`.
-- Don't expand a tweak into a rebuild. If a "tweak" actually requires
-  redoing a phase (the artifact an upstream phase locked has to change,
-  not just one line of what a later phase produced from it), that's the
-  Correction Protocol — say so and route it
-  there rather than patching around it here. Use its **post-build entry**
-  (in this core's own loop skill): the build is already at its Stop
-  Condition, so there's no task in flight to stop and no loop to resume,
-  and the correction is fixed forward in new commits rather than by
+- Don't expand a tweak into a rebuild. A request `hedgehog-daily` sizes
+  above the tweak line gets routed, never patched around here — and a
+  tweak that turns out mid-edit to reach a second layer or need a file
+  that doesn't exist stops and re-enters that gate.
+- When the route is the Correction Protocol, use its **post-build entry**
+  (in this core's own loop skill): your entry condition is that nothing
+  is in flight, so there's no task to stop and no loop to resume, and
+  the correction is fixed forward in new commits rather than by
   reopening a `complete` task. The orchestrating session runs it and owns
   the commits, the same way `hedgehog verify` always is.
 - Don't run job 2's friction detection against anything other than

package/src/db/status.mjs

@@ -55,6 +55,27 @@ function loadInFlightTasks(db) {
   return db.prepare(IN_FLIGHT_TASKS_SQL).all();
 }
 
+// The in-flight list on its own, without the rest of graphStatus. The
+// full report costs a drift comparison against core.yaml, a readiness
+// simulation, an override scan, and two side-channel reads — everything
+// `hedgehog status` prints. `hedgehog-daily` asks only "is a build in
+// flight" and asks it before every change request, so it must not pay
+// for a report it discards. Same query and same reaping contract as the
+// full path; only the other sections are skipped.
+export function inFlightTasks(db) {
+  return loadInFlightTasks(db);
+}
+
+// One line for `hedgehog status --brief`: what is in flight, or that
+// nothing is. Deliberately not a subset of formatStatus's sections — a
+// caller reading this wants a verdict, and the full report stays the
+// right thing to read once the verdict is "something is".
+export function formatBrief(inFlight) {
+  if (inFlight.length === 0) return 'IN FLIGHT  0  — nothing building or verifying';
+  const ids = inFlight.map((task) => task.id).join(', ');
+  return `IN FLIGHT  ${inFlight.length}  — ${ids}`;
+}
+
 function countTasksByStatus(db) {
   const rows = db
     .prepare('SELECT status, COUNT(*) AS n FROM tasks GROUP BY status')

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

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

package/src/skills/filing-issues/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: filing-issues
+description: Use when filing one or more GitHub issues for planned work — "file an issue for this", "turn this plan into issues", "open a tracking issue". Covers filing everything on skyf0xx/hedgehog regardless of which repo's code changes, whether to split a plan into a tracking issue plus sub-issues, which account files the issue, labels, and acceptance criteria. For how to word an issue, see the pr-writing skill.
+---
+
+# Filing issues
+
+The mechanics of getting planned work into GitHub. `pr-writing` owns how
+an issue is worded — title shape, the Why/What structure, `<details>`
+folding, and style. This skill owns everything before and around that.
+
+## Which repo
+
+Every issue is filed on `skyf0xx/hedgehog`, never on a core's own repo
+(e.g. the one shipping `full-stack-app` or `pwa-app`) — one issue queue
+to track and review, regardless of which repo's code changes.
+
+When the fix actually lands in a core repo, open the issue body with a
+line naming that repo and linking it, so a contributor knows where the
+PR belongs even though the issue itself doesn't live there.
+
+## One issue or several
+
+Split when the parts have different reviewers, different repos, different
+risk, or can be worked in parallel. Keep one issue when the work is a
+single reviewable change, even a large one.
+
+A split gets a tracking issue plus sub-issues:
+
+- The tracking issue carries the Why, the scope boundary, and a numbered
+  list of sub-issues with a one-line description of each.
+- Each sub-issue is self-contained — someone picking it up should not
+  have to read the tracker to know what to do.
+- State the dependency edges explicitly, including their absence:
+  which can be picked up now, which blocks which, and which merely
+  prefer an order without blocking.
+- File the tracker first so sub-issues can reference its number, then
+  patch the tracker with the real numbers once they exist.
+- Comment `Part of #<tracker>` on each sub-issue.
+
+## Which account files it
+
+Issues go out as the user's own `gh` session by default.
+
+Some projects have a bot identity for maintainer actions. Use it only
+when the user asks for it by name. A bot voice tuned for short notes
+does not apply to a planned-work issue — write the issue at full length
+and say that is what you are doing.
+
+## Labels
+
+Read the target repo's labels before filing (`gh label list --repo
+<owner/repo>`) — the engine repo and the core repos carry overlapping but
+not identical sets.
+
+Apply what is verifiable at filing time: a type label (`feature`, `bug`,
+`documentation`) and any `risk:` label the change clearly earns.
+`good-first-issue` fits an issue that is genuinely self-contained with an
+obvious done state. Leave `size:` labels alone — they describe a diff
+that does not exist yet.
+
+## Acceptance criteria
+
+End every issue with a checkbox list a contributor ticks off and a
+reviewer checks against. Each line is one observable outcome, not a
+restatement of the task list.
+
+- Testable by inspection or a command, not by judgment. "`pnpm nx test
+  mobile -- src/{module}/` passes on generated output" — not "the
+  generator works well."
+- Include the things that must *not* change: the existing behavior that
+  still has to pass, the version that must not be bumped.
+- Cover the whole change. A criterion nobody can check is noise; a
+  missing one is a gap a reviewer has to find themselves.
+
+On a tracking issue, the criteria are the sub-issues plus the end-to-end
+outcome that proves the whole set landed.
+
+## Before filing
+
+Verify every claim the issue makes about existing behavior, and cite it
+`file:line`. An issue is public and durable — a wrong claim in one sends
+a contributor down a path that does not exist.
+
+Confirm the split and the identity with the user before creating
+anything — the repo is fixed, not a decision to make each time. Issue
+creation is public and hard to reverse.

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

@@ -0,0 +1,125 @@
+---
+name: hedgehog-daily
+description: Use when a change request lands on a project that already has `.hedgehog/` and no build in flight — a finished build being adjusted, or an adopted repo's next piece of work. Triggers on any "change this", "fix this", "add this" on such a project. Sizes the request against the installed core's own layers and routes it to one of three exits: a tweak made and committed here, change-work through `hedgehog intent add` and the core's loop, or a re-plan. Not for a build still in progress — that is the core's loop skill's own job.
+---
+
+# Daily change-work
+
+One gate, three exits, for every change request on a project whose build
+graph already exists. It reads the installed core's layer sequence,
+scope globs and verify commands out of `.hedgehog/core.yaml`, so it is
+the same gate on every core.
+
+The gate exists to stop pricing a two-line edit at the cost of the
+largest change the discipline can handle. Routing up is a real decision
+with a real cost, taken on stated conditions — not the safe default.
+
+## Entry
+
+1. **`.hedgehog/` exists.** Without it there is no core to read and no
+   graph to add to; this skill does not apply.
+2. **Nothing is in flight.** `hedgehog status --brief` — one line. If it
+   names any task, a build is mid-flight: this gate does not run. Read
+   the full `hedgehog status` and hand the request back to the core's own
+   loop skill, which owns work in progress.
+3. **Read `.hedgehog/core.yaml`.** The layer list is the input to every
+   decision below: each layer's `id`, `scope` globs, `verify` command,
+   `verify_radius` and `exclusive`. Read the file, not a memory of it.
+
+## The three exits
+
+Decide by the conditions, in order. The first one that holds is the exit.
+
+### Re-plan
+
+The locked planning artifact that governs this project no longer
+describes what is being asked for. The core's own loop skill names which
+artifact governs — the brief and layer sequence for a shipped core,
+`.hedgehog/core-design.md` for an authored one, `.hedgehog/adoption.md`
+for an adopted one.
+
+Route to `planner`'s re-entry pass, which adds intents for new work
+without re-running planning from scratch and without disturbing anything
+already built.
+
+Where the artifact's failure means the request is a different project
+rather than an extension of this one, say so plainly instead of routing.
+That artifact is never rewritten to accommodate new scope.
+
+### Change-work
+
+Either condition puts the request here:
+
+- It reaches more than one of the core's layers.
+- It introduces a file, module, or capability that does not exist yet.
+
+`hedgehog intent add`, then the installed core's own loop, unchanged.
+Nothing about that path changes because this gate ran.
+
+### Tweak
+
+Both conditions hold:
+
+- Every file it touches is inside one layer's `scope` globs — one
+  layer, not two.
+- Every file it touches already exists.
+
+Then, in this session, with no subagent dispatched:
+
+1. Read the code it touches. Not a summary of it.
+2. Make the smallest correct edit.
+3. Run that layer's own `verify` command from `core.yaml`, at the depth
+   the next section states.
+4. Commit as one conventional commit, in the format the
+   `conventional-commits` skill states.
+
+No `hedgehog intent add`, no `hedgehog plan`, no `hedgehog claim`, no
+subagent. Nothing is written to the build graph.
+
+### Tweak is the default under ambiguity
+
+When the conditions do not clearly place a request above the tweak line,
+it takes the tweak exit. A gate that escalates when unsure prices every
+change at its worst case, which is the failure this gate exists to
+avoid.
+
+An escalation the tweak reveals is cheap: a tweak that turns out to
+touch a second layer or need a file that does not exist stops there and
+re-enters this gate at the change-work exit, having cost one read.
+
+## Test and review depth on the tweak exit
+
+A tweak inherits the test and review bar of the layer it lands in.
+
+- A layer whose `verify_radius` equals its `scope`: run the layer's
+  `verify` command. No new tests, no `reviewer` pass.
+- A layer with a wider `verify_radius`, or `exclusive: true`: the same
+  real test bar and `reviewer` pass that layer gets in the loop.
+
+That is the loop's own rule — "Test depth follows verify radius. Review
+follows exclusivity", stated in full in the core's loop skill — applied
+to a layer instead of a compiled task. `verify_radius` and `exclusive`
+are declared on the layer in `core.yaml`, so both are readable on a path
+that compiles no task.
+
+**A tweak landing in a wide-radius or exclusive layer is a signal.**
+Integration layers are where behavior gets proven, so a change reaching
+one is rarely as small as it looked when it was asked for. Re-check that
+the tweak exit was the right exit. Do not bolt the loop's ceremony onto
+the tweak path instead.
+
+**The floor does not move.** A tweak to code with no tests does not get
+to leave it that way where the layer's own bar says otherwise.
+
+## Hard rules
+
+- Never take the tweak exit on a file that does not exist yet. A new
+  file is change-work by condition, whatever its size.
+- Never widen a layer's `scope` to make a change fit the tweak exit.
+  A change that needs a wider scope is change-work.
+- Never commit a tweak whose layer `verify` command fails. A failing
+  gate means the change is not done.
+- Never batch two unrelated tweaks into one commit.
+- Never rewrite the locked planning artifact to accommodate new scope —
+  that is the re-plan exit's decision, and its answer may be that this
+  is a different project.