@lemoncode/lemony 0.5.1 → 0.6.0

package/catalog/skills/design-tool-sync/SKILL.md

@@ -20,6 +20,11 @@ ahead. That asymmetry shapes everything here:
 - **drift** is one-directional and deterministic: "has the JSON changed since the last
   export?" — a pure-JSON check that needs no tool connection.
 
+**Which file.** `docs/design-tokens.json` is the default path. When `harness.config.yml` sets
+`design_tokens.file`, the path it names (relative to the repository root) is the token file:
+read the binding from it and expect the CLI's import and export to act on it, wherever this
+skill says `docs/design-tokens.json`. Never create a second file at the default.
+
 You are invoked two ways: by `/sync-design-tokens` (the human's explicit handle, argument
 `import` or `export`), and at DEFINE when the drift check shows an export is pending and the
 current user has the tool connected.
@@ -80,10 +85,11 @@ variables and the DTCG JSON:
 
 The CLI maps this to the 3-tier DTCG model: `ref` → an alias `{path}`, `modes` →
 `$extensions["com.lemony.modes"]`, and the tier follows the path. A name without a tier
-lands on the one tier `docs/design-tokens.json` already has it in; otherwise a literal
-defaults to `primitive` and an alias to `semantic`. A bare `ref` — or a bare `{alias}` mode
-value — resolves to the tiered path its target lands at in the same neutral file, or to the
-one tier the token file has it in.
+lands on the one tier `docs/design-tokens.json` already has it in; otherwise a variable that
+is literal in every mode defaults to `primitive`, and one that is an alias in its base value
+or any mode to `semantic` (a primitive is literal in every mode). A bare `ref` — or a bare
+`{alias}` mode value — resolves to the tiered path its target lands at in the same neutral
+file, or to the one tier the token file has it in.
 
 ## import — tool → JSON
 
@@ -109,9 +115,11 @@ one tier the token file has it in.
    `primitive` target is neither in the file nor in the slice: add the target to the same
    `--only`, or fix the file first. When the neutral file does not carry the target at
    all, the refusal says so: create it in the tool first, or leave out what references
-   it. An `--only` path no variable lands at is refused rather than skipped. A refusal
-   prints the preview again, so the slice can be re-curated from the paths it lists. Then run
-   `lemony design-tokens validate` to confirm the result is well-formed.
+   it. A fault no slice fixes, such as a `primitive` that aliases, is named the same way:
+   fix that variable in the tool, or leave it out. An `--only` path no variable lands at
+   is refused rather than skipped. A refusal prints the preview again, so the slice can be
+   re-curated from the paths it lists. Then run `lemony design-tokens validate` to confirm
+   the result is well-formed.
 
 ## export — JSON → tool
 

package/catalog/skills/grill-ui/SKILL.md

@@ -75,7 +75,10 @@ the design direction it settles can inform the spec. Before the first question:
   [Persisting personas](#persisting-personas-when-absent)) — an opt-in offer on your human-facing
   surface, never an unasked write.
 - **Consume `docs/design-tokens.json` if it exists** — the single source of truth for tokens. The
-  handoff §11 points at it; you never inline token values.
+  handoff §11 points at it; you never inline token values. That is the default path: when
+  `harness.config.yml` sets `design_tokens.file`, the path it names (relative to the repository
+  root) is the token file — read, scaffold, bind and point at that path wherever this skill says
+  `docs/design-tokens.json`, and never create a second file at the default.
 - **Read `docs/architecture.md` if it exists** — orient against the system's shape so design
   proposals don't contradict existing surfaces. Absent is fine; never push the user to create it.
 

package/catalog/skills/grill-ui/ui-handoff-format.md

@@ -84,7 +84,8 @@ Every section is **N/A-able** per task: mark a section N/A rather than padding i
 
 ## 11. Token reference
 
-Reference `docs/design-tokens.json` — the single, client-owned source of truth, a 3-tier
+Reference the token file — `docs/design-tokens.json`, or the path `design_tokens.file` names in
+`harness.config.yml` — the single, client-owned source of truth, a 3-tier
 W3C-DTCG model (`primitive` → `semantic` → `component`). **Never inline token values here; point at
 the file.** If the project has no token file yet, the interview offers to scaffold one (derived from
 the answers) or to connect a design tool; if the human declines both, say so and capture it as an

package/catalog/skills/mutation-testing/SKILL.md

@@ -71,19 +71,33 @@ Without a script, each probe is yours to run. The mechanics:
   as accounted-for, is the ledger contract's rule, not this skill's — the floor asks
   for accounting, never exhaustion. One or two well-aimed probes per logic-bearing
   file usually answer the question.
-- **The round trip is one composite command with the revert unconditional.** Apply the
-  mutation, run the focused test, and restore — `;`-separated or a scripted loop,
-  **never `&&` before the revert** (a red test must still revert), and never separate
-  edit / test / revert calls. It leaves the tree exactly as you found it:
+- **The round trip is one composite command whose revert is a trap, installed before
+  the mutation.** Apply the mutation, run the focused test, and restore — in one
+  shell invocation, never separate edit / test / revert calls, and never a revert
+  that a red test or an interrupt can skip. The session can be stopped at any instant
+  (Esc stops the running command with SIGTERM), and a mutant left behind reads as
+  real work to whoever resumes. The `EXIT` trap restores on every way out — green,
+  red, or interrupted:
 
   ```bash
-  sed -i.bak '128s/>=/>/' src/queue.ts; \
-  npx vitest run src/queue.spec.ts; \
-  mv src/queue.ts.bak src/queue.ts
+  ( trap 'mv -f src/queue.ts.bak src/queue.ts 2>/dev/null' EXIT; \
+    trap 'kill $! 2>/dev/null; exit 130' INT TERM HUP; \
+    sed -i.bak '128s/>=/>/' src/queue.ts; \
+    npx vitest run src/queue.spec.ts & wait $! )
   ```
 
   (Line-addressed on purpose — one targeted mutant per trip keeps the kill
-  attributable; the `.bak` the in-place edit leaves is the revert.)
+  attributable; the `.bak` the in-place edit leaves is the revert. The subshell
+  scopes the traps to the probe; the `INT TERM HUP` trap stops the runner and turns
+  the signal into an ordinary exit so the `EXIT` trap runs. The test runs in the
+  background under `wait` because a shell runs no trap while a foreground child is
+  still running, and Claude Code follows Esc's SIGTERM with a SIGKILL within a
+  second or two: `wait` returns on the signal, so the restore lands first. The
+  `kill $!` matters for a Ctrl-C too — a background job in a non-interactive shell
+  ignores SIGINT. Only a `SIGKILL` before the trap runs or a machine crash can
+  still strand a mutant — `git status` after the
+  trip shows the tree exactly as you found it, and a leftover `.bak` is the sign
+  one was stranded.)
 
   A **killed** mutant (the focused test went red) is the good outcome; a **survivor**
   (still green on broken code) is the finding. Batching buys trips, never

package/catalog/skills/prd-to-spec/SKILL.md

@@ -209,7 +209,11 @@ close, is always read as the declaration: it is reported if it does not end the
 even when a list ends a later line. Keep every other `(R<n>)` mention in detail prose
 **mid-line**. When two lists end continuation lines the validator cannot tell which is
 the declaration and reports the task; on a task that declares no list, the one
-line-ending mention is read as its declaration, and a mid-line one is reported.
+line-ending mention is read as its declaration, and a mid-line one is reported. An
+aside that must open a parenthesis with a requirement id opens it with `per` —
+`(per R42, …)` — because a bare `(R42…` falls under the rules above exactly like a
+declaration, and can be elected over the real list, sometimes silently. A `per` aside
+is never read, so it never stands in for the list: the task still declares its own.
 
 The review evidence ledger's validator enumerates each group's review slice from these
 refs; a task it cannot read is reported as `malformed-task-refs` — a spec defect that
@@ -220,14 +224,32 @@ when the task reaches green, with the task's commit. Write every task `- [ ]`; t
 validator reports a task still `[ ]` in a group the loop has passed
 (`unticked-completed-task`), so the file tracks the progress its shape promises.
 
+**Line shapes — read by the same script.** A task line is `- [ ]` or `- [x]` and a bare
+`T<n>` id, at the task list's own indentation; a group header is exactly `## Group <n>`,
+numbered from 1, with `Group` in English even when the spec is written in another
+language. A line that looks like one but is not — an in-progress `[-]`, a suffixed
+`T12b` or `T1.1`, a numbered `1. [ ]` item, a `- T6` with no box, a task inside a `>`
+quote, a `T<n>` sub-item indented under another task, `### Group 3`, `## Group 0`, a
+digit-less `## Group P`, a translated `## Grupo 2 — … _(…)_` — is reported
+(`malformed-task-line`, `malformed-group-header`), never skipped; a note bullet about a
+task opens with
+something other than its `T<n>`. Every `T<n>` is used once in the file
+(`duplicate-task-id` otherwise). Detail prose may run to several paragraphs: a blank
+line inside a task is fine while the next line stays indented at least to the task's
+text (two spaces under `- [ ]`); less, and it is no longer the task's. Code fences and
+`>` quotes are never read as tasks, but a task or header shape inside one is reported
+too — a quoted sample looks exactly like a task under a fence left open — so quote
+samples without a `T<n>` id or a group header.
+
 Rules: order so the first task is a tracer bullet; never "write all tests" then
 "write all code"; keep each task small enough to verify on its own. Grouping never
 changes task granularity — checkboxes stay atomic and TDD runs per task; only review
 and checkpoint frequency follow the groups (all-at-once mode ignores the headers).
-Tasks added mid-implementation (from a discovery) default to **their own group** —
-they are risk by definition, and grouping rule 5 applies to them unchanged — but they
-are added **after** the spec gate, and no later gate presents a group header, so their
-tags get no human reading at all. Tag them for the record; do not rely on anyone
+Tasks added mid-implementation (from a discovery) take the **next free `T<n>`** (never
+a suffixed `T12b`) and default to **their own group** — they are risk by definition,
+and grouping rule 5 applies to them unchanged — but they are added **after** the spec
+gate, and no later gate presents a group header, so their tags get no human reading at
+all. Tag them for the record; do not rely on anyone
 catching a wrong one.
 
 ### 5. Self-check before handing off

package/catalog/skills/review-pr/SKILL.md

@@ -37,7 +37,7 @@ Read the repo's `CLAUDE.md` (and `CONTEXT.md` if present). Summarize in ≤ 50 l
 code-style rules, comment conventions, naming, architecture constraints. This is what
 the analysis judges "against project convention" by.
 
-### 2. Analyze (single sub-agent, the review lenses as a checklist)
+### 2. Analyze (one pass — a single sub-agent, or inline — the review lenses as a checklist)
 
 Spawn **one** `Explore` sub-agent with the full diff, the changed-files list, and the
 project context. Its prompt walks the five review lenses as a checklist — **not** five
@@ -58,6 +58,12 @@ The agent returns a strict JSON array of findings (see [reference.md](reference.
 the exact prompt and schema). It returns `[]` when the diff is clean — it must **not**
 manufacture findings to seem thorough.
 
+**A Reviewer, or no `Agent` tool?** A Reviewer never spawns, whatever its tools (the
+opening rule of the Reviewer contract, `.claude/agents/reviewer.md`), and an agent at
+Claude Code's nesting depth limit has no `Agent` tool unless it is a fork. Then walk
+the five lenses yourself, in this context, with the same prompt as your checklist, and
+produce the same JSON array; the rest of the flow is unchanged.
+
 ### 3. Dry-run
 
 Print the findings as a numbered table (don't post anything yet):

package/catalog/skills/review-pr/reference.md

@@ -2,8 +2,9 @@
 
 ## Analysis agent prompt
 
-Pass this to the single `Explore` sub-agent. The five lenses are a **checklist one
-agent walks**, not a fan-out.
+Pass this to the single `Explore` sub-agent — or, as a Reviewer or with no `Agent`
+tool (SKILL.md §2), walk it yourself. The five lenses are a **checklist one agent
+walks**, not a fan-out.
 
 ```
 You are reviewing a GitHub PR diff. Find real issues worth posting as inline review

package/catalog/templates/claude-code/agents.md.tpl

@@ -105,7 +105,8 @@ A task deserves the harness if it is **specifiable**, **verifiable**, or
    checks precondition (`.claude/hooks/lib/merge-pr.sh --approve-issue <issue>`)
    and never lands on red, absent, or still-pending checks without asking — nor
    content that no longer matches what the Reviewer's APPROVE reviewed (the
-   stale-approve guard; a clean update-branch stays valid, any content change
+   stale-approve guard; a clean update-branch or a task-state write under
+   `.claude/state` stays valid, any other content change
    routes back to re-review). The task stays at `in-review`
    until merged.
 10. **Closeout** — `task-closeout`: confirm the merge via `gh`, run the three Architect

package/catalog/templates/claude-code/harness.config.yml.tpl

@@ -83,7 +83,7 @@ rollback:
 #   - test
 #   - build
 
-# Design tokens (`design-tokens validate` / `design-tokens contrast`).
+# Design tokens (the `design-tokens` verbs, and the token lines of `doctor` / `status`).
 # `scan_extensions`: the anti-hardcode scan inspects a built-in set of UI/style
 # extensions (.css/.scss/.ts/.tsx/.vue/.svelte/.astro/.js/.mdx/.html/…). Add extra
 # suffixes here for a stack the built-ins don't cover — additive, never a replacement.
@@ -92,10 +92,16 @@ rollback:
 # (through `sh -c`, in the repo root) — your design system's own verifier for the rules
 # only it can know (palette under colour-vision-deficiency simulation, property grammar,
 # CSS scans). Its output is forwarded; a non-zero exit fails the gate. It runs on every
-# path: with no docs/design-tokens.json only the WCAG pair check is skipped, and a file
+# path: with no token file only the WCAG pair check is skipped, and a file
 # that cannot be read or parsed is reported alongside it — never the verifier you
 # declared. Default none.
+# `file`: where the token file lives, relative to the repository root — for a DTCG
+# file kept (or generated) somewhere other than docs/design-tokens.json. Every
+# design-tokens verb, `doctor` and `status` read it from here. An absolute path, a `\`
+# separator, a path that leads out of the repository or names its root, or one ending
+# in `/` or `/.` is a config error. Default docs/design-tokens.json.
 # design_tokens:
 #   scan_extensions:
 #     - .foo
 #   verify: pnpm exec my-design-system verify
+#   file: design/tokens.json