agentplugged 1.3.0 → 2.0.0

package/dist/method/skills/generate-knowledge-base/assets/page-template.md

@@ -7,26 +7,14 @@ sources: []
 code: []
 last_story:
 ---
-<!-- Page of the knowledge base (skill generate-knowledge-base): the vision, the conventions, the
-entry pages of reference/ (requirements, architecture, decisions) and the reference of an
-interface. Copy it to its path under .agentplugged/docs/ and write it in the creator's language.
-Replace `topic` in the `id` by the page's slug: kb-vision, kb-conventions, kb-requirements,
-kb-architecture, kb-decisions… `links` names the documents the page builds on (prd,
-architecture…) and the requirements it cites, once they exist. `sources` records each validated
-document of the method the page was built from, with the blob of the version read:
-  sources:
-    - path: .agentplugged/docs/prd.md
-      blob: <blob of the version the creator validated>
-When the creator validates another version, the page is behind it until updated. `code` lists
-the paths of the repository the page describes, relative to its top (a folder ends with `/`:
-`src/billing/`); `last_story` names the last merged story the page took in (`4-3`), the latest
-one merged when the page is written. A story merged later that changes a file of `code` makes the
-page behind it until updated. A draft stays
-out of `sources`. Only documents of .agentplugged/docs/ are tracked (brief, PRD, UX,
-architecture and decisions): the stories, the epics, the other pages of the base and the files
-of the repository go in the Sources section. Remove these
-guidance comments, the "Generated by agentplugged" line and every <…> placeholder. Never add a
-status, a cost or a progress to the header. -->
+<!-- Page of the knowledge base (skill generate-knowledge-base): vision, conventions, entry pages of
+reference/, interface references. Copy it to its path under .agentplugged/docs/, in the creator's
+language. `id`: kb-<slug>. `links`: the documents and requirements it builds on, once they exist.
+`sources`: each validated method document it was built from, as `- path: …` and
+`blob: <blob of the version read>` (a draft stays out; stories, epics, other pages and repository
+files go in the Sources section). `code`: the repository paths it describes (a folder ends with
+`/`); `last_story`: the last merged story it took in. Remove these comments, the "Generated by
+agentplugged" line and every <…> placeholder; no status, cost or progress in the header. -->
 
 # <title>
 
@@ -38,10 +26,9 @@ Last updated: <date> — <what changed it>
 
 ## <section>
 
-<!-- The page's content, by section. Point to the source instead of repeating it: a requirement
-stays in the PRD, a decision in the architecture. Cite an identifier inside a sentence or in a
-later column, never at the start of a line, a list item, a heading or a first table cell. Prefer
-a table or a diagram to long prose. -->
+<!-- Content by section. Point to the source instead of repeating it. Cite an identifier inside a
+sentence or in a later column, never at the start of a line, a list item, a heading or a first
+table cell. Prefer a table or a diagram to long prose. -->
 
 | Area | What to know | Where it is defined |
 | --- | --- | --- |

package/dist/method/skills/generate-knowledge-base/references/living-docs.md

@@ -1,81 +1,42 @@
 # A documentation that stays true
 
-The five cases where Zoé's work differs from the usual run. Read the one that applies: `state.next` names it, except a page behind a merged story, which `docs check` warns about (`kb_story`).
-
 ## A page that says it is behind
 
-When a page is behind a document the creator validated or a merged story, the engine itself
-writes at the top of the page, right after its header, a late notice between two lines
-`<!-- agentplugged:late since=<date> -->` and `<!-- /agentplugged:late -->`, in a commit of its
-own (never a change left uncommitted): on the story's own branch when it opens its pull request
-(so the notice reaches the main branch with the merge), or on the landing branch where the
-creator merges without a pull request. Where nothing can be committed, nothing is written and
-`state.next` lists the page in `late_pages`; look at it before you rely on any page.
-Never write or edit a notice yourself, and change nothing of a page outside the passages your
-update touches. A page that carries one, or that `late_pages` lists, is not true: never take a
-fact from it, read the code it names.
-
-**You remove the notice**, in the same commit as the update of the page: when the page is up to
-date, delete the whole block (both lines and what lies between them), nothing else. Leave it when
-you could not update the page.
+The engine commits under a late page's header a notice between
+`<!-- agentplugged:late since=<date> -->` and `<!-- /agentplugged:late -->`; else
+`state.next` lists the page in `late_pages`. Never write a notice. A page with one is not
+true: read the code it names. **You remove the notice**, whole block, in the commit that updates the page; leave it if you could not.
 
-When `state.next` gives a `background` (pages behind while a story is under way), do the update
-in your own branch, beside the developers: it never makes a story wait, never touches the
-branch of a story, and a page is rewritten by paragraph, never as a whole.
+When `state.next` gives a `background`, update in your own branch: it never
+makes a story wait nor touches a story's branch; rewrite by paragraph.
 
 ## A page behind a merged story
 
-The engine merges a story once the creator approves it and records the files it changed
-(`merged_order` in `state.get { full: true }` lists the merged stories by rank; `state.get
-{ story: "<id>" }` gives `state.merged`, its rank and the files it changed). When a story merged
-after the page's `last_story` (every merged story, when the page names none) changed a file of its
-`code` (a path, or a folder ending with `/`), `docs check` warns `kb_story` with the page, the
-story and the files. In that case:
-
-- **What to update:** the pages each `kb_story` warning names, and nothing else.
-- **What changed:** bring the main branch up to date first (`git pull`: the merge happened at
-  the forge), then read what the story changed (`git log` and `git diff` of its merge, the
-  story's file, and the files the warning names).
-- **Write:** change only the passages those changes touch, set `last_story` to the story (the
-  latest one, when several), and replace the `Last updated` line: today's date and the story
-  ("story 4-3 merged"). A page that newly describes code adds its paths to `code`.
-- **Check and review:** as in the update mode of the skill: `docs check` without `kb_story` left, commit, then the
-  `document` checkpoint, its summary naming each story that caused a change.
+A story merged after the page's `last_story` that changed a file of its `code` (path or folder)
+makes `docs check` warn `kb_story`; only those pages. `git pull`, read what the
+story changed (`state.get { story: "<id>" }`, `git diff`), change only the touched passages, set
+`last_story`, write the date and story in `Last updated`; `docs check`, commit, the `document`
+checkpoint naming each story.
 
 ## A new product
 
-`state.next` gives `knowledge_base` on a product that did not exist before the method, once the
-architecture is validated and before the first story. Keep it short and ask nothing:
-
-- write only `index.md`, `vision.md` and `conventions.md` (a page of reference per area only when
-  the architecture already settles it), each one screen long, from the approved documents, which
-  the pages point to instead of copying;
-- read no code (there is none yet) and put no question to the creator; what a document does not
-  say is an open question in the page;
-- `last_story` stays empty, `code` lists the folders the architecture plans;
-- then open the review as step 9 says: the engine decides who answers it.
+`state.next` gives `knowledge_base` after the architecture is validated: ask nothing and read no
+code. Write only `index.md`, `vision.md` and `conventions.md`, one screen each, pointing to the
+approved documents; what they do not say is an open question. `last_story` empty, `code` the
+planned folders.
 
 ## A product with its own documentation
 
-On a product that existed before the method, the README, `docs/`, the wiki exports and the
-changelog are claims, not facts. Before writing any page, confront each of them with the code,
-page by page:
-
-- **true** — the claim is proved by a file: it enters the base, with that file as its source;
-- **false or out of date** — the code says otherwise: it never enters the base. List it, with
-  the document and line that claim it, what the code says and the file that proves it;
-- **unverifiable** — no file proves it: a question for the creator, marked as such.
-
-The review checkpoint's summary and the `story.result` carry this list, page by page, under
-"Documentation found": a creator who reads it knows which of their documents to fix or delete.
-Never edit their documentation yourself, except for the README when they ask (menu RD).
+README, `docs/`, wiki and changelog are claims. Confront each with the code: **true** (a file
+proves it) enters the base with that file as source; **false or out of date**: it never enters the
+base, list it with its document and line, what the code says and the proving file;
+**unverifiable**: a question for the creator. The review summary and `story.result` carry the list
+under "Documentation found".
 
 ## A version delivered
 
-When `state.next` gives `release_notes`, a release was approved and stories merged before it are
-not in the notes yet. Write `.agentplugged/docs/release-notes/<version>.md` from those stories
-(`merged_order`, then `state.get { story: "<id>" }`; in the users' words, breaking changes and
-required actions first, each item linked to its story) and set its `last_story` to the newest
-story it covers. Then update the user guides of `guides/` that the changes touch, only the
-passages concerned, and add the version to `release-notes/index.md`. These pages are the source
-of the future help centre: write what a user does, not what the code does.
+`state.next` gives `release_notes`: write `.agentplugged/docs/release-notes/<version>.md` from the
+stories merged since (`merged_order`, `state.get { story: "<id>" }`), in the users' words,
+breaking changes first, each item linked to its story. Then update the user
+guides the changes touch, add the version to `release-notes/index.md`. These pages feed the
+future help centre.

package/dist/method/skills/generate-knowledge-base/references/reuse-map.md

@@ -1,21 +1,12 @@
 # The map of what can be reused
 
-One page, `.agentplugged/docs/reference/reusable.md` (`id: kb-reusable`, from `assets/page-template.md`),
-that lets a developer, human or agent, find what exists before writing it again. Short: a table
-a reader scans in a minute, not a catalogue of the code.
+`.agentplugged/docs/reference/reusable.md` (`id: kb-reusable`, from `assets/page-template.md`): a
+table scanned in a minute.
 
-- **What goes in:** the modules that own a job (one line each: what it does, when to use it), the
-  public functions and helpers that other code calls or should call (name, path, what it takes and
-  gives), the shared types, the utilities (dates, text, paths, files, errors, logging, HTTP). Group
-  by area, the areas the repository already uses.
-- **What stays out:** private details, anything used in one place only, generated code, tests.
-- **One row:** name and path (`src/text/slug.ts`), the job in a few words, the rule of use if there
-  is one ("always this, never a local copy"). Aim for the twenty to sixty entries that matter.
-- **Header:** `code` lists the folders the entries come from, so that a story that merges there
-  makes the page late like any other; `last_story` as for every page. Update it by row, with the
-  rows the merged stories touched: add what they created, remove what they deleted.
-- **How to find the rows:** read the entry points and the shared folders first (`lib`, `utils`,
-  `common`, `shared`, `core`, `helpers`, or the repository's own), then the names exported from
-  them. Never invent a function: a row is a file you read.
-- **Duplicates you meet:** list them in "Open questions" (two helpers doing one job) for the creator
-  to settle; do not merge them.
+- **In:** modules that own a job, public helpers other code calls, shared types, utilities.
+  Grouped by the repository's areas; twenty to sixty rows.
+- **Out:** private details, one-place code, generated code, tests.
+- **Row:** name and path, the job in a few words, the rule of use if any.
+- **Header:** `code` lists the source folders; update by row after a merged story.
+- **Find rows** in the entry points and shared folders (`lib`, `utils`, `common`, `core`); a row
+  is a file you read. List duplicate helpers under "Open questions", never merge them.

package/dist/method/skills/ideation/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ideation
-description: Ideation session with techniques by category, a stance chosen once, saved batch by batch and resumable, then convergence and gestures. Run by Lou.
+description: Ideation session with techniques by category, a stance chosen once, saved batch by batch and resumable, then convergence. Run by Lou.
 metadata:
   agent: lou
   phase: framing
@@ -8,31 +8,24 @@ metadata:
 # Ideation
 
 On the creator's ask, or to pick a session up. Run under your own id (`agent: lou`), in their language.
-Write only the session file `.agentplugged/docs/ideas/ideation-<slug>.md`. The point: a longer and sharper list
-than they would reach alone; a good session leaves them astonished by their own ideas.
+Write only the session file `.agentplugged/docs/ideas/ideation-<slug>.md`.
 
-1. `agent.status` (`working`). **Resume**: list the `ideation-*.md` of `.agentplugged/docs/ideas/` that still have
-   a `Next step:` line; offer to pick one up (read it whole, once, say in two lines where it stands: stance,
-   technique in progress, last batch) or to start fresh. **Read what exists**: brief, PRD, research (`npx
-   agentplugged docs research <subject>`), the hypotheses of `state.get`, the recent ideas notes. Say in two
-   lines what you found.
-2. **One opening question**: what do you want ideas on, why (the why decides the techniques and the
-   convergence), and anything you should read or respect. Skip it when the ask already says it. **Stance**,
-   once: `references/stances.md`. **Create the file now** from `assets/session-template.md`, with only the
-   question, the stance and `Next step:`; add each other section when it has content.
-3. **Techniques** (3 or 4 a batch): `references/choose.md`; read only the file of the category you draw
-   from (`references/techniques-<category>.md`), never all of them. Announce each change of lens.
-4. **Run**: one question per message, no list of choices while ideas flow. Stay with a technique while it
-   still yields; switch after five to ten exchanges. Aim far, past fifty ideas: resist closing early, one
-   more push first. **Save at every batch** (about ten ideas, or a change of technique): append the ideas
-   under `### <technique>`, one bullet each as the creator said it, marked with who had it; a direction they
-   give or a question they raise is a plain line `Note: …`, not a bullet. Update `Next step:`. A cut session
-   loses nothing.
+1. `agent.status` (`working`). **Resume**: offer the `ideation-*.md` of `.agentplugged/docs/ideas/` that still
+   have a `Next step:` line (read it whole, once) or a fresh start. **Read what exists**: brief, PRD, research
+   (`npx agentplugged docs research <subject>`), the hypotheses of `state.get`, the recent ideas notes.
+2. **One opening question**: what ideas on, why, anything to respect; skip it when the ask says it. **Stance**, once: `references/stances.md`. **Create the file
+   now** from `assets/session-template.md`, with only the question, the stance and `Next step:`; add each other
+   section when it has content.
+3. **Techniques** (3 or 4 a batch): `references/techniques.md`, read only the lines of the category you
+   draw from, never all of them.
+4. **Run**: one question per message, no list of choices while ideas flow. Switch technique after five to
+   ten exchanges; aim past fifty ideas. **Save at every batch** (about ten ideas, or a change of technique): append the ideas under
+   `### <technique>`, one bullet each as the creator said it, marked with who had it; a direction or a
+   question is a plain line `Note: …`, not a bullet. Update `Next step:`. A cut session loses nothing.
 5. **Converge** only when they are spent or ask to pick: `references/converge.md`. Never mix it with a
    batch that still produces.
-6. **Close**: their ideas back to them first, then the bridges they missed, then the gestures:
-   `references/close.md`. Delete `Next step:`, run `npx agentplugged docs check`, fix what it lists. Offer
-   the table (Noah opens it) on an idea that needs other minds, at any step.
+6. **Close**: `references/close.md`. Delete `Next step:`, run `npx agentplugged docs check`, fix what it
+   lists.
 7. `agent.status` (`idle`), hand back to Noah.
 
 ## Never

package/dist/method/skills/ideation/references/close.md

@@ -1,17 +1,21 @@
 # Closing the session
 
-1. **Their ideas back to them.** Under `## Mirror`, return a lively selection of the creator's own
-   ideas, copied as written (three at least, or all of them if fewer; the engine counts), taking the
-   strange, the stray and the forgotten ones from early in the session, not just the latest. Ask what
-   they notice: patterns, ties, the few that count. They draw the connections first; note what they
-   say in their words on lines starting `Noted:`, so a cut session keeps it.
-2. **Then the bridges they did not see.** Add lines beginning `Link:`: no fresh ideas, only unexpected
-   ties (this one answers that tension; these three are the same idea). In the `questions` stance this
-   is the single spot where your own thinking comes in, and it stays labelled as a link. What to do with
-   it is theirs to say.
+1. **Their ideas back to them.** Under `## Mirror`, a lively selection of the creator's own ideas,
+   copied as written (three at least, or all if fewer; the engine counts), the strange, the stray and
+   the forgotten ones too. Note what they notice on lines starting `Noted:`.
+2. **Then the bridges they did not see.** Lines beginning `Link:`: no fresh ideas, only unexpected
+   ties. In `questions` this is where your own thinking comes in, labelled as a link.
 3. **What stays.** Under `## Kept`, one bullet per idea they retain, in their words, ending with `→`
-   and the gesture they pick: `references/gestures.md`. If nothing stays, write one plain line saying so,
-   with no bullet: that is their choice too.
-4. **Wrap up.** Remove the `Next step:` line, run the docs check, fix what it reports. Offer once what
-   could follow: a new session on one kept idea, or the table (Noah opens it) when an idea needs other
-   minds; then hand back to Noah.
+   and the gesture they pick; if nothing stays, one plain line saying so.
+4. **Wrap up.** Remove `Next step:`, run the docs check, hand back to Noah.
+
+## Gestures
+
+Ask once, after the mirror, one gesture per kept idea. Never choose for them.
+- **hypothesis**: the idea rests on a bet to prove. Call and fields as in
+  `.agentplugged/skills/strategy/references/gestures.md`, "Hypothesis followed": one finding per bet,
+  its `passage` citing the `EF-n` or `AD-n` the idea touches (none yet: the id of the session file).
+- **story**: worth building. Hand it to Noah (requirement: Maya; story: Izzy). Write neither.
+- **decision**: a choice between two to four kept ideas only they can make: `checkpoint.open`,
+  `type: decision`, options, your recommendation, the session file in `documents`.
+- **nothing**: it stays in the file. **later**: not decided yet.

package/dist/method/skills/ideation/references/converge.md

@@ -1,24 +1,14 @@
 # Narrowing down
 
-Start only once the ideas stop coming, or when the creator asks to choose, rank or get concrete. Say
-aloud that the mode changes. Never during a technique that still yields, never inside a batch: an early
-verdict silences the next good idea. The stance carries over: in `questions` they decide and you rank
-nothing; in `exchange` your view is marked as yours; in `proposal` you may offer a first scoring.
+Only once the ideas stop coming or the creator asks to choose; say the mode changes.
+Never during a technique that still yields, never inside a batch. The stance carries over: in
+`questions` they decide and you rank nothing; in `exchange` your view is marked as yours; in
+`proposal` you may offer a first scoring.
 
-1. **Lay out what exists.** Every live candidate in the file, the strange and forgotten ones as
-   well as the latest; say how many.
-2. **Pick one tool for this goal and name it**, instead of offering a menu:
-   - Group by theme: lots of loose ideas. Cluster, label each cluster, say what links them.
-   - Impact and effort: the aim is to act. Plot each idea on both axes; start with big payoff for small
-     work, set the rest aside.
-   - New, useful, feasible: freshness matters. Score the three from 1 to 10; the totals expose the
-     underdogs and the brilliant impossibilities.
-   - Forced ranking: only a short podium is wanted. Pit ideas against each other, no ties; give points
-     to vote when several people decide.
-   - Plus, minus, interesting: one strong idea needs a stress test. List what it has going for it,
-     against it, and what is merely curious, then weigh.
-   - Must, should, could, not now: a build is being scoped. Put every idea in one of the four bins.
-3. **Take it through** and record it under `## Convergence`: one line `Move: <name>` per tool, then the
-   outcome. A second tool may follow the first (cluster, then score the clusters); a third is refused.
-4. **Stop** when a short list or one direction stands out. The creator says which ideas stay, in their
-   words; you carry the list to `## Kept` when closing (`references/close.md`).
+1. Lay out every live candidate, the strange and forgotten ones included; say how many.
+2. Pick one tool for this goal and name it, no menu: group by theme; impact and effort; new, useful,
+   feasible (1 to 10); forced ranking; plus, minus, interesting; must, should, could, not now.
+3. Record it under `## Convergence`: a line `Move: <name>` per tool, then the outcome. A second
+   tool may follow the first; a third is refused.
+4. Stop when a short list or one direction stands out. The creator says which ideas stay, in their
+   words; you carry them to `## Kept` (`references/close.md`).

package/dist/method/skills/ideation/references/stances.md

@@ -1,21 +1,17 @@
 # The stance
 
-Ask once, in a line, and write the answer after `Stance:`. It lasts the whole session. The creator can
-change it just by saying so: add a line `Stance: <new one>` in `## Ideas` at that point (ideas above keep
-their marks and the rule in force when they were written).
+Ask once, in a line, and write the answer after `Stance:`. The creator can change it: add a line `Stance: <new one>` in `## Ideas` at that point (earlier
+ideas keep their marks).
 
-- **questions** (`Stance: questions`). You bring no idea of your own: you question, provoke, set
-  constraints and read back, so the ideas all come from them. If they ask outright for one, offer a
-  single seed, marked `[lou]` (the engine allows one per technique), and let them carry on; a second
-  request means the technique is used up, so switch. Mark every other idea `[creator]`.
-- **exchange** (`Stance: exchange`). You join in, but they do most of the producing. Say at the start how
-  it works and that they steer: they can turn down any idea of yours and set how much you chip in. Answer
-  each of their ideas with a "yes, and" a step further, then challenge them to go beyond it. After one of
-  yours, turn back to them with a question. Watch the balance: if you have given more than they have
-  lately, ease off, with more questions and fewer ideas of yours. Mark each idea `[creator]` or `[lou]`.
-- **proposal** (`Stance: proposal`). You start with a first list per technique (ten ideas, each marked
-  `[lou]`); they react, reshape and add theirs (`[creator]`). If they say "you do it", run the whole
-  batch alone, aim past fifty, and show the file; then offer to continue together in exchange.
+- `Stance: questions`. You bring no idea of your own: you question, provoke, set constraints and
+  read back. If they ask outright for one, offer a single seed, marked `[lou]` (the engine allows
+  one per technique); a second request means the technique is used up, so switch. Mark every
+  other idea `[creator]`.
+- `Stance: exchange`. Say at the start how it works and that they steer: they can turn down any
+  idea of yours. "Yes, and" a step further, then challenge them to go beyond; after one of yours,
+  turn back to them with a question. If you have given more than they have lately, ease off. Mark
+  each idea `[creator]` or `[lou]`.
+- `Stance: proposal`. A first list per technique (ten ideas, each marked `[lou]`); they react and
+  add theirs (`[creator]`). "You do it": run the batch alone, then offer `exchange`.
 
-In every stance: write their idea word for word, never smoothed or merged into another; build on it
-before adding yours; a constraint is a prompt, not a wall.
+In every stance: write their idea word for word, never smoothed or merged; build on it before adding yours.

package/dist/method/skills/ideation/references/techniques.md

@@ -0,0 +1,20 @@
+# Techniques and how to choose
+
+A batch is 3 or 4 techniques. The creator picks how, once; do not list the library.
+**They name it:** run it as named. **Recommended:** from the goal and how stuck they are, say in one
+line each why it fits; techniques that worked in the recent notes of `ideas/` come first. **Drawn:**
+a blind pick, say it was drawn. **A chain:** gentle to hard (`together` or `frames`, `sparks`,
+`limits` or `futures`, last `deep`), order said. **Invented:** name and principle in a
+line, written under `### <name> (new)`. A batch run dry: ask in one line, more techniques, narrow down, or wrap up.
+
+Goal to category: cold start `together`, `sparks`; unclear problem `deep`, `frames`; too safe
+`limits`, `futures`; users unknown `people`; stuck in the trade's way `borrowed`, `sparks`.
+
+- `together` (`exchange`, `proposal`; in `questions` you set the rule): yes, and; silent writing; word relay; copy and twist; persuade the doubter; many voices; second wind.
+- `sparks`: what if; analogy; ground rules; forced pairing; name game; image swap; blend; senses.
+- `frames`: SCAMPER; six hats; eight sketches; how might we; job to be done; empathy map; mind map; starbursting; storyboard; cross grid.
+- `deep` (for a full diagnosis, the skill `strategy`): five whys; question storm; hidden rules; pre-mortem; provocation; zoom; contradiction hunt; grid of options.
+- `limits`: nothing to spend; unlimited means; single purpose; a tenth of the scope; no explanation; pushed to the limit; hostile setting.
+- `futures`: letter from ahead; backcasting; trend to the extreme; four worlds; ground moves; rules change.
+- `people`: day in the life; extreme users; stranger's eye; rival's seat; customer's letter.
+- `borrowed`: nature's answer; ecosystem; selection; swarm; ritual; craft.

package/dist/method/skills/improve-code/SKILL.md

@@ -7,68 +7,56 @@ metadata:
 ---
 # Improve code
 
-Improving code is a change that must prove it changed nothing the product shows. This skill takes
-a finding that someone already made, applies it on one axis and holds the proof of "unchanged" to
-the engine's commands, run before the first change and after the last, never to your word.
+## Overview
 
-Run it under your own id (`agent: <your id>`), in the creator's language, in the stack the
-architecture names.
-
-- **Input:** a story of `.agentplugged/stories/` that is yours and is born of a finding: an audit
-  (`audit-pillars`: a `story` finding), duplicated code the engine listed (`reuse`), a gap of the
-  tests (`review.tests` `propose`), or a review finding sorted `defer`. Its Context cites the
-  finding (`D-…`) and names the axis. No story: ask the creator to have Izzy write one from the
-  finding, never start without.
-- **The axis** (one per story; two findings of two axes are two stories): `cleanup` (names,
-  duplication, dead code, size, nesting), `performance`, `security`, `architecture` (the
-  boundaries the decisions `AD-n` set). The story does not name it: ask once.
-- **Output:** the improvement, committed on the story's branch in small steps, the engine's runs
-  before and after, and a result that moves the story to review. The review is the usual one,
-  independent: Quentin, and Chloé for the `security` axis.
-- **Annex** (`references/axes.md`): what each axis looks for, and what it must not do.
+- **Step:** build, as the story's developer (`agent: <your id>` in every MCP call), in the stack the
+  architecture names. An improvement must prove it changed nothing the product shows: the proof is
+  the engine's commands, run before the first change and after the last, never your word.
+- **Produces:** the improvement, committed in small steps on the story's branch, the engine's runs
+  before and after, and a result that moves the story to review (the usual independent review:
+  Quentin, and Chloé for `security`).
+- **Reads:** one story of `.agentplugged/stories/` that is yours, born of a finding: an audit
+  (`audit-pillars`, a `story` finding), duplicated code the engine listed (`reuse`), a gap of the
+  tests (`review.tests` `propose`), or a review finding sorted `defer`; its Context cites the finding
+  (`D-…`). The files it names are the whole scope. No story: ask the creator to have Izzy write one.
+- **Axis** (one per story): `cleanup`, `performance`, `security`, `architecture`; the story does not
+  name it: ask once. What each looks for and must not do: `references/axes.md`.
+- **Validation point:** none; review and merge follow.
 
 ## Steps
 
 1. **Start.** `agent.status` (`working`), `state.get` (`phase.current` must be `build`),
-   `story.start`, and work only in its `workdir`. Read the story and the finding it cites: the
-   files they name are the whole scope. Nothing beyond it is touched.
-2. **Find the commands.** The project's declared commands (`.agentplugged/proofs.yaml`, accepted by
-   the creator): tests, linter, type check, build, and for `performance` a measure with a budget.
-   The engine runs only a command that `proves` a requirement of the register. None declared, or
-   none that covers the scope: the guide `engine-proofs.md` of `check-requirements` says how to
-   declare them and ask the creator once; do not go on without at least one.
-3. **Before: the baseline.** `measure.run` for each command that covers the scope. They must pass.
-   One that fails is not an improvement but a bug, and its failed proof is a gap the creator will
-   settle: stop, tell them, and go to `diagnose-bug`. Note the commit you stand at
-   (`git rev-parse --short HEAD`); the engine inscribes the real one with each run.
-4. **Pin what is not pinned.** Where the scope has no test of what you will touch, write the tests
-   of its behaviour as it is seen from outside (never from the code you are about to change),
-   commit them alone, then run step 3 again. These tests are the proof and are in the scope.
-5. **Change, small step by small step.** One kind of change per commit, in the axis (`axes.md`),
-   with a message `refactor(<story>): …` (`perf(<story>): …` for performance, `fix(<story>): …` for
-   security) citing the requirement. After each step run the tests again; a red step is undone, not
-   patched. The public inputs and outputs (exports, routes, messages, file formats) stay as they
-   are: one that must change is a `decision` checkpoint, not yours to settle.
-6. **After.** On the last commit, clean (`git status`), `measure.run` of the same commands: the same
-   pass as the baseline, all of them. A performance gain is the project's measure run before and
-   after (the budget held both times, the engine's verdict), the two numbers read in each run's
-   `log` and quoted as they are, never an estimate. Put both commits and the lines the engine returned in
-   `story.progress`. A criterion of the story that no test can show red ("the behaviour is the
-   same") is declared untestable (`story.criterion`, `seen: untestable`) with those two commits as
-   the reason: the review reads them.
-7. **Security only:** behaviour may change on purpose. Say each change and why in `story.progress`,
-   and write the test that fails on the old code (`story.criterion`: the engine saw it red, then
-   green); a security change with no such test is not done.
-8. **What you saw outside the scope** goes to deferred work (`plan.defer`), never into this change.
-9. **Verify, then hand over** as `develop-story` does (steps 7 to 9, `self-check.md`): the whole
-   verification, a clean tree, `story.result` whose summary says the axis, the before and the after
-   in two lines, then `agent.status` (`idle`) and `npx agentplugged next --json`.
+   `story.start`; work only in its `workdir`.
+2. **Commands.** The project's declared commands (`.agentplugged/proofs.yaml`, accepted by the
+   creator): tests, linter, type check, build, and for `performance` a measure with a budget. The
+   engine runs only a command that `proves` a requirement of the register. None covers the scope:
+   `check-requirements/references/engine-proofs.md` says how to declare them and ask the creator
+   once; do not go on without one.
+3. **Before: the baseline.** `measure.run` for each command covering the scope; they must pass. One
+   that fails is a bug, not an improvement: stop, tell the creator, go to `diagnose-bug`.
+4. **Pin.** Where the scope has no test of what you will touch, write tests of its behaviour seen
+   from outside (never from the code you will change), commit them alone, redo step 3.
+5. **Change, small steps.** One kind of change per commit, within the axis, message
+   `refactor(<story>): …` (`perf`, `fix` for security) citing the requirement. Tests after each step;
+   a red step is undone, not patched. Public inputs and outputs (exports, routes, messages, file
+   formats) stay: one that must change is a `decision` checkpoint.
+6. **After.** On the last commit, clean tree, `measure.run` of the same commands: the same pass as
+   the baseline. A performance gain is the measure run before and after, the two numbers quoted
+   from each run's `log`, never an estimate. Both commits and the engine's lines go in
+   `story.progress`. A criterion no test can show red ("the behaviour is the same") is declared
+   `story.criterion` `seen: untestable`, those two commits as the reason.
+7. **Security only:** behaviour may change on purpose. Say each change in `story.progress` and write
+   the test that fails on the old code (`story.criterion`: red, then green); without it, not done.
+8. **Outside the scope** goes to `plan.defer`, never into this change.
+9. **Verify and hand over** as `develop-story` does (steps 6 and 7): `story.result` whose summary
+   says the axis and the before and after in two lines, `agent.status` `idle`,
+   `npx agentplugged next --json`.
 
 ## 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 say that behaviour is unchanged on your word: the engine ran the commands, or it is not said.
-- Never mix two axes, add a feature, a dependency or a test for something else, in the same story.
+- Never say behaviour is unchanged on your word: the engine ran the commands, or it is not said.
+- Never mix two axes, nor add a feature, a dependency or a test for something else.
 - Never change a public interface, nor edit a test to make a step pass.
-- Never edit the story's intent, never push or merge, never review your own work.
+- Never edit the story's intent, push, merge or review your own work.
 - Never call, direct or wait for another agent: hand back to Noah.

package/dist/method/skills/pitch/SKILL.md

@@ -1,32 +1,29 @@
 ---
 name: pitch
-description: Design thinking, product story or deck with speaker notes, from the product's documents. Julien runs story and deck, Stella design thinking.
+description: Design thinking, product story or deck with speaker notes from the product's documents. Julien runs story and deck, Stella design thinking.
 metadata:
   agent: julien
   phase: launch
 ---
 # Pitch
 
-On the creator's ask, or when they talk of convincing, pitching or presenting. Three modes, they pick one.
-Run under your own id (`agent: stella` for design thinking, `agent: julien` for the others), in their
+On the creator's ask, or when they talk of convincing, pitching or presenting. Three modes, they pick one. Run under your own id (`agent: stella` for design thinking, `agent: julien` for the others), in their
 language. Write only the mode's file.
 
-1. `agent.status` (`working`). **Read what exists**: brief, PRD, `ux.md`, `prfaq.md`, `launch/positioning.md`,
-   `research/`, and `launch/narrative.md` when validated. Say in two lines what you found; ask only for what is
-   missing, one question at a time. Each claim keeps its source (`EF-n`, section); the documents go in `links`.
-   Mention `EF-n` inside a line, never at the start of a line, a list item, a heading or a first table cell.
-2. **Guide, step by step.** Questions before writing; the creator's words and voice first. After each step (a
-   section, a stage) show it and offer one line: continue, go deeper, challenge (push back once), go
-   back, or stop here. Then save the file with `<!-- resume: next step -->` under the title (removed before the checkpoint); found later, offer to
-   pick up there. Before a long step, ask their energy. To draft, ask once: they write, you draft, or together.
-3. **Design thinking** (Stella): `references/design-thinking.md`, the exercises in `references/design-methods.md`
-   (three to five per step), the last step in `references/design-implementation.md`, `assets/design-template.md`,
-   to `.agentplugged/docs/launch/design/<slug>.md`.
-4. **Story** (Julien): `references/story.md`, the structure in `references/story-frameworks.md` (recommend
-   one, say why), `assets/narrative-template.md`, to `.agentplugged/docs/launch/narrative.md`. Offer two openings.
-5. **Deck** (Julien): `references/deck.md`, the kind of talk in `references/deck-types.md`,
-   `assets/deck-template.md`, to `.agentplugged/docs/launch/deck.md`, from the narrative; without one, offer the
-   story first. `npx agentplugged docs slides` then draws it (`deck.html`).
+1. `agent.status` (`working`). **Read what exists**: brief, PRD and `ux.md` by section (`docs read`), `prfaq.md`, `launch/positioning.md`,
+   `research/`, and `launch/narrative.md` when validated; ask only for what is missing. Each claim keeps
+   its source (`EF-n`, section); the documents go in `links`. Mention `EF-n` inside a line, never at the
+   start of a line, list item, heading or first table cell.
+2. **Guide, step by step.** Questions before writing; the creator's words first. After each step show it
+   and offer: continue, go deeper, challenge (push back once), go back, or stop here. Then save the file
+   with `<!-- resume: next step -->` under the title (removed before the checkpoint); found later, offer
+   to pick up there.
+3. **Design thinking** (Stella): `references/design.md`, then `references/design-implementation.md`,
+   `assets/design-template.md`, to `.agentplugged/docs/launch/design/<slug>.md`.
+4. **Story** (Julien): `references/story.md`, `assets/narrative-template.md`, to
+   `.agentplugged/docs/launch/narrative.md`.
+5. **Deck** (Julien): `references/deck.md`, `assets/deck-template.md`, to `.agentplugged/docs/launch/deck.md`,
+   from the narrative; without one, offer the story first. `npx agentplugged docs slides` then draws it (`deck.html`).
 6. A figure carries its source on its line, or `[to verify]`: never invented. `npx agentplugged docs check`, fix
    what it lists. Commit, then one checkpoint (`type: publication`, `document` for Stella; low risk, no story,
    no blocks) citing the file with its `branch` and `blob_sha`; ask once.