agentplugged 0.0.1 → 1.0.1

package/dist/method/skills/pitch/assets/design-template.md

@@ -0,0 +1,45 @@
+---
+id: design-topic
+kind: note
+owner: stella
+links: [prd]
+language: en
+---
+<!-- Design thinking synthesis (skill pitch). Copy it to .agentplugged/docs/launch/design/<topic>.md,
+replace `topic` in the `id` by the topic's slug. A step not run keeps its section with one line
+saying why. Remove these comments, the "Generated by agentplugged" line and every <…> placeholder.
+`links`: the documents it is drawn from, at least one. Never add a status or a cost. -->
+
+# Design thinking: <topic>
+
+## Empathy
+
+<what the user does, says, feels, and what blocks them; the source of each>
+
+## Definition
+
+<the user needs a need because an insight; the "How might we" questions>
+
+## Ideas
+
+- <idea kept, and why>
+
+## Prototype
+
+<the cheapest testable form, and what it leaves out>
+
+## Test
+
+<who, which task, what would prove it wrong; results with their date>
+
+## Next round
+
+<!-- Optional: refine, reframe, pilot; the priority action; the metric and its date. -->
+
+<the next step>
+
+## Implementation
+
+<!-- Optional, last step: test plan, feedback to collect, one line per learning. -->
+
+<the lines, each a hypothesis or a story>

package/dist/method/skills/pitch/assets/narrative-template.md

@@ -0,0 +1,40 @@
+---
+id: narrative
+kind: note
+owner: julien
+links: [brief]
+language: en
+---
+<!-- Story of the product (skill pitch). Copy it to .agentplugged/docs/launch/narrative.md and write
+it in the language of its audience (`language`: fr, en...). Remove these comments, the "Generated by
+agentplugged" line and every <…> placeholder. `links`: the ids of the documents it is drawn from
+(brief, prd, positioning, prfaq...), at least one. Never add a status or a cost. -->
+
+# Story: <audience>
+
+## Audience
+
+<who they are, and what they care about>
+
+## Story
+
+<one hero, one tension, one turn>
+
+## Proof
+
+| Claim | Status | Source |
+| --- | --- | --- |
+| <claim> | <verified, stated or untrusted> | <document, date or link> |
+
+## Ask
+
+<the one thing the audience is asked to do>
+
+## Versions
+
+<!-- Optional: short (one to three sentences), medium (a paragraph), and where each is used. -->
+
+## Usage
+
+<!-- Optional: channels, adaptations per audience, tone, how to test it. -->
+

package/dist/method/skills/pitch/references/deck-types.md

@@ -0,0 +1,17 @@
+# Kinds of talk
+
+Ask which, then shape the same `deck.md`.
+
+- **Product deck** (users, partners): 6 to 8 slides. Situation, pain, the product at work, the proof, how
+  to start.
+- **Investor deck**: 10 to 12. Problem, who has it, why now, product, proof so far (every figure sourced),
+  market, model, team, the ask and what it buys. A number is the creator's or `[to verify]`.
+- **Conference talk or workshop**: large type, few words; the speaker notes carry the talk, with timing
+  cues the creator sets; hook, build, payoff; for a workshop, a slide per exercise with its instruction.
+- **Video explainer**: slides are scenes. Name the hook at the opening, then a change of picture or a
+  new question every 15 to 30 seconds; each scene has `Visual:` and the spoken text in `Notes:`.
+- **Single visual** (infographic, one image that explains the idea): one slide whose `Visual:` line
+  states the metaphor and the one thing to grasp; the notes say why it works.
+- **Concept diagram** (journey, process, a metaphor): one slide per stage, `Visual:` describing the drawing.
+
+For all: story shape (hook, tension, payoff), clarity before cleverness, white space, a consistent look.

package/dist/method/skills/pitch/references/deck.md

@@ -0,0 +1,24 @@
+# The deck, as a plan
+
+Build from the narrative: its story becomes the slides, its Proof the evidence slides, its Ask the
+last slide. Length and shape by kind of talk: `deck-types.md`.
+
+- With a brand identity (`launch/identity.md`), the deck takes its tokens and its voice (`launch/brand.md`).
+- One idea per slide. The title is the claim, in a sentence ("Makers lose a week to rework"), not a
+  topic. Content: at most 6 filled lines (a table counts as one, the `Visual:` line as one), or one figure with its source.
+- The 3-second test: can a viewer take the idea in three seconds? Else cut. Every slide has a job:
+  inform, persuade, or move on; otherwise it goes.
+- Each slide has a line `Notes:` with what the speaker says: the story, the context of a figure, the
+  likely question and its answer. Notes carry the detail, the slide stays light.
+- Slides are sections `## Slide 1 — <claim>`, numbered in order. Markdown is the export: a section is
+  a slide, the `Notes:` line its notes; the creator pastes them into the tool they use.
+- A visual is one line, `Visual: <kind> — why`. Never fetch an image. The page draws three kinds from the slide's own
+  words: `figures` (a list "42 % — what it says"), `diagram` (a list of steps, joined by arrows), `quote` (a
+  quote, last line "— who"). Any other visual stays a line for a designer (Julien's `VI`).
+- One visual language for the whole deck: the identity of `ux.md` when it exists.
+
+Drawn: `npx agentplugged docs slides` writes `launch/deck.html` from the file, same text: one slide per screen, arrows or
+space to move, N notes, T light or dark, F full screen, print for a PDF. Nothing to install, nothing sent.
+
+Check: a slide with two ideas is split; a figure has its source or `[to verify]`; the last slide says
+what to do; `docs check` reports nothing.

package/dist/method/skills/pitch/references/design-implementation.md

@@ -0,0 +1,25 @@
+# Design thinking, the last step: implementation
+
+Read when the prototype exists. Write it in `## Implementation` of the synthesis, from the creator's words
+and the test results, never invented. A step with nothing to say keeps one line saying why.
+
+1. **Test plan** (if the test has not run). Who: five to seven people and how to reach them. What: one task
+   each, one thing measured per assumption. The success criterion, fixed before the test ("4 of 5 finish
+   alone"). When, and who watches. Offer a script: the task, the questions, what to observe.
+2. **Feedback to collect.** What exactly (blocked, confused, liked, asked for), by which channel (call, notes,
+   form, usage), and where it comes back in this file, dated.
+3. **From learning to product.** One line per learning, "what we learned → what to do", with its source (test,
+   date). The creator picks one gesture per line, you never choose:
+   - **hypothesis**: the product follows it until its proof. Report them in one `review.critique`
+     (`agent: stella`, `kind: idea`, `lenses: ["socratic"]`, `summary` the test in one line; one finding each:
+     `severity: should_fix`, `claim` the learning as a checkable statement, `passage` `design-<slug>`,
+     `argument` the observation, `proposal`, `proof` the measure and criterion of the plan). Then the gestures
+     as in `.agentplugged/skills/test-idea/references/bets.md`. Refused `critique_unsorted`: sort the earlier
+     stack first.
+   - **story**: a proposal in one line ("<who> can <do what> so that <why>"), kept with `plan.defer`
+     (`origin: deliberate`, `owner: creator`, `title` the line, `detail` the learning and its source). It is
+     cut up at the next planning.
+   - **drop**, with their reason in the file.
+4. **Pilot** (a service, or a first real run): who, how long, who must be aligned (team, partners), the one
+   metric and its date, what makes you stop.
+5. Show the section, then the usual menu. When all is written, remove the `resume` comment, `docs check`.

package/dist/method/skills/pitch/references/design-methods.md

@@ -0,0 +1,45 @@
+# Exercises by step
+
+Offer three to five that fit the need, the access to users and the product (digital, service,
+physical); say when each works best. One line each: what it is, what to ask.
+
+**Empathy**
+- Interviews: a recent real episode, "walk me through it", what frustrates, what would ease it.
+- Empathy map: says, thinks, does, feels; the contradictions are the finding.
+- Shadowing: watch without helping; note the workarounds and what is never said.
+- Journey map: start, steps, struggles, delights, the emotional curve; mark the worst moment.
+- Diary: users note moments over days; authentic and slow, for a long cycle.
+- Five whys: on the worst moment, until the cause is not a symptom.
+
+**Definition**
+- Problem framing: who, what really, why it matters, what success is.
+- Point of view: user, need, insight in one sentence.
+- How might we: open questions, neither too wide nor already a solution.
+- Clustering: group the notes, name each group, read the story they tell.
+- Jobs to be done: the functional, emotional and social job the user hires a solution for, and the alternatives.
+
+**Ideas**
+- Open brainstorm: quantity, no judging, be visual.
+- Eight sketches in eight minutes: forces past the obvious.
+- Seven lenses (substitute, combine, adapt, modify, other use, remove, reverse) on what exists.
+- Provocation: the most extreme version, to find what matters.
+- Analogy: another field or nature already solved this; what to borrow.
+- Worst idea turned around.
+
+**Prototype**
+- Paper or text flow: rough on purpose, core concept only.
+- Role play: act the scenario, where is it awkward.
+- Fake backend: a person does by hand what the product will do.
+- Storyboard: scenes in sequence, with the emotional curve.
+- Physical mock-up: for touch, size, ergonomics.
+
+**Test**
+- Task test: "try to do X", think aloud, do not help.
+- Feedback grid: liked, questions, ideas, changes.
+- Two versions side by side: which serves better, and why.
+- Assumption test: list assumptions, test the riskiest, say what would prove it wrong.
+- Quick loop: fix, retest.
+
+**Next round**
+- Small real pilot. Service blueprint: what the user sees, what happens behind, the handoffs. Stakeholder
+  walk-through of the research and prototype. A measurement plan: metrics and when to revisit.

package/dist/method/skills/pitch/references/design-thinking.md

@@ -0,0 +1,28 @@
+# Design thinking, the course
+
+Keep the user at the centre; judge late; make things tangible fast; a failed test is information.
+Start from what the documents say of the user (PRD `PU-n`, personas of `ux.md`, research pages). When
+no research exists the creator speaks for the users: say so and mark it `[to verify]`.
+
+0. **Challenge.** Ask: the problem or opportunity, who is concerned, the constraints (budget,
+   technology), what success looks like, what research exists. Write one challenge sentence: it opens the
+   **Definition** section.
+1. **Empathy.** Pick exercises (`design-methods.md`). Gather what users say, think, do, feel; the pains,
+   the surprises, the patterns. Ask who the creator can really watch or interview.
+2. **Definition.** "<user> needs <need> because <insight>", then 3 to 5 "How might we" questions;
+   name the assumptions behind them and cluster the insights.
+3. **Ideas.** Diverge first: 15 to 30 ideas, no judging, build on each other, wild and practical. Then
+   cluster, and the creator keeps two or three against the need and the constraints.
+4. **Prototype.** The least that tests the riskiest assumption: what to learn, what the user must be able
+   to do, what can be faked. Say what it leaves out.
+5. **Test.** Five to seven people, one task each; watch what they do more than what they say. Capture:
+   worked, struggled, surprised, questions, changes. Say which assumptions held or fell. Results are the
+   creator's words, dated, never invented.
+6. **Next round.** Refine, reframe, return to empathy, or pilot with real users. Name the priority action,
+   who is involved, and how success will be measured (one metric, one date).
+
+7. **Implementation.** `design-implementation.md`: test plan, feedback to collect, then each learning becomes a
+   hypothesis followed or a proposed story, one gesture each.
+
+Choose by need: unclear problem, steps 0 to 2; known problem, 3 to 5; a built idea, 5 to 7. A step not run
+stays in the file with one line saying why.

package/dist/method/skills/pitch/references/story-frameworks.md

@@ -0,0 +1,39 @@
+# Structures, by purpose
+
+Each: the beats, as questions. Recommend by purpose and audience; for a product, users: customer journey,
+partners: positioning or vision, investors: pitch or fundraising.
+
+**Transformation**
+- Hero's path: who, their ordinary world, what disrupts it, the trials, the change, what they bring back.
+- Spine: once there was, every day, until one day, because of that, until finally.
+- Customer journey: the struggle before, the discovery, the use, the change, the new normal.
+- Obstacle overcome: what blocked, how stakes rose, the darkest moment, the breakthrough, the lesson.
+- Personal arc: who at the start, what forces change, what they resist, what shifts them, who now.
+
+**Strategic**
+- Brand: the spark, the values, the effect on people, the difference, where it goes.
+- Vision: today's reality, the opening, the bold picture, the path, the changed future.
+- Origin: the spark moment, early struggles, the breakthrough, how it grew, today's mission.
+- Positioning: the gap in the market, why us, what is different, why care, the future enabled.
+- Culture: principles, behaviours that show them, stories that prove them, how it feels inside.
+
+**Persuasive**
+- Pitch: the problem landscape, the solution, the proof, the size of the opportunity, the ask.
+- Sales: the pain they feel, that you understand it, the transforming solution, the expected results, the way.
+- Change: why we cannot stay, what better is, the stake of not acting, how, what is in it for them.
+- Fundraising: the problem that moves, the hope, the impact of the gift, why now, how to help.
+- Cause: the wrong, who bears it, the change needed, what happens if we act, how to join.
+
+**Analytical**
+- Data: the context, the revelation, the patterns, so what, the action.
+- Case: the situation, the approach, the difficulties, the results, what transfers.
+- Research: the question, the method, the finding, the meaning, the implications.
+- Insight: what everyone assumed, what you noticed, the deeper pattern, why it matters, what changes.
+- Making-of: what was built, the choice, the obstacles, how they were solved, what was learned.
+
+**Emotional**
+- Hook: the surprising opening, the urgent question, the peaks, the common ground, the payoff.
+- Conflict: who wants what, what stands in the way, the escalation, the resolution.
+- Empathy: whose view, what they live, what they feel, why the audience should care, the common ground.
+- Human interest: the person, their stakes, the universal theme, the journey, what makes it relatable.
+- Candid: the hard truth, the struggle, the lesson, why now, the hope.

package/dist/method/skills/pitch/references/story.md

@@ -0,0 +1,22 @@
+# The story of the product
+
+1. **Context.** Purpose (users, partners, investors, press, team), one audience per story, what they
+   should remember, constraints (length, tone, medium). The documents answer most of it.
+2. **Structure.** From `story-frameworks.md`, recommend one: "for <purpose> and <audience>, <structure>,
+   because <reason>". The creator may take another.
+3. **Elements.** Questions, not writing: the hero, the tension (without a struggle there is no story), the
+   concrete detail, what changes, the true core. Start from the positioning when validated, never copy it:
+   a claim here needs its own source.
+4. **Emotional arc.** The feeling at the start, at the turn, at the end; the peaks and the low points; the
+   stake that makes it matter.
+5. **Opening.** A surprising fact, an urgent question, a recognisable moment, a promised payoff; offer two.
+6. **Draft**, in the mode the creator chose (150 to 300 words).
+7. **Versions.** Short (one to three sentences: a post, a subject line), medium (a paragraph or two), full.
+   Only the channels they name.
+8. **Use.** Best channels, adaptations for each audience, tone, a visual if useful, how to test it on a
+   few people.
+9. **Polish.** What is strongest, what is weak, the one action asked, other audiences to write for.
+
+Then **Proof** (claim, status `verified`, `stated` or `untrusted`, source) and **Ask** (one thing).
+Check: a figure without source is `[to verify]`; a customer quote that is not real is `[imagined]`; a promise
+the product cannot keep is cut; `docs check` reports nothing.

package/dist/method/skills/plan-sprint/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: plan-sprint
+description: Propose the next sprint from the validated stories (goal, order, budget, capacity), check it with the creator, then record it. Run by Izzy in the build phase.
+metadata:
+  agent: izzy
+  phase: build
+---
+# Plan a sprint
+
+A sprint is a promise the creator can hold the team to: what will be delivered, in what order,
+for how much, and by whom. This skill builds that promise from what already exists — validated
+stories, their budgets and their dependencies, and the people and agents available — and records
+it in the journal, where `state.next` and every agent read it. The engine checks the proposal and adds
+up the budgets; it estimates nothing itself, and it refuses (`budget_out_of_range`) a story budgeted
+more than three times off the product's measured range or the method's reference. The judgement
+is yours, and the decision is the creator's.
+
+This skill belongs to Izzy. Run it as Izzy, with `agent: izzy` in every MCP call. Work in the
+creator's language; keep identifiers (`1-2`, `S-…`, `G-…`) as they are.
+
+- **Inputs:** the stories of `.agentplugged/stories/` and their epics, `state.get` (statuses,
+  done stories, the sprint in force), `.agentplugged/method.yaml` (`profile.specialties` and
+  `profile.max_parallel_stories`).
+- **Output:** one sprint, recorded with `plan.sprint`. No file: the journal holds the sprint.
+- The creator may ask for the next sprint at any time, even while the current one runs. A story
+  started and not finished may move on to the next sprint.
+
+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 "sprint planning").
+2. Call `state.get`:
+   - `phase.current` must be `build` (or null when the profile has no phases). Otherwise, say
+     which phase is current and what closes it, and stop.
+   - `sprint.latest` with `status: proposed`: a proposal already waits for the creator. Tell
+     them its checkpoint (`checkpoint`) and stop: `plan.sprint` refuses a new one meanwhile.
+   - `sprint.latest` with `status: refused`: read the creator's note on its checkpoint
+     (`state.get { checkpoint: "<id>" }`, then `checkpoint.resolution.note`). This run answers that note.
+   - `sprint.current`: the sprint in force. List its stories still `todo`, `in_progress`,
+     `in_review` or `blocked`: they are the first candidates for the next sprint.
+3. Run `npx agentplugged docs check`. A story that fails it cannot enter a sprint: name it and
+   its problem, and leave it out (its owner, or you for the breakdown, fixes it first).
+
+**Produces:** the phase confirmed, the state of the last sprint, and the list of stories that hold.
+
+## Step 2 — List the candidates
+
+A story is a candidate when all of these hold:
+
+- it is **validated**: an approved `document` checkpoint lists its file (the end of the
+  breakdown) at its current content: a story edited since, even its header, must be validated
+  again. `plan.sprint` refuses any other with `not_validated`;
+- it is **not done**: no `story` checkpoint of it was approved after its last status;
+- its header is complete: `owner`, `budget_usd`, `depends_on`.
+
+For each candidate, note its owner, its budget and its dependencies, and whether each dependency
+is done. Build the order from the dependency graph: a story comes after every dependency that is
+not done yet. When several orders are possible, prefer, in this order: what unblocks the most
+other stories, what carries the most user value for the epic in progress, what reduces a risk the
+architecture or the creator named.
+
+**Produces:** the candidates, in a valid order, each with its owner, budget and dependencies.
+
+## Step 3 — Ask for the capacity and the budget
+
+Ask the creator, in one message:
+
+- **the developer agents** who will work in this sprint. Propose the active ones:
+  `profile.specialties` in `method.yaml` lists the active specialties (`sam` and `ethan` for
+  backend, `hugo` and `lina` for frontend, `jade` for mobile, and any developer the creator added
+  with a specialty of their own). One developer may build several stories at once, each one an
+  instance of its own (the pair developer and story), up to `profile.max_parallel_stories` stories
+  in progress when it is set; small changes go to the developer of their story, in the quick lane.
+  Name only agents that are active;
+- **the humans** who will build stories themselves (stories whose `owner` is `creator`), as a
+  number;
+- **the budget ceiling** for the sprint, in US dollars, if they want one.
+
+Never assume a capacity the creator did not confirm. When the answer is "same as last time",
+reuse `sprint.current.capacity`.
+
+**Produces:** `capacity.agents`, `capacity.humans`, and the ceiling or none.
+
+## Step 4 — Propose the sprint
+
+1. Write a **goal**: one line of at most 112 characters, what a user will be able to do at the
+   end of the sprint. Not a list of stories.
+2. Pick the stories, in order, from the candidates:
+   - every dependency of a story is done or comes earlier in the sprint;
+   - every story's owner is in the capacity (`creator` needs at least one human). Otherwise,
+     propose to change the story's owner with the creator, or leave it out;
+   - the total of the budgets stays under the ceiling. Cut from the end of the order, never by
+     breaking the order;
+   - the load is plausible for the capacity: a developer agent finishes a story at a time, and a
+     sprint gives each one a few stories, not dozens. Say plainly when the wish does not fit.
+3. Present the proposal: the goal; the stories in order, each with its owner, budget and what it
+   waits on; the total against the ceiling; the capacity; the risks (a long dependency chain, a
+   story with open questions, an owner with too many stories); and what was left out and why.
+4. Revise with the creator until they agree. A change of story owner is a change to the story:
+   make it in the story's header (never in its intent), run `docs check`, and commit it.
+
+**Produces:** a goal, an ordered list of stories, a capacity and a ceiling the creator agreed to.
+
+## Step 5 — Record it
+
+1. Call `plan.sprint` with `agent: izzy`, the `goal`, the `stories` in order, the `capacity`
+   (`agents`, `humans`), the `budget_limit_usd` when there is a ceiling, and a `summary`: the
+   reasons for the order, the risks, and what was left out. The engine composes the checkpoint
+   the creator reads from the sprint it checked: the stories, owners, budgets, total and capacity.
+2. On `SPRINT_INVALID`, nothing was written. Read every problem in `details.problems` and fix
+   the proposal, never the rules:
+   - `unknown_story`, `unreadable`, `invalid_story`: a wrong id, a file that cannot be read,
+     or a story that fails `docs check` (`why` lists its problems);
+   - `not_validated`: the story's breakdown was never approved (`why: never`), or the story
+     changed since (`why: changed`); leave it out, or have the creator validate it again;
+   - `done`: the story is already done; leave it out;
+   - `dependency_missing`, `dependency_later`: add the dependency earlier, or move the story
+     later;
+   - `agent_inactive`, `no_capacity`, `owner_unavailable`: fix the capacity with the creator;
+   - `over_budget`: cut stories from the end, or ask the creator to raise the ceiling;
+   - `proposal_open`: a proposal already waits for the creator;
+   - `too_long`: the checkpoint shows your summary and one line per story, never cut. Shorten
+     the summary to `max` characters, or plan fewer stories (`field: stories`).
+   If the creator must decide anything to fix it, go back to step 4 with them.
+3. On success, `plan.sprint` returns the sprint (`sprint`: `S-…`) and its checkpoint
+   (`checkpoint`: `G-…`). Ask whether the sprint suits them only now, once, since the
+   checkpoint is open: present it in the chat and record the creator's answer with
+   `chat.answer`, quoting their words (constitution, "Checkpoints in the chat"): they
+   approve it, or ask for changes.
+
+   When other checkpoints are open at the same time as the sprint's, present those that are
+   plain approvals as one stack (constitution, "Stacks to validate"); the sprint's own checkpoint
+   keeps its own answer, which sets the stories' ceilings.
+
+**Produces:** a sprint recorded in the journal, and its checkpoint open.
+
+## Step 6 — Hand over
+
+1. Call `story.result`: `complete`, a summary naming the sprint and its checkpoint, your
+   assumptions (a capacity you inferred, a budget you found low), the open questions, and the
+   conflicts (a story that cannot fit any order).
+2. Call `agent.status` (`idle`).
+3. Run `npx agentplugged next --json` and tell the creator what it says. While the checkpoint is
+   open, it is in `waiting`; its `step` is `validation` once the sprint in force, if any, has no
+   story left to start. Once the creator approves it, the sprint is in force: `state.next` proposes its
+   stories one by one, in order, each to the owner the sprint recorded (else the first active
+   agent of its capacity, else the creator); when none is left to start and the started ones are
+   done, it calls you again for the next sprint, or for the breakdown when no story left can be
+   planned. You never call a developer yourself: hand back to Noah, who proposes what comes next; the creator decides (without Noah, the creator picks 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 invent an amount: the budgets are the ones the stories carry (each read from `state.get`
+  `usage.estimates`), a sprint's total is their sum, and when you tell it to the creator you say
+  what it rests on (`history` or `reference`) and its range. The capacity is the one the creator
+  confirmed.
+- Never put a story that is not validated, or already done, in a sprint, and never break the
+  dependency order.
+- Never write a sprint file, nor edit a story's intent: the sprint lives in the journal.
+- Never start, call or direct a developer agent: the sprint is a plan, not a launch.

package/dist/method/skills/quick-lane/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: quick-lane
+description: Carry a small change (one story, no public interface, no migration, fewer than 5 files) through the quick lane, with its story, review and validation. A mode of the developer.
+metadata:
+  agent: sam ethan hugo lina jade
+  phase: build
+---
+# The quick lane
+
+Some changes are too small to go through framing, planning and design: a fix, a wording, a
+forgotten case. The quick lane carries them straight to a tested pull request. What it skips is
+the paperwork upstream, never the story, the tests, the independent review nor the creator's
+validation before the merge, and it hands a change back the moment it stops being small.
+
+The quick lane is a mode of the developer the story goes to, carried by the story (the fast track
+of the engine, `fast_track` in `state.get`): there is no dedicated agent. The developer of the
+story's specialty (backend, frontend, mobile, or a specialty the creator added) runs this skill
+under their own id: `agent: <your id>` in every MCP call. Work in the creator's language; keep
+identifiers (`1-2`, `EF-n`, `AD-n`, `G-…`) as they are.
+
+- **Input:** one story of `.agentplugged/stories/`, if only one line long, whose `owner` is you.
+- **The creator's Git workflow:** the story lands where `git` in `state.next` says (the integration branch, or the main branch), with or without a branch of its own, a pull request, a CI or a review, as the creator chose; the quick lane never changes that.
+- **Output:** the change and its test, committed on the story's branch (`feat/<story>-<slug>`, the
+  one its header names) in its own working copy, then its pull request; or, when the change is not
+  small, the way back to the full lane with a checkpoint that explains it to the creator.
+
+## Triage a reported bug
+
+When the creator reports a bug, ask for the symptom, where it shows and how often. Reproduce it,
+find the cause and size the fix against the limits of the quick lane below. Report the cause, the
+files involved, the test that would prove the fix and whether it fits the quick lane or needs the
+full lane, before changing anything. When one reading of the code and one run of the
+reproduction do not give the cause, the bug is not trivial: do not start the quick lane, do not
+guess; say so and follow `diagnose-bug` (hypotheses kept by the engine), in the full lane.
+
+## The limits
+
+A change fits the quick lane only when all of these hold. The engine reads what it can in the
+repository; you declare what only you can know.
+
+| Limit | Who checks it |
+|---|---|
+| it fits in one story | the engine: the story has its file, is validated and is yours |
+| it touches fewer than 5 files, tests included (a renamed file counts twice) | the engine, on the diff of your branch |
+| it adds no dependency | the engine: no dependency manifest nor lockfile is touched; you declare a dependency a manifest does not show |
+| it needs no data migration | the engine: no migration nor schema file is touched; you declare the rest |
+| it changes no public interface | the engine reads the files of an interface's contract (API descriptions, schemas, type declarations); you declare the rest |
+| its goal has a single reading | you declare it |
+| no step of it is irreversible | you declare it |
+
+A quick change always has a story, if only one line long: when none exists, ask the creator to
+have Izzy write it (or to write it themselves) before you start. Check the limits before starting;
+the engine checks them again at every pull request and every CI read.
+
+The review before merging always happens: by Quentin, and Chloé for security, or by the creator
+when the product's profile has no quality agent. The creator validates the merge, the engine
+merges: the quick lane changes nothing there.
+
+## Leaving the quick lane
+
+The way back to the full lane is final, and there are two ways to it:
+
+- **The engine** sends the story back when it reads a commit of your branch that no longer fits
+  (5 files or more, a dependency manifest, a migration, an interface's contract): the result of
+  `story.pr` or `story.ci` says `fast_track` with `left: true`, and the story is
+  `blocked`.
+- **You** leave the moment the goal can be read two ways (`ambiguous_intent`), a step could not be
+  undone (`irreversible_action`), the change keeps growing (`growing_scope`), or it needs a public
+  interface change (`public_interface`), a data migration (`data_migration`) or a new dependency
+  (`new_dependency`). Stop at once, never bend a limit to keep a change, and:
+
+1. Call `story.leave_fast_track` with the `reasons` (each once) and a `detail` that says what you found.
+   The engine records the exit, blocks the story and opens, in the same write, the `decision`
+   checkpoint that explains it to the creator (continue in the full lane, or stop). Do not open a
+   checkpoint of your own, do not call `story.status`.
+2. Call `story.result` with status `partial`: what is done, what you found, what is left.
+3. Recommend the full lane: framing or design when needed, then the story built with the
+   `develop-story` skill. The creator decides; the story stays blocked until they answer.
+4. Leave the branch as it is, with a note of what it holds.
+
+Whether a change may take the quick lane when in doubt, and any step out of it, belong to the
+creator: you recommend, the creator decides.
+
+## Steps
+
+1. **Start.** Call `agent.status` (`working`, the story as `story`). Read `state.get`:
+   `phase.current` must be `build` (or null when the profile has no phases); otherwise say which
+   phase is current and what closes it, build nothing, and go to step 8 with `partial`. When
+   `state.get` shows that you are not an active agent of the product, say so and go to step 8
+   with `partial`.
+2. **Read the story.** Read the change's story entirely, the requirements and decisions it cites,
+   the parts of the architecture (`.agentplugged/docs/architecture.md`) the change touches —
+   the product's stack and conventions are there, whatever they are — and the knowledge base
+   pages about it (`.agentplugged/docs/index.md` first; a page with an `agentplugged:late` notice is
+   behind the code: read the code, assert nothing from that page). When there is no story, stop and ask the
+   creator to have Izzy write a one-line story (or to write it themselves): no quick change
+   without a story. A story already started in the full lane stays there (`already_started`, whoever started it). Run
+   `npx agentplugged docs check` and report what it finds instead of working around it.
+3. **Check the limits.** Restate the change in one sentence, then check it against each limit
+   out loud: which hold, which do not. When one fails, the change belongs to the full lane: say so
+   to the creator and build nothing.
+4. **Take the working copy.** Call `story.start` with `fast_track`: `summary` (the sentence of
+   step 3) and `declared` (`single_reading`, `reversible`, `no_public_interface`, each `true`).
+   The engine creates the story's branch from the main branch in a working copy of its own and
+   records that the story is in the quick lane; it refuses (`FAST_TRACK_NOT_POSSIBLE`,
+   `declaration`) when you cannot declare one of the three, and never enters the quick lane for a
+   story already started. Work only in the `workdir` it returns; never on the main branch nor in
+   another story's working copy.
+5. **Build.** Write a test that reproduces the problem or proves the change, watch it fail, then
+   make it pass, fixing the cause, not only its symptom (`story.criterion`).
+   A criterion a test already covers needs no red: a passing test is enough. Commit with a message that cites the
+   story and the requirement it touches, for example `fix(2-3): empty name refused (EF-12)`.
+   Call `story.progress` as you go.
+6. **Verify.** Run the project's whole verification, as its CI does, even for a one-line change:
+   type checks, linter, every test suite and the build. Then check the limits again on what you
+   actually changed; when one gave way, go to "Leaving the quick lane".
+7. **Open the pull request.** Call `story.pr`: the engine pushes the branch (never the
+   main branch, never a force-push), opens the pull request with the fixed template — the story,
+   the linked requirements, the acceptance criteria checked, the test results —
+   and reads the changes of your branch against the limits (`fast_track` in its result). If it
+   says `left: true`, go to "Leaving the quick lane" step 2 onwards: the exit is already recorded.
+   Call `story.status` (`in_review`). Read the CI with `story.ci` as the full lane does. Never
+   merge: the review before merging always applies, and the creator validates and the engine
+   merges.
+8. **Report.** Announce no cost (the engine measures it in the tool's traces), then `story.result` with the story:
+   `complete`, `partial` or `blocked`, a summary, your assumptions, open questions and conflicts
+   (empty lists when there are none). Call `agent.status` (`idle`), run
+   `npx agentplugged next --json` and tell the creator what it says.
+
+## Budget
+
+The story carries a budget (`budget_usd`): an estimate, never a ceiling. You write no cost: the
+engine measures what your session consumed and keeps it in the journal.
+
+## 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 take a change without its story, nor bend a limit to keep a change in the quick lane.
+- Never enter the quick lane for a story already started, nor go back to it after leaving it.
+- Never skip the test, the full verification, the independent review nor the creator's validation before the merge.
+- Never push to the main branch, force-push nor merge.
+- Never leave a quick change half done: it is finished or handed back, with the reason.
+- 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).