voidmachine 0.0.0 → 4.0.0

package/core-assets/skills/void-claude-md/SKILL.md

@@ -0,0 +1,180 @@
+---
+name: void-claude-md
+description: Author a lean, runnable CLAUDE.md (or AGENTS.md). Only universal instructions; defer detail to docs; push style to linters and certainties to hooks. Use when writing or auditing a project CLAUDE.md.
+---
+
+# claude-md
+
+A CLAUDE.md is not free documentation. Claude Code injects it wrapped in a system-reminder that says it "may or may not be relevant," and the system prompt already spends on the order of fifty instructions before yours arrive. Every line you add competes for the model's attention with every other line, so a bloated CLAUDE.md does not make the agent more careful — it dilutes the few instructions that actually matter and quietly buries them. This skill governs how the harness writes the CLAUDE.md files it ships into consumer projects: minimal, universal, runnable, with detail deferred and certainties mechanized.
+
+**Attribution**: see `.source` in this directory.
+
+---
+
+## The load-bearing insight
+
+The CLAUDE.md is appended to the system prompt with a "may or may not be relevant" framing. That framing is the whole game:
+
+- It is **not** a contract the model must obey. It is context the model weighs.
+- Attention is finite and shared. A 400-line CLAUDE.md does not give you 400 enforced rules; it gives you 400 things competing to be the one the model attends to this turn.
+- So the question for every line is never "is this true?" but **"does this earn a slot against everything else here?"**
+
+Target ~60 lines. Hard ceiling well under 150 instructions. If you are past that, you are not documenting — you are hoping.
+
+---
+
+## What belongs in CLAUDE.md
+
+Only the **universal** and the **load-bearing**:
+
+- How to run the project: build, test, dev server, the one command that proves the agent's change works.
+- Repo-wide architecture in one or two sentences (where domain lives, where infra lives) — enough to orient, not a tour.
+- Project-wide invariants that have no mechanical enforcer yet (a boundary no linter checks, a domain rule).
+- Pointers to the docs that hold the detail (progressive disclosure, below).
+
+That is most of it. A good CLAUDE.md is short because almost everything else has a better home.
+
+---
+
+## What does NOT belong (and where it goes)
+
+| Tempting to inline | Why it does not earn its slot | Where it belongs |
+|---|---|---|
+| Code style, formatting, naming, import order | An LLM is a probabilistic stylist; a linter is deterministic. Never send an LLM to do a linter's job. | hooks / formatter / linter config |
+| Code snippets / example implementations | They rot the moment the referenced code changes, and lie silently after. | a `file:line` reference to the real code |
+| Anything that must happen 100% of the time | An instruction is obeyed *probabilistically*; a hook fires *always*. | a hook |
+| Deterministic config: permissions, tool attribution, env | CLAUDE.md is read by a fallible reader; settings is read by the runtime. | `settings.json` |
+| Long process docs, runbooks, deep architecture | Burns the budget for content needed only occasionally. | `agent_docs/…` or `.void/…`, referenced on demand |
+| Per-feature or per-subdir specifics | Not universal; pollutes every unrelated task. | a nested `CLAUDE.md` in that subdir, or a doc |
+
+The pattern is one rule: **route each instruction to its strongest enforcer.** The strongest enforcer is almost never the CLAUDE.md.
+
+---
+
+## Progressive disclosure
+
+Do not inline detail you need only sometimes. State the pointer, not the payload:
+
+```markdown
+Database migrations follow a strict expand/contract protocol.
+Read `agent_docs/migrations.md` before touching any migration.
+```
+
+The agent reads the doc when the task calls for it and pays zero budget when it does not. This is how a 60-line CLAUDE.md governs a large codebase: it is an index into deeper docs, not the docs themselves.
+
+For genuinely conditional guidance, scope it tightly:
+
+```markdown
+<important if="editing files under packages/billing/">
+Money is integer cents, never floats. See `agent_docs/money.md`.
+</important>
+```
+
+A narrow `if` condition keeps the instruction out of attention for every task it does not apply to. A wide or vague condition is just an always-on instruction wearing a costume.
+
+---
+
+## Runnable, not aspirational
+
+A CLAUDE.md is correct only if it is **runnable**: an agent that reads "run the tests with `pnpm test`" and runs it must succeed on the first try, in a clean checkout. The same goes for build and dev commands.
+
+- A command that needs an undocumented setup step is a broken instruction, not a terse one.
+- Test the CLAUDE.md the way you would test code: fresh clone, follow it literally, see if it works.
+- An aspirational CLAUDE.md ("we lint with X" — but the lint script is missing) teaches the agent to distrust the whole file.
+
+---
+
+## Auditing an existing CLAUDE.md
+
+The harness must be able to prune its own and its consumers' files. Walk every line with one question:
+
+**"Would removing this line cause the agent to make an error?"** If not, cut it.
+
+Pruning checklist:
+
+- [ ] **Style/format rules** → move to linter/formatter, delete from CLAUDE.md.
+- [ ] **Certainties** ("always run X after Y") → convert to a hook, delete the instruction.
+- [ ] **Code snippets** → replace with a `file:line` reference.
+- [ ] **Deep/occasional detail** → extract to `agent_docs/…` or `.void/…`, leave a pointer.
+- [ ] **Non-universal specifics** → move to a nested `CLAUDE.md` or a doc.
+- [ ] **Deterministic config** → move to `settings.json`.
+- [ ] **Vague/decorative lines** ("write clean code", "be careful") → delete; they cost a slot and enforce nothing.
+- [ ] **Unconditional lines that apply only sometimes** → wrap in a narrow `<important if="…">` or move out.
+- [ ] **Stale commands** → verify each is runnable from a clean checkout; fix or remove.
+
+A CLAUDE.md gets *shorter* over a healthy project's life, not longer. Growth without pruning is the default failure.
+
+---
+
+## Composition with other skills
+
+- **`void-context`**: the foundation. Context is the constraint; CLAUDE.md spends from the same budget every task pays. This skill is that principle applied to the always-on prompt.
+- **`void-source-driven-development`**: when CLAUDE.md points at a deferred doc, that doc grounds tool config in version-matched official sources rather than inlining remembered config into the prompt.
+- **`void-learn`**: the harness *produces* CLAUDE.md files for consumer projects; this skill is the doctrine those generated files must obey. A "the harness should add X to CLAUDE.md" gap (Branch B) is judged against this skill before it lands. When a user states a *project-specific* rule, learn (Branch A) routes it; this skill answers *where it lands* — universal certainty → hook; deterministic → settings; project invariant with no enforcer → a lean CLAUDE.md line; deep detail → a deferred doc.
+
+---
+
+## Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "More instructions make the agent more careful." | More instructions dilute attention; the rule that mattered is now buried among forty that did not. Fewer, sharper lines win. |
+| "I'll inline the style rules so it always formats right." | It will *not* always format right — instructions are probabilistic. A formatter is deterministic. Send the linter, not the LLM. |
+| "A short code example makes it concrete." | The example rots when the code moves and then lies. A `file:line` pointer stays true. |
+| "This is important, so it has to live in CLAUDE.md." | If it must happen every time, it is a hook, not an instruction. CLAUDE.md cannot guarantee 'every time.' |
+| "Better to over-document than miss something." | Over-documenting is how you miss something: the signal drowns. Pruning is documentation. |
+| "I'll just let `/init` generate it." | Auto-generated CLAUDE.md is bloated by default — it inlines style, snippets, and obvious facts. Generate, then prune hard against the audit checklist. |
+| "It's only a few extra lines." | Every line evicts attention from the others. There is no free line in an always-on prompt. |
+
+---
+
+## Verification
+
+Before shipping or approving a CLAUDE.md:
+
+- [ ] Length near the ~60-line target; well under the ~150-instruction ceiling.
+- [ ] No code-style/format/naming rules (those live in linter/formatter config).
+- [ ] No code snippets that can rot — references are `file:line`.
+- [ ] Every "must happen every time" certainty is a hook, not an instruction.
+- [ ] Deterministic config (permissions, attribution, env) is in `settings.json`, not here.
+- [ ] Deep/occasional detail is deferred to `agent_docs/…` or `.void/…` with an explicit "read it when…" pointer.
+- [ ] Conditional guidance uses a narrowly-scoped `<important if="…">`, not an always-on line.
+- [ ] Every line survives "would removing it cause an error?" — no decorative or vague filler.
+- [ ] Runnable: build/test/dev commands succeed from a clean checkout on the first try.
+
+If any box is unchecked, the file is spending attention budget it has not earned.
+
+---
+
+## Anti-rules
+
+- MUST NOT put code-style, formatting, or naming rules in CLAUDE.md — those are a linter's job.
+- MUST NOT inline code snippets — reference `file:line` so they cannot rot.
+- MUST NOT encode an every-time certainty as an instruction — make it a hook.
+- MUST NOT inline deterministic config (permissions, attribution, env) — put it in `settings.json`.
+- MUST NOT add non-universal or decorative lines — every line must earn its attention slot.
+- MUST NOT ship an auto-generated CLAUDE.md unpruned — generate, then audit it down.
+- MUST NOT leave an unrunnable command in the file — verify from a clean checkout.
+
+---
+
+## When you are stuck
+
+| Problem | Solution |
+|---|---|
+| Unsure if a line belongs | Ask "would removing it cause an error?" No → cut it. |
+| The file keeps growing | You are adding without pruning. Run the audit checklist; route each line to its strongest enforcer. |
+| Want a rule enforced 100% of the time | That is a hook, not a CLAUDE.md line. |
+| Need a lot of detail somewhere | Defer it to `agent_docs/…` / `.void/…` and leave a one-line pointer. |
+| A rule applies only to one area | Nested `CLAUDE.md` in that subdir, or a narrow `<important if="…">`. |
+| `/init` produced something huge | Treat it as a draft; prune hard against the audit checklist before shipping. |
+
+---
+
+## Final rule
+
+```
+CLAUDE.md → only universal, load-bearing, runnable lines; style to linters,
+certainties to hooks, config to settings, detail to deferred docs.
+Otherwise → it spends attention budget it never earned, and buries the rules that mattered.
+```

package/core-assets/skills/void-claude-md/harness.yaml

@@ -0,0 +1,14 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: standard
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: active
+    codex: active
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-code-review/.source

@@ -0,0 +1,14 @@
+Sources for `void-code-review` skill (see `docs/plans/skill-audits/void-code-review.md` for full audit):
+
+- citypaul/.dotfiles pr-reviewer skill — dimensions list, blocker vs nit distinction
+- superpowers/requesting-code-review + receiving-code-review — request perspective + absorb-feedback discipline
+- Google "engineering practices" code review docs — https://google.github.io/eng-practices/review/reviewer/ — CL Size, How to handle pushback
+- gstack /code-review — composed at effort levels low/medium/high/max/ultra (diff analysis)
+- gstack /codex review — composed for independent second opinion (different model family)
+- gstack /review (PR review) — composed at PR level for SQL safety + LLM trust boundary
+
+Strategy: distill + compose. Skill orchestrates dimensions + composition; a diff-analysis tool does the enumeration; the `doctrine-critic` agent handles the doctrine-conformance deep pass (security routes to void-security-audit).
+
+Tool repoint (DEV-399, 2026-07-10): the enumeration engine was gstack `/code-review` and the second opinion was gstack `/codex review`. Both were repointed off gstack — the enumeration now runs Claude Code's **native `/code-review`** (low→ultra, `--comment`/`--fix`), the second opinion runs the standalone **`codex` CLI** (`~/.local/bin/codex`, cross-model, survives the gstack teardown). This unblocks DEV-395 (gstack teardown); the gstack lines above are historical attribution, not live dependencies. `/benchmark` (perf) and `/ship` remain gstack-composed pending DEV-401 / DEV-400.
+
+Companion hooks: pre-PR-review-evidence, large-cl-grep, blocker-prefix-grep.

package/core-assets/skills/void-code-review/SKILL.md

@@ -0,0 +1,232 @@
+---
+name: void-code-review
+description: Pre-PR critical pass. Six dimensions (correctness, tests, security, structure, readability, perf). Two modes (strict/souple). Composes the native /void-code-review and codex CLI. Use on a diff.
+---
+
+# code-review — voidcorp craftsman edition
+
+A review without a framework is "the first ten things I noticed." This skill provides the framework: six dimensions in order, blocker vs nit, evidence block in the PR body, two modes, explicit composition with Claude Code's native `/void-code-review` and specialized agents. The skill orchestrates; it does not duplicate the deep-pass agents.
+
+**Attribution**: see `.source` in this directory.
+
+---
+
+## Six dimensions, in order
+
+The order matters. A correctness issue blocks regardless of beautiful structure. A perf issue does not block if the first four dimensions are clean.
+
+1. **Correctness** — does it do what it claims? edge cases? error paths? composes with `void-tdd` (cycle evidence) and `void-debug` (root cause for fixes).
+2. **Tests** — failing test before the code? real code over mocks? names describe behavior? composes with `void-testing`.
+3. **Security** — input validated at trust boundaries? secrets handled? SQL safe? LLM input untrusted? composes with `void-security-guidance` (which routes deep audits to `void-security-audit`).
+4. **Structure** — boundaries respected (no domain importing infrastructure)? service/repository split? function lengths? composes with `void-hexagonal-architecture`, `void-domain-driven-design`, `void-refactor`, and the `doctrine-critic` agent.
+5. **Readability** — names? exhaustive switches? `any` slips? `as` casts? composes with `void-typescript-strict`.
+6. **Performance** — obvious O(n²) inside loops? leaky reactive subscriptions? unbounded queries? measured claims come from the project's perf tooling (Lighthouse CI, bundlesize), not guesses.
+
+A11y, observability, LLM cost discipline ride inside dimensions 1-6 (e.g. missing a11y is a Correctness issue at the UI boundary; missing structured log is a Structure issue at the service layer).
+
+### Leverage hierarchy in review
+
+Spend attention where defects cost the most. An upstream design or contract flaw (Correctness, Structure) cascades through everything downstream; a code-detail nit (Readability) stays local. Surface the high-leverage defects first, and weight scrutiny toward them.
+
+Do not over-engineer the review itself: report only what touches correctness or the stated requirements, not every possible finding. A reviewer who flags every theoretical improvement buries the one BLOCKER that matters. When in doubt, the bar is "would shipping this without the fix be wrong?" — if not, it is at most a `NIT:`.
+
+---
+
+## Blocker vs nit
+
+Every comment is explicitly prefixed:
+
+- **`BLOCKER:`** — must be fixed before merge. Block the PR.
+- **`NIT:`** — suggestion. Author decides. Does NOT block.
+- **`QUESTION:`** — clarification request. May escalate to BLOCKER if answer reveals a defect.
+- **`PRAISE:`** — explicit acknowledgement of good code (rare, but valued).
+
+Style / naming / minor structure: `NIT:`. Correctness / missing test / security / boundary violation: `BLOCKER:`.
+
+A review that does not use the prefixes is incomplete. The companion hook `blocker-prefix-grep` produces the BLOCKER/NIT count for the evidence block.
+
+---
+
+## PR body — review evidence
+
+Every PR in strict mode includes a Review Evidence block:
+
+```markdown
+## Review Evidence
+
+- **Mode**: strict
+- **Reviewer runtime**: native independent reviewer or codex CLI (one general pass)
+- **Dimensions covered**:
+  - [x] Correctness — tdd evidence verified (RED commit c925187, GREEN 5e0055b)
+  - [x] Tests — 4/4 passing, mutation score 94%, no business mocks
+  - [x] Security — trust boundary validated via Zod at /api/checkout
+  - [x] Structure — services do not touch DB (repository pattern verified)
+  - [x] Readability — typescript-strict clean (no any, no rogue as)
+  - [x] Performance — no measured claim, no obvious smell
+- **Blockers raised**: 0
+- **Nits raised**: 2 (variable rename suggestion, helper extraction suggestion)
+- **Claude vs Codex disagreement**: none
+- **Skipped dimension**: none
+```
+
+If a dimension is skipped, the reason is explicit. If Claude and Codex disagree, the deltas are surfaced — not silently arbitrated.
+
+The companion hook `pre-PR-review-evidence` warns if the PR body lacks this block (strict mode).
+
+---
+
+## CL Size discipline
+
+PRs larger than ~400 LOC of diff should either:
+
+- Be split into multiple PRs each focused on one concern
+- Or include a `large-cl-justification: <reason>` marker in a commit message
+
+Review quality decays after ~400 added LOC. The optional `large-cl-grep` adapter warns without blocking when a branch exceeds the threshold. It reads Git only: no forge, `gh`, or `jq` dependency.
+
+---
+
+## Modes
+
+| Mode | Trigger | Posture |
+|---|---|---|
+| **strict** | PR targeting `main` / `develop` / release branches. Pre-PR final pass. | All six dimensions checked. Blockers fail. Evidence block REQUIRED. Default effort: native `/void-code-review medium`, escalate to `ultra` for high-stakes diffs. Select one independent reviewer runtime. |
+| **souple** | In-progress feedback on a feature branch during work. WIP commits. | Dimensions checked at user discretion. No evidence block required. Default effort: native `/void-code-review low` or `medium`. |
+
+---
+
+## Composition with specialized agents and tools
+
+| Dimension | Composed with |
+|---|---|
+| Correctness, Tests | `void-tdd` skill (verify cycle), `void-testing` skill (verify quality), `doctrine-critic` agent (doctrine conformance) |
+| Security | `void-security-guidance` skill, `doctrine-critic` agent (flags boundaries), `void-security-audit` (only at user request for full audit) |
+| Structure | `void-hexagonal-architecture` skill, `void-domain-driven-design` skill, `doctrine-critic` agent (boundary spirit) |
+| Readability | `void-typescript-strict` skill, Biome (formatter) |
+| Performance | the project's perf tooling (Lighthouse CI, bundlesize) for measured claims; this skill flags only obvious smells |
+| Independent reviewer alternative | `codex review` (choose this or the native independent reviewer for the general pass) |
+| Diff analysis at high effort | native `/void-code-review medium` / `high` / `ultra` |
+
+The skill is the orchestration. Specialized agents and the native `/void-code-review` do the heavy work.
+
+---
+
+## Operating procedure
+
+### Pre-condition (strict mode)
+
+- The PR's HEAD has been built and tested locally / in CI. No build errors or failing required tests. Lint findings block only for a demonstrated consequence.
+- Inspect output for leaked data and actionable errors; advisory diagnostics do not reopen review.
+- The PR description includes a clear "what" and "why."
+
+If any pre-condition fails, the review pauses — fix the pre-condition first.
+
+### Pass
+
+1. Bind the task, acceptance criteria, exact commit and base before reading. Prefer a dedicated
+   worktree pinned to the commit, with native read-only permissions. The reviewer never edits.
+2. Perform one independent general review across the six dimensions. Report only demonstrated
+   consequences in scope. Every blocker names its violated criterion, concrete consequence,
+   evidence and resolution condition. Style and optional refactoring remain advisory.
+3. Preserve the minimal review receipt and original result: reviewer, subject, conclusions,
+   proofs and defect resolutions. Record missing or refused native identity as an exact
+   provenance limitation; it alone cannot reject a traceable independent review. Do not invent
+   independence or accept self-review as a substitute.
+4. The author corrects blockers or records a reasoned disagreement. After each correction batch,
+   verify only the corrections and affected behavior. Reuse unaffected conclusions and proofs;
+   never restart the general review. Newly raised blockers must demonstrate a correction
+   regression or a concrete defect within the original scope.
+5. Follow `void-implement`'s maximum two correction batches. Incomplete review, resumption and
+   transport repair do not consume or reset that budget. Advisory findings never request a
+   correction cycle. At the limit, report unresolved defects with cause and next action.
+6. The orchestrator may request one independent opinion on a disputed point and retain it
+   as evidence for targeted verification, without reopening general review or resetting the
+   budget. No separate automatic arbitration command is provided. Escalate beyond-mandate
+   decisions to the human. Retain historical
+   findings and their resolutions; never call an unresolved blocking defect conformant.
+
+
+### Author response (Google practices)
+
+- Address every BLOCKER (fix or reasoned pushback).
+- Read every NIT. Address those you agree with; ignore the rest.
+- Treat QUESTION as a thinking prompt — answer or escalate.
+- Push back when you disagree. Reviewer may hold ground with a clear "why."
+
+---
+
+## Banned
+
+### "LGTM" reviews
+
+A review that does not list the dimensions checked is not a review. Even "everything looks fine" requires the evidence block in strict mode.
+
+### File-by-file linear walk
+
+Default to dimension-by-dimension across the whole diff. Linear walk misses cross-file issues (service change without its repository update, schema change without its consumer update).
+
+### Style / naming bikeshedding marked as BLOCKER
+
+Style is solved by Biome + `void-typescript-strict`, not by reviewer preference. Anything stylistic is `NIT:` at most.
+
+### Architectural-rewrite suggestions inside the PR
+
+If the diff reveals a structural problem larger than the diff, add a `QUESTION:` comment + suggest a follow-up issue. Do not block on "rewrite this PR." Scope creep at review time tanks velocity.
+
+### Silent disagreement between Claude and Codex
+
+Disagreements are surfaced. Not averaged. The user decides.
+
+---
+
+## Composition summary
+
+- **Upstream**: `void-verify` (the author claims the code is ready before review starts).
+- **Downstream**: `void-commit-discipline` (the merge commit follows conventional commit + always-say-why), then the ship step (`void-implement` pass 11 + `gh` lands the PR; release-please owns versions).
+- **Side-by-side**: the `doctrine-critic` agent (doctrine conformance, read-only).
+
+---
+
+## Companion hooks
+
+- **`pre-PR-review-evidence`** (pre-push) — warn if PR body lacks the Review Evidence block (strict mode)
+- **`large-cl-grep`** (optional pre-push) — warn if the branch adds > 400 LOC without a commit-message `large-cl-justification:` marker
+- **`blocker-prefix-grep`** (post-review) — informational: count BLOCKER vs NIT comments for the evidence block
+
+See `../../hooks/`.
+
+---
+
+## Anti-rules
+
+- MUST NOT decide whether to ship — user owns the merge decision.
+- MUST NOT block on style / naming (Biome + `void-typescript-strict` jobs).
+- MUST NOT suggest scope expansion inside the PR — escalate to follow-up.
+- MUST NOT duplicate `doctrine-critic` or `void-security-audit` work — delegate.
+- MUST NOT silently arbitrate Claude-vs-Codex disagreements — surface them.
+- MUST NOT mark style nit as BLOCKER.
+- MUST NOT pass a review when the test suite has not been observed passing on the PR's HEAD.
+
+---
+
+## When you are stuck
+
+| Problem | Solution |
+|---|---|
+| Review feels shallow | You skipped a dimension. Walk all six in order. |
+| Cannot tell BLOCKER from NIT | Correctness / security / missing test / boundary violation = BLOCKER. Everything else = NIT. |
+| Diff is too large to review | Ask the author to split, or invoke `large-cl-justification:` if truly atomic. |
+| Found a structural rot beyond the diff | `QUESTION:` + suggest follow-up issue. Do not block this PR on it. |
+| Claude and Codex disagree | Surface the delta. Let the author/user decide. |
+| Cannot reach pristine output | Pre-condition failed. Pause the review until fixed. |
+
+---
+
+## Final rule
+
+```
+A review → six dimensions in order, blockers explicit, evidence in PR body (strict), delegated where deep.
+Otherwise → it is not a voidcorp code-review.
+```
+
+The independent reviewer examines the committed result. The author owns all code changes.

package/core-assets/skills/void-code-review/harness.yaml

@@ -0,0 +1,15 @@
+# Harness metadata for this skill. Not part of the Agent Skills
+# specification, and never copied into a consumer project: the SKILL.md
+# beside it stays portable and validates against the official six fields.
+# Read by this repository's graph, and by the installer for `runtimes`.
+kind: action
+activation: always
+owner: folpe
+runtimes: [claude, codex]
+enforcement:
+  floor: ci
+  inline:
+    claude: pretooluse
+    codex: pretooluse
+    hermes: ci-only
+eval_targets: [claude/anthropic/opus]

package/core-assets/skills/void-commit-discipline/.source

@@ -0,0 +1,9 @@
+Sources for `void-commit-discipline` skill (see `docs/plans/skill-audits/void-commit-discipline.md` for full audit):
+
+- Conventional Commits spec — https://www.conventionalcommits.org — foundation, allowed type list, footer conventions.
+- Folpe "always say why" rule (from DECLIK CLAUDE.md) — load-bearing addition: substantive commits MUST explain rationale.
+- citypaul/.dotfiles commit guidance — body wrapping, subject style.
+
+Strategy: original. Slim skill. Conventional Commits + Folpe "why" + scope guidance.
+
+Companion hooks: commitlint-precommit (pack-monorepo), tidying-commit-prefix (core, already shipped), refactor-named-grep (core, already shipped), no-emdash-no-emoji-in-commit-msg (pack-monorepo).