@zenera/cli 1.1.43 → 1.1.44

package/templates/editor/.github/{prompts/project-review.prompt.md → skills/project-review/SKILL.md}

@@ -1,5 +1,7 @@
 ---
+name: project-review
 description: Review the project against the checklist before committing.
+disable-model-invocation: true
 ---
 
 Review this project the way a maintainer would, then report. Read
@@ -18,6 +20,10 @@ spec-sync record, in the order they matter. Load the `zen-review` skill for what
 each one owns and how to read its output. Do not re-verify by hand anything it
 already decided, and do not go further while `zen check` fails - nothing below
 matters until it passes.
+If `review.sh check` already passed in this conversation and nothing has been
+edited since, run `review.sh --skip-check` instead: it verifies that receipt
+rather than probing again, and fails if the project changed. Reusing the check
+does not narrow the review - everything below still covers the whole project.
 
 **Then list the capabilities this project turns on** — a `memory:` block, a
 `zen rag` index, a sandbox, an agent that writes code (`zen-code-python`), a

package/templates/editor/.github/{prompts/spec-apply-feedback.prompt.md → skills/spec-apply-feedback/SKILL.md}

@@ -1,5 +1,7 @@
 ---
+name: spec-apply-feedback
 description: Fold the answers left in SPECIFICATION-FEEDBACK.md back into SPECIFICATION.md, and mark each answered question as answered.
+disable-model-invocation: true
 ---
 
 `SPECIFICATION-FEEDBACK.md` is a questionnaire. Each question carries two to

package/templates/editor/.github/{prompts/spec-edit.prompt.md → skills/spec-edit/SKILL.md}

@@ -1,9 +1,11 @@
 ---
-description: Change SPECIFICATION.md as the request after the command asks - written in the specification's own structure and voice, checked against what the runtime can actually do - and nothing else.
-argument-hint: what to add, change or remove in the specification
+name: spec-edit
+description: Change SPECIFICATION.md as the request given with the command asks - written in the specification's own structure and voice, checked against what the runtime can actually do - and nothing else.
+argument-hint: 'what to add, change or remove in the specification'
+disable-model-invocation: true
 ---
 
-Edit `SPECIFICATION.md` the way the request after this command asks. The
+Edit `SPECIFICATION.md` the way the request given with this command asks. The
 specification is the intent of the project; you are changing the intent, not
 the implementation. Making the project match it is `/spec-sync-project`, which
 runs after this.
@@ -11,41 +13,41 @@ runs after this.
 You change one file: `SPECIFICATION.md`. Not `agents.yaml`, not a prompt, not a
 skill, not `SPECIFICATION-FEEDBACK.md`.
 
-## 0. Everything you need is already attached
+## 0. Read everything you need first
 
-These files are attached to this prompt so the work starts without a round of
-reads. Use them as they are; do not read them again with a tool.
+These are the files the work depends on. Read them before anything else, so
+the work starts from all of them rather than from a round of reads later.
 
 The project:
 
-- [SPECIFICATION.md](../../SPECIFICATION.md) - the file you are editing.
-- [SPECIFICATION-FEEDBACK.md](../../SPECIFICATION-FEEDBACK.md) - the questions
+- [SPECIFICATION.md](../../../SPECIFICATION.md) - the file you are editing.
+- [SPECIFICATION-FEEDBACK.md](../../../SPECIFICATION-FEEDBACK.md) - the questions
   still open against it, and the ones already answered. It may not exist; that
   only means nothing is open.
 
 What the runtime can do, so that what you write is something it can build:
 
-- [zen-cli](../skills/zen-cli/SKILL.md) - every `zen` command, and
-  [its models reference](../skills/zen-cli/references/models.md) - how to find
+- [zen-cli](../zen-cli/SKILL.md) - every `zen` command, and
+  [its models reference](../zen-cli/references/models.md) - how to find
   which models this machine can actually use.
-- [zen-instructions](../skills/zen-instructions/SKILL.md) - house rules: what
+- [zen-instructions](../zen-instructions/SKILL.md) - house rules: what
   every agent is told, and what belongs there rather than in a prompt.
-- [zen-topology](../skills/zen-topology/SKILL.md) - one agent or several,
+- [zen-topology](../zen-topology/SKILL.md) - one agent or several,
   hand-off or fork, and what each costs.
-- [zen-memory](../skills/zen-memory/SKILL.md) - what memory is, who may read and
+- [zen-memory](../zen-memory/SKILL.md) - what memory is, who may read and
   write it, and what a strategy for it has to say.
-- [zen-rag-docs](../skills/zen-rag-docs/SKILL.md) - an index over a folder of
+- [zen-rag-docs](../zen-rag-docs/SKILL.md) - an index over a folder of
   markdown documents.
-- [zen-rag-schema](../skills/zen-rag-schema/SKILL.md) - an index over an OpenAPI
+- [zen-rag-schema](../zen-rag-schema/SKILL.md) - an index over an OpenAPI
   description.
-- [zen-sandbox](../skills/zen-sandbox/SKILL.md) - the container: what it mounts,
+- [zen-sandbox](../zen-sandbox/SKILL.md) - the container: what it mounts,
   what it can reach, what persists.
-- [zen-code-python](../skills/zen-code-python/SKILL.md) - reusable scripts as
+- [zen-code-python](../zen-code-python/SKILL.md) - reusable scripts as
   tools, where they live, and which agents own them.
 
-If any of these did not arrive attached - your editor does not resolve links in
-prompt files - read all of them in **one** batch of parallel reads before doing
-anything else, `SPECIFICATION-FEEDBACK.md` included if it exists. Never one at a
+Any of these already in your context - attached, or loaded as a skill - you
+need not read again. Read the rest in **one** batch of parallel reads before
+doing anything else, `SPECIFICATION-FEEDBACK.md` included if it exists. Never one at a
 time, and never skip one because the request seems not to need it: a request
 about an agent's job can still decide what that agent may remember.
 
@@ -60,7 +62,7 @@ That is the list of models with a credential on this machine - the only ones a
 `zen models search <name>` once; if it is still absent, say so in the chat and
 do not write it.
 
-If there is no request after the command, ask what to change and stop.
+If no request was given with the command, ask what to change and stop.
 
 ## 1. Understand the request against what is there
 
@@ -245,6 +247,7 @@ In the chat:
   needs a value only the reader has
 - then, in one line: send `/spec-sync-project` to make the project match.
 
-## 5. User Request:
+## 5. The request
 
-Following is the user request that the specification should address (if any):
+The words given with the command are the request the specification should
+address. Without them, ask what to change and stop (§0).

package/templates/editor/.github/{prompts/spec-sync-project.prompt.md → skills/spec-sync-project/SKILL.md}

@@ -1,5 +1,8 @@
 ---
+name: spec-sync-project
 description: Bring the project into compliance with SPECIFICATION.md, and record every open question in SPECIFICATION-FEEDBACK.md.
+argument-hint: '[file or area to focus on]'
+disable-model-invocation: true
 ---
 
 Make this project match `SPECIFICATION.md`. The specification is the intent;
@@ -29,11 +32,15 @@ file under `agents/` say what has been **built or hand-edited** since then. The
 first narrows the pass to the work nobody has done; the second only widens it,
 because a prompt or skill someone changed outside a pass still has to be
 accounted for against the specification.
+Generated house-rule copies print as `maintenance:` and do not alone widen
+the pass; their diffs remain visible and `zen check --fix` owns their repair.
 
 The scope decides what you **read and edit**. It never decides what you
-**verify**: §6, §7 and the five checks in the skill run at full size on every
-pass, however small the diff. The one exception is the skill's **spec-only
-pass**, and only under the conditions the skill sets.
+**verify** outside the skill's explicit tiers: **spec-only** and
+**model-reference-only** narrow verification under the conditions the skill
+sets. Choose the tier before loading capability skills. In a normal incremental
+pass, load only skills for capabilities the diff or unresolved work reaches;
+in a full pass, load every enabled capability's skill.
 
 When inputs disagree - a ticked answer against a later specification edit, the
 specification against `zen --version` - use the order of precedence in the
@@ -55,15 +62,17 @@ Read, in this order, and do not edit until all of it is read:
 6. `SPECIFICATION-FEEDBACK.md`, if it exists - do not re-raise something already
    open there.
 
-Never read `.tmp/logs/meta.*` - those are other runs of this prompt, not
+Never read `.tmp/logs/meta.*` - those are other runs of this command, not
 evidence - nor anything of `zen`'s own (copilot instructions §0.2).
 
 On an incremental pass this list narrows to the artefacts the scope implicates,
 and to the changed hunks of the specification rather than all of it. The
 narrowing is a claim: name what you skipped and why the diff does not reach it.
 
-Run `zen check` first and record what it said. A project that does not load is
-the first thing to fix.
+If an initial diagnostic is needed, run
+`zen check --no-models --no-sandbox` and record what it said. A project that
+does not load is the first thing to fix. Do not run expensive model or sandbox
+probes both before and after a narrow edit; the final check covers them.
 
 ## 2. Build the difference
 
@@ -102,10 +111,13 @@ forward pass can see:
 These are bugs whatever the specification says: fix them in place and report each
 one. An extra that is merely unspecified is reported under `➕`, not removed.
 
-On an incremental pass this reverse reading covers every file this pass touched
+On an incremental pass this reverse reading covers every project-owned file this pass touched
 plus every file the implementation diff in §0 named - an edit made in this
 session, or made by hand since the last pass, is exactly where a fresh
 contradiction comes from. On a full pass it is the whole tree, as above.
+Generated house-rule copies and the editor tree are maintained by `zen check`,
+not audited line by line against the specification. Preserve any project policy
+discovered in their maintenance diffs in a project-owned topic file.
 
 ## 3. Change the smallest thing that closes the gap
 
@@ -395,10 +407,12 @@ that replaced it, and leave the newer text alone.
 ## 6. Run `scripts/_setup.sh` and watch it finish
 
 After `zen check` passes, run `scripts/_setup.sh` yourself. A pass is not done
-until it has run to completion in this session. The exception is a spec-only
-pass, as the `zen-spec-sync` skill defines it: there `scripts/_setup.sh --check`
+until it has run to completion in this session. The exceptions are a spec-only
+or model-reference-only pass, as the `zen-spec-sync` skill defines them:
+there `scripts/_setup.sh --check`
 reporting every step `skipped` is enough, and anything else sends you back to
-the full run below.
+the full run below. For any tier, when `STEPS` is empty, one successful
+`scripts/_setup.sh --check` is sufficient; do not run it twice to prove nothing.
 
 It is slow - embedding a large corpus is hours, and the progress line says how
 many - so start it in the background and follow the logs instead of waiting
@@ -436,10 +450,18 @@ blind:
 
 ## 7. Verify and report
 
-Run `zen check` again and fix whatever it names rather than working around it.
+After the final edit and setup, run
+`.github/skills/zen-review/scripts/review.sh check full --fix` and fix whatever
+it names rather than working around it. The model-reference-only tier may use
+`check no-sandbox` under the skill's unchanged-sandbox conditions. A pin repair
+requires the full sandbox check. This is the final expensive check, not an
+instruction to repeat an already valid one. Use
+`.github/skills/zen-review/scripts/review.sh --skip-check` (with `no-sandbox`
+only for that eligible tier) for the mechanical review, which verifies the
+receipt instead of probing again. Edits after a check invalidate reuse.
 It validates structure and says nothing about the prose, so work §9 of the
 copilot instructions as a checklist afterwards and report each group pass or
-fail. Then report in the chat:
+fail, narrowed only by the skill's tier rules. Then report in the chat:
 
 - what changed, file by file, and which specification item each change closes
 - every prompt or skill line that served no specification item, and what became
@@ -450,7 +472,9 @@ fail. Then report in the chat:
 
 ## 8. Record the pass
 
-Last, and only once §6 and §7 have actually passed. Write
+Last, and only once §6 and §7 have actually passed. Use `snapshot.sh record`
+with explicit scope, changes, feedback, unresolved items and check outcomes
+(see the `zen-spec-sync` skill), or write
 `.spec-sync/history/<stamp>.md` in the format the `zen-spec-sync` skill gives -
 including `Still open`, which is the only place the next pass learns that an
 unchanged specification line is not yet implemented - and then:
@@ -468,4 +492,4 @@ A pass that changed nothing still writes a history file and still commits. Say
 in the chat which history file you wrote and that the baseline moved.
 
 Do not report a specification item as done unless the file that implements it
-exists, `zen check` passes, and `scripts/_setup.sh` completed every step it owns.
+exists, `zen check` passes, and setup satisfies the selected tier's proof.

package/templates/editor/.github/skills/zen-analyze-run/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-analyze-run
 description: 'Use when asked to analyze, audit or review one recorded Zenera run as a whole - how healthy it was, whether memory was used and saved correctly, whether delegation and forking were right, where tools were misused and time or tokens wasted - and which sentence in the prompts, skills, house rules or tool descriptions to change so the next run does better. Needs a run directory or run id.'
+user-invocable: false
 ---
 
 # Analyze a run

package/templates/editor/.github/skills/zen-cli/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-cli
 description: How to drive this project from the terminal with `zen` - running it, validating it, credentials, the sandbox, run reports, and the `gym` and `rag` modules.
+user-invocable: false
 ---
 
 # The `zen` command line
@@ -44,25 +45,25 @@ The full reference lives next to this file, one document per part of the command
 line. **Read the one that covers the question before answering it** - do not
 guess a flag, and do not read them all.
 
-| The question is about                                               | Read                                                            |
-| ------------------------------------------------------------------- | --------------------------------------------------------------- |
-| Global flags, `--json`, exit codes, environment, where files live   | [frame.md](./references/frame.md)                               |
-| Creating, finding or opening a project                              | [projects.md](./references/projects.md)                         |
-| Running: the TUI, one-shot answers, sessions, workspaces, overrides | [run.md](./references/run.md)                                   |
-| Many questions at once: `zen run batch`, its file, where answers go | [run.md](./references/run.md)                                   |
-| Validating: `zen check`, what it can and cannot see                 | [check.md](./references/check.md)                               |
-| API keys, providers, the keyring, "no credential" errors            | [keys.md](./references/keys.md)                                 |
-| Which models exist, whether one works, recovering from a refusal    | [models.md](./references/models.md)                             |
-| The container shell commands run in, images, `persist`              | [sandbox.md](./references/sandbox.md) (and `zen-sandbox` skill) |
-| Run reports, trajectories, what a session directory holds           | [inspect.md](./references/inspect.md)                           |
-| Reading a run yourself: the node graph, opening a node by id        | [inspect.md](./references/inspect.md) (and `zen-inspect` skill) |
-| What the agents remember, why something was recalled, forgetting    | [memory.md](./references/memory.md)                             |
-| The meta agent: `zen meta run`, stored prompts, its `--json` object | [meta.md](./references/meta.md)                                 |
-| The evaluation dataset: cases, drift, notes, drawing a sample       | [dataset.md](./references/dataset.md) (and `zen-dataset` skill) |
-| Tuning the prose on the dataset: workers, applies, STATUS.md        | [finetune.md](./references/finetune.md)                         |
-| Sharing a project: archives, what travels, importing one safely     | [export.md](./references/export.md)                             |
-| `zen gym` - a mock API from an OpenAPI/Swagger document             | [gym.md](./references/gym.md)                                   |
-| `zen rag` - searching an API description, or a pile of markdown     | [rag.md](./references/rag.md)                                   |
+| The question is about                                                | Read                                                            |
+| -------------------------------------------------------------------- | --------------------------------------------------------------- |
+| Global flags, `--json`, exit codes, environment, where files live    | [frame.md](./references/frame.md)                               |
+| Creating, finding or opening a project                               | [projects.md](./references/projects.md)                         |
+| Running: the TUI, one-shot answers, sessions, workspaces, overrides  | [run.md](./references/run.md)                                   |
+| Many questions at once: `zen run batch`, its file, where answers go  | [run.md](./references/run.md)                                   |
+| Validating: `zen check`, what it can and cannot see                  | [check.md](./references/check.md)                               |
+| API keys, providers, the keyring, "no credential" errors             | [keys.md](./references/keys.md)                                 |
+| Which models exist, whether one works, recovering from a refusal     | [models.md](./references/models.md)                             |
+| The container shell commands run in, images, `persist`               | [sandbox.md](./references/sandbox.md) (and `zen-sandbox` skill) |
+| Run reports, trajectories, what a session directory holds            | [inspect.md](./references/inspect.md)                           |
+| Reading a run yourself: the node graph, opening a node by id         | [inspect.md](./references/inspect.md) (and `zen-inspect` skill) |
+| What the agents remember, why something was recalled, forgetting     | [memory.md](./references/memory.md)                             |
+| The meta agent: `zen meta run`, its `/commands`, its `--json` object | [meta.md](./references/meta.md)                                 |
+| The evaluation dataset: cases, drift, notes, drawing a sample        | [dataset.md](./references/dataset.md) (and `zen-dataset` skill) |
+| Tuning the prose on the dataset: workers, applies, STATUS.md         | [finetune.md](./references/finetune.md)                         |
+| Sharing a project: archives, what travels, importing one safely      | [export.md](./references/export.md)                             |
+| `zen gym` - a mock API from an OpenAPI/Swagger document              | [gym.md](./references/gym.md)                                   |
+| `zen rag` - searching an API description, or a pile of markdown      | [rag.md](./references/rag.md)                                   |
 
 ## The short version
 
@@ -82,7 +83,7 @@ zen import a.zip                      unpack one somebody sent, run nothing in i
 zen key ls --check                    which credentials still work
 zen models test <ref>                 whether one model actually answers
 zen models ls --embeddings            the embedders this machine can reach
-zen meta run acme /analyze --json > analyze.json   a stored prompt, the result as JSON
+zen meta run acme /analyze --json > analyze.json   a command, the result as JSON
 ```
 
 ## Searching documents without help

package/templates/editor/.github/skills/zen-cli/references/finetune.md

@@ -30,7 +30,7 @@ tries used up  ->  difficult
 - **A parked case gives its worker back**, so another case runs while it waits
   for an apply; once woken, it takes a worker before any new case does.
 - **Applies are batched.** Parked cases' improvement requests are applied
-  together by `/finetune-apply` once **M** cases are parked, or once nothing is
+  together by `/zen-finetune-apply` once **M** cases are parked, or once nothing is
   running and no case is left to start. `-M` is at least 2 (`-M 1` needs
   `--force`): one case is an anecdote. No run starts during an apply; runs in
   flight finish first. Each apply gets its own `applies/<NNN>/APPLY.md`: every

package/templates/editor/.github/skills/zen-cli/references/meta.md

@@ -2,8 +2,8 @@
 
 ```
 zen meta run [project] "<question>"        ask it something
-zen meta run [project] /<name> [words]     run .github/prompts/<name>.prompt.md
-zen meta prompts [project]                 list the stored prompts
+zen meta run [project] /<name> [words]     run the command .github/skills/<name>/SKILL.md
+zen meta prompts [project]                 list the commands (skills without zen-)
 zen meta resume [project] [session]        carry on a run that stopped
 zen meta model [ref]                       show or set the model it uses
 zen meta dataset <verb>                    see dataset.md

package/templates/editor/.github/skills/zen-code-python/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-code-python
 description: Code an agent writes must be a reusable tool that can be remembered and re-run, never a one-off. Holds the coding rules (`references/code_python.md`) and decides where they go in the target project - a section of a dedicated code agent's system prompt, or a coding skill for generic agents that sometimes run code - how to adapt them, and what a prompt or skill for a code-writing agent must never say. Load before writing, editing or reviewing any agent prompt, skill or house rule for an agent that writes or runs code - any agent holding `sandbox:*` or `run_command` - and before shipping a script inside a skill.
+user-invocable: false
 ---
 
 # Code an agent writes is a tool

package/templates/editor/.github/skills/zen-dataset/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-dataset
 description: Keep a project's evaluation dataset in `dataset/` with `zen meta dataset` - every case read from its sources with a class, a complexity, tags, a verbatim rubric and an anchor to the section it came from. Covers extracting a training set of any shape into a proposal, applying it as a revision, finding which cases their sources moved under (drift) and re-reading only those sections, settling gone and uncovered sections, overriding a field by hand, leaving notes and verdicts on a case, reading a case's history and the sessions that touched it, and drawing samples by criteria (class, complexity, tag, rubric, revision, verdict, note kind, source, text) stratified, weighted and seeded. Load before building or refreshing a dataset, before running /dataset, before choosing which cases to run, and before writing a note or verdict on a case.
+user-invocable: false
 ---
 
 # The dataset

package/templates/editor/.github/skills/zen-finetune/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-finetune
-description: Fine-tune an agent project against a training set, a batch at a time, and every batch twice over — first with NO memory, then WITH the memory it just built. Read the whole training set, in any format, into a classified, complexity-rated dataset with rubrics; choose up to a limit of cases from it evenly by class, rubric and complex cases first. Batch 1 is a smoke test of 3 cases; each batch that goes smoothly doubles the next, up to a maximum, and each is built when it is needed from new cases plus rechecks of earlier ones — difficult ones first, then complex ones. Each batch runs with an empty memory via `zen run batch`; every trajectory is graded with `zen inspect graph`, `node` and `ask` for rubric compliance, llm-call count, fork use, assumptions, what it committed to memory and delegation; the proposals of every case are merged into edits of prompts, skills, house rules and `agents/<topic>-policy-instructions.md` files, and the same cases run again until they pass. Then what the passing run's cases committed is merged with the last good memory into a candidate, every case runs again from its own copy of it, recall and re-commits are graded the same way, the memory policy is tuned until recall makes the work dramatically cheaper without changing a verdict or re-committing what memory already held — and only then does the candidate become the last good memory and the next batch start. Cases that cause the most trouble go on a difficult list and keep coming back until they are fixed or declared stuck. The agent writes `finetune/README.md` — the plan, a mermaid map of every step, and the progress — before the first run and patches it after every step; `scripts/next.mjs` reads the state off disk so an interrupted session can resume. Load before evaluating an agent project against example queries, before acting on "it gets this wrong", when asked to improve prompts or instructions from evidence rather than taste, when building an eval or regression set out of a specification, when optimising memory use or run cost, or whenever a batch of runs has to be graded rather than merely executed.
+description: Fine-tune an agent project's prose - prompts, skills, house rules, policy files - against a training set, a batch at a time, each batch first with NO memory and then WITH the memory it built. Batch 1 is a 3-case smoke test, each smooth batch doubles the next, and earlier difficult and complex cases come back as rechecks. Trajectories are graded with `zen inspect`, proposals merged into edits, and runs repeated until they pass; then the committed memory becomes a candidate and the memory policy is tuned until recall makes the work cheaper. `finetune/README.md` and `scripts/next.mjs` keep the state on disk so an interrupted session resumes. Load before evaluating a project against example queries, acting on "it gets this wrong", improving instructions from evidence, building a regression set from a specification, optimising memory use or run cost, or grading a batch of runs.
+user-invocable: false
 ---
 
 # Fine-tuning an agent project

package/templates/editor/.github/{prompts/finetune-apply.prompt.md → skills/zen-finetune-apply/SKILL.md}

@@ -1,10 +1,13 @@
 ---
-description: Apply a batch of improvement requests from the tuning loop to the project's prose - merge them into patterns, edit prompts, skills and policy files, tidy up every file touched, and record what was done with each. Run by `zen meta finetune`; the line after the prompt names the apply directory, and a brief follows it.
+name: zen-finetune-apply
+description: Apply a batch of improvement requests from the tuning loop to the project's prose - merge them into patterns, edit prompts, skills and policy files, tidy up every file touched, and record what was done with each. Run only by `zen meta finetune`, never by hand; the words given with it name the apply directory, and a brief follows them.
+user-invocable: false
+disable-model-invocation: true
 ---
 
 The tuning loop has collected improvement requests from several cases and
-wants them applied **together**. The line after this prompt names the apply
-directory.
+wants them applied **together**. The words given with this skill name the
+apply directory.
 
 Every sentence you add is read by every later call of every agent that loads
 it, so prose has a price even when it fixes the case in front of you. The loop
@@ -14,7 +17,7 @@ your edit; one it broke comes back to the next apply as a request.
 
 ## What you are given
 
-A `## The brief` section after that line is what the loop already read and
+A `## The brief` section after them is what the loop already read and
 worked out for you, from the files below. Work from it:
 
 - Do not read a file the brief shows, and do not run a command it shows -

package/templates/editor/.github/skills/zen-inspect/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-inspect
 description: 'Use when an LLM agent must diagnose a recorded Zenera run non-interactively: read `zen inspect graph`, open selected nodes, replay an `llm_call` with `zen inspect ask`, identify loops, failed tools, wrong prompts, missed skills, early hand-offs, failed branches, compaction, latency, or token waste. Requires explicit run, node, and question arguments so commands remain deterministic and never prompt.'
+user-invocable: false
 ---
 
 # Diagnose a run non-interactively

package/templates/editor/.github/skills/zen-inspect-ask/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-inspect-ask
 description: 'Use when formulating a question for `zen inspect ask` about an `llm_call` node of a recorded Zenera run - especially a "why did you NOT do X" question (why no `memory_search` first, why no `fork` for independent research branches, why no skill, why no test run). Covers choosing the node, ruling out missing tools before asking, wording the counterfactual so the answer quotes the instruction that blocked the better behaviour, and verifying that quote against the recorded request.'
+user-invocable: false
 ---
 
 # Asking a run why it did not do the better thing

package/templates/editor/.github/skills/zen-instructions/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-instructions
 description: The house rules - `agents/instructions.md` and every `agents/<topic>-instructions.md` prepended to every agent's system prompt. How the set is discovered and ordered, the `requires:` frontmatter and its closed vocabulary (`files`, `files-write`, `fork`, `memory`, `memory-write`, `memory-forget`), which four documents are `zen`'s own and are replaced by `zen check --fix`, how a project writes its own customisable topic prompts beside them (`files-policy-instructions.md`, `memory-policy-instructions.md`, `fork-<topic>-instructions.md`, `tools-<topic>-instructions.md`) without losing the copy, what belongs in a house rule as against an agent prompt or a skill, and every `zen check` finding these files can produce. Load before creating, editing, reviewing or deleting any `agents/*instructions.md`, before adding a capability whose rules arrive as one, and whenever `rules.stale`, `rules.unreached`, `files.uninstructed`, `memory.uninstructed` or `fork.uninstructed` is reported.
+user-invocable: false
 ---
 
 # House rules

package/templates/editor/.github/skills/zen-memory/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-memory
 description: Agent memory in Zenera projects - the `memory:` block and per-agent `access`/`sees`/`writes`/`autoRecall`, the five `memory_*` tools (when to use `memory_grep` instead of `memory_search`), kinds, relations and how recall ranks, inspecting a graph with `zen memory`, designing a memory strategy, `agents/memory-instructions.md` vs `agents/memory-policy-instructions.md`, remembering files under `/memory`, and putting memory in front of a `zen rag` index.
+user-invocable: false
 ---
 
 # Memory

package/templates/editor/.github/skills/zen-memory-warmup/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-memory-warmup
 description: Pre-populating an agent project's memory graph before production by running a curated file of seed queries through `zen run batch` — one parallel batch instead of a hand-rolled fan-out, with per-item workspaces and per-item memories the command makes for you, choosing the source graph with --memory, bounding the parallelism with --concurrency, warming with a stronger --model, reading what each query learned from batch.json and per-item output.json, folding it all back with zen memory merge, validating with zen memory stats, atomic promotion into the project, and generating the population script in scripts/memory_warmup.sh.
+user-invocable: false
 ---
 
 # Memory Warmup

package/templates/editor/.github/skills/zen-rag-docs/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-rag-docs
 description: What a document index is, how to build one from a folder of `.md` files with `zen rag docs index` (or `npx @zenera/cli`), and how to ask it something - searching by meaning and narrowing to a release, a heading or a table, listing and grepping it exactly instead of reaching for shell `grep`/`rg`, reading a section back verbatim, giving it to an agent as tools, and writing the project skill that a wired-in index requires. For an OpenAPI description instead of prose, see `zen-rag-schema`.
+user-invocable: false
 ---
 
 # The document index

package/templates/editor/.github/skills/zen-rag-schema/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-rag-schema
 description: What a schema index is, how it finds the right call inside a large OpenAPI/Swagger document, and how to build and query one with `zen rag schema` (or `npx @zenera/cli`) - searching it by meaning, listing and grepping it exactly instead of reaching for shell `grep`/`rg`, tracing a field up to the operations that carry it, giving it to an agent as tools, and writing the project skill that a wired-in index requires. For a pile of markdown instead of an API description, see `zen-rag-docs`.
+user-invocable: false
 ---
 
 # The schema index

package/templates/editor/.github/skills/zen-review/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: zen-review
 description: Checking a project before committing - the three mechanical checks `/project-review` makes before any judgement (`zen check`, the §2.5 path sweep, the spec-sync record), what each one owns, what their exit codes mean, which findings hand off to `zen-instructions`, and what deliberately has no check because no tool can make it. Load before running `/project-review`, before saying a project is ready, and whenever a review finding needs verifying rather than restating.
+user-invocable: false
 ---
 
 # Reviewing a project
@@ -40,6 +41,39 @@ nothing about the model id it is spent on.
 Nothing below matters while `zen check` fails. Report what it said and fix that
 first.
 
+## Reusing a check within the same pass
+
+Instead of calling `zen check` separately and repeating it in the review, run:
+
+```sh
+.github/skills/zen-review/scripts/review.sh check full --fix
+.github/skills/zen-review/scripts/review.sh --skip-check
+```
+
+`check` runs only the CLI check and saves a receipt in `.tmp/review-check.json`
+on success. `--skip-check` verifies that receipt, then still runs the path sweep
+and spec-sync checks. It fails explicitly for a missing, failed, stale or
+insufficient check; it never silently treats a skipped check as success.
+
+Receipts cover project file contents, permissions, additions and deletions, and the CLI
+version. They exclude only root `.git/`, `.tmp/` and `.spec-sync/`, so writing
+history does not invalidate a result. Symlinks and special files are unsupported:
+run the ordinary review instead. Hashing includes assets and dependencies and
+can itself be costly for large projects; the ordinary review remains available.
+
+This is same-pass reuse, not a persistent health cache. Do not reuse after
+changing credentials, environment variables, external files, ignored scratch
+inputs or remote resources: those are not certified by the receipt. Run a fresh
+check instead. Only use reuse for a self-contained project's stable inputs.
+
+`check no-sandbox` and `--skip-check no-sandbox` are for the spec-sync skill's
+eligible model-reference-only pass. They still probe models. `check fast` and
+`--skip-check fast` omit both expensive probes and are for iteration only.
+A full receipt covers either partial mode, but a partial receipt cannot stand
+in for a full one. If a partial check repairs or otherwise changes files, no
+reusable receipt is issued: run `check full`, because a repair may have changed
+the sandbox pin. Finish setup and all edits before saving the final receipt.
+
 ## The script this skill ships
 
 ### `check-paths.sh` - the §2.5 sweep

package/templates/editor/.github/skills/zen-review/scripts/check-paths.sh

@@ -38,7 +38,7 @@ NOISE='^(and/or|he/she|his/her|input/output|read/write|w/o|n/a|N/A|24/7|km/h)$|^
 # second half is indistinguishable from a real absolute path once it is alone.
 #
 # A meta agent command, `zen meta run /spec-edit`, goes the same way: its
-# `/<name>` is a stored prompt, not a file the running agent is told to open.
+# `/<name>` is a command (a skill), not a file the running agent is told to open.
 strip_urls() {
     sed -E -e 's#[a-zA-Z][a-zA-Z0-9+.-]*://[^][ )"'"'"'`>]*##g' \
         -e 's#(zen meta run( [A-Za-z0-9_.-]+)?) /[A-Za-z0-9_-]+#\1#g' "$1"

package/templates/editor/.github/skills/zen-review/scripts/check-receipt.mjs

@@ -0,0 +1,95 @@
+import { createHash } from 'node:crypto';
+import { spawnSync } from 'node:child_process';
+import { lstatSync, mkdirSync, readFileSync, readdirSync, writeFileSync } from 'node:fs';
+import { resolve } from 'node:path';
+
+const [action, mode = 'full', fix] = process.argv.slice(2);
+const modes = {
+    full: [],
+    'no-sandbox': ['--no-sandbox'],
+    fast: ['--no-models', '--no-sandbox'],
+};
+const receipt = '.tmp/review-check.json';
+
+function fingerprint() {
+    const hash = createHash('sha256');
+    function walk(dir) {
+        for (const entry of readdirSync(dir, { withFileTypes: true }).sort((a, b) =>
+            a.name < b.name ? -1 : a.name > b.name ? 1 : 0,
+        )) {
+            if (dir === '.' && ['.git', '.tmp', '.spec-sync'].includes(entry.name)) continue;
+            const path = `${dir}/${entry.name}`;
+            hash.update(JSON.stringify([path, entry.isDirectory(), lstatSync(path).mode]));
+            if (entry.isDirectory()) walk(path);
+            else if (entry.isFile())
+                hash.update(createHash('sha256').update(readFileSync(path)).digest('hex'));
+            else throw new Error(`cannot reuse validation with a symlink or special file: ${path}`);
+        }
+    }
+    walk('.');
+    return hash.digest('hex');
+}
+
+function version() {
+    const result = spawnSync('zen', ['--version'], { encoding: 'utf8' });
+    if (result.error) throw result.error;
+    if (result.status !== 0) throw new Error('zen --version failed');
+    return result.stdout.trim();
+}
+
+try {
+    if (
+        !Object.hasOwn(modes, mode) ||
+        !['run', 'verify'].includes(action) ||
+        (fix !== undefined && (action !== 'run' || fix !== '--fix')) ||
+        process.argv.length > 5
+    ) {
+        throw new Error('usage: check-receipt.mjs run|verify full|no-sandbox|fast [--fix]');
+    }
+    if (action === 'run') {
+        mkdirSync('.tmp', { recursive: true });
+        // Invalidate the previous result before trying a new check.
+        writeFileSync(receipt, 'null\n');
+        const before = fingerprint();
+        const result = spawnSync('zen', ['check', ...modes[mode], ...(fix ? [fix] : [])], {
+            stdio: 'inherit',
+        });
+        if (result.error) throw result.error;
+        if (result.status !== 0) process.exit(result.status ?? 1);
+        const after = fingerprint();
+        if (mode !== 'full' && before !== after) {
+            throw new Error(
+                'files changed during a partial check (possibly a sandbox pin repair); run check full before reusing validation',
+            );
+        }
+        writeFileSync(
+            receipt,
+            JSON.stringify({
+                root: resolve('.'),
+                mode,
+                version: version(),
+                fingerprint: after,
+            }) + '\n',
+        );
+        console.log(`check receipt: ${receipt}`);
+    } else {
+        const saved = JSON.parse(readFileSync(receipt, 'utf8'));
+        const covers =
+            saved &&
+            (saved.mode === 'full' ||
+                saved.mode === mode ||
+                (saved.mode === 'no-sandbox' && mode === 'fast'));
+        if (
+            !covers ||
+            saved.root !== resolve('.') ||
+            saved.version !== version() ||
+            saved.fingerprint !== fingerprint()
+        ) {
+            throw new Error('check receipt is stale or lacks required probes; run a fresh check');
+        }
+        console.log(`zen check: reusing successful ${saved.mode} check`);
+    }
+} catch (error) {
+    console.error(`check receipt: ${error.message}`);
+    process.exitCode = 1;
+}