@jesdi/skills 0.0.28 → 0.0.30

package/README.md

@@ -50,19 +50,27 @@ npx @jesdi/skills-cli uninstall <skill> [--global]
 npx @jesdi/skills-cli pin <skill> [--global]     # keep the installed version
 npx @jesdi/skills-cli unpin <skill> [--global]
 npx @jesdi/skills-cli hook                 # register the session update hook
+npx @jesdi/skills-cli session-update       # run the session checks now
 ```
 
 ## Automatic updates
 
 A global install registers a session-start hook in Claude Code
 (`~/.claude/settings.json`) and Codex (`~/.codex/hooks.json`), for each one
-that is present. The first session of a day runs
-`skills-cli update --all --global` in the background; the result is in
-`~/.my-skills/.session-update.log`. Project installs do not change: they stay
+that is present. Every session runs `skills-cli session-update` in the
+background. It checks all external skills on every run and updates own global
+skills once a day. The result is in `~/.my-skills/.session-update.log`.
+Claude and Codex share a lock so concurrent starts cannot change the installs
+at the same time. External checks run before npm updates, whose requests have
+a 30-second deadline. Because the check runs in the background, a repaired skill
+may appear in the next session. Project installs stay
 at the versions committed in `.my-skills.json`.
 
+Existing hooks keep the CLI version that registered them. After a CLI release,
+run `npx -y @jesdi/skills-cli@latest hook` once to register the new behavior.
+
 To keep a skill at its installed version, pin it: `skills-cli pin <skill>
---global`. No update touches a pinned skill until `unpin`. To stop all
+--global`. No own-skill update touches a pinned skill until `unpin`. To stop all
 automatic updates, remove the hook entry from the two config files; the next
 global install or `skills-cli hook` adds it again.
 
@@ -71,19 +79,52 @@ global install or `skills-cli hook` adds it again.
 Skills authored by other people are **not** copied into this repo — they keep
 their own authors, upstreams, and licenses. `external-skills.json` records
 which ones are part of the standard setup, where they come from, and (under
-`pins`) the upstream commit the box set is taken from. Install them from
-upstream with the [skills.sh](https://skills.sh/) CLI:
+`pins`) the upstream commits for the standard setup and the box set.
+Session checks fetch this catalogue from this repository's `main` branch at
+most once a day. They compare installed files, including resources and executable
+permissions, with the files at each pinned ref. Missing or different files
+are repaired from upstream or a verified local cache. A failed or invalid
+catalogue refresh uses the last valid cached catalogue and reports the error.
+Ref changes take effect
+even when the version label stays the same. Sources without version labels
+are identified by their commit ref.
+
+External installs live in `~/.agents/skills/` for Codex and OpenCode, with links
+in `~/.claude/skills/` when Claude Code is present. Their source, path, ref,
+optional version and content hash are recorded in
+`~/.config/my-skills/external.json`. Upstream attribution and the identities
+of directories created by the updater establish
+ownership. Interrupted swaps retain ownership only of their known directory
+identities; failed replacements roll back uncommitted provenance. Existing
+skills.sh entries from the same
+source can be adopted, including Claude copies with matching content and current
+source attribution. Copies awaiting recovery also retain their directory identity.
+Publication and rollback use the OS's atomic no-replace rename through Koffi:
+[`RENAME_EXCL`](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/APFS_Guide/ToolsandAPIs/ToolsandAPIs.html)
+on macOS, [`RENAME_NOREPLACE`](https://man7.org/linux/man-pages/man2/rename.2.html)
+on Linux, and [`MoveFileExW`](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw)
+without replacement flags on Windows. Unsupported filesystems fail without a
+replacement fallback. If a concurrent install blocks rollback, both copies are
+preserved and the log names the backup location. Current
+conflicting skills.sh provenance and independently replaced Claude directories
+are preserved and reported in
+the log. An enabled Claude frontend-design plugin takes precedence over a
+direct Claude install of that skill; the Codex entry is still installed.
+
+For a manual setup, use the [skills.sh](https://skills.sh/) CLI:
 
 ```bash
-npx skills add mattpocock/skills          # grill-me, grill-with-docs, grilling, improve-codebase-architecture, to-questionnaire, tdd, code-review, codebase-design, diagnosing-bugs, resolving-merge-conflicts, handoff, teach, wait-what
+npx skills add mattpocock/skills          # grill-me, grill-with-docs, grilling, improve-codebase-architecture, to-questionnaire, tdd, code-review, codebase-design, diagnosing-bugs, resolving-merge-conflicts, pr, handoff, teach, wait-what
 npx skills add JuliusBrussee/caveman      # caveman suite
 npx skills add vercel-labs/skills         # find-skills
 npx skills add vercel-labs/agent-skills   # vercel-react-best-practices
 npx skills add anthropics/skills          # frontend-design (skip if using the Claude Code plugin)
 ```
 
-The skills.sh lockfile (`~/.agents/.skill-lock.json`) tracks installed
-versions; `npx skills update` refreshes them.
+The skills.sh lockfile (`~/.agents/.skill-lock.json`) records its own installs.
+Session checks leave that file in place. `npx skills update` can move an install
+away from the configured pin; the next session check restores the catalogue's
+version.
 
 ### Forks (the one exception)
 
@@ -99,6 +140,7 @@ them afterwards). `external-skills.json` lists them under `forks`.
 
 `external-skills.json` → `sets.box` names the skills the agent-ops box
 receives: `own` from this package, `external` from the pinned upstream.
+`pr` is in the external set and is installed directly from mattpocock/skills.
 agent-ops vendors that set into its claude-home seed with its own refresh
 command; this repo's job is to publish the set and keep the pins resolvable.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jesdi/skills",
-  "version": "0.0.28",
+  "version": "0.0.30",
   "description": "jesdi's agent skills (content package consumed by @jesdi/skills-cli)",
   "license": "MIT",
   "repository": {
@@ -13,8 +13,12 @@
     "skills-manifest.json"
   ],
   "devDependencies": {
+    "@types/jsdom": "^30.0.0",
     "@types/node": "^22.0.0",
+    "@types/proper-lockfile": "^4.1.4",
+    "@vitest/coverage-istanbul": "2.1.9",
     "gray-matter": "^4.0.3",
+    "jsdom": "^30.1.1",
     "tsx": "^4.19.0",
     "typescript": "^5.5.0",
     "vitest": "^2.1.0"
@@ -24,6 +28,10 @@
   },
   "scripts": {
     "test": "vitest run",
+    "test:coverage": "vitest run --coverage --coverage.reportOnFailure",
+    "test:python": "mkdir -p .crap && python3 -m coverage run -m pytest skills/backlog skills/crap-gate -q && python3 -m coverage json -o .crap/python.json",
+    "crap-gate": "sh skills/crap-gate/run.sh",
+    "check": "sh scripts/check.sh",
     "generate-manifest": "tsx scripts/generate-manifest.ts"
   }
 }

package/skills/implement-spec/SKILL.md

@@ -11,7 +11,7 @@ Changes: a model tier per subagent; a context-isolated test-writer commits
 locked acceptance tests at the ticket's Seam, the implementer turns them green
 with /tdd and reports to a contract; per-ticket review before merge, fix loop
 capped at 4 rounds with escalation; a ruling ledger and four stop conditions;
-a per-ticket gate (check command + crap-gate) before DONE, re-run by the reviewer;
+a per-ticket gate (check command + crap-gate) before DONE, verified by the reviewer;
 already-green locked tests need a demonstrated mutation; a Codex correctness
 pass per risky ticket; tickets touching the same functions run in sequence;
 check command after each merge; final /review-diff on the most capable model, one
@@ -19,6 +19,11 @@ fixer; ticket-grouped history with fixes folded in before review; closes
 tickets only if they are issues; no push and no PR until every
 ticket is merged and the final review has passed. Review loop and ledger adapt
 superpowers' subagent-driven-development (obra/superpowers, MIT).
+Verification schedule (after a 44-hour run with 65 full gates for six tickets):
+one gate record per candidate, verified by the reviewer instead of re-run;
+mutation proofs once, then only for changed lines; a budget ruling after round 2;
+fixture corrections outside the fix loop; a named fallback when codex exec is refused;
+one report file per agent; plain-sentence ledger.
 -->
 
 You have been provided a spec. This spec should have tickets associated with it, describing how to implement the spec.
@@ -29,19 +34,19 @@ The tickets are not a list of steps. They are a **task graph** with blocking rel
 
 Communication to and from subagents should be sparse. Communicate primarily through **context pointers**: to the spec, tickets, research notes, and previous commits. Don't duplicate information already available via pointers.
 
-Run ticket subagents in the background where possible for **maximum concurrency**.
+Run ticket subagents in the background where possible for **maximum concurrency**. Wait on a running subagent with one long wait, in minutes. Each subagent leaves one report file plus its gate log in the notes directory; mutation evidence is a table in the report, and a tree-hash manifest or a per-mutant log is a sign the agent is building its own procedure.
 
 **Every dispatch prompt says: never `git stash`, reset or check out other branches; worktrees share one stash and one ref store.**
 
 **Name the model on every dispatch.** Omitted, it inherits yours. Exploration, test-writer, reviewer: mid tier (reviewer higher for risky diffs). Implementer: mid tier; cheapest for a small, fully specified ticket; most capable for design judgment or broad codebase work. Merger: cheapest. Escalations: one tier above the agent that got stuck. Final reviewer: most capable.
 
-**Rule, don't stall.** Keep a **ledger** file in the notes directory: every decision as `Ruling: <what> — <why> — <cost if wrong>`, and each ticket's state, so you can resume after compaction. Don't check in between tickets. Stop and ask only for: an irreversible or destructive operation, a security-sensitive action, a side effect outside the worktrees (a push to a shared branch, a publish), or a spec so broken that every path forward is a guess.
+**Rule, don't stall.** Keep a **ledger** file in the notes directory: every decision as `Ruling: <what> — <why> — <cost if wrong>`, and each ticket's state, so you can resume after compaction. Ledger entries are plain sentences, one line per event, written for a human who was not there. After a compaction, read the ledger and continue from its last state: a recorded green gate, review or merge stays settled. Don't check in between tickets. Stop and ask only for: an irreversible or destructive operation, a security-sensitive action, a side effect outside the worktrees (a push to a shared branch, a publish), or a spec so broken that every path forward is a guess.
 
 ## Steps
 
 1. Read the spec and tickets. Read enough to understand the task graph.
 
-2. Create a notes directory outside the repo, readable by all subagents, and start the ledger there. (optional) An **exploration subagent** saves its notes on relevant code and docs there, so implementers focus on implementation.
+2. Create a notes directory outside the repo, readable by all subagents, and start the ledger there. (optional) An **exploration subagent** saves its notes on relevant code and docs there, so implementers focus on implementation. It is the only exploration or preparation agent: a ticket starts with its test-writer, when its frontier turn comes.
 
 3. Create the PR branch locally. Do **not** push it and do **not** open a PR yet: nothing leaves the
    machine until every ticket is merged and the final review has passed (step 10). Intermediate
@@ -50,13 +55,21 @@ Run ticket subagents in the background where possible for **maximum concurrency*
 
 4. Each ticket gets its own worktree and branch. For a ticket with behavioral criteria, a **test-writer subagent** goes first. It sees ONLY the spec, the ticket, CONTEXT.md/ADRs and the public interface of the ticket's **Seam** line (pointers, not summaries), never the implementer's plan or code. It writes one black-box acceptance test per criterion through that interface (defining the interface if it doesn't exist yet), confirms each fails for the right reason (missing behavior, not an import or syntax error), commits them red, and reports the SHA and files. A test that is already green before any implementation is vacuous until proven otherwise (an earlier guard or early return often satisfies it for an unrelated reason): the test-writer rewrites it to fail, or, when the criterion truly holds already, reports the production-code mutation that turns it red and the red output. Those files are now **locked**. A ticket with no behavioral criteria (Seam: `none — refactor`) skips this: its existing tests are the contract, unmodified.
 
-5. An **implementer subagent** starts from that commit and makes the locked tests green, using /tdd vertical slices for anything internal. It never edits locked files and never dispatches subagents. Before reporting DONE it runs the **gate** in its worktree: the repo's check command (lint, typecheck, full test suite: `make check`, or what AGENTS.md documents) and, when the repo has `.crap-gate.json`, crap-gate scoped to the ticket (`run.sh --base <PR branch>`, or the repo's `make crap-gate` wrapper). DONE means both are green; a gate it can't turn green is BLOCKED, with the output. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, the gate's final lines, files touched, concerns. If a locked test contradicts the spec or ticket, it reports BLOCKED with evidence; you rule, and either send the test-writer a correction or overrule the implementer. Handle any BLOCKED by changing something: more context, a stronger model, a split ticket, or a ruling. Never retry unchanged.
+5. An **implementer subagent** starts from that commit and makes the locked tests green, using /tdd vertical slices for anything internal. It never edits locked files and never dispatches subagents. While working it runs targeted tests. Before reporting DONE it runs the **gate** once, on a clean tree at its final commit, as one **gate record**: the repo's check command (lint, typecheck, full test suite: `make check`, or what AGENTS.md documents) and, when the repo has `.crap-gate.json`, crap-gate scoped to the ticket (`run.sh --base <PR branch>`, or the repo's `make crap-gate` wrapper), wrapped so the log in the notes directory carries the start and end time, the commit, and the status:
 
-6. On DONE, a **reviewer subagent** re-runs the gate first (a red gate is a Critical finding; don't trust the report), then checks the diff against the ticket and spec, then for quality. It also checks that `git diff <test-writer-sha>..HEAD -- <locked files>` is empty and that every criterion has a locked test. For each locked test, it breaks the production line the test exists to protect (a temporary edit, reverted after) and confirms that test goes red; a test that stays green is Critical. It re-runs every mutation the test-writer reported. Name your specific suspicions in the reviewer prompt (a sibling caller, a key built from the old identity, a guard another ticket added): named suspicions find regressions a generic review misses.
+   ```sh
+   { date -u; git rev-parse HEAD; git status --short; <gate commands>; echo "gate exit $?"; date -u; } 2>&1 | tee <notes>/<ticket>-gate-$(git rev-parse --short HEAD).log
+   ```
 
-   A **risky** ticket touches shared state, persistence keys or identities, concurrency, money or auth. For those, run the correctness pass from /review-diff yourself, in parallel with the reviewer: `codex exec` with that skill's `correctness.md` on range `<PR branch>...<ticket branch>` (three dots: from the merge-base, so tickets merged meanwhile don't show up), in quick mode (the command is in the review-diff skill). Its findings join the reviewer's, with the same severities.
+   DONE means the record is green; a gate it can't turn green is BLOCKED, with the output. CRAP findings are the implementer's to resolve inside the ticket, within this same gate. It reports: status (DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT or BLOCKED), commits, red→green evidence for locked tests and its own slices, the gate record's path and final lines, files touched, concerns. If a locked test contradicts the spec or ticket, it reports BLOCKED with evidence; you rule, and either send the test-writer a correction or overrule the implementer. Handle any BLOCKED by changing something: more context, a stronger model, a split ticket, or a ruling. Never retry unchanged.
 
-   Critical or Important findings start a fix loop of at most 4 rounds, each a fix plus a re-review scoped to that fix: rounds 1-2 resume the implementer; rounds 3-4 go to a fresh implementer one tier up. After round 4, rule on each open finding in the ledger and move on. Minor findings go to the ledger for the final review.
+6. On DONE, a **reviewer subagent** verifies the gate record first: the recorded commit is the ticket tip, the status was clean, and the tail is green. A missing, mismatched or red record is a Critical finding, and only then does the reviewer run the gate itself. It then checks the diff against the ticket and spec, then for quality. It also checks that `git diff <test-writer-sha>..HEAD -- <locked files>` is empty and that every criterion has a locked test; that one diff is the whole locked-file check. In the first review, for each locked test, it breaks the production line the test exists to protect (a temporary edit, reverted after) and confirms that test goes red; a test that stays green is Critical. It re-runs every mutation the test-writer reported. A mutation proof is keyed to its test and production line: a later round repeats it only when that line changed. Name your specific suspicions in the reviewer prompt (a sibling caller, a key built from the old identity, a guard another ticket added): named suspicions find regressions a generic review misses.
+
+   A **risky** ticket touches shared state, persistence keys or identities, concurrency, money or auth. For those, run the correctness pass from /review-diff yourself, in parallel with the reviewer: `codex exec` with that skill's `correctness.md` on range `<PR branch>...<ticket branch>` (three dots: from the merge-base, so tickets merged meanwhile don't show up), in quick mode (the command is in the review-diff skill). Its findings join the reviewer's, with the same severities. When `codex exec` is refused or unavailable, the reviewer's brief gains `correctness.md` for the ticket's risk; that reviewer is the correctness pass, with no second agent.
+
+   A finding that a locked test encodes a stale path, format, fixture layout or setup detail is a **fixture correction**, outside the fix loop: one test-writer dispatch fixes it, the ledger records the file and reason, and the review continues. A setup or environment failure (a missing dependency link, a cache permission, a leftover process) is fixed at its cause before any gate runs again.
+
+   Critical or Important findings start a fix loop of at most 4 rounds, each a fix plus a re-review scoped to that fix: the implementer uses targeted tests, ends the round with one gate record on its final commit, and the re-review verifies that record and the changed lines. Rounds 1-2 resume the implementer; rounds 3-4 go to a fresh implementer one tier up. After round 2, rule in the ledger before continuing: continue, split the ticket, or redesign it. After round 4, rule on each open finding in the ledger and move on. Minor findings go to the ledger for the final review.
 
 7. Once a ticket passes review, a **merger subagent** merges it to the PR branch and runs the repo's check command (lint, typecheck, full suite). If it fails, an implementer fixes the PR branch before the next merge. Record the ticket's commits and any integration fixes in the ledger. After the merge and checks pass, remove that ticket's worktree and delete its branch with `git branch -d` from the PR branch, while its commits are still ancestors of the PR tip. Cleanup is part of completing the ticket, before any rebase.
 

package/skills/review-page/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: review-page
+description: One interactive HTML page for a plan review or a questionnaire, built from a fixed template. Use when a pipeline session must deliver a plan review or a questionnaire as an interactive page the console shows.
+---
+
+# Review page
+
+The session fills a fixed template. The console shows the page in an iframe and reads the operator's answers from it. Messages and the answers file are in [schema.md](schema.md).
+
+## Modes
+
+Set the mode on the body: `<body data-mode="plan">` or `<body data-mode="questionnaire">`.
+
+- `plan`: tickets, open questions, corrections, a track, and a bar with the count of answered questions.
+- `questionnaire`: questions only. The template hides the other sections.
+
+The page has no buttons. The console shows "Send changes" and "Approve" (or "Send answers") outside the page, so a page can never submit or approve. Never add a button or a `submit` value to the page.
+
+## Steps
+
+1. Copy [template.html](template.html) to the path the prompt names: `.agent/review.html` (plan) or `.agent/questionnaire.html` (questionnaire).
+2. Set `data-mode` on the body.
+3. Replace the content between `<!-- slot: NAME -->` and `<!-- /slot -->` in each slot. Keep the `<section data-slot="...">` wrappers. Slots: `header` (eyebrow, `h1`, lede), `tickets`, `questions`, `corrections`, `track`. Do not nest a `<section>` in a slot.
+4. Open the file and check that it renders.
+
+## Slot shapes
+
+Ticket, in `ol.tickets`:
+
+```html
+<li><span class="n">01</span><span>Title <span class="by">· blocked by none · seam: file.py</span></span></li>
+```
+
+Question, in `questions`. The `data-q` value, the radio `name` and the note id `note-ID` use the same id:
+
+```html
+<div class="q" data-q="format">
+  <header><h3>Question text</h3><span class="chip waiting">needs you</span></header>
+  <p class="why">Why it matters.</p>
+  <div class="opts">
+    <label class="opt"><input type="radio" name="format" value="a"><span><span class="t">Option A <span class="chip rec">recommended</span></span><br><span class="d">Trade-off.</span></span></label>
+    <label class="opt"><input type="radio" name="format" value="b"><span><span class="t">Option B</span><br><span class="d">Trade-off.</span></span></label>
+  </div>
+  <textarea id="note-format" placeholder="Note (optional)"></textarea>
+</div>
+```
+
+Correction, in `corrections`:
+
+```html
+<div class="corr"><p class="was">Old statement.</p><p>New statement.</p></div>
+```
+
+Track pills, in `track`. Check the proposed track:
+
+```html
+<div class="tracks" role="radiogroup" aria-label="track">
+  <label><input type="radio" name="track" value="standard" checked>standard</label>
+</div>
+```
+
+## Rules
+
+- Never edit the `<script>` or the CSS. Only fill slots.
+- Every question has an id that matches `[a-z0-9_-]{1,64}`. The id `track` is reserved for the track pills. Slot content never carries the id `state`, or the name `track` outside the track slot: the script owns them.
+- Every question has exactly one recommended option, marked with `chip rec`. It is one recommended option, never zero and never two.
+- Option values are short ids. Put no option text in a value.
+- The page has no network, no storage and no external file: no script `src`, no `<link>`, no image or font URL.
+- Keep `<meta name="agent-ops-review" content="1">`. The dispatcher looks for it.
+- Re-write the file after a plan revision. Remove the questions and tickets that no longer apply.

package/skills/review-page/schema.md

@@ -0,0 +1,59 @@
+# Review page schema
+
+Every message carries `v`. `v` is the integer `1`. It changes only when the console cannot read the old shape.
+
+## Messages
+
+Page to console, once, when its script listens:
+
+```json
+{"type": "ready", "v": 1}
+```
+
+Page to console, on every change:
+
+```json
+{"type": "answers", "v": 1, "answers": {"format": "a", "track": "standard"}, "submit": null}
+```
+
+`submit` is always `null`: a page sends drafts only, and the console ignores any other value. The buttons belong to the console: when the operator presses "Send changes" or "Send answers" it posts the last set with `"changes"`, and on the second tap on "Approve" with `"approve"`. The console adds the request's `revision` when it posts the set to the box.
+
+Console to page, after `ready` and whenever saved answers arrive:
+
+```json
+{"type": "restore", "v": 1, "answers": {"format": "b", "track": "standard"}}
+```
+
+The page accepts `restore` only from its parent window, and only when `v` is `1`.
+
+## The `answers` object
+
+`answers` is a flat JSON object. A key is a question id, a question id followed by `.note`, or `track`. A value is a string (one chosen option id, a note, or a track name), a list of strings (a multi-choice question), or a boolean. A question with no choice has no key. A note appears only when it is not empty.
+
+A question id is the `data-q` value of the question block. It matches `[a-z0-9_-]{1,64}`.
+
+## Answers file
+
+The dispatcher writes `.agent/review-answers.json` (plan) or `.agent/questionnaire-answers.json` (spec) in the task worktree. Sessions read it. A session that takes a text answer writes it in the same shape.
+
+```json
+{
+  "v": 1,
+  "stage": "plan",
+  "submitted": "changes",
+  "submitted_at": "2026-10-12T10:12:03+00:00",
+  "actor": "jesdi",
+  "revision": "9f2c…",
+  "answers": {"debounce": "draft", "debounce.note": "flush on pagehide", "track": "standard"}
+}
+```
+
+- `v`: the integer `1`.
+- `stage`: `"plan"` for `.agent/review-answers.json`, `"spec"` for `.agent/questionnaire-answers.json`.
+- `submitted`: `null` for a draft, `"changes"` or `"approve"` for a submission.
+- `submitted_at`: the time of the intent that was applied, or `null` for a draft.
+- `actor`: the operator's console login, or `"text"` when the session wrote the file from a typed reply.
+- `revision`: the page revision the answers were made on (the request's `revision`). A session that writes the file from a typed reply leaves it out; such a submission blocks later drafts until the page changes.
+- `answers`: the object above.
+
+The file holds no option texts.

package/skills/review-page/template.html

@@ -0,0 +1,232 @@
+<!doctype html>
+<html lang="en">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<meta name="agent-ops-review" content="1">
+<title>Review</title>
+<style>
+/* Layout: one column, phone first; the console's own token system so the page
+   reads as part of the console, not as a foreign document. */
+:root {
+  --surface: #f5f7fa; --raised: #ffffff; --ink: #1e293b; --muted: #5b6577;
+  --border: #dce1e8; --attention: #fbf6ec;
+  --waiting-bg: #fef3c7; --waiting-fg: #92400e;
+  --running-bg: #dcfce7; --running-fg: #166534;
+  --parked-bg: #ede9fe; --parked-fg: #5b21b6;
+  --accent: #1e40af; --accent-bg: #dbeafe;
+  --sans: "IBM Plex Sans", ui-sans-serif, system-ui, sans-serif;
+  --mono: "IBM Plex Mono", ui-monospace, SFMono-Regular, Menlo, monospace;
+}
+@media (prefers-color-scheme: dark) { :root:not([data-theme="light"]) {
+  --surface: #0f141a; --raised: #181e27; --ink: #e4e8ee; --muted: #98a2b1;
+  --border: #2b3340; --attention: #1f1b15;
+  --waiting-bg: #372812; --waiting-fg: #fcd34d;
+  --running-bg: #10301e; --running-fg: #86efac;
+  --parked-bg: #291f45; --parked-fg: #c4b5fd;
+  --accent: #93c5fd; --accent-bg: #1e293b; color-scheme: dark } }
+:root[data-theme="dark"] {
+  --surface: #0f141a; --raised: #181e27; --ink: #e4e8ee; --muted: #98a2b1;
+  --border: #2b3340; --attention: #1f1b15;
+  --waiting-bg: #372812; --waiting-fg: #fcd34d;
+  --running-bg: #10301e; --running-fg: #86efac;
+  --parked-bg: #291f45; --parked-fg: #c4b5fd;
+  --accent: #93c5fd; --accent-bg: #1e293b; color-scheme: dark }
+
+* { box-sizing: border-box }
+body { margin: 0; background: var(--surface); color: var(--ink); font: 14px/1.5 var(--sans) }
+main { max-width: 680px; margin: 0 auto; padding: 16px 16px 112px }
+h1 { font-size: 18px; font-weight: 600; margin: 0; text-wrap: balance; line-height: 1.3 }
+h2 { font-size: 11px; font-weight: 600; letter-spacing: .06em; text-transform: uppercase; color: var(--muted); margin: 0 }
+section { display: grid; gap: 10px; margin-top: 24px }
+p { margin: 0 }
+code { font: 12px var(--mono); overflow-wrap: anywhere }
+.eyebrow { font: 500 12px var(--mono); color: var(--muted); margin-bottom: 6px; overflow-wrap: anywhere }
+.lede { color: var(--muted); margin-top: 6px }
+.chip { display: inline-block; border-radius: 4px; padding: 0 6px; font-size: 11px; font-weight: 500; white-space: nowrap }
+.chip.waiting { background: var(--waiting-bg); color: var(--waiting-fg) }
+.chip.rec { background: var(--running-bg); color: var(--running-fg) }
+.chip.parked { background: var(--parked-bg); color: var(--parked-fg) }
+
+/* Tickets: a plain list, numbered because the order is the build order. */
+ol.tickets { list-style: none; margin: 0; padding: 0; display: grid; gap: 6px }
+ol.tickets li { display: grid; grid-template-columns: 28px 1fr; gap: 8px; align-items: baseline }
+ol.tickets .n { font: 500 12px var(--mono); color: var(--muted); font-variant-numeric: tabular-nums }
+ol.tickets .by { color: var(--muted); font-size: 12px }
+
+/* Questions: the one boxed element, because it takes input. */
+.q { background: var(--raised); border: 1px solid var(--border); border-radius: 6px; padding: 12px }
+.q.answered { border-color: color-mix(in srgb, var(--running-fg) 40%, var(--border)) }
+.q header { display: flex; justify-content: space-between; gap: 8px; align-items: baseline }
+.q h3 { font-size: 14px; font-weight: 600; margin: 0; text-wrap: balance }
+.q .why { color: var(--muted); margin-top: 4px }
+.opts { display: grid; gap: 6px; margin-top: 10px }
+.opt { display: grid; grid-template-columns: 18px 1fr; gap: 10px; align-items: start;
+  border: 1px solid var(--border); border-radius: 6px; padding: 10px; cursor: pointer; min-height: 44px }
+.opt input { margin: 3px 0 0; width: 16px; height: 16px; accent-color: var(--accent) }
+.opt:has(input:checked) { border-color: var(--accent); background: var(--accent-bg) }
+.opt:has(input:focus-visible) { outline: 2px solid var(--accent); outline-offset: 2px }
+.opt .t { font-weight: 500 }
+.opt .d { color: var(--muted); font-size: 13px }
+.q textarea { width: 100%; margin-top: 10px; min-height: 44px; border: 1px solid var(--border); border-radius: 6px;
+  padding: 8px 10px; font: 13px/1.5 var(--sans); background: var(--surface); color: var(--ink); resize: vertical }
+.q textarea:focus-visible { outline: 2px solid var(--accent); outline-offset: 1px }
+
+/* Corrections: before / after pairs. */
+.corr { display: grid; gap: 4px; padding-left: 10px; border-left: 2px solid var(--border) }
+.corr .was { color: var(--muted); text-decoration: line-through }
+
+/* Track selector: a row of pills. */
+.tracks { display: flex; flex-wrap: wrap; gap: 6px }
+.tracks label { border: 1px solid var(--border); border-radius: 999px; padding: 6px 12px; min-height: 36px;
+  display: inline-flex; align-items: center; cursor: pointer; background: var(--raised) }
+.tracks label:has(input:checked) { border-color: var(--accent); background: var(--accent-bg); color: var(--accent); font-weight: 500 }
+.tracks label:has(input:focus-visible) { outline: 2px solid var(--accent); outline-offset: 2px }
+.tracks input { position: absolute; opacity: 0; width: 0; height: 0 }
+
+/* State bar: fixed to the bottom. The console owns the buttons: a page never submits. */
+.bar { position: fixed; left: 0; right: 0; bottom: 0; background: var(--raised); border-top: 1px solid var(--border);
+  padding: 10px 16px calc(10px + env(safe-area-inset-bottom, 0px)) }
+.bar .in { max-width: 680px; margin: 0 auto; display: flex; gap: 8px; align-items: center; flex-wrap: wrap }
+.bar .state { flex: 1 1 100%; font-size: 12px; color: var(--muted); min-width: 0 }
+.bar .state.saved { color: var(--running-fg) }
+
+@media (prefers-reduced-motion: no-preference) { .opt, .tracks label { transition: background .12s, border-color .12s } }
+
+/* Questionnaire mode: questions only. */
+body[data-mode="questionnaire"] section[data-slot="tickets"],
+body[data-mode="questionnaire"] section[data-slot="corrections"],
+body[data-mode="questionnaire"] section[data-slot="track"] { display: none }
+</style>
+</head>
+<body data-mode="plan">
+<main>
+  <!-- slot: header -->
+  <div class="eyebrow">plan review · owner/repo #123 · branch task/123-example</div>
+  <h1>Title of the plan</h1>
+  <p class="lede">2 tickets · 1 open question · 1 correction. Pick an option under each question, then send.</p>
+  <!-- /slot -->
+
+  <section data-slot="tickets">
+    <!-- slot: tickets -->
+    <h2>Tickets</h2>
+    <ol class="tickets">
+      <li><span class="n">01</span><span>First ticket title <span class="by">· seam: module.py</span></span></li>
+      <li><span class="n">02</span><span>Second ticket title <span class="by">· blocked by 01 · seam: other.py</span></span></li>
+    </ol>
+    <!-- /slot -->
+  </section>
+
+  <section data-slot="questions">
+    <!-- slot: questions -->
+    <h2>Open questions</h2>
+    <div class="q" data-q="format">
+      <header><h3>Which format does the export use?</h3><span class="chip waiting">needs you</span></header>
+      <p class="why">One sentence on why the answer matters.</p>
+      <div class="opts">
+        <label class="opt"><input type="radio" name="format" value="a"><span><span class="t">Option A <span class="chip rec">recommended</span></span><br><span class="d">What A costs and gives.</span></span></label>
+        <label class="opt"><input type="radio" name="format" value="b"><span><span class="t">Option B</span><br><span class="d">What B costs and gives.</span></span></label>
+      </div>
+      <textarea id="note-format" placeholder="Note (optional)"></textarea>
+    </div>
+    <!-- /slot -->
+  </section>
+
+  <section data-slot="corrections">
+    <!-- slot: corrections -->
+    <h2>Corrections</h2>
+    <div class="corr">
+      <p class="was">The old statement.</p>
+      <p>The corrected statement.</p>
+      <p class="why" style="color:var(--muted)">Why: the reason.</p>
+    </div>
+    <!-- /slot -->
+  </section>
+
+  <section data-slot="track">
+    <!-- slot: track -->
+    <h2>Track</h2>
+    <p class="why" style="color:var(--muted)">The plan session proposed <strong>standard</strong>. Change it only when needed.</p>
+    <div class="tracks" role="radiogroup" aria-label="track">
+      <label><input type="radio" name="track" value="trivial">trivial</label>
+      <label><input type="radio" name="track" value="standard" checked>standard</label>
+      <label><input type="radio" name="track" value="security">security</label>
+    </div>
+    <!-- /slot -->
+  </section>
+</main>
+
+<div class="bar">
+  <div class="in">
+    <p class="state" id="state">0 of 0 questions answered</p>
+  </div>
+</div>
+
+<script>
+// Fixed part of the template: collect, post, restore. The session never edits this.
+const V = 1;
+const state = document.querySelector('.bar #state');   // lives in the bar, never in a slot
+const embedded = window.parent !== window;
+const questions = () => [...document.querySelectorAll('.q[data-q]')];
+let restored = false;
+
+function collect() {
+  const answers = {};
+  for (const el of questions()) {
+    const q = el.dataset.q;
+    const picked = [...document.getElementsByName(q)].find(i => i.checked);
+    if (picked) answers[q] = picked.value;
+    const note = document.getElementById('note-' + q);
+    if (note && note.value.trim()) answers[q + '.note'] = note.value.trim();
+  }
+  const track = document.querySelector('input[name="track"]:checked');
+  if (track) answers.track = track.value;
+  return answers;
+}
+
+function post() {
+  // In the console this is the only way out of the sandbox. Always a draft:
+  // the console's own buttons submit, so no page script can approve.
+  if (embedded) window.parent.postMessage({ type: 'answers', v: V, answers: collect(), submit: null }, '*');
+  paint();
+}
+
+function paint() {
+  let n = 0;
+  const all = questions();
+  for (const el of all) {
+    const done = [...document.getElementsByName(el.dataset.q)].some(i => i.checked);
+    el.classList.toggle('answered', done);
+    const chip = el.querySelector('header .chip.waiting, header .chip.rec');
+    if (chip) { chip.textContent = done ? 'answered' : 'needs you'; chip.className = done ? 'chip rec' : 'chip waiting'; }
+    if (done) n++;
+  }
+  state.textContent = `${n} of ${all.length} questions answered` + (restored ? ' · saved answers restored' : '');
+  state.classList.toggle('saved', restored);
+}
+
+function restore(answers) {
+  for (const [k, v] of Object.entries(answers || {})) {
+    if (k.endsWith('.note')) { const t = document.getElementById('note-' + k.slice(0, -5)); if (t) t.value = v; continue; }
+    const input = [...document.getElementsByName(k)].find(i => i.value === v);
+    if (input) input.checked = true;
+  }
+  paint();
+}
+
+document.addEventListener('change', e => {
+  if (e.target.type === 'radio') post();
+});
+document.addEventListener('input', e => { if (e.target.tagName === 'TEXTAREA') post(); });
+
+// From the console: saved answers, when the page reopens on any device.
+window.addEventListener('message', e => {
+  const d = e.data;
+  if (e.source !== window.parent || !d || d.v !== V || d.type !== 'restore') return;
+  restored = Object.keys(d.answers || {}).length > 0; restore(d.answers);
+});
+if (embedded) window.parent.postMessage({ type: 'ready', v: V }, '*');
+paint();
+</script>
+</body>
+</html>

package/skills-manifest.json

@@ -1,6 +1,6 @@
 {
   "schemaVersion": 1,
-  "generatedAt": "2026-10-08T10:41:10.504Z",
+  "generatedAt": "2026-10-08T23:26:31.695Z",
   "skills": [
     {
       "name": "backlog",
@@ -46,8 +46,8 @@
     },
     {
       "name": "implement-spec",
-      "version": "0.1.6",
-      "hash": "sha256-836f28be9230179d7389ef5ed8e1dacadd43d649a20a06f32adb891d5a4c1357",
+      "version": "0.1.7",
+      "hash": "sha256-dfcd2f6a13fd06dd4fb7a45bb0d85ae39228ec804dc94c845310afa72808d3d5",
       "description": "Implement a specification in code."
     },
     {
@@ -74,6 +74,12 @@
       "hash": "sha256-70beaf1478820d66e1831d45739ce97ced50224b46c5003d887ea62c8438f251",
       "description": "Review a branch before merge: first a gate (the repo's check command plus crap-gate), then three independent reviewers in parallel — spec (did we build what was asked, no more, no less), correctness via Codex (races, idempotency, money, time, authz, indexes, N+1, migrations, error paths, test quality) and structure (deep-quality-review). `--quick` runs only spec and correctness, shortened, for a live interview. Use when the user says \"/review-diff\", \"review this branch\", \"review this slice\", \"review before merge\", or before closing out a spec task."
     },
+    {
+      "name": "review-page",
+      "version": "0.1.0",
+      "hash": "sha256-f5fc0964e0558c6b9ca5d9ed77c3647b22cbc1d9710a9dfdf270d8c062caa741",
+      "description": "One interactive HTML page for a plan review or a questionnaire, built from a fixed template. Use when a pipeline session must deliver a plan review or a questionnaire as an interactive page the console shows."
+    },
     {
       "name": "to-openspec",
       "version": "0.1.3",