@zenera/cli 1.1.25 → 1.1.27

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

@@ -557,7 +557,7 @@ and why.
 | `agents/prompts/<name>.md`                          | no memory   | Yes — the usual place a per-agent finding lands                       |
 | `agents/skills/<name>/SKILL.md`                     | no memory   | Yes — when the fix is knowledge, not standing policy                  |
 | `agents/instructions.md`                            | no memory   | Yes — when the fix binds every agent in the project                   |
-| `agents/<topic>-policy-instructions.md`             | no memory   | Yes — new files are created here, one topic per file                  |
+| `agents/<topic>-policy-instructions.md`             | no memory   | Yes — edit the owner; create one only when the rule is absent         |
 | `agents/memory-policy-instructions.md`              | both        | Yes — what to commit without memory; recall and re-commit with it     |
 | the memory paragraph of a prompt or skill           | with memory | Only where an ask's `why` line names it                               |
 | `agents.yaml`                                       | —           | No — a structural finding is an open problem in the README            |
@@ -1224,10 +1224,11 @@ across proposals_. Two cases proposing the same sentence in different words are
 one pattern; two cases proposing opposite edits to one sentence are a conflict,
 and the conflict is the finding. Write the merged table into `findings.md`,
 under `## Proposals, merged`: one row per pattern, the cases and nodes behind
-it, the file, and the edit. A cost pattern becomes a rule the same way a
-correctness one does: three cases listing a directory to find a file the skill
-could name is a line in that skill; three cases running independent lookups in
-sequence is a fan-out rule in the prompt.
+it, the one-sentence obligation, intended audience, owner, existing locations,
+disposition, and edit. A cost pattern becomes a rule the same way a correctness
+one does: three cases listing a directory to find a file the skill could name
+is a line in that skill; three cases running independent lookups in sequence is
+a fan-out rule in the prompt.
 
 **One case is an anecdote.** A rule written from a single failure fixes that
 case and adds a line every other run has to read. Three cases missing the same
@@ -1266,6 +1267,30 @@ Prefer mechanical wording. "Put X before Y", "if the path does not end in `.py`,
 stop", "copy this literal verbatim" are followed. "Be thorough", "generalise
 appropriately" are followed about half the time and are not worth their tokens.
 
+### Prove the owner and the absence before editing
+
+Do this for every merged pattern, including memory patterns:
+
+1. State the behavioral obligation without using the wording of any proposed
+   rule.
+2. Name exactly which agents must obey it. Choose the narrowest source that
+   reliably reaches all of them: one agent's prompt, the workflow skill, a
+   capability policy, or the project-wide instructions.
+3. Search every source those agents load for the same obligation: house rules,
+   capability policies, their prompts, preloaded skills and relevant on-demand
+   skills. Search distinctive verbs and nouns and obvious alternate wording,
+   not only an exact quote. Use the assembled request from the inspected node
+   to settle which sources actually reached the failing call.
+4. Put every matching or conflicting location in the merged table and choose
+   exactly one disposition: `edit existing`, `move and delete`, `delete
+  contradiction`, or `add because absent`.
+
+An `add because absent` row is the only permission to append prose. If several
+sources express the obligation, consolidate them into the one owner and delete
+the others in the same round. If an existing broad rule caused the failure,
+rewrite or narrow it; do not leave it in place and add a case-specific
+exception elsewhere.
+
 ## Phase 6 — Apply (step 6)
 
 Route each rule by what kind of thing it is. When the pattern's `why` line
@@ -1274,22 +1299,32 @@ that file is where the change goes, whatever the table below would have
 guessed; find it the way **zen-analyze-run** finds its sources of trouble, by
 grepping the quote in the request and then in `agents.yaml` and `agents/`.
 
-| The finding is…                               | It goes in                                                                   |
-| --------------------------------------------- | ---------------------------------------------------------------------------- |
-| One agent's behaviour, one agent's job        | `agents/prompts/<agent>.md`                                                  |
-| A fact, a format, an API shape, a procedure   | A skill — extend one, or create one                                          |
-| A standing rule every agent must obey         | `agents/instructions.md`                                                     |
-| A standing rule about one capability          | `agents/<topic>-policy-instructions.md` — new file                           |
-| The wrong agent had the tool, or no agent did | not changed — structural: an open problem in the README, reported at the end |
-| The dataset was wrong                         | `finetune/dataset.json`, before the next run                                 |
-
-New policy files are the usual output of a first batch: `memory-policy-`,
-`fork-policy-`, `tools-policy-`, `files-policy-instructions.md`. They sit beside
-`zen`'s own four, they are yours, and `zen check --fix` does not touch them. Load
-**zen-instructions** before writing one — in particular: `requires:` is _not_
-inherited, so a policy file must repeat the condition of the file it sits next to
-(`requires: memory` beside `memory-instructions.md`), and the files are prepended
-in filename order, so `memory-policy-` reads after `memory-instructions.md`.
+| The finding is…                                          | It goes in                                                                                            |
+| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
+| One agent's behaviour, one agent's job                   | `agents/prompts/<agent>.md`                                                                           |
+| A fact, a format, an API shape, a procedure              | A skill — extend one, or create one                                                                   |
+| A standing rule every agent must obey                    | `agents/instructions.md`                                                                              |
+| A project-wide rule every user of a capability must obey | its existing `agents/<topic>-policy-instructions.md`, or a new one only when the obligation is absent |
+| The wrong agent had the tool, or no agent did            | not changed — structural: an open problem in the README, reported at the end                          |
+| The dataset was wrong                                    | `finetune/dataset.json`, before the next run                                                          |
+
+Policy files are a last destination, not the usual output of a batch. Create
+`memory-policy-`, `fork-policy-`, `tools-policy-` or
+`files-policy-instructions.md` only when the merged table proves the rule is
+absent and every agent with that capability must obey it. They sit beside
+`zen`'s own four, they are yours, and `zen check --fix` does not touch them.
+Load **zen-instructions** before writing one — in particular: `requires:` is
+_not_ inherited, so a policy file must repeat the condition of the file it sits
+next to (`requires: memory` beside `memory-instructions.md`), and the files are
+prepended in filename order, so `memory-policy-` reads after
+`memory-instructions.md`.
+
+Apply the disposition from the merged table. Prefer editing an existing owner;
+when moving a rule, add it to the owner and delete every displaced copy in the
+same change. Do not keep a general rule and stack narrower exceptions under it.
+Before finishing, search again for the obligation's terms and read the affected
+assembled prefix in order. The remaining copies must either have different
+audiences or be deleted.
 
 Never edit `agents/memory-instructions.md`, `agents/fork-instructions.md`,
 `agents/tools-instructions.md` or `agents/files-instructions.md`. They are copies
@@ -1299,10 +1334,11 @@ change the master upstream in the CLI templates, and note it in the run.
 
 Record what changed and why in the run's own `changes.md` —
 `finetune/runs/batch01-nomem-run1/changes.md` — one entry per edit, each
-naming the merged pattern and the proposals behind it. It is what makes the next
-run's difference interpretable, and it is what you read when a number goes
-_down_. `next.mjs` looks for it to tell whether a graded run is waiting to be
-confirmed.
+naming the merged pattern and the proposals behind it. Include the obligation,
+owner, searches, existing locations, disposition, rules removed or replaced,
+and the net line change. It is what makes the next run's difference
+interpretable, and it is what you read when a number goes _down_. `next.mjs`
+looks for it to tell whether a graded run is waiting to be confirmed.
 
 Then:
 
@@ -1519,12 +1555,14 @@ Then the per-case grading, each case ending in its proposals, as in phase 4.
 ### Merge, update the memory policy, run again (steps 12–14)
 
 Merge the proposals into patterns exactly as in phase 5, and write the merged
-table under `## Proposals, merged`. Then apply them — to
-`agents/memory-policy-instructions.md`, or to the memory paragraph of a prompt
-or skill where an ask's `why` line names one: rules about _when_ to recall, when
-to trust a recalled fact, when to go and look anyway, and when **not** to
-commit because memory already holds it. Record them in this run's `changes.md`
-and run `zen check`.
+table under `## Proposals, merged`. Run the phase 5 ownership and duplicate
+check before applying anything. Apply a project-wide rule to
+`agents/memory-policy-instructions.md` only when every memory-enabled agent must
+obey it; apply one agent's behavior to its prompt and one workflow's behavior to
+its skill. These rules cover _when_ to recall, when to trust a recalled fact,
+when to go and look anyway, and when **not** to commit because memory already
+holds it. Edit or consolidate an existing rule before adding one. Record the
+disposition and removals in this run's `changes.md`, then run `zen check`.
 
 A pattern that cannot be written as one of those is a no-memory finding that
 escaped: the with-memory runs do not fix it. Write it under "Open problems" in
@@ -1730,8 +1768,11 @@ next one. Change them upstream, in the CLI's `templates/editor/.github/skills/`.
     case is tuned against unless the user named a smaller limit.
 13. **Patch the README after every step, by hand.** Exactly one `now` node on the
     map. When `next.mjs` says `first: patch finetune/README.md`, do that first.
-14. **Never edit from one case's proposal.** Merge every case's proposals first;
-    a rule needs a pattern, unless the failure was catastrophic.
+14. **Never edit from one case's proposal, and never apply a pattern by merely
+    appending prose.** Merge every case's proposals first; then prove the owner,
+    search loaded sources for semantic duplicates, and record `edit existing`,
+    `move and delete`, `delete contradiction`, or `add because absent`. A rule
+    needs a pattern unless the failure was catastrophic.
 15. **Never edit `zen`'s four instruction files.** `zen check --fix` overwrites
     them. Project policy goes in a `-policy-` file beside them.
 16. **Never adjust a rubric after seeing the run.** Fix a wrong rubric before the

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

@@ -278,9 +278,22 @@ zen inspect node n11 --part thinking --part text --dir <run dir>
 zen inspect node n11 --full --dir <run dir>
 ```
 
+An `llm_call` carries two more parts read out of its request, held back the
+same way: `tools`, the tool names that call was offered, one per line, and
+`messages`, the conversation it saw, one clipped line per message with its
+tool calls under it. They answer "was the tool offered" and "what had it seen"
+without opening the request. For the request itself as JSON, `--raw` prints
+one part of one node with no framing, ready for `jq`:
+
+```sh
+zen inspect node n11 --part tools --dir <run dir>
+zen inspect node n11 --part request --raw --dir <run dir> | jq '.messages'
+```
+
 `--part` is repeatable and matches a **prefix**, so `--part call` catches a part
 named `call run_command (toolu_01A…)` without your typing the id. A name that
-matches nothing is an error listing the parts the node does carry.
+matches nothing is reported in a `#` line; when no name matches at all it is an
+error listing the parts the nodes do carry.
 
 ```
 # zen inspect node · 1/41 nodes of run 20260825-143012-a7f3 · ids from `zen inspect graph`

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

@@ -35,14 +35,14 @@ invented rationale.
 
 | Check                                  | How                                                                                     | If it fails, the cause is                          |
 | -------------------------------------- | --------------------------------------------------------------------------------------- | -------------------------------------------------- |
-| The tool was offered on that call      | grep the recorded request for its schema (below)                                        | `agents.yaml` - tool not granted, or depth cap hit |
+| The tool was offered on that call      | `--part tools` of that call (below)                                                     | `agents.yaml` - tool not granted, or depth cap hit |
 | The instruction file was in the prompt | the `system_prompt` label lists files: `fork-instructions.md`, `memory-instructions.md` | missing file, or its `requires:` not met           |
 | The skill was loaded                   | a `load_skills` node naming it, or the skill index in `request`                         | binding in `agents.yaml` (`skills:`)               |
 | Memory was already recalled for it     | a `memory_recall` node before the call; `recall 0 nodes`                                | memory content, not behaviour                      |
 | The context still held what it needed  | no `compaction` before the node, or the item is not `hidden by` one                     | compaction, not instructions                       |
 
 ```sh
-zen inspect node n9 --part request --dir <run-dir> | grep -oE '"name": *"(fork|memory_search|memory_grep)"' | sort -u
+zen inspect node n9 --part tools --dir <run-dir> | grep -xE 'fork|memory_search|memory_grep'
 ```
 
 Only when every row passes is the question "which instruction stopped you".
@@ -144,7 +144,8 @@ zen inspect ask n9 --question-file .tmp/ask/<run-id>/n9-memory.md --dir <run-dir
 ```
 
 - One file per question, at `.tmp/ask/<run-id>/<node>-<topic>.md`. `.tmp/` is
-  the project's git-ignored scratch.
+  the project's git-ignored scratch. A tuning loop's brief names its own `ask/`
+  folder instead: use that one.
 - `--question-file` is the only way the question reaches `zen`. Never a quoted
   argument, a heredoc, `$(cat ...)`, or a Python or Node script around `zen`.
 - A retry (section 5, step 1) or a second opinion (step 4) reuses the same

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

@@ -185,7 +185,7 @@ open something, and a running agent sees four: `/workspace`, `/assets`,
 
 It reads `agents/*instructions.md` and exits `1` on any candidate.
 `agents/memory-instructions.md` is exempt: it is worked examples by design, and
-`check-instructions.sh` is the check it actually needs.
+`rules.stale` is the check it actually needs.
 
 ## What `zen check` reports
 
@@ -210,17 +210,9 @@ is quietly a project whose agents were never told how to call a tool. And
 `rules.unreached` deliberately never fires for ours, because they land in every
 project whether the capability is used or not.
 
-The memory copy has a check of its own, byte for byte, because the two files
-drift by trailing whitespace inside tables and that is invisible on screen:
-
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh        # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh diff   # every differing line
-.github/skills/zen-memory/scripts/check-instructions.sh fix    # copy the reference over
-```
-
-Never read the two against each other by eye, and never paraphrase the reference
-into prose of your own.
+`rules.stale` compares bytes, so it catches the usual drift - trailing
+whitespace inside a table, invisible on screen. Never compare one of ours
+against anything by eye, and never paraphrase one into prose of your own.
 
 ## Related
 

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

@@ -1,6 +1,6 @@
 ---
 name: zen-memory
-description: How agent memory is organised and how to configure it in `agents.yaml` - the `memory:` block, per-agent `access`/`sees`/`writes`/`autoRecall`, the five `memory_*` tools, kinds and relations, how recall ranks and stitches a subgraph, when an agent should reach for `memory_grep` instead of `memory_search`, how to inspect a graph with `zen memory search`/`grep`/`export`, and how to design a memory strategy for a project. Includes the default usage rules every memory-enabled project must carry in `agents/memory-instructions.md` (references/memory-instructions.md), the script that says whether that copy is still current (scripts/check-instructions.sh), where a project's own customisations go instead (`agents/memory-policy-instructions.md`, under `requires: [memory]`), what to commit and what never to, how to keep a working file under `/memory` and re-run it later, and how to put memory in front of a `zen rag schema` or `zen rag docs` index so a search that already succeeded once is not paid for again.
+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.
 ---
 
 # Memory
@@ -142,8 +142,8 @@ node. It is house rules under `requires: [memory]`, so it reaches exactly the
 agents that have the store and no others, and it gates its own advice on the
 tools the reader actually holds. The runtime adds the preference block and
 nothing else. Do not restate any of it in a prompt; state project-specific
-policy instead, and keep the copy byte-identical to the reference so
-`check-instructions.sh` stays meaningful.
+policy instead, and leave the file exactly as `zen` wrote it - `zen check`
+reports any byte that differs as `rules.stale`.
 
 ## How it is organised
 
@@ -556,38 +556,20 @@ gets whether it loads the skill or not.
 
 ## The house rules
 
-**Every project that enables memory carries `references/memory-instructions.md`
-in its own `agents/memory-instructions.md`**, as part of turning memory on. That
-file is how the agent is told to use the store: read and search it only through
-the tools, never through `/memory` itself, and what a node must carry to still be
-worth having.
+**Every project that enables memory carries `agents/memory-instructions.md`**,
+as shipped by `zen`. That file is how the agent is told to use the store: read
+and search it only through the tools, never through `/memory` itself, and what a
+node must carry to still be worth having.
 
 `zen init` writes it, because the projects it scaffolds have memory on from the
-first run. Two cases are left to check by hand: a project that turned memory on
-afterwards, and one whose copy has drifted from the reference or was deleted.
+first run. `zen check` covers the two cases left over:
 
-Neither is checked by eye. The skill ships the check, and it is one command:
+- `memory.uninstructed` - memory is on and the file is missing or empty.
+- `rules.stale` - any byte differs from what this `zen` ships. The usual drift
+  is trailing whitespace inside a table, invisible on screen.
 
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh        # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh diff   # every differing line
-.github/skills/zen-memory/scripts/check-instructions.sh fix    # copy the reference over
-```
-
-It says whether this project turns memory on at all, exits non-zero on a copy
-that is missing or stale, and prints the `cp` that repairs it. When the only
-difference is trailing whitespace it says so - that is the usual drift, it is
-invisible on screen, and it is the reason reading the two files side by side
-never caught it.
-
-It is a copy, not a transcription - this reference already sits in the project,
-because `zen init` and `zen open` write the whole `.github/` tree, and they write
-it from the same file the project's copy came from. What `fix` runs, from the
-project root, is exactly:
-
-```sh
-cp .github/skills/zen-memory/references/memory-instructions.md agents/memory-instructions.md
-```
+`zen check --fix` repairs both, writing the file from the version of `zen` in
+hand. Never write or patch it by hand.
 
 Everything the project keeps under `agents/` named `<topic>-instructions.md` is
 prepended to every agent, in filename order, so this belongs in its own document
@@ -598,19 +580,55 @@ memory and it leaves with it.
 
 | File                                   | Is                                                                 | Owned by    |
 | -------------------------------------- | ------------------------------------------------------------------ | ----------- |
-| `agents/memory-instructions.md`        | the DEFAULT rules - how the store works, and how any agent uses it | this skill  |
+| `agents/memory-instructions.md`        | the DEFAULT rules - how the store works, and how any agent uses it | `zen`       |
 | `agents/memory-policy-instructions.md` | this PROJECT's customisations on top of them                       | the project |
 
-**Keep the first a pure copy.** It is predefined: it describes this version of
-the runtime, not this project, and `check-instructions.sh` compares it byte for
-byte. Anything edited into it is lost the next time the reference changes.
+### Keep project policy additive
+
+`agents/memory-policy-instructions.md` is not a second memory manual and is not
+the default destination for every memory finding. A rule belongs there only
+when it changes how **every memory-enabled agent in this project** uses memory
+and the default rules do not already say it.
+
+| The rule is about                                                   | Owner                                                   |
+| ------------------------------------------------------------------- | ------------------------------------------------------- |
+| How the memory tools and graph work in every Zenera project         | the upstream default; never repeat it in project policy |
+| A project-wide restriction or obligation for every memory agent     | `agents/memory-policy-instructions.md`                  |
+| One agent's job, finish condition, recall timing or commit behavior | that agent's prompt                                     |
+| One workflow, index, API or body of domain knowledge                | the skill that teaches that workflow or knowledge       |
+| One observed case with no repeated pattern yet                      | the tuning findings, not an instruction                 |
+
+Before adding or changing a project memory rule:
+
+1. Write the intended obligation in one sentence without naming a file.
+2. Choose its owner from the table above and name the agents that must receive
+   it. If that set is smaller than every memory-enabled agent, policy is the
+   wrong owner.
+3. Search the default memory rules, every project policy file, the affected
+   prompts and the affected skills for the obligation. Search distinctive
+   verbs and nouns plus obvious alternate wording; an exact-text search alone
+   does not find semantic duplicates.
+4. Record one disposition: `edit existing`, `move and delete`, `delete
+  contradiction`, or `add because absent`. An addition without this record is
+   not ready to apply.
+5. Make one source authoritative in the same change. Remove weaker copies and
+   rewrite a conflicting rule as one complete rule; never preserve the old rule
+   and append an exception beneath it.
+
+The narrowest source that reliably reaches every intended agent owns the rule.
+Several cases supporting one pattern do not make that pattern global; scope is
+decided by who must obey it, not by how often it failed.
+
+**Keep the first untouched.** It is predefined: it describes this version of
+the runtime, not this project, and `zen check` compares it byte for byte.
+Anything edited into it is lost the next time `zen check --fix` runs.
 
 Everything a project decides for itself goes in the second - audiences, what
 must never be written down, what an agent commits at the end of a job, which
 index a recalled route is checked against. Filename order puts it directly
 after the defaults, so it reads as the exceptions to them. Then keeping up with
-a changed reference is the same one command again, rather than a hand-patch
-around prose that has to be preserved.
+a newer `zen` is `zen check --fix` again, rather than a hand-patch around prose
+that has to be preserved.
 
 **It must open with the same frontmatter**, or it is prepended to every agent in
 the project, including the ones with no store to apply it to:
@@ -720,10 +738,17 @@ agents:
 
 ## Review checklist
 
-- [ ] `.github/skills/zen-memory/scripts/check-instructions.sh` exits zero, so
-      `agents/memory-instructions.md` is the reference byte for byte - and
+- [ ] `zen check` reports neither `memory.uninstructed` nor `rules.stale`, so
+      `agents/memory-instructions.md` is what `zen` ships byte for byte - and
       project policy lives in `agents/memory-policy-instructions.md`, opening
       with `requires: [memory]`.
+- [ ] Every project memory-policy rule applies to every memory-enabled agent;
+      role-specific rules are in prompts and workflow-specific rules are in
+      skills.
+- [ ] For every added or changed policy rule, the review records its one-sentence
+      obligation, owner, semantic searches, existing locations and disposition.
+- [ ] No project policy rule restates a default memory rule, and no equivalent
+      or softer copy remains in another loaded prompt, skill or policy file.
 - [ ] `memory.embedding` is set, and was set before the graph had content.
 - [ ] Every agent that should learn has a `memory:` binding - the top-level
       block alone enables nothing.

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

@@ -1,6 +1,6 @@
 ---
 name: zen-review
-description: Checking a project before committing - the four mechanical checks `/project-review` makes before any judgement (`zen check`, the §2.5 path sweep, the memory house-rules copy, 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.
+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.
 ---
 
 # Reviewing a project
@@ -22,17 +22,16 @@ From the project root, or anywhere at all:
 .github/skills/zen-review/scripts/review.sh
 ```
 
-It runs four checks in the order a reviewer needs them and prints a summary:
+It runs three checks in the order a reviewer needs them and prints a summary:
 
 | Step        | Runs                                       | Owns                                         |
 | ----------- | ------------------------------------------ | -------------------------------------------- |
 | `zen check` | the CLI                                    | everything decidable about the configuration |
 | `paths`     | `zen-review/scripts/check-paths.sh`        | paths a running agent cannot open - §2.5     |
-| `memory`    | `zen-memory/scripts/check-instructions.sh` | the house-rules copy, byte for byte - §5.3   |
 | `spec-sync` | `zen-spec-sync/scripts/snapshot.sh status` | whether the record of the last pass is sound |
 
 Every step runs even when an earlier one fails, because a review that stops at
-the first problem is one somebody has to run four times. The exit code is `1` if
+the first problem is one somebody has to run three times. The exit code is `1` if
 any step wants attention and `0` if none does. `review.sh fast` passes
 `--no-models --no-sandbox` to `zen check`, which is the right call while
 iterating and the wrong one before committing - a key that authenticates says
@@ -41,7 +40,7 @@ nothing about the model id it is spent on.
 Nothing below matters while `zen check` fails. Report what it said and fix that
 first.
 
-## The two scripts this skill ships
+## The script this skill ships
 
 ### `check-paths.sh` - the §2.5 sweep
 
@@ -60,9 +59,8 @@ It exits `1` whenever it prints a candidate, because the list is meant to be
 emptied or explained rather than skimmed. It strips urls before tokenising, skips
 a handful of English constructions that contain a slash, and leaves the four
 copies `zen` ships (`agents/{files,fork,memory,tools}-instructions.md`) out
-entirely - they are worked examples by design, `zen check` keeps them
-byte-identical (`rules.stale`), and `check-instructions.sh` is the check memory
-actually needs.
+entirely - they are worked examples by design, and `zen check` keeps them
+byte-identical (`rules.stale`).
 
 Everything it does print is either noise the script has not learned yet or a
 real finding. There is no third case. A candidate that is genuinely noise is a
@@ -71,29 +69,6 @@ copy sitting in this project.
 
 `raw` is the sweep with nothing filtered, for when you suspect the filter.
 
-### `check-instructions.sh` - the memory house rules
-
-Lives in the `zen-memory` skill, because it is about memory and it is read at
-the moment that skill is:
-
-```sh
-.github/skills/zen-memory/scripts/check-instructions.sh        # the verdict
-.github/skills/zen-memory/scripts/check-instructions.sh diff   # and every differing line
-.github/skills/zen-memory/scripts/check-instructions.sh fix    # copy the reference over
-```
-
-`agents/memory-instructions.md` must be a byte-identical copy of the `zen-memory`
-skill's `references/memory-instructions.md`, and the reference is rewritten by
-every `zen init` and `zen open`, so the copy goes stale without anyone touching
-it. It drifts by **trailing whitespace inside tables**, which is invisible on
-screen - this is the check no one should be asked to make by eye. When the
-difference is whitespace alone the script says so, because that is the usual
-cause and the least believable finding.
-
-`fix` is the one-line `cp` and nothing else. Project policy belongs in
-`agents/memory-policy-instructions.md`, which filename order puts directly after
-the copy - see the `zen-memory` skill.
-
 ## Findings that are not yours to fix in place
 
 `zen check` reports `rules.stale`, `files.uninstructed`, `memory.uninstructed`,

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

@@ -46,8 +46,7 @@ strip_urls() {
 # The four copies `zen` ships (files-, fork-, memory-, tools-instructions.md)
 # are left out on purpose. They are full of worked examples, so they fail this
 # sweep by design, and the project cannot edit them anyway: `zen check` reports
-# any byte that differs as `rules.stale`. Memory has a check of its own too:
-# .github/skills/zen-memory/scripts/check-instructions.sh
+# any byte that differs as `rules.stale`.
 files() {
     {
         if [ -d agents/prompts ]; then find agents/prompts -type f -name '*.md'; fi

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

@@ -2,7 +2,7 @@
 #
 # Every check a review can make without judgement, in the order it makes them.
 #
-#   review.sh            zen check, then paths, memory, and the spec-sync record
+#   review.sh            zen check, then paths and the spec-sync record
 #   review.sh fast       the same, with `zen check --no-models --no-sandbox`
 #
 # What it prints is findings. What it cannot see — whether an agent has one job,
@@ -10,7 +10,7 @@
 # the rest of /project-review, and the reason that prompt still exists.
 #
 # Every step runs even when an earlier one fails: a review that stops at the
-# first problem is one somebody has to run four times. The exit code is 1 if
+# first problem is one somebody has to run three times. The exit code is 1 if
 # anything wants attention, 0 if nothing does.
 #
 # Run it from anywhere; it finds the project root from its own location.
@@ -58,7 +58,7 @@ if command -v zen >/dev/null 2>&1; then
         verdict 'zen check' "exit $rc — nothing below matters until this passes" 1
     fi
 else
-    echo "zen is not on PATH — install it, or run the other three alone"
+    echo "zen is not on PATH — install it, or run the other two alone"
     verdict 'zen check' 'not run' 1
 fi
 
@@ -71,15 +71,6 @@ else
     verdict 'paths' 'candidates to explain or fix' 1
 fi
 
-step 'memory'
-"$SKILLS/zen-memory/scripts/check-instructions.sh"
-rc=$?
-if [ "$rc" -eq 0 ]; then
-    verdict 'memory' 'ok' 0
-else
-    verdict 'memory' 'the house rules are missing or stale' 1
-fi
-
 step 'spec-sync'
 if [ -f SPECIFICATION.md ]; then
     # `status` reports a tampered baseline rather than failing on one, so the

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

@@ -18,7 +18,7 @@ and no argv length to overflow.
 
 The container engine is **Podman** (rootless by default).
 
-For the CLI subcommands (`zen sandbox status`, `up`, `pull`, `clean`, `disk`)
+For the CLI subcommands (`zen sandbox status`, `top`, `up`, `pull`, `clean`, `disk`)
 and command-line options, see the [zen-cli skill](../zen-cli/SKILL.md) and its
 dedicated reference document [sandbox.md](../zen-cli/references/sandbox.md).
 
@@ -260,6 +260,7 @@ Use the `zen sandbox` commands via terminal to inspect and manage container stat
 
 ```sh
 zen sandbox status          # Check podman version, machine status, and active containers
+zen sandbox top --once      # Memory and cpu of the machine and every running container
 zen sandbox up              # Start VM (macOS) and pull or build the required image
 zen sandbox pull            # Re-pull base image or force build of sandbox/Dockerfile
 zen sandbox clean           # Force remove all zn-* containers created by this CLI

package/templates/editor/.github/skills/zen-spec-sync/SKILL.md

@@ -120,10 +120,8 @@ However small the diff:
 3. **§9 of the copilot instructions, worked as a checklist**, group by group.
 4. **The capability obligations in §0.1.** For every capability the project has
    turned on, load that capability's skill and re-check what it requires - in
-   particular that `agents/memory-instructions.md` is still byte-identical to
-   `.github/skills/zen-memory/references/memory-instructions.md`. `zen init` and
-   `zen open` rewrite the reference, so this drifts without anybody editing the
-   project.
+   particular that `zen check` reports no `rules.stale`: a newer `zen` ships
+   newer house rules, so they drift without anybody editing the project.
 5. **`zen-instructions` is loaded before any house rule is touched.** A pass
    whose scope reaches `agents/*instructions.md` - and input 4 puts it there
    whenever one of them moved - has to know that `tools-instructions.md`,