agentplugged 0.0.1 → 1.0.0

package/dist/method/skills/audit-pillars/references/security.md

@@ -0,0 +1,13 @@
+# Pillar: security (Chloé's)
+
+Walk the threat model (`.agentplugged/docs/threat-model.md`, when it exists) against the code: for
+each entry point, who can reach it and what they can do. Read the authentication and access code,
+the places where input enters, where secrets are read and where data leaves.
+
+Look for: input used before it is checked; an access rule missing on one path of several;
+credentials, keys or tokens in the code, a log, a document or the history (never copy one into
+the report); data returned that the caller should not see; unsafe defaults; logs that hold
+personal data.
+
+Every finding names the asset at risk and the path to harm, in plain words; a worry without a
+path is a `note`. Requirements: the security `ENF-n`.

package/dist/method/skills/audit-pillars/references/tests.md

@@ -0,0 +1,17 @@
+# Pillar: tests
+
+Read the test strategy (`.agentplugged/docs/test-strategy.md`, when it exists), then, for the most
+important behaviours of the PRD, the test that proves each. `state.trace` lists which tests cite
+which requirement (`path:line`).
+
+Look for: a requirement no test cites; a test that cannot fail (no assertion, asserts what it just
+set); a test that passes only most of the time; a level too low or too high for what it proves;
+failure and boundary cases missing next to the happy path; slow tests nobody runs; tests that
+depend on each other's order.
+
+The quality of the tests themselves (graded, broken by the engine, holes tied to the requirements) is
+the skill `review-tests`: point to it rather than redo it.
+
+Requirements: the tests `ENF-n` (coverage, speed, stability). Prove it with `measure.run` when the
+project declares its test command, else only from a test that cites the requirement and that its
+own command ran green.

package/dist/method/skills/chain-stories/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: chain-stories
+description: Chain the ready stories, stopping at every point that is the creator's. Run by Noah.
+metadata:
+  agent: noah
+  phase: build
+---
+# Chain the stories
+
+On the creator's ask ("do the ready stories", "go on while I do something else"). The loop lasts
+while this session is open: it never goes on without it. Work in the creator's language, under
+your own id (`agent: noah`).
+
+1. **Turn.** `story.loop { agent: "noah" }`. Say its `line` in one sentence, nothing more.
+2. **`run`.** Hand the `step` to its `agent` as usual (`agent.delegate`, a sub-agent for a story).
+   The brief carries `until` (the criteria that must hold) and `tried` (approaches that already
+   failed: never again). The developer declares its approaches: `references/attempts.md`.
+3. **`stop`.** The loop is at a point that is the creator's, or at its own limit: present it as
+   the `reason` says, one decision at a time (`references/stops.md`). Their gesture ends the stop.
+4. **`done`.** Nothing is left: say what was done, in one line (`point` of the answer).
+5. **Again.** After each hand comes back, and after each gesture of the creator, take a new turn.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never answer a point, merge, spend, publish or run a command in the creator's place: a stop is
+  theirs, and the loop does not go round it.
+- Never hand over twice in a row: you hand over, the agent works and calls no one (`ROLE_FORBIDDEN`).
+- Never retry a story by yourself past its limit: the engine opens the point, the creator lifts it.
+- Never rewrite the creator's words in a brief or a decision.

package/dist/method/skills/chain-stories/references/attempts.md

@@ -0,0 +1,19 @@
+# Approaches and attempts (the developer's side)
+
+Put this in the brief of the developer you hand a story to. The success condition is the story's
+acceptance criteria (`until`): the tests of its criteria, run by the engine (`story.criterion`).
+While one fails, the developer tries again, within a limit, and never repeats a failed approach.
+
+- **Before an approach:** `story.loop { agent, story, note }`, one line saying what you will
+  try ("recompute the total at checkout"). The engine refuses an approach that is one already
+  tried and failed (`approach_failed`, with those approaches), a second one while the first is not
+  reported (`attempt_open`), and any once the limit is reached (`attempts_exhausted`).
+- **After it:** `story.loop { agent, story, seen: "failed", note }` with the line that mattered
+  (the test, the message), or `seen: "green"` once every criterion holds: the engine checks
+  them itself and refuses (`CRITERIA_NOT_PROVEN`) while one does not.
+- **The limit is three failed approaches.** The third opens a point for the creator in the same
+  write; stop there and say so in your result (`blocked`). They may allow three more; the approaches
+  that failed stay failed.
+- An approach is a way of doing, not a try of the same way: another file, another algorithm,
+  another cut of the problem. A close rewording is the same approach, and the engine refuses it.
+- Never declare an approach for a story you did not build, and never to hide a test.

package/dist/method/skills/chain-stories/references/stops.md

@@ -0,0 +1,27 @@
+# The stops of the loop
+
+`story.loop` answers `stop` with a `reason` and a `subject` (a point `G-…`, a story or a step).
+The engine wrote the stop in the journal once; the first `run` after the creator's gesture writes
+the resumption. Present one stop at a time, then take a turn again.
+
+| `reason` | What it is | What you do |
+| --- | --- | --- |
+| `validation` | A document, the end of a phase or a change of the memory waits | `state.next` `decisions`, the usual way |
+| `decision` | A choice between options, or an action of theirs that is neither a command nor irreversible | The same, with the recommendation |
+| `merge` | A story's merge waits (their settings keep it) | Present the point with its review stack and walkthrough |
+| `spend` | A budget was exceeded | Present the point: raise, remove the ceiling, or stop |
+| `irreversible` | A release, a publication or an action that cannot be undone | Present it alone, with what cannot be taken back |
+| `command` | An installation or a command to accept | Present the exact command; never accept it for them |
+| `gap` | A gap of a requirement to settle | Present the point, record it with `checkpoint.gap` |
+| `creator_step` | A step that is theirs (a key to endorse, a method to sync) | Say it in one line and what to do |
+| `attempts` | A story's approaches failed up to the limit | Say what was tried (`tried`), ask if they allow three more |
+| `blocked` | A story is blocked | Read `state.get` for the story, bring the question |
+| `outside` | The next step is not the stories' work (framing, design, delivery, launch) | Say which step, and that it is a conversation with them |
+
+The points the creator did not keep are decided by their agent with a reason, as usual
+(`point_decision`): they are not stops, except a spend, an irreversible action and a command, which
+are always theirs. A point they kept waits beside work the engine calls independent of it (`waiting`
+counts them): the loop goes on with that work and presents the point at its next stop. At the end, and at each stop, `point` tells in a line what
+was done since they last answered: stories done, points decided by the agents, deferred items
+still open. A deferred item that locks a story is treated by its owner (`deferred_work`), and the
+creator decides what is theirs.

package/dist/method/skills/check-readiness/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: check-readiness
+description: Check, before stories are cut and built, that the plan holds together. Run by Izzy.
+metadata:
+  agent: izzy
+  phase: build
+---
+# Check readiness
+
+When `state.next` carries `readiness` (`check`), or the creator asks, check the plan as a whole
+before the stories are cut (`stage: breakdown`) or built (`stage: build`). Read-only: you change no
+document. Run it under your own id (`agent: izzy`), in the creator's language.
+
+1. `agent.status` (`working`). `review.ready` with `agent` alone: the engine's reading, nothing
+   written. `stack` holds what it computed (documents validated and unchanged, identifiers known,
+   requirements, stories, journeys and decisions traced both ways), the graver first; `documents`
+   what to read. Never judge again what the stack already says.
+2. Judge what only a reading tells, in a fresh context (a sub-agent when you have one): it reads the
+   documents, the epics, the stories the stack or a doubt points to, and `references/judge.md`.
+3. `review.ready` with `summary` and `findings` (possibly none): `references/judge.md` gives the
+   shape; fix what the engine says is missing. It answers `verdict` (`ready`, `reserves`,
+   `blocking`) and `stack`; a blocking one has opened a `decision` for the creator.
+4. `ready`: one line to the creator. Otherwise show `stack` as it is and take their gestures
+   (`references/settle.md`).
+5. `agent.status` (`idle`), hand back to Noah.
+
+On the short path (`track: short`) the spec stands for the documents: read it and the stories, at
+most 6 findings.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never rewrite the creator's text, never settle for them: no gesture without their words.
+- Never call, direct or wait for another agent: hand back to Noah.

package/dist/method/skills/check-readiness/references/judge.md

@@ -0,0 +1,21 @@
+# What you judge, and the report
+
+Three questions, nothing else:
+
+1. **Conflict**: do two documents say different things? (a requirement and a decision, a screen
+   and a rule, an epic and the PRD.)
+2. **Gap**: would a developer have to settle alone a point that no document writes down? (a choice of data, an interface, a rule, a screen state that no document settles.)
+3. **Shape** (a `gap`): does an epic deliver nothing a user sees (a layer), or lean on a later one?
+
+A missing document matters only when the stories rely on what it would have said.
+
+`review.ready` report:
+
+- `summary`: what you read and your answer to question 2, one line.
+- `findings`, at most 12 (6 on the short path), the weakest dropped; none is a valid answer:
+  - `severity`: `blocking` (built as written, the product breaks), `should_fix`, `minor`.
+  - `kind`: `conflict` or `gap`.
+  - `claim`: one line, checkable.
+  - `passages`: 1 to 3 of `<document>: <heading or EF-n, ENF-n, PU-n, AD-n>`; the document by its
+    id or file name. The first is the one to correct; a conflict names two documents. The engine checks them.
+  - `proposal`: one line, what to change and where (unless minor).

package/dist/method/skills/check-readiness/references/settle.md

@@ -0,0 +1,17 @@
+# The creator's gestures
+
+Ask once, in the chat, with `stack` as the engine gave it: one gesture per finding.
+
+- **correct** (`fix`): the author of the document corrects it.
+- **accept** (`accept`): the creator keeps it as it is, with their own `reason`.
+
+Beyond the twelve lines shown (`more`), settle these first, then check again. They may answer some now and the rest later. Settle: `review.ready` with `items` (`id` as in the
+stack, `gesture`, `reason` for an accept) and `quote` (their words). The engine answers `fix`: for
+each `owner`, the lines to hand over. The author changes the document and gets it validated again;
+an `owner` of `creator` means the creator writes it: offer the lines, change nothing. After a
+change, run the check again: a reading holds only for the documents it read (`judged: stale`).
+
+A blocking verdict has opened a `decision`: correct first, or go on all the same. It is the
+creator's alone; present it like any decision (`state.next` `decisions`).
+
+The creator may skip the gate in a word (`step_skip` `readiness`): Noah records it, once.

package/dist/method/skills/check-requirements/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: check-requirements
+description: Compare a started story's work with the requirements it cites, during the build and at the latest before the merge; report and verify each deviation. Run by the quality reviewer.
+metadata:
+  agent: quentin
+  phase: build
+---
+# Check a story against its requirements
+
+A story cites requirements (`EF-n`, `ENF-n`, and the decisions `AD-n` it must follow). This skill
+compares what was actually built with what those requirements say, and records every gap as a
+deviation in the journal: the creator then sees it on the story, on its pull request and on the
+requirement, and the story is not merged while one is open. It never fixes the code: the story's
+developer does.
+
+This skill belongs to the quality reviewer. Run it under your own id: `agent: <your id>` in every
+MCP call. Work in the creator's language; keep identifiers (`1-2`, `EF-n`, `AD-n`, `V-…`) as they
+are.
+
+- **Input:** one started story of `.agentplugged/stories/`, its branch, and the documents it cites.
+- **Output:** a deviation (`V-…`) per gap found, recorded with `story.deviation`; the deviations
+  you verified fixed, lifted with `story.lift_deviation`; and a structured result. No code change, no
+  push, no merge.
+
+## When
+
+- **During the build:** when the story's developer reports progress on a criterion, or when the
+  creator asks, compare what is already committed.
+- **Before the merge, at the latest:** once the story is in review and its pull request is open,
+  compare the whole branch. A story whose deviations are not all lifted is never merged.
+- **After a fix:** when the developer moves the story back to review, compare again: lift what is
+  fixed, report what is still wrong or newly wrong.
+
+## Steps
+
+1. **Start.** Call `agent.status` (`working`, the story as `story`). Read `state.get`: the story
+   must be started (`stories.<id>.started`) and not done; its open deviations are in
+   `deviations.open`. Otherwise say so and go to step 8 with `partial`.
+2. **Read the story, and only what it cites.** The story file, entirely (its `requirements` and
+   its four sections). Each requirement it lists, in the PRD: the requirement itself and the
+   journey it belongs to. Each decision `AD-n` it cites, in the architecture. Never the rest of the
+   repository "to get a feel".
+3. **Read the trace.** Call `state.trace` with each requirement of the story: its status, its stories,
+   the tests that cite it (`path:line`), the pull requests of its stories and its deviations. A
+   test cites a requirement by writing its id in its name, in a comment or in its file's name:
+   `EF-18`, or `EF_18` where a name takes no dash, in a test file. `state.trace` reads the tests of
+   the working copy the MCP server runs in, usually the main checkout: the tests of a story not
+   merged yet live on its branch. Look for them there too, in the story's worktree
+   (`stories.<id>.started.worktree`) or with `git grep -n -i -E "(EF|ENF)[-_]18" <branch> --`,
+   before you conclude anything about them. When `tests.status` is not `read`, the trace says
+   nothing about the tests.
+4. **Read what was built.** In the story's worktree (`stories.<id>.started.worktree`), or from its
+   branch (`git diff <base>...<branch>`, `git log <branch>`): the code the story changed, and the
+   tests it added or changed. Note the commit you compare (`git rev-parse <branch>`).
+5. **Compare, requirement by requirement.** For each requirement the story cites:
+   - what it asks, as written (every condition, limit, error case and non-functional bound);
+   - what the code does, with the file and line that show it;
+   - which test proves it: a test that cites the requirement and checks that very behaviour. A
+     requirement of the story that no test on the story's branch cites is a deviation
+     (`no test cites EF-n`), unless the story says how it is checked otherwise; never conclude it
+     from the main checkout alone.
+   Then for each acceptance criterion: met, with its test, or not. A gap between the code and a
+   requirement or a criterion is a deviation; a matter of taste is not. When the requirement
+   itself is ambiguous, do not guess: say so in your result (an open question).
+6. **Report each deviation.** One `story.deviation` per distinct gap: the `story`, the
+   `requirements` it drifts from (only requirements the story cites), a one-line `summary` of what
+   differs, a `detail` with what the requirement says, what the code does and where (file and
+   line), and the `commit` you compared. The engine attaches it to the story's pull request when
+   there is one, and sends a story in review back to its developer. Never report the same gap
+   twice: read `deviations.open` first.
+7. **Verify the fixes.** For each open deviation you reported on the story: when the code and its
+   test now satisfy the requirement, call `story.lift_deviation` with the deviation and how it was
+   fixed (the commit). Lift only the deviations you reported, and only once verified; another
+   agent's deviation is its own to lift, and the creator may lift any, in the chat. A
+   deviation on a story you built yourself is never yours to lift (`DEVIATION_NOT_ALLOWED`); when
+   the agent that reported one is no longer active, ask the creator to lift it.
+8. **Report.** Call `story.result` with the story: `complete` when the comparison ran to the end
+   (whatever it found), `partial` when something kept you from it. A summary that lists, per
+   requirement, `ok` or the deviation ids; your assumptions, open questions and conflicts. Then
+   `agent.status` (`idle`) and `npx agentplugged next --json`, and tell the creator what it says.
+
+## Proofs before a release
+
+The release point is refused while a non-functional requirement lacks a valid proof:
+`measure.requirements` (the gaps), then the proof: `measure.run` for a declared command
+(`references/engine-proofs.md`), else `measure.proof`; then the creator decides the rest, one gap
+at a time (`references/proofs-and-gaps.md`).
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): checkpoint before the question, ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never change the code, the tests or the story: report, do not fix.
+- Never report a deviation from a requirement the story does not cite (`not_linked`): a gap
+  outside the story is a note for the creator in your result.
+- Never lift a deviation you did not verify, nor one you did not report.
+- Never merge, never approve a story: the creator validates.
+- Never call, direct or wait for another agent: hand back to Noah, who proposes what comes next; the creator decides (without Noah, the creator picks the next agent).

package/dist/method/skills/check-requirements/references/engine-proofs.md

@@ -0,0 +1,43 @@
+# Proofs the engine produces
+
+The engine runs the commands the project declares, itself, and inscribes the proof: exit code,
+duration, commit tested, whether the copy was clean, a short masked summary. Such a proof is marked
+`engine`; one you report with `measure.proof` is `reported`. `measure.requirements` counts both
+(`engine`, `reported`) once the engine has produced one. Never run a declared command yourself to
+report its result.
+
+**1. Declare.** Write or complete `.agentplugged/proofs.yaml` (a proposal: it runs nothing yet):
+
+```yaml
+commands:
+  - name: tests            # lower case, - or _
+    run: npm test          # a program and its arguments, as in a terminal
+    timeout: 600           # seconds, 300 without, 3600 at most
+    proves: [ENF-2]        # the requirements a passing run proves
+  - name: bench
+    run: node bench.mjs
+    cwd: perf              # inside the project, `.` without
+    proves: [ENF-1]
+    measured_after: "p95_ms="   # a measure: the number after this text on the last line that has it
+```
+
+Use the project's own commands, never a tool you assume. A line that only a shell reads (a pipe,
+`&&`, `$VAR`) goes through the shell: prefer a plain line or a script of the project.
+
+**2. Ask the creator once.** `guard.creator_action` with `{kind: proof_commands}`: the engine reads
+the file and asks for every line that is new or modified. Show `preview` to the creator as it is,
+line by line (name, exact line, folder, limit, requirements); never reword it. `later` lines did not
+fit: ask again after the answer. A line they refuse stays refused: name it (`commands: [name]`) only
+when they ask again. Changing a line, its folder, its limit or what it proves asks again. To demand
+at the release that proofs be the engine's own: `{kind: proof_commands, require: engine}` (`any`
+takes it back).
+
+**3. Run.** `measure.run` with `source` = the command's name. You get `ok`, `seconds`, `proved`,
+`failed`, `skipped` (`id:why`: a review comes from the audit, a CI from the CI, a test proof needs a
+test that cites the requirement, a measure needs a budget), `unclean` (changes not committed: commit,
+then run again before a release) and, on a failure, `lines`; the whole output is in `log`, a local
+file. A failure, a timeout or a command that never started is a failed proof: a gap, never a proof.
+Do not retry in a loop: fix the cause, or ask the creator.
+
+Refusals say what to do: `not_accepted` (step 2), `refused_by_the_creator` (their word stands),
+`nothing_to_prove` (the command proves nothing the engine can prove by running it).

package/dist/method/skills/check-requirements/references/proofs-and-gaps.md

@@ -0,0 +1,45 @@
+# Proofs and gaps of the non-functional requirements
+
+**What counts as a proof** (`measure.proof`: `requirement`, `source`, and `passed` or `measured`).
+The register says which kind each requirement expects (`id:why:proof` in its gaps); you give no
+kind. A command the project declares is run by the engine itself (`references/engine-proofs.md`):
+prefer it. Otherwise what you report is the result of the project's own command, that you ran,
+marked `reported`. Never record a proof you did not get.
+
+- `test`: the source is `path:line` of a test that cites the requirement (its id in the name or a
+  comment); the engine looks for it. `passed` is what the project's own test command said.
+- `ci`: the source is the id of a story (`1-2`) whose CI the engine read; it decides from that read
+  (green or not), you give no `passed`. When stories cite the requirement, it is one of them.
+- `analysis`: a scan or an analysis; the source is the command the project declares for this
+  requirement. `passed` is its result.
+- `measure`: the source is the declared command; give `measured` in the unit of the requirement's
+  budget (`≤ 300 ms` takes milliseconds). The engine compares and decides; you never say pass.
+- `review`: never typed in: it comes from the audit (skill `audit-pillars`, `verified`), for the
+  requirements that expect a review.
+
+A requirement whose wording is unclear (two budgets in one sentence, `1,000` that could be one or a
+thousand) is a finding for the PRD's author, not a proof to invent: the register then expects a
+test or an analysis. A proof stays valid while the requirement says the same and no story that
+covers it is delivered after it (all stories, for a requirement none cites); then run it again.
+
+**When the release point is refused** (`RELEASE_NOT_READY`, the requirements `id:why`). The end of
+the delivery phase is held the same way.
+
+1. Run `measure.requirements` again first: the register follows the PRD and the architecture as
+   they are now, and tells what it no longer holds (`removed`).
+2. Get each missing proof: `measure.run` for a declared command, else run the project's command
+   and record the real result.
+3. For each requirement still failing or without proof, open one `decision` point with
+   `checkpoint.open`, its title naming the requirement ("Gap on ENF-3"), two lines on what is
+   missing and what it costs, and exactly the options `fix` (a story is proposed; the release
+   waits), `accept` (the creator takes the risk and says why), `defer` (to a version they name).
+   Recommend `fix`. A point serves one gap and is used once; a failure recorded after it needs a
+   new point.
+4. Ask the creator through the chat, one point at a time. Once they chose, relay it with
+   `checkpoint.gap`: the `requirement`, the `option`, the point's id and their reason in their own
+   words (for `defer`, the version they named).
+5. When none is left, the release point can be approved (by the creator, or by the agent they left
+   this kind of point to): the engine refuses it otherwise, and says which.
+
+Never accept, defer or fix a gap on the creator's behalf, and never reword their reason. A gap the
+creator accepted stays accepted until the requirement changes; a new failing proof reopens it.

package/dist/method/skills/correct-course/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: correct-course
+description: Compute what a change of mind touches; the creator settles each element with one gesture.
+metadata:
+  agent: maya
+  phase: planning
+---
+# Correct the course
+
+The creator changes their mind: `references/steps.md`.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Call, direct or wait for another agent: hand back to Noah.

package/dist/method/skills/correct-course/references/gestures.md

@@ -0,0 +1,20 @@
+# The creator's gestures on the stack
+
+`stack` is sorted by the engine, the most structuring first (decisions, requirements, passages,
+documents, stories under way then to do then done, criteria, hypotheses, pages). Ask once, in the
+chat, with the lines as they are; one gesture each. They may answer some now and the rest later:
+`step: show` with `item` (C-…) says what is left and what is still incoherent.
+
+- **update**: it changes; its author does it (`handoff` says who). `gesture: update`.
+- **retire**: for a requirement or a decision that goes: the identifier stays, marked retired
+  (`(retired)` before its text), never deleted, never reused. `gesture: retire`.
+- **keep**: it stays as it is, with their reason. `gesture: keep`, `reason`.
+
+`step: decide` with `item`, `items` (`n`, `gesture`, `reason` for a keep) and `quote` (their words).
+A story under way is held until its decision is taken: tell its developer (`blocked`).
+
+Close with `step: close`: the engine finds every element marked update changed, every
+retirement marked, no story citing a retired requirement, no
+proof still valid for a requirement whose text changed (Quentin brings the register of proofs up
+to date: hand it to Noah). While something is wrong it answers `problems` and writes nothing; an
+update that is not needed becomes a keep, with a reason. Once whole, the course is closed.

package/dist/method/skills/correct-course/references/starts.md

@@ -0,0 +1,18 @@
+# Naming what a change touches
+
+`starts`: 1 to 8 entries, each one of these forms. The engine refuses one it does not find (`EF-9:
+not found`) and writes nothing.
+
+- A requirement or a decision: `EF-3`, `ENF-2`, `AD-4`, `PU-1`, `MS-2`.
+- A story: `4-3`. A criterion of a story: `4-3#2` (its number in the list).
+- A passage of a document: `prd#Public cible`, `ux#Parcours d'achat`, `architecture#Données`
+  (`brief`, `prd`, `ux`, `architecture`, `spec`; a heading of the document, or an identifier it
+  holds). The identifiers a passage names are followed too.
+
+Name the least that says the change: the engine follows the trace from there (stories that cite an
+identifier, tests, proofs, hypotheses, documents and pages of the base). A change that touches
+several things names several starts, one call. A new requirement is not a start: write it, then
+change course on what it replaces.
+
+`summary` is the change in one line, in the creator's terms; `quote` is their sentence as they
+said it. One course at a time: finish the one that is open (`step: show`) before another.

package/dist/method/skills/correct-course/references/steps.md

@@ -0,0 +1,14 @@
+# Correcting the course, step by step
+
+1. `agent.status` (`working`), under your own id. Say the change in one line and name what it touches
+   (`starts.md`); read the document or `state.trace` before naming, never guess.
+2. `plan.course` `step: open` (`summary`, `starts`, their words in `quote`). Show `stack` as it
+   is, then `blocked` (their developers are told, they do not merge) and `proofs`.
+3. One gesture per element, in their words (`gestures.md`): `step: decide`.
+4. Do your own updates (PRD: `write-prd` « Identifiers » and « Decisions »; then
+   `npx agentplugged docs check`; a `decision` checkpoint for each ambiguity the change brings);
+   hand the others over with `handoff`.
+5. `step: close`: fix what `problems` says, close again. `agent.status` (`idle`), hand back to Noah.
+
+Never decide a gesture for the creator, rewrite their text without their gesture, renumber an
+identifier or delete one: retire it.

package/dist/method/skills/critique-deliverable/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: critique-deliverable
+description: Attack a brief, PRD, UX spec or architecture with a chosen method before building on it; submit one closed report; the creator sorts the objections. Run by Quentin.
+metadata:
+  agent: quentin
+  phase: planning
+---
+# Critique a deliverable
+
+On the creator's ask, or when `state.next` carries `critique`, attack one document of
+`.agentplugged/docs/` (`brief`, `prd`, `ux`, `architecture`) before anyone builds on it. Read-only.
+Run it under your own id (`agent: <your id>`), in the creator's language.
+
+1. `agent.status` (`working`). Method: the creator's, else `references/choose.md`, in one line.
+2. Critique in a fresh context (a sub-agent when you have one): it reads the document,
+   `references/format.md` and the method's file here, nothing else (two files if blended), never the author's reasoning.
+3. `review.critique` (report: `references/format.md`); fix what the engine says is missing. Show `stack` as it is.
+4. Gestures, settling and hypotheses: `references/gestures.md`.
+5. `agent.status` (`idle`), hand back to Noah.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never rewrite the creator's text, never settle or close for them: no gesture without their words.
+- Never call, direct or wait for another agent: hand back to Noah.

package/dist/method/skills/critique-deliverable/references/assumption-audit.md

@@ -0,0 +1,11 @@
+# Assumption audit
+
+List what the document takes for true without having checked it, and test the weakest.
+
+1. Extract the assumptions, stated (`[assumption]`, "we expect") or silent (about users, volumes,
+   platforms, partners, the team).
+2. Rank them by how likely each is to be wrong and by what it costs the product if it is.
+3. Take the few at the top. For each, say what the document would have to change if it fell.
+
+Each is an objection: the assumption is the `claim`, the passage that rests on it is the
+`passage`, and the cheapest check (a question, a number, a prototype) is the `proof`.

package/dist/method/skills/critique-deliverable/references/choose.md

@@ -0,0 +1,27 @@
+# Choosing a method
+
+The creator may name one, or two to blend. Otherwise choose by what the document is and what it
+risks, and say why in one line. Identifiers are those of the report; the file is
+`references/<identifier with - for _>.md`.
+
+- **brief**: `socratic` (premises nobody questioned); `reframe` if it may answer the wrong question.
+- **prd**: `pre_mortem` (what it forgot); `subtraction` if long; `extreme_user` if users are varied.
+- **ux**: `devils_advocate` (defended by whoever drew it); `extreme_user`; `subtraction` for excess.
+- **architecture**: `divergence` (two parts true to each decision that still do not fit);
+  `red_team` (adversary and load); `failure_modes` (each part failing); `compare_existing` when
+  code already exists.
+- One big assumption: `first_principles`, or `assumption_audit` for several.
+- A hard-to-reverse decision: `inversion`, `second_order` (what it causes next), `steelman` (the
+  best case for the option dropped).
+- Whether a PRD or a UX specification is good as a whole (thesis, theater, trade-offs, excess):
+  `judgment`, whose grid is in the checklist of the skill that wrote it.
+- A regulated or specialised field: `domain_expert`.
+
+**Blend**: two methods in one critique when the risks differ (`divergence` with `failure_modes`);
+`lenses` holds both, the sub-agent reads both files, the report stays one and holds the 12
+strongest objections. Never three. `personas` and `reconcile` stand alone.
+
+**Reconcile** (`reconcile`): before a PRD, UX or architecture is validated, not instead of a
+critique; at most five findings, see `references/reconcile.md`.
+
+A third method, or another with a different aim, is a new critique.

package/dist/method/skills/critique-deliverable/references/compare-existing.md

@@ -0,0 +1,13 @@
+# Compare with the existing
+
+Set the document beside what already exists, and see where it re-invents, contradicts or
+forgets.
+
+1. Gather what exists: the code and documents in the repository, the products the users
+   already use, the creator's earlier decisions. Read only what the document touches.
+2. For each major point, ask: does something here already do this, and does the document agree
+   with it (names, limits, behaviour, constraints)?
+3. Keep the contradictions, the duplicates, and the existing things the document would break.
+
+Each is an objection: the mismatch is the `claim`, the passage is the `passage`, and the place
+where the existing thing can be seen (a file, a screen, a product) is the `proof`.

package/dist/method/skills/critique-deliverable/references/devils-advocate.md

@@ -0,0 +1,13 @@
+# Advocate against
+
+Defend the opposite choice with conviction, as someone who would lose if the document were
+followed and who is intelligent and fair.
+
+1. List the document's main choices (what is in, what is out, how it works, in what order).
+2. For each, build the strongest case for the other choice: who it serves better, what it costs
+   less, what the document's choice gives up.
+3. Keep the cases the document does not answer. A choice that survives its best opponent is
+   not an objection.
+
+Each unanswered case is an objection: the case is the `claim`, the choice it contests is the
+`passage`, and what would show which choice is right is the `proof`.

package/dist/method/skills/critique-deliverable/references/divergence.md

@@ -0,0 +1,15 @@
+# Divergence
+
+Two teams build two parts of the product, each obeying every decision of the document exactly
+as written. Find where the parts still do not fit.
+
+1. Pick two parts that must work together (two modules, a client and a server, two screens that
+   share data).
+2. Build each in your head, applying each decision as written and nothing else. Wherever a choice
+   is left open (a format, an owner, a name, an error, an order), the two builders choose
+   differently.
+3. Keep the divergences that would break the whole: a seam nobody owns, a rule that says what to
+   do but not how far, a decision left to "later" that both parts depend on.
+
+Each is an objection: the divergence is the `claim`, the decision (`AD-n`) that should have
+closed it is the `passage`, and the integration test that would fail is the `proof`.

package/dist/method/skills/critique-deliverable/references/domain-expert.md

@@ -0,0 +1,14 @@
+# Domain expert
+
+Read the document as a veteran of the field it enters would, one who has seen similar products
+fail for reasons outsiders miss.
+
+1. Name the field in one line (health data, logistics, teaching, payments, games…) and the
+   rules, habits and traps of it that every practitioner knows.
+2. Walk the document and mark what that person would find naive, impossible, illegal, or already
+   solved a known way.
+3. Keep what is wrong for the field, not what is merely unusual. Say what the practitioner
+   would do.
+
+Each is an objection: what the practitioner would say is the `claim`, the passage is the
+`passage`, and a real practitioner's answer or a standard of the field is the `proof`.

package/dist/method/skills/critique-deliverable/references/extreme-user.md

@@ -0,0 +1,13 @@
+# Extreme user
+
+Test the document against the users at its edges, since the middle is what it was written for.
+
+1. Choose three or four: the most expert, the newest, the one with the most data, the one with
+   the least time or the worst connection, the one who does not read, the one who abuses.
+2. For each, walk their journey through the document and mark where it stops, wastes their
+   time, locks them out or breaks.
+3. Keep the gaps a real share of users will meet. Drop the rare ones the product may ignore, and
+   say so.
+
+Each is an objection: what happens to that user is the `claim`, the requirement or flow they
+cross is the `passage`, and a session with that kind of user is the `proof`.

package/dist/method/skills/critique-deliverable/references/failure-modes.md

@@ -0,0 +1,13 @@
+# Failure modes
+
+Go through the parts one by one and ask how each one fails, what the user then sees, and what
+catches it.
+
+1. List the parts the document relies on (components, steps of a flow, outside services,
+   data).
+2. For each, write how it can fail: absent, slow, wrong, duplicated, out of order, refused.
+3. Check what the document says happens then. Keep the failures with no detection, no recovery or
+   a silent loss. Order by the damage to the user.
+
+Each is an objection: the failure is the `claim`, the part is the `passage`, and the test that
+provokes the failure and shows the outcome is the `proof`.

package/dist/method/skills/critique-deliverable/references/first-principles.md

@@ -0,0 +1,12 @@
+# First principles
+
+Strip the document to what must be true, then see what it added by habit.
+
+1. State the need in one sentence, as the person who has it would, with no solution in it.
+2. List what is physically, legally or logically fixed, and what is only convention or copied
+   from how others do it.
+3. Rebuild the simplest answer from the fixed things alone. Compare with the document: what does
+   it carry that the need does not require, and what does the need require that it lacks?
+
+Each gap is an objection: the extra weight or the missing piece is the `claim`, where the
+document carries or omits it is the `passage`, and the simplest test that settles it is the `proof`.