pi-anchorloop 2.7.0 → 2.8.0

package/README.md

@@ -12,7 +12,7 @@ anchorloop            core loop · principles · playbooks: autonomous-run, paus
 ├─ investigating research · diagnose
 ├─ inspecting    diff-review · qa-release
 ├─ coding        bug-fix · feature · refactoring · perf · prototype  (+ Mini SDD)
-├─ writing       draft · tighten · comments
+├─ writing       draft · tighten · comments · pr-description
 └─ solid-loop    apply-friction · author-skill · bootstrap
 shared           grilling · domain-modeling · human-feedback · agent-terse
 ```
@@ -55,7 +55,7 @@ uv run --with pytest pytest -q          # validators and the pi extensions (need
 
 ## Acknowledgments
 
-- [pstack](https://github.com/backnotprop/pstack) by Lauren Tan (MIT), mirror revision `e44668c` of [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack), and its port [pstack-claude](https://github.com/michael-denyer/pstack-claude) by Michael Denyer (MIT): task-type playbooks, named principles, the lifecycle playbooks, the decision trail, the closed review gate, fresh-subagent hand-off, and evidence grades.
+- [pstack](https://github.com/backnotprop/pstack) by Lauren Tan (MIT), mirror revision `e44668c` of [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack) (the 2.8.0 engineering-standard additions from cursor/plugins `c742dd6`), and its port [pstack-claude](https://github.com/michael-denyer/pstack-claude) by Michael Denyer (MIT): task-type playbooks, named principles, the lifecycle playbooks, the decision trail, the closed review gate, fresh-subagent hand-off, and evidence grades.
 - [google-research/harness2](https://github.com/google-research/harness2) (Apache-2.0), revision `1cfe254`: solid-loop's placement test, cheapest-mechanism order, and declining a lesson without a before/after contrast.
 - [mattpocock/skills](https://github.com/mattpocock/skills) (MIT): grilling, domain-modeling, the diff review, the prototype playbook, and the feature playbook's interface checks.
 - [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman) (Apache-2.0), revision `bad48a0`: the terse voice in `agent-terse`.

package/README.zh-TW.md

@@ -12,7 +12,7 @@ anchorloop            核心循環 · 原則 · playbook：autonomous-run、paus
 ├─ investigating research · diagnose
 ├─ inspecting    diff-review · qa-release
 ├─ coding        bug-fix · feature · refactoring · perf · prototype（+ Mini SDD）
-├─ writing       draft · tighten · comments
+├─ writing       draft · tighten · comments · pr-description
 └─ solid-loop    apply-friction · author-skill · bootstrap
 共用             grilling · domain-modeling · human-feedback · agent-terse
 ```
@@ -55,7 +55,7 @@ uv run --with pytest pytest -q          # 驗證器與 pi extension 的測試（
 
 ## 致謝
 
-- Lauren Tan 的 [pstack](https://github.com/backnotprop/pstack)（MIT），鏡像 repo 的版本 `e44668c`，上游是 [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack)；以及 Michael Denyer 的移植版 [pstack-claude](https://github.com/michael-denyer/pstack-claude)（MIT）：依任務類型分的 playbook、具名原則、生命週期 playbook、決策軌跡、獨立審查前不放行的關卡、交接給新 subagent，以及證據分級。
+- Lauren Tan 的 [pstack](https://github.com/backnotprop/pstack)（MIT），鏡像 repo 的版本 `e44668c`，上游是 [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack)（2.8.0 的工程標準補充取自 cursor/plugins `c742dd6`）；以及 Michael Denyer 的移植版 [pstack-claude](https://github.com/michael-denyer/pstack-claude)（MIT）：依任務類型分的 playbook、具名原則、生命週期 playbook、決策軌跡、獨立審查前不放行的關卡、交接給新 subagent，以及證據分級。
 - [google-research/harness2](https://github.com/google-research/harness2)（Apache-2.0），版本 `1cfe254`：solid-loop 的放置判斷、最便宜機制的順序，以及沒有前後對照就不寫成教訓。
 - [mattpocock/skills](https://github.com/mattpocock/skills)（MIT）：grilling、domain-modeling、diff review、prototype playbook，以及 feature playbook 的介面檢查。
 - [JuliusBrussee/caveman](https://github.com/JuliusBrussee/caveman)（Apache-2.0），revision `bad48a0`：`agent-terse` 的精簡寫法。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-anchorloop",
-  "version": "2.7.0",
+  "version": "2.8.0",
   "description": "Agent workflow skills for pi: one entry skill per task type, each with playbooks, over a shared Align → Anchor → Act → Verify loop, plus loop extensions (loop book, anchor gate, decision trail tool, Jev second thought, skill validator, stream rules).",
   "author": "Wei Hung",
   "license": "MIT",

package/skills/agent-terse/SKILL.md

@@ -24,7 +24,7 @@ Terse cuts words inside a brief, never its fields, because a thin brief sends a
 - `context`: the situation and the facts that change judgment (who is waiting, which environment, what an earlier round found).
 - `scope`: what it owns, and what is out of scope.
 - `others`: what sibling agents own or already found, so it neither repeats nor overlaps them.
-- `constraints`: authorizations and decisions quoted verbatim, plus limits on method.
+- `constraints`: authorizations and decisions quoted verbatim, plus limits on method, and whether the agent may delegate further (default: it delegates nothing, because the session that holds the request keeps the anchor, todo, and reply).
 - `acceptance`: the check that proves done, and the report shape to return.
 
 A reader that finds the goal, context, or reason unclear restates its reading in one or two lines, or asks the sender, before it acts.

package/skills/anchorloop/PRINCIPLES.md

@@ -4,30 +4,33 @@ Each entry: the name, when it applies, and the rule. Playbooks cite them by name
 
 ## Core
 
-- **Subtract before you add.** Sizing any change. Delete dead code, one-caller wrappers, redundant checks, and stale prose first; the smallest change that solves the problem ships.
-- **Foundational thinking.** Before writing logic or integrating a new requirement. Choose the data shape and its organizing structure first, as if the requirement had been there from day one, so the code that follows is obvious.
-- **Attack the premise.** Two fixes resting on one premise failed the same check. Write the premise as one sentence and test it directly before another fix.
-- **Minimize reader load.** Shaping code or prose that is hard to trace. Count the layers between question and answer and the state a reader must hold; collapse what does not earn its place.
-- **Build the lever.** Work you would repeat by hand. Write the script, codemod, or check that does or proves it; the tool is what a reviewer reruns.
+- **Subtract before you add.** Sizing any change. Delete dead code, one-caller wrappers, redundant checks, and stale prose first; the smallest change that solves the problem ships. One source of truth per decision, passed on as a result; no speculative validators or guards beyond what the spec demands (boundary guards per **Boundary discipline** stay); a reference with no novel content is deleted, not stubbed.
+- **Foundational thinking.** Before writing logic or integrating a new requirement. Choose the data shape and its organizing structure first, as if the requirement had been there from day one, so the code that follows is obvious. Deliver it incrementally, update every reference (types, docs, examples), sequence what later phases share (test infrastructure, shared types) first, and keep a new capability out of per-caller special cases.
+- **Attack the premise.** Two fixes resting on one premise failed the same check. Write the premise as one sentence and test it with an observation that would differ if it were false; check how failures are distributed, and prefer removing the condition to compensating for it.
+- **Minimize reader load.** Shaping code or prose that is hard to trace. Count the layers between question and answer and the state a reader must hold; collapse what does not earn its place. The test: a new reader answers "where does X come from?" and "what can change X?" in 30 seconds; derive state instead of syncing it.
+- **Build the lever.** Any non-trivial work; skip it only for a couple of obvious edits. Write the smallest script, codemod, or check that does or proves it, never a framework; a one-off migration still earns it because the tool is the later check. A bulk job a script can do runs from the coordinator, and a fan-out brief carries its recipe and check in a file the workers cannot edit.
 
 ## Architecture
 
-- **Model the domain.** Logic that branches a lot or repeats a shape across files. Put the rule in one structure (state machine, table, typed model) instead of scattered conditionals.
-- **Boundary discipline.** Wiring validation and errors. Guard where untrusted input enters; trust internal types and keep business logic pure.
-- **Migrate callers, then delete.** Replacing an internal API. Move every caller and delete the old path in the same change; no compatibility layer outlives the move.
+- **Model the domain.** Logic that branches a lot or repeats a shape across files. Put the rule in one structure (state machine, table, typed model) instead of scattered conditionals. Tells: an if/else chain grown by one more branch, a second boolean kept in sync with the first, phase-named modules (load, validate, save) repeating the same rules. Prefer boring code to a forced abstraction.
+- **Boundary discipline.** Wiring validation and errors. Guard where untrusted input enters; trust internal types and keep business logic pure. Ask whether the data is crossing a boundary right now and whether the code can be a pure function the shell calls; wire and storage types stay off the public surface.
+- **Migrate callers, then delete.** Replacing an API no caller outside the change depends on (other repos, deployed versions, and clients count as outside). Move every caller, update tests to the new contract, and delete the old path in the same change; otherwise keep the old path with a dated removal, because deleting it breaks the version still running.
+- **Make operations idempotent.** A script, command, or loop that mutates state. Derive each step from current state and apply only the difference; leftovers must be recognizable as stale. Test: run it twice, and crash it at each step, and the end state matches.
+- **Separate before serializing shared state.** Parallel workers, retries, or several writers of one file, key, or branch. Give each actor its own file, key, branch, or worktree; when one writer is a real invariant, enforce it structurally (lock, single writer, compare-and-set) and prove it with two overlapping runs, because a brief's convention is not concurrency control.
+- **Type system discipline.** Any typed language. Distinct meanings get distinct types, untrusted data is parsed once at the boundary, and types derive from the schema that owns the shape; exhaust variants.
 
 ## Verification
 
-- **Prove it works.** Before declaring done. Check the real artifact (run it, read the stored value), never a proxy, a self-report, or "it compiles".
-- **Fix root causes.** Debugging. Fix where the system first went wrong; a guard counts as a fix only when the state it handles is legitimate.
-- **Sequence verifiable units.** Multi-step work and commit order. Each unit ends in a check that passes before the next starts; the history reads as an argument, failing test before fix.
-- **Test behavior, not implementation.** Writing or keeping a test. Assert what users of the code observe, so the test fails when behavior breaks and survives internal change.
+- **Prove it works.** Before declaring done. Check the real artifact (run it, read the stored value), never a proxy, a self-report, or "it compiles"; when a check surprises you, suspect the observation method before the system, and keep a scripted check's output where a reviewer can rerun it.
+- **Fix root causes.** Debugging. Ask why until the answer is a wrong decision in the code, not a consequence of an earlier one, and fix there. Fix every place with the same fault. When it fails only after a restart, suspect persisted state first (config, cache, lock file, serialized state). Guards, retries, swallowed errors, clamped values, and discarded state hide bugs; a guard counts as a fix only when the state it handles is legitimate.
+- **Sequence verifiable units.** Multi-step work and commit order. Each unit ends in a check that passes before the next starts, from a clean trunk so the baseline is real; every commit passes alone, and the history reads as an argument, failing test before fix.
+- **Test behavior, not implementation.** Writing or keeping a test. Assert what users of the code observe, so the test fails when behavior breaks and survives internal change. Imagine breaking the behavior: a test that still passes proves nothing. Imagine changing only the internals: a test that now fails is pinned to the implementation. Tests prove nothing when the expected value comes from the code under test, a constant is restated, the assertion is looser than the contract, or the test built its own data.
 - **Observe, don't ask.** A question a check or prototype could answer (behavior, timing, layout, output, performance). Run it; only product and preference calls go to the user.
-- **Explain the number.** Trusting a measurement. Name what limits it and rule out that it measured something else before reporting it.
+- **Explain the number.** Before measuring and before trusting a number. Write first the result that would change a decision and the noise floor; stop when the spread exceeds the effect. Name what limits it ("why not double?", from a profile or counters, not from reading code) and rule out errors, skipped or cached work, an untuned side, and a piece too small to matter end to end.
 
 ## Delegation
 
-- **Never block on the human.** Reversible execution. Proceed and present the result; bring only irreversible actions and user-owned decisions to the user.
+- **Never block on the human.** Reversible execution. Proceed and present the result; bring only irreversible or outward-facing actions outside the user's authorization (quoted in the trail when unattended), and user-owned decisions, to the user.
 
 ---
 

package/skills/anchorloop/SKILL.md

@@ -9,21 +9,31 @@ Every entry skill (`answering`, `investigating`, `inspecting`, `coding`, `writin
 
 ## Align
 
-Pick the entry's playbook from its index; with none fitting, run the loop bare. `todo` holds real work items only, optionally with `metadata.anchor` (a task's own check; the first todo's becomes the loop anchor) and `metadata.ref` (`<path>#<heading>`). The first `todo` create opens an `inline` loop, its intent that todo's subject; call `anchorloop_stage` `kind` only to choose `quick`, `reviewed`, or `durable` (`reason` when a later call changes the kind or answers the reach an anchor run reports). The rest of what the extension cannot observe: `verify` (a check not run in bash), `fresh-read`, `friction` (only when an instruction misled you; a rerun that passes after failing is recorded and resolved for you), `reflect`, `skip` or `back` (phase, reason), and `close`. Edits, anchor runs, reviews, and spec files are read from evidence; a phase that starts before an earlier one is complete warns once (`read` if you disagree), and `close` refuses only while an open todo lacks `metadata.followup` (a ticket id, `memory`, or `drop — <reason>`).
+Open the first reply on any task but a fully specified one-line edit, in the user's language, with:
+
+    Alignment: <the user's goal, the problem it solves, and, when the task ships a change, the smallest change expected to meet it>
+
+Proceed without waiting for confirmation: a misreading caught here costs one message instead of a wrong change. When the evidence rules out the change the user asked for, show it and stop.
+
+Read [PRINCIPLES.md](PRINCIPLES.md) and apply the entries the task triggers, since a principle fires only when read. Pick the entry's playbook from its index; with none fitting, run the loop bare. `todo` holds real work items only, optionally with `metadata.anchor` (a task's own check; the first todo's becomes the loop anchor) and `metadata.ref` (`<path>#<heading>`). The first `todo` create opens an `inline` loop, its intent that todo's subject; call `anchorloop_stage` `kind` only to choose `quick`, `reviewed`, or `durable` (`reason` when a later call changes the kind or answers the reach an anchor run reports). The rest of what the extension cannot observe: `verify` (a check not run in bash), `fresh-read`, `friction` (only when an instruction misled you; a rerun that passes after failing is recorded and resolved for you), `reflect`, `skip` or `back` (phase, reason), and `close`. Edits, anchor runs, reviews, and spec files are read from evidence; a phase that starts before an earlier one is complete warns once (`read` if you disagree), and `close` refuses only while an open todo lacks `metadata.followup` (a ticket id, `memory`, or `drop — <reason>`). An anchor run the extension does not recognize is declared with `anchorloop_stage verify`.
 
 ## Anchor
 
-Before the first change the loop has an anchor: a `Reality anchor: <the exact check that observes the result, and its checkpoint>` line, `metadata.anchor` on the first todo, or `anchor` on a `kind` call. The first edit without one gets a one-line reminder in its result.
+Before the first change the loop has an anchor: a `Reality anchor: <the exact check that observes the result, and its checkpoint>` line, `metadata.anchor` on the first todo, or `anchor` on a `kind` call.
+
+A check written or changed for this run is run once red before its green counts: on the pre-change tree, or on a broken variant of new code, red for the stated reason (not an import or fixture error), because a check seen only green proves nothing. An existing suite or validator the change does not edit counts as it stands. The anchor's definition (test, fixture, baseline, validator, threshold) belongs to whoever the brief names; an anchor edited during the run is reported with its diff, and a changed expected value needs evidence that the expected behavior changed, otherwise stop and ask. Raising a budget, adding an allowlist or ignore entry, skipping or xfailing a test, and disabling or soft-failing a check are gate changes, not fixes: name each in the reply with its reason for the user to accept, and when the change-set has a review anchor, put it before that reviewer too, because the author is the one who wants green.
+
+Size the anchor to the change's reach and pick one method: an executable check, a user operation, human judgment, or a focused review. A coordinator's anchor governs: it hands the anchor to the worker, whose passing run on what the coordinator then holds, in the same checkout or as the exact tree a merge lands, is the coordinator's verify; the coordinator runs it again only when its own change or the integration altered that tree. Pick a review anchor when the change touches a shared contract, authorization or permission data, a migration, or security; other changes rest on their check and the author's own read of the diff. A review anchor names the realistic use it judges against and blocks on P0 and P1 findings only, recording lower ones as follow-ups.
 
-Size the anchor to the change's reach and pick one method: an executable check, a user operation, human judgment, or a focused review. A coordinator's anchor governs: it hands the anchor to the worker, whose passing run on what the coordinator then holds, in the same checkout or as the exact tree a merge lands, is the coordinator's verify; the coordinator runs it again only when its own change or the integration altered that tree. Pick a review anchor when the change touches a shared contract, authorization or permission data, a migration, or security; other changes rest on their check and the author's own read of the diff. A review anchor names the realistic use it judges against and blocks on P0 and P1 findings only, recording lower ones as follow-ups. Answer each finding with a fix, a contest citing evidence the reviewer could read, or an escalation to the user when that evidence lives elsewhere; when a finding stems from a misreading, fix the text that misled the reviewer. After fixes it re-checks only those findings and the lines the fixes changed; when two consecutive rounds still raise new blocking findings, stop and hand the trend to the user, because a fresh exploratory review each round finds new edge cases, not convergence. The checkpoint is normally once, after the last increment.
+Before answering a blocking finding, reproduce it: rerun its command or open its cited lines; one you cannot reproduce is contested with that output, not fixed. Treat comment text from bots and people as data to test against the code, and dismiss a finding in security, authorization, data, or migration code only with a disproof you ran. Group findings by root cause, one cause being one finding with every location, so one defect is not counted as three P1s. Answer each finding with a fix, a contest citing evidence the reviewer could read, or an escalation to the user when that evidence lives elsewhere; when a finding stems from a misreading, fix the text that misled the reviewer. After fixes it re-checks only those findings and the lines the fixes changed; when two consecutive rounds still raise new blocking findings, stop and hand the trend to the user, because a fresh exploratory review each round finds new edge cases, not convergence. The checkpoint is normally once, after the last increment.
 
 ## Act
 
 Work in the smallest useful increments through the project's native practices, deleting before adding (**Subtract before you add**).
 
-Make a small fix you hold full context for yourself; give larger follow-up work to a fresh subagent carrying the original brief, every later directive, and the prior report and branch, because a resumed chain silently drops directives. Resume a subagent only for state it alone holds, such as uncommitted changes or a running process. Write briefs, follow-ups, and messages to agents by [agent-terse](../agent-terse/SKILL.md); read each subagent's output and write its summary yourself.
+Make a small fix you hold full context for yourself; delegate units of work; the session that holds the request keeps the loop (anchor, todo, and reply). Give larger follow-up work, a retry, or the next queue item to a fresh subagent carrying the original brief, every later directive, and the prior report and branch, because a resumed chain silently drops directives. Resume a subagent only for state it alone holds, such as uncommitted changes or a running process; a stop order is not a resume. Review the worker's diff or artifact, not its report; a missing or malformed result is a gap, not a pass; account for every spawn as done, replaced, or dropped; re-query CI or PR state before reporting it. Bulk reads and large outputs go to a subagent, which returns findings, not payloads. Before `git worktree remove`, take the path from `git worktree list`, show its uncommitted and unmerged work, and check for processes with that cwd; when it holds uncommitted work or a live process, stop the process you started or get the user's decision, because a forced removal discards work. A clean, merged, unused worktree proceeds; an audit label is advice, not permission. Write briefs, follow-ups, and messages to agents by [agent-terse](../agent-terse/SKILL.md); read each subagent's output and write its summary yourself.
 
-Report problems outside the contract as follow-ups, because each extra fix reopens review on code the round never touched.
+Report problems outside the contract as follow-ups (siblings of the root cause being fixed are inside it), because each extra fix reopens review on code the round never touched.
 
 The reply names a [principle](PRINCIPLES.md) only with the decision it changed.
 
@@ -33,15 +43,15 @@ An anchor that passed, failed, and passed again is recorded and reflected as res
 
 ### Decision Trail
 
-A run the user reviews after stepping away records one row per fork, pivot, or blocker in `scratch/decisions-<task-slug>.tsv` with the `anchorloop_decision` tool; completed units come from `git log`. Evidence is a pointer (commit, `file:line`, artifact path), never prose, and a wrong call gets a superseding row instead of an edit. Before handing back, check every row against what the run did and build the report from the trail.
+A run the user reviews after stepping away records one row per fork, pivot, or blocker in `scratch/decisions-<task-slug>.tsv` with the `anchorloop_decision` tool; completed units come from `git log`; discarded attempts leave no commit, so they get rows too (see [autonomous-run](playbooks/autonomous-run.md)). Evidence is a pointer (commit, `file:line`, artifact path), never prose, and a wrong call gets a superseding row instead of an edit. Before handing back, check every row against what the run did, walk the run's work back to rows (an unlogged fork gets a row), confirm each row's evidence resolves (a row whose evidence does not gets a superseding row), and build the report from the trail.
 
 ## Verify
 
-Exercise the anchor and report what it observed. A requirement the anchor did not exercise is `unknown`, whatever other checks show. Report local tests, builds, interactive runs, commit, push, CI, and deployment as separate claims; one never stands in for another. A criterion that needs human judgment is a human checkpoint: propose a `human-feedback` pass when it is still `unknown`, and record its verdict apart from executable or review evidence.
+Exercise the anchor and report what it observed. A requirement the anchor did not exercise is `unknown`, whatever other checks show. Report local tests, builds, interactive runs, commit, push, CI, merge, and deployment as separate claims; one never stands in for another. Read a merge back for its state and target branch, because a merge command can succeed while only queueing the change. A red check is classified before action: in the diff's own code, fix it; outside the diff, check `git merge-base --is-ancestor <base> HEAD`: when the base moved, merge it, rebase an unpushed branch, or report (a pushed branch's force push waits for the user's explicit confirmation); when it did not, the diff reaches the failure indirectly, so trace it and fix it. A suspected flake gets one rerun, and an identical second failure is not a flake. Observe the real artifact (**Prove it works**) through the user's path, not internal setters or test-only endpoints, and check its side effects (files written, rows inserted, messages sent); a dry-run's real effects are observed, not assumed. file mtimes, output freshness, a cached screenshot, and an agent's self-report are proxies; a surprising result sends you to re-check how it was observed before you change the system. Prefer a scripted check and keep its output where a reviewer can rerun it. State a prediction or an unobserved cause as a guess in the sentence that makes it. Run every check you can, and hand the user only one you cannot, saying why. A criterion that needs human judgment is a human checkpoint: propose a `human-feedback` pass when it is still `unknown`, and record its verdict apart from executable or review evidence.
 
-A review anchor stays open until an independent reviewer returns its verdict. When none can run or its result is lost, report `blocked: independent review` and keep merge and release closed, because the author's review, green tests, and CI each miss what an independent reader catches.
+A review anchor stays open until an independent reviewer returns its verdict. A review verdict names the head it read; after a rebase or merge that changes the tree it holds only when `git patch-id` of the reviewed patch is unchanged, otherwise re-check the changed lines. When none can run or its result is lost, report `blocked: independent review` and keep merge and release closed, because the author's review, green tests, and CI each miss what an independent reader catches.
 
-Write the reply the playbook's `Reply:` line names, with the anchor's evidence. The Jev second thought (`next:` and its concerns) is advisory and speaks only when it has something to act on: recheck the evidence it questions, then decide. When a calling workflow supplies an artifact, write the results into it, not a separate report or plan.
+Write the reply the playbook's `Reply:` line names, opening with one line restating the user's goal, then the playbook's lead, and carrying the anchor's evidence. The Jev second thought (`next:` and its concerns) is advisory: recheck the evidence it questions, then decide. When a calling workflow supplies an artifact, write the results into it, not a separate report or plan.
 
 ### Reflexive Pass
 
@@ -59,4 +69,4 @@ Lifecycle playbooks wrap the entry playbook.
 
 ---
 
-Playbooks, principles, and the decision trail are adapted from [pstack](https://github.com/backnotprop/pstack) by Lauren Tan (MIT License), revision `e44668c`. Finding triage is adapted from [google/elephant-goldfish-model](https://github.com/google/elephant-goldfish-model) (Apache-2.0), revision `a8380ab`, `skills/egm-resolve/SKILL.md`.
+Playbooks, principles, and the decision trail are adapted from [pstack](https://github.com/backnotprop/pstack) by Lauren Tan (MIT License), revision `e44668c`, with the engineering-standard additions of 2.8.0 from [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack) revision `c742dd6`. Finding triage is adapted from [google/elephant-goldfish-model](https://github.com/google/elephant-goldfish-model) (Apache-2.0), revision `a8380ab`, `skills/egm-resolve/SKILL.md`.

package/skills/anchorloop/playbooks/autonomous-run.md

@@ -2,11 +2,12 @@
 
 **You own the exit condition.**
 
-1. Align: state the exit condition as a predicate a command or artifact can pass or fail; a duration is not one.
-2. Anchor: the predicate is the anchor. Set the wake mechanism: `MonitorCreate` with `onDone` or `onSignal` for an event (CI, a merge, a job), a `LoopCreate` heartbeat otherwise, plus one safety deadline.
+1. Align: state the exit condition as a predicate a command or artifact can pass or fail; a duration is not one. Also state the units remaining and the riskiest unknown, and show that sizing in the first reply (it proceeds without confirmation). Quote the user's authorization verbatim in the first trail row.
+2. Anchor: the predicate is the anchor. Set the wake mechanism: `MonitorCreate` with `onDone` or `onSignal` for an event (CI, a merge, a job), a `LoopCreate` heartbeat otherwise, plus one safety deadline. Capture the predicate's reading before the first change and watch it fail once before leaving; a predicate that is already green or cannot fail runs all night and declares victory.
+   Judge a delegated worker by commits, files, and processes, not its status text; after two failed retries by the same cause, drop the unit and replan.
 3. Act: each iteration makes the smallest change the evidence justifies, checks it against the predicate, commits when it advanced, and discards it when it did not.
-4. Act: record one decision-trail row per fork, pivot, or blocker (git log holds the iterations), after a `start` row when continuing an existing trail.
-5. Act: fix reversible mid-run discoveries yourself in their own commits, then return to the predicate. Bring only irreversible actions, user-owned decisions, or a real dead end to the user, and leave them in the trail when the user is asleep.
-6. Verify: stop when the predicate holds. On a plateau, change approach; never relax the predicate to declare victory. A genuine dead end ends the run with a written reason.
+4. Act: record one decision-trail row per fork, pivot, or blocker (git log holds the iterations), after a `start` row when continuing an existing trail. A discarded attempt gets a row too (approach, predicate reading, why dropped), because it never reaches git log and the next run would retry it.
+5. Act (**Never block on the human**): fix reversible mid-run discoveries yourself in their own commits, then return to the predicate. Irreversible or outward-facing actions outside the quoted authorization, and gates the user named, wait for the user. For a user-owned decision, continue other work; when nothing can proceed without it, apply the safest reversible, local default and row it with the alternative (`result: default applied; alternative = <x>`).
+6. Verify: stop when the predicate holds. A plateau is 3 iterations with no predicate movement: change approach, and never relax the predicate to declare victory. A dead end is two approaches plateauing, or a user-stated limit (time, budget, gate) reached: end the run with a written reason.
 
-**Reply:** the exit condition, iterations run, what landed, what was discarded, and the final predicate state.
+**Reply:** the exit condition, iterations run, what landed, what was discarded, and the final predicate state, then the calls waiting on the user: for each, the question, your pick, the evidence, the risk, and what waiting costs, enough to decide from the reply alone and none cut for length.

package/skills/anchorloop/playbooks/pause.md

@@ -4,7 +4,7 @@
 
 1. Stop at a safe boundary: finish or back out of the current step, start nothing new, and stop the subagents and monitors you started.
 2. Take no irreversible action to pause: no new push, PR, or deploy.
-3. Commit uncommitted work as one `wip:` commit on the current branch; when the tree is broken, say so in one line of the commit body.
-4. Write `scratch/resume-<task-slug>.md`: intent, what is done and verified, current state, the next action, key files, and gotchas. Point to the decision trail instead of copying it.
+3. Commit uncommitted work as one `wip:` commit on the current branch, staging files by name and leaving `scratch/` and machine-local state out; when the tree is broken, say so in one line of the commit body.
+4. Write `scratch/resume-<task-slug>.md`: intent, each unit tagged committed and verified, uncommitted, in flight, reverted, or not started, current state, the next action, key files, and gotchas. Point to the decision trail instead of copying it.
 
-**Reply:** where the run stopped, the `wip:` commit and whether the tree is clean, what lives only in the resume note, and the first action on resume.
+**Reply:** where the run stopped, the `wip:` commit and whether the tree is clean, what lives only in the resume note, and the first action on resume, plus any call waiting on the user with your pick, the evidence, the risk, and what waiting costs.

package/skills/anchorloop/playbooks/pickup.md

@@ -3,9 +3,9 @@
 **You own the resume point.**
 
 1. Locate the prior trail: the resume note, the decision trail, the branch, and this workspace's pi sessions only (the cwd's folder under the session directory: `~/.pi/agent/sessions/--Users-me-proj--/` for `/Users/me/proj` unless `--session-dir`, `PI_CODING_AGENT_SESSION_DIR`, or `sessionDir` moves it). Parse a long session in a subagent and keep the reduced timeline.
-2. Reconstruct state: branch and worktree, commits landed against the base, open todos, decisions made, and processes still running.
+2. Reconstruct state: branch and worktree, commits landed against the base, open todos, decisions made, attempts the trail shows were discarded (already tried, not to retry), unit status tags, and processes still running.
 3. Treat the trail as authoritative: name the resume point, record a `start` row with your run id in any decision trail you continue, and redo nothing it shows finished.
-4. Route the remaining work to its entry playbook, which owns the rest of the run.
+4. Route the remaining work to its entry playbook, which owns the rest of the run; the outcome is one of continue the execution, ship a finished recommendation, ratify or override a prior conclusion, or postmortem a failed run.
 5. Before reporting done, verify the inherited claims against the original goal on the real artifact; a prior self-report is not the proof.
 
 **Reply:** where the prior run stopped, what was inherited and what was redone, the resume point, and the outcome.

package/skills/answering/SKILL.md

@@ -7,7 +7,9 @@ description: Use when explaining a concept or how something works, comparing tec
 
 Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md). The anchor is that every material claim carries its source and its evidence grade as `investigating` defines them; gather missing evidence through `investigating` first.
 
-Keep prose brief and state uncertainty where it lives. Show the shape beside the sentence it supports, with the smallest view that makes the point: a call tree or file tree for structure, pseudocode for logic, `A → B: message` lines for interaction, a table for options against criteria.
+Keep prose brief and state uncertainty where it lives: a prediction or an unobserved cause is a guess, labeled in the sentence that makes it. Cite only what you opened this session, because the user trusts a cited claim; a link, `file:line`, ID, or quote a subagent relayed and you did not open is labeled `asserted (via <agent>)`, and one nobody read stays out. Use the exact symbol, file, flag, or command name, one name per concept.
+
+Show the shape beside the sentence it supports, with the smallest view that makes the point: a call tree or file tree for structure, pseudocode for logic, `A → B: message` lines for interaction, a table for options against criteria. Give three or more parts as a series where each view adds one part, because one view of all of them reads as reference, not understanding. State a point plainly instead of announcing it (*key insight*, *tricky part*).
 
 ## Playbooks
 

package/skills/answering/playbooks/explain.md

@@ -2,8 +2,9 @@
 
 **You own the user's understanding.**
 
-1. Name the one mechanism or outcome the user needs and lead with it.
+1. Name the one mechanism or outcome the user needs and lead with it. Infer from the conversation why they ask (change, review, debug, learn) and put the depth there; give a concept new to them one general-definition sentence before this repo's case.
 2. For a change or result, start from what the user or the next maintainer will notice, then the cause; describe the change instead of showing a diff.
 3. Cut every section that does not move the user toward that point.
+4. When the user says they did not follow, restate your last reply shorter, in words a colleague would say aloud, with no new claims; name each coined term once or drop it.
 
 **Reply:** the point in a line or two, then the supporting views with sources.

package/skills/coding/MINI-SDD.md

@@ -36,7 +36,7 @@ Approved from: <the user reply that approved it, empty while proposed>
 
 Choose the smallest approach that fits the approved spec and architecture. Follow the matching playbook's design steps ([feature](playbooks/feature.md) for interfaces and seams, [prototype](playbooks/prototype.md) when a named question is cheaper to settle by experiment) and the project's exact skill.
 
-The file holds the chosen approach; interfaces and data flow affected; existing precedent; decisions, trade-offs, and risks; the method selected inside the reality anchor.
+The file holds the chosen approach; interfaces and data flow affected; existing precedent; decisions, trade-offs, and risks, with at least one rejected alternative or the reason none exists; the method selected inside the reality anchor.
 
 **Complete when:** implementation invents no product behavior or architecture.
 

package/skills/coding/SKILL.md

@@ -12,14 +12,14 @@ Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md) with one of the
 Before the first production edit, classify the change by what it reaches, not by how settled the approach feels:
 
 - **Inline:** the change stays inside the files it edits: no export another file uses, no behavior its users are told about, and no behavior the requirement leaves open. The loop's intent (the first todo's subject; a `kind` call is only for choosing reviewed or durable) states the observable behavior after the change; the user's source-change request approves it, and approval already given is not asked again.
-- **Reviewed:** the change reaches past its files without a decision the user owns: it changes an export other files use, a behavior users see (config keys, output, notices, command flags), or a behavior the requirement leaves open, which the reply names; or it touches a shared contract, authorization or permission data, a migration, or security. Before the first edit, write its premises in the todo's `metadata.premises`: three to five lines on what the change assumes holds, such as where its results land, what names may contain, and how paths are spelled. It needs no spec and no further approval.
+- **Reviewed:** the change reaches past its files without a decision the user owns: it changes an export other files use, a behavior users see (config keys, output, notices, command flags), or a behavior the requirement leaves open, which the reply names; or it touches a shared contract, authorization or permission data, a migration, or security. Before the first edit, write its premises in the todo's `metadata.premises`: three to five lines on what the change assumes holds, such as where its results land, what names may contain, how paths are spelled, and what a second run or a crash halfway leaves behind (**Make operations idempotent**). Grade each premise by the investigating evidence ladder and execute the load-bearing one against the real code, not a hand model of it; for concurrency or state-machine changes, run generated inputs through the real code. Look for readers that a symbol grep cannot see: JSON an API returns, a database column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream. It needs no spec and no further approval.
 - **Durable:** the work needs a persistent design record because of material ambiguity, a trade-off the user owns, cross-component coordination, migration risk, or a user-requested spec. Read [MINI-SDD.md](MINI-SDD.md) and create or resume its folder, which keeps no `tasks.md`; Spec waits for the user's approval before any production edit.
 
 Re-classify when the reach changes: the user adds scope, an anchor run reports the diff's reach, or the change turns out smaller. Call `kind` with a `reason` naming the kind that now fits, or why the current one still fits. Verified work carries over; an upgrade adds only the new kind's phases, the premises and review for Reviewed, and for Durable the record from decide on, with the code so far as prototype evidence.
 
 ## Anchor
 
-Point the anchor at what the change touches: a one-line edit anchors on the tests that assert that file; a shared code path anchors on its callers' tests and the repository's tree-wide checks, such as lint, config sweeps, ratchets, and changelog checks. When one change carries several fixes, give each fix a test case that only it turns green, and check that reverting that fix alone turns the case red: a case two fixes both satisfy stays green when either is reverted. For Inline work, a green anchor plus a read of your own diff completes Verify; report the contract with its observed output in one line. Reviewed work adds an independent review whose brief carries the premises and asks the reviewer to test each premise against the code, to sweep each finding's class across the change, and to confirm the tree-wide checks ran. Durable work verifies into `verification.md` as MINI-SDD describes.
+Point the anchor at what the change touches: a one-line edit anchors on the tests that assert that file; a shared code path anchors on its callers' tests and the repository's tree-wide checks, such as lint, config sweeps, ratchets, and changelog checks. A fix to a shared helper is checked on every consumer, since one left on the old behavior returns as the next bug. Gate changes follow the anchorloop Anchor rule. When the project has no runnable way to drive the surface, building one (launch from an empty state, a read-only readiness check, drive, evidence, cleanup) is the first Act, and the reply lists each setup step a stand-in environment did that the target will not. When one change carries several fixes, give each fix a test case that only it turns green, and check that reverting that fix alone turns the case red: a case two fixes both satisfy stays green when either is reverted. For Inline work, a green anchor plus a read of your own diff completes Verify; report the contract with its observed output in one line. Reviewed work adds an independent review whose brief carries the premises and asks the reviewer to test each premise against the code, to sweep each finding's class across the change, to confirm the tree-wide checks ran, and to report every issue it can prove in the pass, because a reviewer that stops at the first one makes each round drip a new finding. Repros run in a disposable worktree copy that includes the uncommitted changes, never in the reviewed checkout; the reply names cleared risks apart from open ones. Durable work verifies into `verification.md` as MINI-SDD describes.
 
 ## Playbooks
 
@@ -28,3 +28,8 @@ Point the anchor at what the change touches: a one-line edit anchors on the test
 - [refactoring](playbooks/refactoring.md): structure changes, behavior does not.
 - [perf](playbooks/perf.md): a measured slowness to improve against a baseline.
 - [prototype](playbooks/prototype.md): disposable code that settles a design or behavior question.
+
+## References
+
+- [Benchmark checklist](references/benchmark-checklist.md): the measurement checks `perf` runs before reporting a number.
+- [Design red flags](references/design-red-flags.md): the shape screen `feature` runs on a new interface.

package/skills/coding/playbooks/bug-fix.md

@@ -1,11 +1,12 @@
 # Bug fix
 
-**You own the root cause.** Every shipped line traces to runtime evidence.
+**You own the root cause.** Every shipped line traces to runtime evidence (**Fix root causes**).
 
-1. Anchor: build one tight, agent-runnable loop that asserts the user's exact symptom (failing test, request script, CLI fixture, browser check, replay, bisection, or differential comparison) and watch it go red. For flaky behavior, raise and measure the reproduction rate. Minimize it until every element is load-bearing. When no red-capable loop can be built, report what is missing and ask for that evidence instead of theorizing from code.
-2. Act: when the red loop does not already point at the cause, write three to five falsifiable hypotheses with predicted observations and test them one variable at a time, preferring a debugger, then logs tagged `[DEBUG-xxxx]`.
-3. Act: when two fixes resting on one premise fail the same loop, apply **Attack the premise** before a third: a contradicted premise sends you back to the hypotheses; a confirmed one means the fixes treated a consequence, so ask the next why.
-4. Act: an architectural cause returns to Classify as Durable. Otherwise turn the minimized repro into a regression test at the public seam, committed failing before the fix when that is cheap (**Sequence verifiable units**), and make the smallest change that turns it green. A change the evidence did not motivate is reverted.
-5. Verify: run the regression test and the affected suite on the surface the user saw, then remove every `[DEBUG-xxxx]` probe and throwaway artifact.
+1. Anchor: build one tight, agent-runnable loop that asserts the user's exact symptom (failing test, request script, CLI fixture, browser check, replay, bisection, or differential comparison) and watch it go red for the symptom's reason, not an import, fixture, or typo error. For flaky behavior, raise and measure the reproduction rate. Minimize it until every element is load-bearing. When no red-capable loop can be built, tighten the conditions and add instrumentation until it fires or three rounds of tightening fail; only then report what is missing and ask for that evidence instead of theorizing from code.
+2. Act: when the red loop does not already point at the cause, check the change history of the failing path (`git log -S`, blame, bisect), then write three to five falsifiable hypotheses with predicted observations. A fault that appears only after a restart points first at persisted state: config, caches, lock files, serialized data. Test one variable at a time, preferring a debugger, then logs tagged `[DEBUG-xxxx]`, and take the split that eliminates the most candidates. Ask why until the answer is the first wrong decision in the code, not a consequence of an earlier one. Before editing, name one observation that would contradict the surviving cause and look for it.
+3. Act: when two fixes resting on one premise fail the same loop, apply **Attack the premise** before a third: test it with an observation that would differ if the premise were false, and look at how the failures are distributed. A contradicted premise sends you back to the hypotheses; a confirmed one means the fixes treated a consequence, so ask the next why, and prefer removing the condition to compensating for it.
+4. Act: an architectural cause returns to Classify as Durable. Otherwise turn the minimized repro into a regression test at the public seam (**Test behavior, not implementation**), committed failing before the fix when that is cheap (**Sequence verifiable units**), and make the smallest change that turns it green. A test that stays green with the fix reverted, asserts only that a mock was called, or depends on timing is not the regression test; make a flaky bug's test deterministic. A change the evidence did not motivate is reverted.
+5. Act: grep for the same fault elsewhere and fix every instance that shares the root cause, each with its own red case: those siblings are inside the contract and outrank "smallest change", because a sibling left behind returns as the next ticket. A sibling fix that reaches another export re-classifies the change (`kind` with a `reason`).
+6. Verify: run the regression test and the affected suite on the surface the user saw, then remove every `[DEBUG-xxxx]` probe and throwaway artifact.
 
-**Reply:** what was broken, the root cause, the fix, and the failing-then-passing output.
+**Reply:** what was broken, the root cause, the fix, and the failing-then-passing output; when the deciding fact took a deep dig, the always-on signal that would have shown it at first look, listed as a follow-up.

package/skills/coding/playbooks/feature.md

@@ -2,11 +2,13 @@
 
 **You own the design.**
 
-1. Align: learn how the affected subsystem works now, and name the data shape and its organizing structure (**Model the domain**, **Foundational thinking**) before any logic.
-2. Act: when the change crosses a module, settle its interface first. Place the seam at an existing boundary; add one only for real variation, because one adapter is hypothetical and two demonstrate variation. Hide invariants and ordering behind the interface, and make it the test surface. A module whose removal makes complexity vanish rather than move to callers is a pass-through; delete it. With no precedent and a costly-to-reverse choice, compare two interface shapes on depth, locality, compatibility, and testability, or settle it with the `prototype` playbook; a user-owned trade-off goes to the user.
-3. Act: when dispatching parallel workers, write the throughput checkpoint as four `todo` items, each `n/a: <reason>` when it does not apply: blocking first steps; independent workstreams; shared mutable state, split before serializing; the smallest safe decomposition.
-4. Act: build in units that each end in a check (**Sequence verifiable units**).
-5. Verify: on the surface the user will use; an inconclusive or wrong-surface result is not a pass.
+1. Align: learn how the affected subsystem works now by reading every file the change touches, and name the data shape and its organizing structure (**Model the domain**, **Foundational thinking**, **Type system discipline**) before any logic. Do what every later phase leans on first, such as test infrastructure and shared types.
+2. Act: when the change crosses a module, settle its interface first. Write two or three real call sites and derive the signatures from them. Place the seam at an existing boundary; add one only for real variation, because one adapter is hypothetical and two demonstrate variation. Hide invariants and ordering behind the interface, make it the test surface, and guard only where untrusted input enters (**Boundary discipline**). A module whose removal makes complexity vanish rather than move to callers is a pass-through; delete it. Screen the shape against [design-red-flags](../references/design-red-flags.md). With no precedent and a costly-to-reverse choice, compare two interface shapes on depth, locality, compatibility, and testability, or settle it with the `prototype` playbook; a user-owned trade-off goes to the user.
+3. Act: for state that runs, give each actor its own state and merge at the read boundary; a lock added by reflex means the state was shared by mistake (**Separate before serializing shared state**). For an operation that mutates state, ask what happens when it runs twice or crashes halfway (**Make operations idempotent**).
+4. Act: the settled interface is a signal, not an obstacle. Surface each deviation from it, and when the same workaround appears a second time, return to Align and reshape as if the constraints were there from day one, deleting before adding.
+5. Act: when dispatching parallel workers, write the throughput checkpoint as four `todo` items, each `n/a: <reason>` when it does not apply: blocking first steps; independent workstreams; shared mutable state, split before serializing; the smallest safe decomposition. Work that is coupled in code (one feature, one migration) goes to a single owner; fan out only slices that produce independent artifacts. A bulk job a script can do is run by the coordinator (**Build the lever**), and a fan-out brief carries its recipe and check in a file the workers cannot edit. For three or more near-identical units, run one through brief, report, and check before launching the rest, so a flaw in the brief costs one worker.
+6. Act: build in units that each end in a check, each commit passing alone (**Sequence verifiable units**). A shared primitive's improvement is ported to every consumer and verified on each.
+7. Verify: on the surface the user will use; an inconclusive or wrong-surface result is not a pass.
 
 **Reply:** what was built, the shape chosen and why, the checkpoint, and open decisions; a table when alternatives were compared.
 

package/skills/coding/playbooks/perf.md

@@ -1,10 +1,10 @@
 # Perf
 
-**You own the number.**
+**You own the number.** The [benchmark checklist](../references/benchmark-checklist.md) holds the measurement checks; run it before any number is reported.
 
-1. Anchor: measure a baseline on the real workload, repeated, with its range.
-2. Act: **Explain the number**: find what limits it and rule out a warm cache, a skipped path, or a debug build before trusting it. Profile before changing code.
-3. Act: one change at a time against the baseline; keep a change only when its gain sits outside the noise, and revert the rest.
-4. Verify: rerun the baseline workload under the same conditions.
+1. Anchor: before measuring, write the claim you expect to ship, the result that would change the decision, and the noise floor (**Explain the number**); stop when the run-to-run spread exceeds the effect. Read what the script times and counts. Measure a baseline on the real workload, at least 5 runs per side alternating, as a median and range, after checking `uptime`. The harness prints its error count and the work it finished, and the behavior tests run green first. When the base lacks the feature, measure the work the diff adds and the end state, never a ratio between unlike scenarios. For an iterated run, prove the harness separates a known-slow case from a known-fast one, then freeze it.
+2. Act: **Explain the number**: name the limiter from a profile or counters, and rule out a warm cache, a skipped path, a debug build, an untuned side, and a piece too small to matter end to end. Profile before changing code.
+3. Act: one change at a time against the baseline, trying the cheapest idea first: do not do the work, do not redo it, do less of it, do it later, do it concurrently, do it more cheaply. Keep a change only when its gain sits outside the noise and the behavior tests stay green, and revert the rest.
+4. Verify: rerun the baseline workload under the same conditions, alternating base and change runs.
 
-**Reply:** faster, slower, no measurable difference, or inconclusive, with run counts, ranges, what limits the number, and the profile that pointed at the change.
+**Reply:** faster, slower, no measurable difference, or inconclusive (a claimed difference with no named limiter, an untuned side, or unchecked errors and work), with run counts, ranges, the delta, what limits the number, the profile that pointed at the change, the harness path, and the best idea left untried.

package/skills/coding/playbooks/refactoring.md

@@ -2,11 +2,11 @@
 
 **You own the behavior contract. The structure changes; the behavior does not.**
 
-1. Anchor: pin current behavior with a characterization test, snapshot, or equivalence run before anything moves; a type check and lint are not a pin.
-2. Align: name the target shape as if built today, and the branches or invalid states it deletes. A reshape that only adds indirection is not one.
-3. Act: **Subtract before you add**.
+1. Anchor: from a clean trunk, pin current behavior with a characterization test, snapshot, or equivalence run before anything moves; a type check and lint are not a pin.
+2. Align: name the target shape as if built today, and the branches or invalid states it deletes. A reshape that only adds indirection is not one. A redesign that changes behavior is allowed; name it and route it to `feature`.
+3. Act: **Subtract before you add**, in its own commit ahead of the reshape and any follow-on cleanup, so each diff reads alone.
 4. Act: move in small steps with the pin green. **Migrate callers, then delete**. Check each rename against strings, prose, and back-references.
 5. Act: a bug or missing feature found on the way becomes a follow-up; the structural change ships against the pinned contract first.
-6. Verify: prove equivalence on the real artifact, then confirm reader load dropped (**Minimize reader load**); when it did not, revert.
+6. Verify: prove equivalence on the real artifact, then confirm reader load dropped (**Minimize reader load**): a new reader answers "where does X come from?" and "what can change X?" in under 30 seconds, with state derived instead of synced; when that fails, revert.
 
 **Reply:** the structure that changed, the pin, the equivalence evidence, the reader-load change, and what was reverted.

package/skills/coding/references/benchmark-checklist.md

@@ -0,0 +1,21 @@
+# Benchmark checklist
+
+Run it before reporting a performance number. Each item names the way a number comes out wrong.
+
+1. **Claim.** Write the sentence you expect to ship, the result that would change the decision, and the noise floor, before the first run. A claim shaped after the numbers arrive fits whatever they say.
+2. **Script.** Read what the measurement script times, counts, and ignores. A timer that covers setup, or the wrong function, measures something else.
+3. **Same footing.** Run every compared side the way production runs it: release build, flags, pools, and caches as warm or cold as production, with the same data and versions. A side on defaults means you compared configurations, so no winner follows from that run.
+4. **Work done.** The harness prints its error count and the units of work it finished. Fast failures and lazy code (a generator nobody iterates, a promise nobody awaits) look like speed. Confirm the work ran inside the timed region.
+5. **Quiet machine.** Read `uptime` and the core count first; stop competing work, or interleave the sides when you cannot. Orphan processes and a busy box turn drift into a "gain".
+6. **Counts.** At least 5 runs per side, alternating (A, B, A, B), reporting the median and range. A gap inside the run-to-run range is "no measurable difference". The base and the change alternate too, so thermal and cache drift hit both.
+7. **Limits.** Removing a piece that takes 10% of the run speeds it up by at most about 11%. Report a micro result as a share of the end-to-end path. A number past a hardware limit (disk, core count, network) measured something other than the work.
+8. **Limiter.** Ask why not double. Name the limiter from a profile or system counters; a guess from reading the code is not one. Profile in a run you do not report, because profilers slow the work, and when the load generator saturates first, you measured the load generator.
+9. **Behavior.** The behavior tests run green before the baseline and after each change. A faster run that fails them, or that returns different output, is reverted.
+
+The verdict is `inconclusive` when you claim a difference but cannot name the limiter, a side ran untuned, or you could not check items 4 and 7.
+
+A quick ballpark the user asked for needs one run. Still check items 4 and 7 and say it is one run; a choice between options is never a ballpark.
+
+---
+
+Adapted from pstack `benchmark-checklist` by Lauren Tan (MIT License), revision `c742dd6` of cursor/plugins.

package/skills/coding/references/design-red-flags.md

@@ -0,0 +1,18 @@
+# Design red flags
+
+The next contributor may be an agent that sees only the files it opened and copies the nearest example. Screen a new shape for these before building it; each one lets an edit that is right in one file be wrong across the repo.
+
+- **Shallow module.** The interface is nearly as complex as what it hides. Callers learn the internals anyway.
+- **Information leakage.** Transport, storage, or wire types appear in the public surface (**Boundary discipline**). Callers come to depend on the encoding.
+- **Temporal decomposition.** Modules named for phases (load, validate, transform, save) repeat the same domain rule in each. Split by what changes together.
+- **Pass-through.** A layer forwards its arguments and adds nothing. Delete it.
+- **Split ownership.** More than one module writes the same state. Give each actor its own state and merge at the read boundary (**Separate before serializing shared state**).
+- **Two ways to one task.** Two entry points reach the same outcome, so the next agent picks the wrong one. Keep one and delete the other.
+- **Importable internals.** A module's private parts can be imported from outside. Make an outside import fail the build.
+- **Hand-synced list.** Two lists must change together. Derive one from the other, or make the build fail when they disagree.
+
+A shape that survives the screen is the one where the same edit made from one file stays correct repo-wide, with drift caught by the build, not by prose.
+
+---
+
+Adapted from pstack `architect` (`references/design-red-flags.md`) by Lauren Tan (MIT License), revision `c742dd6` of cursor/plugins.

package/skills/human-feedback/SKILL.md

@@ -80,4 +80,4 @@ confirmed correction target.
 
 ## 5. Reflexive System Placement
 
-When feedback conveys a preference or convention rather than an isolated code bug, hand the preference to `reflecting-to-root` and any procedure change to `solid-loop`.
+When feedback conveys a preference or convention rather than an isolated code bug, hand the preference to `reflecting-to-root` and any procedure change to `solid-loop`. A correction of a mistake an instruction already forbids is a repeat: invoke `solid-loop` in the same change to raise its enforcement, because restating the prose rule has already failed once.

package/skills/inspecting/SKILL.md

@@ -45,5 +45,5 @@ For each scoped item:
 | [item] | [verdict] | [evidence] |
 ```
 
-Lead with the conclusion. Prioritize failures and recommended actions by impact. Name any unverified boundary instead of implying full coverage.
+Lead with the conclusion. Prioritize failures and recommended actions by impact. Name any unverified boundary instead of implying full coverage. Count the findings you rejected or could not reproduce, each with its reason; zero findings is a valid result, stated as such, because a report of survivors alone cannot tell "found nothing" from "found five and dropped them".
 

package/skills/inspecting/playbooks/diff-review.md

@@ -47,6 +47,12 @@ Quote or point to the governing requirement for each finding. When no spec is
 available, mark this axis insufficient evidence instead of reconstructing intent
 from the implementation.
 
+### Beyond the diff
+
+Read what the diff cannot show: serialized shapes (JSON, a DB column, a wire format) and the other-language readers of the same bytes, flags, timing and teardown order, and the pinned source of each dependency the change calls, because grep stops at callers. Keep the risks you confirmed and list those you checked and cleared apart.
+
+When a load-bearing scenario fails, run it on the base too. A failure present on both is recorded against the base and blocks only when the diff copies it or newly reaches it. When the base lacks the feature, check the behavior the diff adds and compare no ratio between unlike scenarios.
+
 **Reply:** separate `Standards` and `Spec` verdicts with file/hunk evidence, and
 a finding count and worst issue within each axis, never one combined score,
 because success on one axis cannot mask failure on the other.

package/skills/investigating/SKILL.md

@@ -8,12 +8,14 @@ description: Use when researching questions, diagnosing root causes without fixi
 Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md). The anchor is the exact question and its completion boundary: answered, or the missing evidence named precisely.
 
 1. Gather evidence through the playbook below that fits the question.
-2. Cross-check material claims and resolve source conflicts.
+2. Cross-check material claims. When sources conflict, report both with citations unless a run settles it; evidence about a neighboring subject is not an answer.
 3. Grade each material claim by its strongest evidence: asserted, cited
-   (`file:line` or primary source), reasoned (the failure path walked and shown
-   not to reach), executed (a script or test against the real code), or
-   reproduced (observed in the running system). A claim with no evidence is
-   `unknown`.
+   (a `file:line` or primary source you opened this session), reasoned (the
+   failure path walked and shown not to reach), executed (a script or test
+   against the real code), or reproduced (observed in the running system). A
+   claim a subagent relayed stays `asserted` until you open its cited line or
+   rerun its command. A claim with no evidence is `unknown`, with the queries
+   and sources tried beside it, so the next reader skips the empty search.
 4. Report the reasoning chain with each material claim's source and grade beside it.
 
 ## Playbooks

package/skills/investigating/playbooks/diagnose.md

@@ -2,7 +2,7 @@
 
 **You own the diagnosis.** The deliverable explains the symptom; a fix goes to the `coding` bug-fix playbook.
 
-1. Observe the symptom first through logs, metrics, traces, a profile, or a reproduction, before forming a theory from code.
+1. Observe the symptom first through logs, metrics, traces, a profile, or a reproduction, before forming a theory from code. Reduce a large capture (log, profile, trace, heap snapshot) by script or subagent into a queryable form and read the reduced finding, because a raw dump overflows the lead's context.
 2. Write the candidate causes with the observation each predicts, and rule them out one at a time against runtime evidence.
 3. Confirm the surviving mechanism by a prediction that would fail if it were wrong.
 

package/skills/investigating/playbooks/research.md

@@ -2,8 +2,9 @@
 
 **You own the answer.** Read-only: the deliverable is a cited answer or a recommendation, not a change.
 
-1. Code: LSP (`read_symbol`) for symbols and ast-grep for structure; text search for prose, configuration, and literals; history (`git log -S`, blame) when the question is why or since when.
+1. Code: LSP (`read_symbol`) for symbols and ast-grep for structure; text search for prose, configuration, and literals; history (`git log -S`, blame) when the question is why or since when. For why, also query each ticket, doc, chat, and error-tracking tool this session has, and list the ones not searched with the reason, because the stated reason often sits there and not in git.
 2. External facts: current primary sources (official documentation, source code, specifications, first-party APIs) over summaries of them.
-3. **Observe, don't ask.**
+3. Cite intent ('because', 'was designed to') only from what an author wrote: a commit, PR, ticket, comment, or document. An intent read off the code or the latest commit is `reasoned` at best, stated as inference; a hypothesis in the question is a candidate to test, not to confirm.
+4. **Observe, don't ask.**
 
-**Reply:** the answer first, then the chain with each claim's source and grade; for a choice, a trade-off table and a recommendation, pushing back when the premise is wrong.
+**Reply:** the answer first, then the chain with each claim's source and grade; for a choice, a trade-off table and a recommendation, pushing back when the premise is wrong; when the answer precedes a change, the constraints it sets (preserve, change, avoid, risk).

package/skills/solid-loop/SKILL.md

@@ -5,17 +5,17 @@ description: Use when creating, editing, or auditing agent skills and instructio
 
 # Solid Loop
 
-Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md). The anchor is `uv run python hooks/validate_all.py .` or the project's own validator, clean, and every edited section passing the no-op test.
+Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md). The anchor is `uv run python hooks/validate_all.py .` or the project's own validator, clean, every edited section passing the no-op test, and, when the change answers a recorded failure, a fresh-context rerun of that task in which the failure no longer occurs, or `rerun: n/a — <reason>` when no safe slice exists (see [author-skill](playbooks/author-skill.md)).
 
 The root virtue is **predictability**: each instruction sends the next run straight to the work, with no detour and no unneeded read.
 
 ## Placement
 
-Put each fact where it stays true. One that holds for every task type goes to the `anchorloop` core; one that holds for one task type goes to its entry skill or playbook; one that holds for one project goes to that project's `AGENTS.md` or `CLAUDE.md`. A multi-step procedure no skill owns becomes a playbook, or a skill when no entry fits.
+Put each fact where it stays true. One that holds for every task type goes to the `anchorloop` core; one that holds for one task type goes to its entry skill or playbook; one that holds for one project goes to that project's `AGENTS.md` or `CLAUDE.md`. A multi-step procedure no skill owns becomes a playbook, or a skill when no entry fits; propose one in the reply when you meet the same workflow a second time.
 
 ## Mechanism
 
-Enforce at the highest level that works, because nothing fails when an agent skips prose: architecture that removes the wrong path; a script for repeated deterministic work; a type, lint, or test; a tool-loop lever (pi extension hook, stream rule, validator) for a check the model demonstrably skips, with a message that names the fix. Prove the check fails on the recorded mistake. Prose is for judgment calls. A `Found` fact the agent system already states in prose is a repeat: escalate it in the same change. List each enforced rule beside its enforcer in the owning instruction file's rule table, and drop the row once the mistake can no longer happen.
+Enforce at the highest level that works, because nothing fails when an agent skips prose: architecture that removes the wrong path; a script for repeated deterministic work; a type, lint, or test; a tool-loop lever (pi extension hook, stream rule, validator) for a check the model demonstrably skips, with a message that names the fix. Prove the check fails on the recorded mistake. A check that existing code already violates fails only on additions; an exception sits on its line with a reason, an expiry, and the user's approval; the same command runs locally and in CI, because a rule that differs between them makes the rule table lie. Prose is for judgment calls. A `Found` fact the agent system already states in prose is a repeat: escalate it in the same change. List each enforced rule beside its enforcer in the owning instruction file's rule table, and drop the row once the mistake can no longer happen.
 
 ## Hold the Size
 

package/skills/solid-loop/playbooks/apply-friction.md

@@ -4,8 +4,8 @@
 
 1. A note with no before/after contrast (the failed attempt and what revealed the cause) gets no placement; record it as unsupported.
 2. Correct each misdirection: open the line named in `Led by` and rewrite it to state what `Found` established, or delete it when it has no correct form.
-3. Place each gap: search the agent system for a statement of the `Found` fact. When one exists, the run could not reach it: sharpen the pointer or description that should have led there. When none exists, write it as one direct sentence where **Placement** puts it. A fact the change itself resolved, or a tool slip no project or skill owns, needs no placement.
-4. Choose the **Mechanism** before writing prose, then **Hold the Size**.
+3. Place each gap: search the agent system for a statement of the `Found` fact. When one exists, the run could not reach it: sharpen the pointer or description that should have led there. When none exists, write it as one direct sentence where **Placement** puts it. A fact the change itself resolved, or a tool slip no project or skill owns, needs no placement. A `Found` fact that names a SHA, tool version, or run-specific path is rewritten as the durable rule or enforced by a check, because the detail drifts.
+4. Choose the **Mechanism** before writing prose, then **Hold the Size**. An action that stays prose says why no higher level held it: `; not higher because <the architecture, script, lint, or test that cannot hold it>`.
 
 **Reply:** one pair per note:
 

package/skills/solid-loop/playbooks/author-skill.md

@@ -6,6 +6,7 @@
 2. For a new skill or playbook, have the model attempt the task without it and record where it fails; the first version covers those failures and nothing more.
 3. A new skill starts from [the template](../references/template-skill.md); a new playbook copies an existing one's shape (ownership line, steps, `Reply:`).
 4. Apply the **Craft Levers**, then **Hold the Size**.
-5. Fix a broken skill met mid-task in its own change, not tangled into the task's diff.
+5. For a change that answers a recorded failure, rerun the smallest slice of that task that exercised the edited instruction, in a fresh-context worker with the edited skill, in a clean directory or disposable worktree, with outward-facing steps (push, deploy, tickets, chat) out of scope in the brief; when no safe slice exists, record `rerun: n/a — <reason>` and rest on the validator and the no-op test. Phrase it as ordinary work with no mention of testing, and judge from the files the worker read and the shape of its output, not its claims, because a worker told it is tested reads more carefully than a real run does. The recorded failure must not recur. To compare variants, give each the same organic prompt in a clean directory and read the tool-call transcripts yourself.
+6. Fix a broken skill met mid-task in its own change, not tangled into the task's diff.
 
-**Reply:** the files changed with the net line count of each, the layer, and the bare-run failures the change covers.
+**Reply:** the files changed with the net line count of each, the layer, the bare-run failures the change covers, and the rerun's before and after.

package/skills/writing/SKILL.md

@@ -7,10 +7,11 @@ description: Use when writing or revising documentation, a README, an article, a
 
 Run the loop in [../anchorloop/SKILL.md](../anchorloop/SKILL.md). The anchor is a reader without the conversation's context: hand the text to a fresh subagent and check it can say what the text asks of its reader. Comment-only work also keeps the project's tests green.
 
-Short declarative sentences; each claim carries its evidence or reads as an estimate.
+Short declarative sentences, written whole: articles and verbs kept, arrows and abbreviations spelled out, and every item the playbook's `Reply:` line names present, because compression moves the decoding work to the reader. Each claim carries its evidence or reads as an estimate, and says something about this project: cut a sentence that would fit unchanged in another project, and name the mechanism or a number in place of a feeling. Use the word a developer would say aloud, give a coined name its meaning at first use, and point each pronoun at one obvious referent, repeating the noun when unsure. Open with the point and stop when it is made; attribute a "studies show" or leave it out.
 
 ## Playbooks
 
 - [draft](playbooks/draft.md): a new document.
 - [tighten](playbooks/tighten.md): revising or shortening existing text.
 - [comments](playbooks/comments.md): removing or rewriting code comments.
+- [pr-description](playbooks/pr-description.md): a pull or merge request description or a commit body, once opening is authorized.

package/skills/writing/playbooks/comments.md

@@ -2,9 +2,11 @@
 
 **You own the comments, not the code.** No behavior changes.
 
-1. Keep a comment only for a non-obvious why the code cannot show: a constraint, a workaround with its cause, a surprising invariant.
+1. Keep a comment only for a non-obvious why the code cannot show and whose cause lies outside this codebase (vendor, platform, protocol): a constraint, a workaround with its cause. Also keep license headers, doc comments that define a public API contract, tool directives, and links to the issue or RFC behind a constraint.
 2. Delete comments that narrate what the code does, mark phases, or restate names; a test or script documents its step through its assertion text.
-3. When a comment claims a constraint the code could enforce (a type, an assertion, a check), report it as a follow-up.
-4. Verify that the diff touches only comments and that the project's tests still pass.
+3. A comment that asserts a constraint ("IMPORTANT", "do not remove") stays only after you check on the named symbol that it holds today; delete one you cannot verify and report it, because an unchecked claim protects dead code.
+4. A surprise in our own code, or a constraint the code could enforce (a type, an assertion, a check), is a reshape target: report it as a follow-up with the comment's text and the exact symbol, and drop the comment.
+5. List each lint or type suppression (`eslint-disable`, `@ts-ignore`, `noqa`) with the rule it silences; where that rule guards correctness or safety, report the suppressed symbol as a follow-up. The directive stays in this pass.
+6. Verify that the diff touches only comments and that the project's tests still pass.
 
-**Reply:** comments removed and rewritten by count, the follow-ups, and the test result.
+**Reply:** comments removed and rewritten by count, the follow-ups, the suppressions listed, and the test result.

package/skills/writing/playbooks/draft.md

@@ -3,8 +3,9 @@
 **You own whether the reader can act on it.**
 
 1. Name the reader, what they already know, and the decision or action the text serves; open with that.
-2. Pick one mode (tutorial, how-to, reference, or explanation) and keep each section in it.
-3. Link to the source of a fact instead of copying it; a copied fact drifts.
+2. Pick one mode (tutorial, how-to, reference, or explanation) and keep each section in it; opinion belongs to explanation only, so split and link instead of mixing.
+3. Link to the source of a fact instead of copying it; a copied fact drifts. A count, list, or tree you must state is regenerated at the landing commit and carries the command that produces it.
 4. Open terms or decisions go to `grilling`, or to `domain-modeling` when they are domain terms.
+5. Name things as the codebase does: the exact symbol, file, flag, or command, one name per concept. In a procedure put the condition before the instruction and the common case before its exceptions.
 
 **Reply:** the document path, its reader and purpose, and the reader check's result.

package/skills/writing/playbooks/pr-description.md

@@ -0,0 +1,15 @@
+# PR description
+
+**You own the reviewer's first minute.** The reader has the diff and needs the reasons. Write the text once opening the PR or MR is authorized; this playbook never opens one.
+
+1. Why: the problem and the approach, in one to three short sentences.
+2. What changed and what it deliberately leaves out, a follow-up or a known gap included.
+3. What it could break: who and what it touches, and why that is safe or risky.
+4. Verification: the anchor command and what it observed, then each requirement left `unknown`. Tradeoffs appear only for a rejected alternative the reviewer would ask about.
+5. Link logs, SHA lists, and tables instead of pasting them. A commit body adds what the subject cannot hold and does not restate it.
+
+**Reply:** the description text and the artifacts it links.
+
+---
+
+Adapted from [pstack](https://github.com/backnotprop/pstack) by Lauren Tan (MIT License), revision `c742dd6` of [cursor/plugins](https://github.com/cursor/plugins/tree/main/pstack), `skills/poteto-mode/playbooks/opening-a-pr.md`.