agentplugged 1.3.0 → 1.4.0

package/dist/method/skills/setup-ci/SKILL.md

@@ -1,121 +1,57 @@
 ---
 name: setup-ci
-description: Set up the product's base CI (lint, tests, build, audit) for its forge, never over an existing one, for the creator to merge. Run by Omar.
+description: Set up the product's base CI (lint, tests, build, audit) for its forge, never over an existing one; the creator merges it. Run by Omar.
 metadata:
   agent: omar
   phase: build
 ---
 # Set up the CI
 
-> **The creator's Git workflow, not the method's.** Read `git` in `state.next` or `state.get` before you act: the branch a story lands on is `git.branches.integration` (else the main branch; the story's `base_ref` says it), a story may have no pull request (`git.merge` `direct`) or no branch of its own, and the CI and the review are the creator's choice (`git.ci` `none`, `git.review` false). Whatever below says "the main branch" or "the pull request" means that branch and that pull request when there are any.
-
-The CI is what lets the creator see only green pull requests. Each check it runs is one name the
-engine reads back (`story ci`, `story.ci`): a failed check sends the story to its developer, who
-fixes it on the same branch. This skill writes that CI once, from the method's templates, and
-leaves it to the product: the engine never writes it again.
-
-This skill belongs to Omar. Run it as Omar, with `agent: omar` in every MCP call. Work in the
-creator's language; keep commands, file names and check names as they are.
-
-- **Inputs:** the product's `package.json` and lock file, `.nvmrc` when there is one, the
-  architecture and the test strategy (`.agentplugged/docs/`), the runbook when it exists.
-- **Output:** `.github/workflows/ci.yml` (GitHub) or `.gitlab-ci.yml` (GitLab), delivered in a
-  branch of its own, pushed for the creator to open and merge, and its description in the runbook.
-- The CI comes before the first story of the build: `state.next` proposes this skill then
-  (`setup_ci`), even though Omar's own phase is the delivery.
-
-Follow the steps in order. Each one ends with what it must have produced.
-
-## Step 1 — Check where the product stands
-
-1. Call `agent.status` (`working`, task "CI setup").
-2. Call `state.get`: `phase.current` should be `build` (or null when the profile has no phases).
-   In an earlier phase, say which phase is current and stop.
-3. Look for an existing CI: `.github/workflows/*.yml`, `.gitlab-ci.yml`, or another system's file
-   at the repository's top (`.circleci/`, `azure-pipelines.yml`, `Jenkinsfile`…). When one
-   exists, never replace it: compare it with the four checks below, propose what is missing to
-   the creator, and go to Step 4. `npx agentplugged ci setup` lists, as `Not checked by the CI`, the
-   test scripts (`test:api`, `test:integration`, `test:e2e`) the CI does not run: add them to the
-   `test` job (skill `api-e2e-tests`, reference `ci`).
-
-**Produces:** the phase confirmed, and whether a CI already exists.
-
-## Step 2 — Generate the workflow
-
-1. Run `npx agentplugged ci setup` at the repository's top. The forge is `ci.forge` in
-   `.agentplugged/method.yaml` when set, else the `origin` remote's host (`github.com`,
-   `gitlab.com`, or a host starting with `github.` or `gitlab.`). When neither says it (a forge
-   hosted under another name), ask the creator which one, then run
-   `npx agentplugged ci setup --forge github` (or `--forge gitlab`), and propose to set
-   `ci: { forge: … }` in `method.yaml` so that reading the CI finds it too.
-2. Read what it says: the file written, the stack it recognised (pnpm, npm, yarn, or other), and
-   every `TODO` left. It writes nothing when a CI exists (`exists`).
-
-The workflow has four jobs, one check each, named `lint`, `test`, `build` and `audit`. Each one
-installs the dependencies as locked and runs the product's own script (`lint`, then `typecheck`
-when it exists; `test`, then `test:api`, `test:integration` and `test:e2e` when it has them; `build`), or the package manager's audit of high-severity advisories.
-
-**Produces:** the workflow file, and the list of TODOs.
-
-## Step 3 — Complete what the template could not guess
-
-1. Read the file whole. Each `TODO` comment is followed by a step that fails on purpose: replace
-   both with the real command — the script the product lacks, or the toolchain of a stack the
-   template does not know (from the architecture: language, version, package manager).
-2. Keep one job per check and keep their names: the engine reports failed checks by name.
-3. Never weaken a check to make it pass: no `continue-on-error`, no `allow_failure`, no
-   `|| true`, no skipped test. A check that cannot pass yet is a `decision` checkpoint for the
-   creator, never a silent green.
-4. Refer to secrets by name only (`${{ secrets.NAME }}`, `$NAME`), never by value. The base CI
-   needs none.
-
-**Produces:** a workflow without a `TODO`, each check meaningful.
-
-## Step 4 — Deliver it
-
-1. Create a branch of its own (`ci/base-workflows`), commit the workflow there and push that
-   branch by its name (`git push origin ci/base-workflows`: never the main branch, never
-   forced). Never run `gh` or `glab` yourself: no pull request by hand, no CI or repository
-   setting (the engine delivers it). The creator types no command either:
-   the engine delivers it once they approve.
-   - When the product has no remote repository yet (no `origin`), ask the creator for it first
-     (`guard.creator_action`, `forge_repo_create` {forge, name}: private by default), then,
-     for the main branch that was never pushed, `forge_push_main` {}. Each is a request the
-     creator approves in the chat, confirming the action ("yes, create the private repository
-     shop on GitHub"); the engine does it with the forge's tool they connected.
-   - Then ask for the merge: `guard.creator_action`, `forge_merge_ci` {branch:
-     `ci/base-workflows`}. The engine opens the pull request (its title and text are fixed)
-     when there is none, and merges it on the commit the creator saw, if only the CI's files and
-     the product's documentation changed in the branch and the branch is at the remote exactly as
-     it was read. Present the request as it asks: the repository, the branch and the commit it
-     names; never merge anything yourself.
-2. Describe the pipeline in `.agentplugged/docs/runbook.md` (create it with its YAML header when
-   it does not exist: `id`, `kind: note`, `owner: omar`, `links`): each check, what it proves,
-   and what to do when it fails. Run `npx agentplugged docs check` and fix what it reports.
-
-**Produces:** the branch of the CI, pushed, and the runbook updated.
-
-## Step 5 — Report
-
-1. Call `story.result`: `complete`, a summary naming the workflow, its checks and the
-   branch, your assumptions (a script you inferred, a version you chose), the open questions and
-   the conflicts. `partial` when a TODO is left, saying which.
-2. Call `agent.status` (`idle`).
-3. Tell the creator what the engine did once they approved the merge (`executed` in the
-   result): from then on, every story's pull request runs these checks, and a failed one goes
-   back to its developer. When a request answers `FORGE_GESTURE_FAILED`, say what it says
-   (the forge's tool not logged in, a branch not pushed, a remote ahead of the main branch…):
-   the creator fixes it, you ask again.
-   Then hand back to Noah, who proposes what comes next; the creator decides (without Noah, the
-   creator picks the next agent).
+> **The creator's Git workflow, not the method's.** Read `git` in `state.next` or `state.get`: stories land on `git.branches.integration` (else the main branch), may have no pull request (`git.merge` `direct`), and the CI is the creator's choice (`git.ci` `none`). "The main branch" and "the pull request" below mean those.
+
+## Overview
+
+- **Step:** before the first story of the build (`state.next` proposes it, `setup_ci`), as Omar
+  (`agent: omar` in every MCP call). A failed check (`story.ci`) sends the story to its developer.
+- **Produces:** `.github/workflows/ci.yml` or `.gitlab-ci.yml` from the templates in `assets/`, in a
+  branch of its own for the creator to merge; its description in `.agentplugged/docs/runbook.md`.
+- **Reads:** `package.json`, the lock file, `.nvmrc`.
+- **Validation point:** the creator action `forge_merge_ci` (step 4).
+
+## Steps
+
+1. **Start.** `agent.status` (`working`). `state.get`: `phase.current` should be `build` (or null);
+   earlier: stop. An existing CI (`.github/workflows/`, `.gitlab-ci.yml`,
+   `.circleci/`, `azure-pipelines.yml`, `Jenkinsfile`…) is never replaced: compare it with the four
+   checks, propose what is missing, go to step 4. `npx agentplugged ci setup` lists as `Not checked
+   by the CI` the test scripts (`test:api`, `test:integration`, `test:e2e`) it skips: add them to
+   the `test` job (skill `api-e2e-tests`, reference `ci`).
+2. **Generate.** `npx agentplugged ci setup`. Forge: `ci.forge` in `.agentplugged/method.yaml`, else
+   the `origin` host; if neither says it, ask, run `--forge github|gitlab`, propose setting
+   `ci: { forge: … }`. Read every `TODO`. Four jobs named `lint`, `test`,
+   `build`, `audit`, running the product's own scripts and the package manager's audit.
+3. **Complete.** Replace each `TODO` and the step that fails on purpose after it with the real
+   command. Keep one job per check, with its name. Never weaken a check (`continue-on-error`,
+   `allow_failure`, `|| true`, a skipped test): one that cannot pass yet is a `decision`
+   checkpoint, never a silent green. Secrets by name only (`${{ secrets.NAME }}`).
+4. **Deliver.** Branch `ci/base-workflows`, commit, `git push origin ci/base-workflows` (never the
+   main branch, never forced). Never `gh` or `glab`, no pull request by hand: the engine delivers
+   once the creator approves in the chat; they type no command.
+   - No `origin`: `guard.creator_action` `forge_repo_create` {forge, name} (private by default),
+     then `forge_push_main` {}.
+   - Then `forge_merge_ci` {branch: `ci/base-workflows`}: the engine opens the pull request and
+     merges it on the commit the creator saw, if only CI files and documentation changed. Present
+     the repository, branch and commit it names.
+   - Runbook: each check, what it proves, what to do when it fails (header `id`, `kind: note`,
+     `owner: omar`, `links`); `npx agentplugged docs check`.
+5. **Report.** `story.result` `complete` (workflow, checks, branch, assumptions; `partial` with a
+   `TODO` left); `agent.status` `idle`. Tell the creator what the engine did (`executed`); on
+   `FORGE_GESTURE_FAILED` say what it says, they fix it, you ask again. Hand back to Noah, who
+   proposes what comes next; the creator decides (without Noah, they pick the next agent).
 
 ## 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 write over an existing CI, and never edit a CI file the creator wrote without a pull
-  request.
-- Never merge, never push to the main branch, never deploy: the repository, the first push of
-  the main branch and the CI's merge are requests the engine carries out for the creator, never
-  commands you run nor ones the creator types.
-- Never weaken, skip or re-run a check to turn it green.
-- Never put a secret's value in the repository.
+- Never write over an existing CI, nor edit a CI file the creator wrote without a pull request.
+- Never merge, never push to the main branch, never deploy: the repository, the first push and the merge are requests the engine carries out.
+- Never weaken, skip or re-run a check to turn it green; never put a secret's value in the repository.

package/dist/method/skills/split-into-stories/SKILL.md

@@ -7,199 +7,66 @@ metadata:
 ---
 # Split into stories
 
-This skill takes the approved plan of the product and turns it into work that a developer agent
-can pick up, finish and hand over for review with nothing but the story in hand. It writes the
-epics in `.agentplugged/epics/` and the stories in `.agentplugged/stories/`, proves with
-`npx agentplugged docs check` that the breakdown holds, and ends with a checkpoint the creator
-answers. It never plans a sprint: that is a separate step.
+## Overview
 
-Work through the steps in order. Do not jump ahead: each step relies on what the previous one
-settled with the creator.
+- **Step:** build, as Izzy (`agent: izzy` in every MCP call); no sprint planning.
+- **Produces:** `.agentplugged/epics/epic-<n>.md` from `assets/epic.md.tmpl` and
+  `.agentplugged/stories/<n>-<s>.md` from `assets/story.md.tmpl`.
+- **Reads:** by section (`reading: true`, `docs read @requirements @journeys
+  @decisions @screens`), never whole. Short path
+  (`full_path` in `journey.skipped`): `spec.md` alone stands for all three, its Stories part is
+  the first draft. A prototype without PRD: 3 to 6 stories, one per page, citing the prototype's
+  sections instead of requirements.
+- **Validation point:** a `document` checkpoint per epic (step 6), one stack.
 
-## Rules that hold throughout
+## Rules
 
 - 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`.
-- Write only in `.agentplugged/epics/` and `.agentplugged/stories/`. The PRD, the architecture and
-  the UX specification are read, never edited: a gap in them goes back to their owner (Maya, Alex,
-  Stella) through the creator.
-- Identifiers: an epic is `epic-<n>`, a story `<n>-<s>` (`2-6` is the sixth story of epic 2), the
-  same id the journal uses. Story numbers follow the delivery order inside the epic, and epics
-  follow each other in the order they can be built. Never renumber an id once the creator has
-  seen it: add a new one, or mark the old one `(retired)` in its title.
-- The order of the ids is the order of the work: `1-9` before `1-10` before `2-1`. A story may
-  depend only on stories that come before it in that order. `docs check` refuses anything else.
-- Report through the `agentplugged` MCP server: `agent.status` (`working`) when you start,
-  `checkpoint.open` at the end, `story.result` with your assumptions and open questions, then
-  `agent.status` (`idle` or `waiting`).
-
-## The short path: a prototype to carry over
-
-When the creator gave a complete prototype and chose the short path (no PRD, a light
-architecture), cut it into a few stories, not a long list: one story per page or per group of
-screens, each one naming the sections of the prototype to reproduce, the check that the rendering
-matches (on a computer and on a phone, in each language the prototype has), and what stays as it
-already is. Three to six stories usually carry a whole site. A story's budget is read in
-`state.get` `usage.estimates` (the product's measured stories, else the method's reference), never a
-figure guessed. Where `docs check`
-asks for requirement identifiers the short path does not have, say it once to the creator and
-cite the prototype's sections instead: never write requirements nobody asked for just to
-satisfy it. The full breakdown stays possible if the creator prefers it.
-
-## The short path: one spec
-
-When `journey.skipped` holds `full_path`, `spec.md` stands for the PRD, the architecture and the
-UX specification: read it whole instead of Step 1's documents, with the creator's approval of the
-spec as the only gate (no closed phases to check). Its Stories part is your first draft of the
-epics and stories; refine it with the creator and write them from the same templates.
-
-## Step 1: check that the plan can be cut
-
-1. Read `.agentplugged/docs/prd.md`, `architecture.md` and `ux.md` in full (skip `ux.md` only
-   when the profile has no UX domain).
-2. With `state.get`, check that the planning and design phases are closed (`phase.phases`): their
-   `phase_end` checkpoints resolved `approved` (`state.get { checkpoints: { type: "phase_end", status: "resolved" } }`). A draft is not an input. If one is missing, say which and who
-   owns it, and stop.
-3. Check that the requirements carry stable identifiers (`EF-n`, `ENF-n`) and are testable, that
-   the architecture answers what stories will need (stack, data, interfaces, decisions `AD-n`),
-   and that the key flows of the UX specification are described. List each gap with its owner.
-   Small gaps can be noted as assumptions; a gap that changes what gets built goes to the creator
-   before you cut anything.
-4. Check that the developers the plan needs are at work. Read `profile.specialties` in
-   `.agentplugged/method.yaml` and compare it with the platforms the architecture and the PRD decide (a mobile
-   app needs `mobile`, a website or a web app `frontend`, a service or an API `backend`). When a
-   specialty is off, say it before you cut anything: you do not name an inactive developer as a
-   story's owner (the engine refuses a sprint that does), and you do not give the work to another
-   specialty to get around it. Hand back to Noah, who asks the creator to turn it on
-   (`guard.creator_action`, `profile` or `agent_enable`); cut the plan once it is on, or, if the
-   creator prefers, with the story owned by `creator`.
-
-## Step 2: take the inventory
-
-Build, for yourself, the full list of what the breakdown must carry:
-
-- every active `EF-n` and `ENF-n` of the PRD, with a short label (a requirement marked
-  `(retired)` is out);
-- the architecture decisions (`AD-n`) that shape the work: a starter or template to set up first,
-  the data model, the interfaces between parts, the infrastructure;
-- the UX elements: flows, screens with their sketches, responsive rules, and each `UX-n` of the
-  table "Elements to build" of `ux.md` (components, states, accessibility fixes), none dropped.
-
-Show the inventory to the creator in a compact form, and ask whether anything is missing or
-should be left out on purpose.
-
-## Step 3: design the epics
-
-1. Group the requirements into epics by user value: each epic lets a user do something they could
-   not do before. Never cut by technical layer ("database", "API", "front end"): such an epic
-   delivers nothing a user can see.
-2. Order the epics so that each one works on top of the previous ones alone, never waiting on a
-   later epic. When the architecture names a starter or template, the first story of the first
-   epic sets it up.
-3. Map every active `EF-n` and `ENF-n` to an epic. A requirement the creator decides to leave out
-   of this breakdown goes into the `out_of_scope` list of the epic it would belong to, so that the
-   choice is written down rather than forgotten.
-4. Present the list: for each epic, its title, the user value in one sentence and the requirements
-   it covers. Refine it with the creator until they agree.
-5. Write one file per epic from `assets/epic.md.tmpl`: copy the template, keep its header keys,
-   replace every value and every `<…>` placeholder (`docs check` refuses one left behind). In
-   `links`, name only documents that exist: drop `ux` when the profile has no UX domain. Mention a requirement in backticks (`` `EF-1` ``),
-   never as `EF-1 : …` at the start of a line: that would define it a second time, next to the
-   PRD's definition, and `docs check` refuses it.
-
-## Step 4: write the stories, one epic at a time
-
-For each epic, in order, propose its stories to the creator, then write one file per story from
-`assets/story.md.tmpl`, replacing every `<…>` placeholder and keeping in `links` only documents
-that exist (no `ux` without a UX domain). Each story:
-
-- is small enough for one developer agent to finish and one reviewer to check, ideally in a day of
-  agent work; split anything larger;
-- delivers something observable: a user can do it, or a later story can build on it;
-- creates or changes only the data, files and interfaces it needs now, never "everything the next
-  epics will use";
-- carries the full header: `id`, `kind: story`, `owner` (the developer who will build it: an active
-  developer of the specialty the story concerns, for example `sam` or `ethan` for the server and
-  the data, `hugo` or `lina` for the interface, `jade` for the mobile applications; a small change
-  goes to that same developer, who builds it in the quick lane), `links` (the documents it builds
-  on), `title`, `epic` (`epic-<n>`, the epic of its id), `reviewer` (`quentin` for QA, or
-  `creator` without a quality
-  agent), `requirements` (the `EF-n`, `ENF-n`, `AD-n` it implements: at least one), `budget_usd`
-  (the story's estimate in US dollars at the API's public prices, above zero: the `expected` of
-  its lane in `state.get` `usage.estimates`, `standard` or `fast` for a small change, never a figure
-  of your own; `plan.sprint` refuses a budget three times off that range), `branch` (`feat/<id>-<slug>`) and
-  `depends_on` (earlier stories only). Never a status, a progress or a cost spent: the journal
-  holds those;
-- has the four sections, as level 2 headings:
-  - `## Context`: everything the developer needs, by identifier: requirements, architecture
-    decisions, screens, flows and the `UX-n` it builds, and the page of its screen in
-    `ux-mockups/` if one is drawn (opened for visual detail only). Cite; do not paste whole
-    documents;
-  - `## Intent`: why the story exists and what it must achieve, in a few plain sentences. Once the
-    creator approves the breakdown, this section belongs to the creator;
-  - `## Acceptance criteria`: testable criteria, one per line, in "given, when, then" form,
-    covering the error cases and edges, not only the happy path. A story that builds a screen
-    takes that screen's sketch in `ux.md` as a criterion, by region number;
-  - `## Out of scope`: what the story does not do, and which story does it, by id.
-
-Write each story as if its developer will read nothing else. If a criterion only makes sense with
-another story in hand, the cut is wrong: move the boundary.
-
-## Step 5: check the breakdown
-
-1. Run `npx agentplugged docs check` and fix everything it reports. Beyond the headers and the
-   identifiers, it checks the breakdown:
-   - `REQ_NOT_COVERED`: an active `EF-n` or `ENF-n` of the PRD is in no story's `requirements`
-     and in no epic's `out_of_scope`;
-   - `STORY_DEPENDENCY_FORWARD`: a story depends on a later one. Reorder the stories, or split
-     the earlier one;
-   - `STORY_DEPENDENCY_CYCLE`: stories depend on each other in a loop, or a story on itself;
-   - `STORY_SECTION_INVALID`: one of the four sections is missing, empty or given twice;
-   - `LAUNCH_DOCUMENT_INVALID` with reason `ux_element_uncovered`: a `UX-n` of `ux.md` is named in
-     the Context or criteria of no story;
-   - `DOC_PLACEHOLDER_LEFT`: a `<…>` marker of a template is still in a title or a section;
-   - `DOC_HEADER_INVALID` and `DOC_LINK_DANGLING`: a field outside the contract, an epic, story or
-     requirement that does not exist.
-2. Then review what the command cannot see:
-   - every story traces to at least one requirement, and its acceptance criteria actually cover
-     the requirements it lists;
-   - no story text refers to work that a later story does;
-   - each epic works with the earlier epics only;
-   - the budgets are plausible next to each other and read from `usage.estimates`. Tell the
-     creator what they rest on (`basis`: `history`, the product's own measured stories, or
-     `reference`, the method's prudent range because none is measured yet), always as a range
-     (`low` to `high`), and the product's total as the sum of its stories, never a global figure.
-     Never write an amount without that basis: an estimate without a base is not given.
-3. Draw the dependency graph in each epic file (the `## Dependency graph` section of the
-   template): one line per story with what it depends on, earlier stories only.
-
-## Step 6: ask the creator to validate
-
-1. Commit the epics and stories on your working branch, so that Git holds the exact files the
-   creator will approve.
-2. For each epic, open a checkpoint with `checkpoint.open`: `type: document`, `risk: medium`, no
-   story and no blocks, a title naming the epic, a summary with the user value, the stories in
-   order, the dependency graph, the requirements covered and those left out of scope, and your
-   open questions. In `documents`, list the epic file and each of its story files, each with the
-   branch and its Git blob (`git rev-parse HEAD:<path>`): at most 20 documents per checkpoint, so
-   split a larger epic's stories over two checkpoints.
-3. Only once the checkpoints are open, ask the creator whether the breakdown suits them, once.
-   Several epics are one stack, never one question each: call `chat.stack_open` with the epics'
-   checkpoints (2 to 16; a larger breakdown goes in several stacks), then `chat.stack_ask` when
-   `validation.channels.available` holds more than `chat`. Otherwise (`answered: false` with
-   `channel: "chat"`, or nothing to click) present the epics
-   numbered, each with its title and a short summary, and record the creator's one message with
-   `chat.stack_answer` ("j'approuve tout", "j'approuve 1, 2 et 4": constitution, "Stacks to
-   validate"). A single epic, or one the stack refused, is answered with `chat.answer`
-   (constitution, "Checkpoints in the chat").
-4. End with `story.result` (`complete`), your assumptions and open questions, then
-   `agent.status`, and hand back to Noah, who proposes what comes next; the creator decides
-   (without Noah, the creator picks the next agent).
-
-When the creator approves a checkpoint, the intent of each story it lists is frozen: `docs check`
-fails as soon as that section differs from the approved version. From then on, never edit an
-intent. When the creator wants to change one, they edit it themselves, or ask you to propose the
-new wording; either way, the change counts only once a new `document` checkpoint listing the story
-at its new blob is approved. Other sections may still be refined: say what changed in your result.
-The creator's `review` card shows, for each story listed, the first lines of the intent it would
-freeze and whether it replaces one already frozen; list the story files by their path under
-`.agentplugged/stories/`, or the card and `docs check` cannot recognise them.
+- Write only in `.agentplugged/epics/` and `.agentplugged/stories/`; a gap in the PRD,
+  architecture or UX goes back to its owner through the creator.
+- Ids: `epic-<n>`, story `<n>-<s>`, in delivery order; a story depends only on earlier ones. Never
+  renumber an id the creator has seen: add one, or mark the old `(retired)` in its title.
+
+## Steps
+
+1. **Check that the plan can be cut.** `agent.status` (`working`). Planning and design closed:
+   their `phase_end` checkpoints resolved `approved` (`state.get`); a draft is not an input; else say which and who owns it, and stop. A gap that changes the build goes to the
+   creator. A needed specialty off in `profile.specialties` is said before you cut; never name an
+   inactive developer as owner: Noah asks the creator to turn it on, or `creator` owns the story.
+2. **Inventory.** Every active `EF-n`, `ENF-n`, the shaping `AD-n`, each `UX-n` of "Elements to
+   build", none dropped.
+3. **Epics.** By user value, never by technical layer; each builds on the earlier ones only; the
+   architecture's starter comes first. Every active requirement is in an
+   epic, or in its `out_of_scope`. Write each from the template (replace every `<…>`; `links`
+   only to existing documents). Mention a requirement in backticks
+   (`` `EF-1` ``), never as `EF-1 : …` at a line's start (it would define it twice).
+4. **Stories**, one epic at a time, from the template, small and observable: each is the
+   developer's only reading (the sheet). Header: `owner` an active developer of the specialty,
+   `reviewer` `quentin` (or `creator` without a quality agent), `requirements` at least one `EF-n`,
+   `ENF-n` or `AD-n`, `budget_usd` the `expected` of its lane in `state.get` `usage.estimates`
+   (`standard`, or `fast`), never your own figure (`plan.sprint` refuses three times off). Sections:
+   `## Context` (requirements, `AD-n`, `UX-n` by identifier, a section without one as
+   `` `prd.md#glossary` ``, dependencies: cite, paste nothing); `## Intent` (why, plain);
+   `## Acceptance criteria` ("given, when, then", edges included; a story that builds a screen
+   takes that screen's sketch in `ux.md` as a criterion, by region number); `## Screen` (its page
+   in `ux-mockups/`, its sketch as `` `ux.md#<anchor>` ``); `## Tests expected`; `## Reuse` (from
+   `reference/reusable.md`); `## Out of scope` (and which story does it). Then `npx agentplugged
+   docs sheet`: the engine quotes each cited passage in `## Excerpts` with its fingerprint (never
+   edit it). Over 300 lines (`STORY_SHEET_TOO_LONG`): cut the story.
+5. **Review gate.** `npx agentplugged docs check` until clean (among others `REQ_NOT_COVERED`,
+   `STORY_DEPENDENCY_FORWARD`, and `LAUNCH_DOCUMENT_INVALID` with reason `ux_element_uncovered`: a
+   `UX-n` in no story). Then: criteria cover the listed requirements; no story speaks of a
+   later one's work. Tell the creator the budgets' `basis` (`history`, or `reference` when none is
+   measured) as a range (`low` to `high`), the total their sum; never an amount without a basis. Draw each epic's `## Dependency graph`.
+6. **Ask.** Commit. For each epic, `checkpoint.open`: `type: document`,
+   `risk: medium`, no story, no blocks, a summary (value, stories, graph, coverage, questions), and in `documents` the epic file and each story file by
+   path under `.agentplugged/stories/`, with the branch and `git rev-parse HEAD:<path>` (20 at most
+   per checkpoint). Only once the checkpoints are open, ask the creator whether the breakdown suits
+   them, once. Several epics are one stack (constitution, "Stacks to validate"); one epic:
+   `chat.answer`.
+7. **Report.** `story.result` (`complete`), assumptions, questions; `agent.status`; hand back to
+   Noah, who proposes what comes next; the creator decides.
+
+Once approved, a story's intent is frozen (`docs check` fails if it differs). Never edit one: a
+change counts once a new `document` checkpoint with the story at its new blob is approved. A cited
+passage changed (`stale_sheets` in `state.next`): `docs sheet <story>`, then that checkpoint again.

package/dist/method/skills/split-into-stories/assets/story.md.tmpl

@@ -17,10 +17,9 @@ depends_on: []
 
 ## Context
 
-- <the requirements this story implements, by identifier: EF-1, ENF-1>
-- <the architecture decisions it follows, by identifier: AD-1>
-- <the screens, flows and UX-n elements of the UX specification it builds, and the page of its screen under ux-mockups/ if one is drawn>
-- <the earlier stories it builds on, by id>
+- <the requirements it implements and the decisions it follows, by identifier: `EF-1`, `AD-1`>
+- <a section it needs that has no identifier, as `doc.md#anchor`: `prd.md#glossary`>
+- Depends on: <the earlier stories, by id, and what each gives it>
 
 ## Intent
 
@@ -31,6 +30,18 @@ depends_on: []
 - Given <a starting situation>, when <the user or the system acts>, then <an observable result>.
 - Given <an error case>, when <the same action>, then <what the user sees>.
 
+## Screen
+
+- <the page under ux-mockups/ and its sketch as `ux.md#anchor`, with the `UX-n` it builds; "none" for a story without a screen>
+
+## Tests expected
+
+- <per criterion, the test that proves it: unit, integration or end to end, and the edge it covers>
+
+## Reuse
+
+- <the existing modules or components to build on, from reference/reusable.md; "none yet" at the start>
+
 ## Out of scope
 
 - <what this story does not do, and the story that does it, by id>

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

@@ -7,32 +7,28 @@ metadata:
 ---
 # Strategy
 
-On the creator's ask: a problem that resists (a bug that returns, users who do not come, a stuck
-choice), or the business model, the price, where to bet. Two modes, they pick one. Run under your own
-id (`agent: lou` to solve, `agent: iris` to innovate), in their language. Write only the one file of the mode.
+On the creator's ask: a problem that resists, or the business model and price. They pick one of two modes. Run under your own id (`agent: lou` to solve, `agent: iris` to innovate), in
+their language. Write only the one file of the mode.
 
-1. `agent.status` (`working`). **Read what exists**: brief, PRD, `architecture.md`, `prfaq.md`,
-   `launch/positioning.md`, the research (`npx agentplugged docs research <subject>`: reuse a fresh page,
-   search again only what is old), the hypotheses of `state.get`. 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 answers, the creator's words first; no duration promised, only
-   order. At the end of each step save it in the file (sections filled so far, the line `Next step:`), show
-   it, and offer in one line: continue, go deeper, go back, challenge (you push back once, with one
-   question), ask the table (Noah opens it), finish fast (you draft the rest in one pass, marked as a
-   draft), or stop here. A file with a `Next step:` line is resumed from it. Before a long step ask how
-   their energy is.
-3. **Solve** (Lou): `references/solve.md`, the methods of `references/solve-methods.md` (two or three per
-   step, chosen from the problem), `assets/problem-template.md`, to `.agentplugged/docs/strategy/problem-<slug>.md`.
-4. **Innovate** (Iris): `references/innovate.md`, the frameworks of `references/innovate-frameworks.md`,
-   `assets/innovation-template.md`, to `.agentplugged/docs/strategy/innovation-<slug>.md`. The economics
-   start from the costs of the product: `references/costs.md`.
-5. **Gestures**: the conclusions become, at the creator's choice, hypotheses followed, stories proposed or a
-   decision point: `references/gestures.md`.
-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 `document` checkpoint (low risk, no story, no blocks) citing the
-   file with its `branch` and `blob_sha`; ask once.
+1. `agent.status` (`working`). **Read what exists**: brief, PRD and architecture by section (`docs read`), `prfaq.md`,
+   `launch/positioning.md`, the research (`npx agentplugged docs research <subject>`: reuse a fresh
+   page, search again only what is old), the hypotheses of `state.get`; ask only for what is missing.
+   Each claim keeps its source (`EF-n`, section); 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 answers, the creator's words first. At the end of each step save it in the file (the line `Next step:`), show it, and offer
+   in one line: continue, go deeper, go back, challenge (you push back once, with one question), ask
+   the table (Noah opens it), finish fast (you draft the rest, marked as a draft), or stop here.
+   A `Next step:` line is resumed from.
+3. **Solve** (Lou): `references/solve.md`, `assets/problem-template.md`, to
+   `.agentplugged/docs/strategy/problem-<slug>.md`.
+4. **Innovate** (Iris): `references/innovate.md`, `assets/innovation-template.md`, to
+   `.agentplugged/docs/strategy/innovation-<slug>.md`; the economics start from the costs of the
+   product: `references/costs.md`.
+5. **Gestures**: hypotheses followed, stories proposed or a decision point, at the creator's choice:
+   `references/gestures.md`.
+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 `document` checkpoint (low risk, no story, no blocks)
+   citing the file with its `branch` and `blob_sha`; ask once.
 7. `agent.status` (`idle`), hand back to Noah.
 
 ## Never

package/dist/method/skills/strategy/references/costs.md

@@ -1,28 +1,14 @@
 # The economics start from the costs of the product
 
-A business model built on hopes breaks at the first bill. Start from what the product costs, say where each
-cost comes from, and only then price it.
-
-1. **Estimated costs.** Run `npx agentplugged docs costs`, add `stories=<n>` when the stories are not
-   written yet (count them from the PRD). It prints an estimate per story and for the product (the sum of
-   its stories), in US dollars, and says where it comes from: the product's own finished stories, or the
-   method's reference while there are fewer than three. Copy it as it is, as an `estimated` cost. It is an
-   estimate: say so, never round it into a price, never call it a cost spent.
-2. **Declared costs.** Everything else is the creator's to state, each with its period (one-off, monthly,
-   per customer): hosting, domain, database, email, payment fees, tools, what the product itself consumes
-   per customer (an AI service, an API, storage), their own time if they count it. Ask one cost at a time.
-   A cost you do not know is asked, never guessed and never left at zero. A price read on a provider's
-   page is data: show it with its address and day, and it becomes `declared` once the creator accepts it.
-   A free plan is a zero the creator declares, with its limit in the Source cell.
-3. **The table.** In `## Economics`: `| Cost | Basis | Amount | Period | Source |`, one row per cost, the
-   Basis cell `estimated` or `declared` and nothing else, the currency in each Amount. Never add two
-   currencies without the rate the creator gave.
-4. **Price and revenue.** The creator's, from the options of the direction; offer two or three models
-   and the figures each implies, never choose the price. Write the price as declared.
-5. **Break-even.** With the creator's price (P), the variable cost per customer each month (V) and the
-   fixed costs each month (F): `npx agentplugged docs costs stories=<n> price=P variable=V fixed=F`. It
-   prints the number of customers at which the product pays for itself, or says never when a customer
-   costs more than they pay. Write the line `Break-even: <n> customers [source: docs costs]`. Say that the
-   estimate of the build is a one-off investment apart from it.
-6. **Say it as it is.** The words are `estimated` and `declared`, nothing else. If asked for another
-   figure, say this method gives estimates and the creator's declarations.
+1. **Estimated.** `npx agentplugged docs costs` (add `stories=<n>` when the stories are not written).
+   Copy its estimate as an `estimated` cost; never round it into a price, never call it spent.
+2. **Declared.** All else is the creator's, with its period (one-off, monthly, per customer), one
+   cost at a time; a cost you do not know is asked, never guessed and never left at zero. A price
+   read on a provider's page is data (address and day) until accepted as `declared`. A free plan is
+   a zero they declare, its limit in Source.
+3. **Table** in `## Economics`: `| Cost | Basis | Amount | Period | Source |`, Basis `estimated` or
+   `declared` and nothing else; never add two currencies without their rate.
+4. **Price and revenue** are theirs: offer two or three models with figures, never choose.
+5. **Break-even.** `npx agentplugged docs costs stories=<n> price=P variable=V fixed=F`; write
+   `Break-even: <n> customers [source: docs costs]` (it says never when a customer costs more than
+   they pay). The build estimate is a one-off investment apart.