agentplugged 0.0.1 → 1.0.1

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

@@ -0,0 +1,28 @@
+# 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.

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

@@ -0,0 +1,24 @@
+# From conclusions to gestures
+
+At the end of the file, list in a few lines what the work concluded: the cause found, the option chosen,
+the bets under the strategy. For each, ask the creator once which gesture they want. They may answer
+some now and the rest later. Never choose for them.
+
+- **Hypothesis followed.** A bet that must be proved (a cause not yet verified, an option that may not
+  work, a market claim, a price): `review.critique` with `kind: idea`, `lenses: ["pre_mortem"]`, a
+  `summary` (what the file is), and at most twelve findings, one per bet (`severity`, `claim` in one line of 200 characters at most,
+  `passage` a label of 120 at most that cites the `EF-n` or `AD-n` the bet touches, so that it comes back when
+  a story citing it is delivered, `argument` of ten characters or more, and unless the bet is minor
+  `proposal` and `proof`, what would prove or refute it). An earlier idea report not yet sorted
+  (`critique_unsorted`) is sorted first. Then the gestures
+  and the calls of the skill `critique-deliverable`
+  (`.agentplugged/skills/critique-deliverable/references/gestures.md`): keep as a hypothesis, drop with
+  their reason, or correct the file. A hypothesis kept comes back when its proof arrives; close it with
+  their words only.
+- **Story proposed.** One line each under `## Plan` or `## Roadmap` (`Story proposed:` the change, the
+  reason, the source). Hand the kept ones to Noah in your closing line: a new requirement goes to Maya, a
+  story to cut to Izzy. Write no story and no requirement yourself.
+- **Decision point.** A choice between two to four options that only they can make (the direction, the
+  price model, the fix): `checkpoint.open` with `type: decision`, the options, your recommended one and
+  the file in `documents`; ask once. Record the answer in the file once it is given.
+- **Nothing.** The file is enough. Some conclusions are only for the creator to think about.

package/dist/method/skills/strategy/references/innovate-frameworks.md

@@ -0,0 +1,48 @@
+# Frameworks by step
+
+Choose two to four for the step and the stage of the product (an idea, a first customer, a plateau); one
+line to the creator on what each reveals. A solo creator has little data: say so, and prefer the light
+ones that need only a few conversations.
+
+**Market (step 2)**
+- Market size in three rings (total, reachable, obtainable): a realistic first target, not a dream.
+- Five forces: suppliers, buyers, rivals, newcomers, substitutes; where the power sits.
+- Outside forces (political, economic, social, technical, legal, environmental): which ones matter here.
+- Timing: what must be true first, what is changing now, whether customers and the technology are ready.
+- Positioning map: two axes that matter to buyers, where each competitor sits, the empty corner.
+
+**Model (step 3)**
+- Business model canvas: the nine blocks (segments, value, channels, relationships, revenue, resources,
+  activities, partners, costs); mark the weak ones.
+- Value fit: the customer's jobs, frictions and benefits against what the product relieves and creates.
+- Model patterns: subscription, free then paid, marketplace, razor and blade, licence, usage, bundle; which
+  fits the cost and the buyer.
+- Revenue ideas: who could pay, for what, how (per seat, per use, per result, one time); what customers
+  would accept.
+- Cost redesign: the biggest costs, what to remove, automate or buy; the price point that unlocks.
+
+**Openings (step 4)**
+- Disruption from below: a simpler, cheaper offer for those the incumbents overlook.
+- Jobs to be done: the progress customers seek and the alternatives they hire today.
+- Blue ocean: what to eliminate, reduce, raise and create to leave the crowded market.
+- Crossing the gap: from the first fans to the mainstream through one narrow starting market.
+- Platform: two or more sides that attract each other; what makes the network worth joining.
+
+**Options (step 5)**
+- Three horizons: protect the core, build the next, seed the later; balance the three.
+- Build, measure, learn: the riskiest assumption, the smallest test, the measure, the pivot.
+- Ambition grid: core, adjacent and transformational moves, with the risk of each.
+- Strategic intent: a bold aim that stretches the means; what would change the field.
+- Scenarios: the key uncertainties, a few futures, a strategy that holds in several.
+- Value chain: the whole chain, where value is made and captured, the activities to own.
+- Unbundling: what is sold together that could be sold apart, where the value really sits.
+- Ecosystem design: sides, exchanges, how to attract each, what is shared.
+- Make or buy: the real strength, what gives the advantage, what to own and what to rent.
+- Partnerships: who has the missing strength, what each side gives, how the value is split.
+
+**Technology (steps 3 to 5, when the product rests on one)**
+- Adoption curve: who adopts when, and what each group needs to hear.
+- S-curve: where the technology stands, the next curve, when to jump.
+- Technology roadmap: the capabilities needed, their order, their dependencies.
+- Open innovation: what to take from outside, what to give, with whom.
+- Digital shift: what the digital tools change in the model, the operations and the customer's life.

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

@@ -0,0 +1,40 @@
+# Innovation strategy, the course
+
+Tell the truth about the market before looking for a breakthrough; a flattering picture sinks a strategy.
+Push for evidence over hope, a lasting advantage over a clever feature, a bold idea over a safe one that
+changes nothing, and keep the plan one a solo creator can carry. The creator is not asked to know the
+frameworks: you choose them (`innovate-frameworks.md`, two to four per step), say in a line what each
+reveals, and ask the questions. The sections of the file are the steps; a step not run keeps its
+section with one line saying why.
+
+1. **Context.** The business or product, what drives the exploration (pressure, an opening, a plateau),
+   the current model in brief, the limits (money, time, rules, skills), and what a breakthrough would look
+   like. Start from the brief, the positioning and the story if they exist.
+2. **Market.** Segments and how they move; the real competitors, the unexpected ones and the substitutes;
+   what is changing; who is underserved and who overserved. Reuse the research pages (`docs research`);
+   search only what is missing or old, and every size or share carries its source or `[to verify]`.
+3. **Model.** Who is really served and what job they hire the product for; how value is made, delivered
+   and captured today; the honest advantage; where the model is vulnerable; the assumptions that may be
+   false. Revenue and costs are only named here; their figures go to the economics.
+4. **Openings.** Where an entrant could win: non-users to serve, jobs left undone, a good-enough version
+   for a new segment, a technology that just made something cheap, a space where competition is
+   irrelevant. Name the disruption vectors and the white space.
+5. **Options.** Five to ten concrete moves, across the model (how value is made and captured), the value
+   chain (what to do, what to buy), partnerships and technology. Mix the near and the far.
+6. **Direction.** Merge them into three different strategic options. For each: the direction, what it
+   changes in the model, the position against competitors, what it needs, the main risks and
+   dependencies, what to expect. Judge them on fit with the creator's strengths, timing, defensibility,
+   feasibility and risk against reward. Then recommend one or a combination: why, what gives
+   confidence, what worries, the hypotheses to prove first, what would make you change course. The creator
+   decides.
+7. **Economics.** The cost of the product, the price, the revenue, the break-even point: `costs.md`.
+8. **Roadmap.** Three phases, no dates: first the moves that prove the riskiest hypothesis and give
+   momentum; then the foundations (capabilities, the first market, steady growth); then scale and
+   efficiency. For each: the initiatives, what they need, the measures of success, and the decision gate
+   that opens the next.
+9. **Risks.** Early signals (adoption, engagement, efficiency) and results (revenue, share, margin); the
+   go and no-go gates; what could kill the strategy, the assumptions that may be wrong, how competitors
+   may answer, and the backup plan.
+
+Choose by need: no model yet, steps 1 to 3 then 7; a plateau, steps 3 to 6; a decision on price, steps 3
+and 7. Then the gestures (`gestures.md`).

package/dist/method/skills/strategy/references/solve-methods.md

@@ -0,0 +1,45 @@
+# Methods by step
+
+Offer two or three that fit the problem and the creator's taste (systematic or playful); say in a line
+when each works best and what to ask. Do not run them all.
+
+**Problem and causes (diagnosis)**
+- Statement sharpening: turn a complaint into one precise sentence; who, what, where, the gap, the stake.
+- Is / is not: where, when, who and what it is and is not; the differences point at the cause.
+- Five whys: a chain of "why" on one symptom; good for a single line of cause, stop at what can be acted on.
+- Cause map (fishbone): causes by family (people, process, tools, inputs, environment, measures); good for many factors.
+- Systems view: parts, links, feedback loops, delays, leverage points; good when fixing one thing breaks another.
+
+**Forces and constraints (analysis)**
+- Force field: forces for and against the change, rated; remove an opposing force before adding a push.
+- Vital few (80/20): count the causes by frequency or impact and take the few that carry most of it.
+- Gap analysis: current against wanted state, one dimension at a time, with the size of each gap.
+- Bottleneck search: find the one constraint that limits the whole; improve there, nowhere else first.
+- Failure modes: for each step of a fix, how it fails, how likely, how bad, how to prevent or detect it.
+
+**Options (synthesis and creative)**
+- Contradiction matrix (TRIZ): name what improves and what worsens, then borrow from the inventive
+  principles that resolved the same contradiction elsewhere (split, merge, invert, do it in advance...).
+- Lateral thinking: a provocation or a random entry to leave the usual path, then find the sense in it.
+- Morphological grid: the parameters of a solution, the choices for each, combine the unusual ones.
+- Nature analogy: how living systems solve the same function; what principle transfers.
+- Analogy chain (synectics): make the strange familiar and the familiar strange through metaphors.
+- Assumption busting: list what is taken for granted, flip each one, see what becomes possible.
+- Random word: a random word forced into relation with the problem; keep the sparks.
+- Reverse brainstorm: how to make the problem happen or get worse, then turn each answer around.
+- Six hats: facts, feelings, benefits, risks, creativity, process, one at a time, on the same option.
+- Seven lenses on what exists: swap, merge, adapt, change, repurpose, remove, reverse.
+
+**Choice (evaluation)**
+- Weighted matrix: options against weighted criteria, scored, the total read with suspicion.
+- Cost and benefit: what it costs and brings, in the same unit, payback; every cost with its basis.
+- Risk grid: likelihood against impact for each option; deal with the top right first.
+- Trial protocol: the smallest experiment, its success criterion, the data, the decision it feeds.
+- Feasibility: technical, operational, financial and organisational, one verdict each.
+
+**Plan and checks (implementation)**
+- Plan, do, check, adjust: a loop with a review after each pass.
+- Sequence and dependencies: tasks, order, what blocks what, milestones that prove progress.
+- People map: who is affected, how much they can help or block, what each needs to hear.
+- Change handling: what changes for whom, the resistance to expect, how to tell it.
+- Indicator board: few measures, a target and a reading rhythm each, a threshold that triggers a decision.

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

@@ -0,0 +1,35 @@
+# Solving a problem, the course
+
+Diagnose before you solve; a good question is worth more than a quick answer. Symptoms lie, structure does not.
+Balance rigour and momentum: do not stay in analysis when the cause is clear. Start from the documents
+(PRD, architecture, research, the hypotheses already followed). The sections of the file are the steps;
+a step not run keeps its section with one line saying why.
+
+1. **Problem.** Ask: what exactly is wrong, how it was first noticed, who lives it, when and where, what it
+   costs, what success looks like. Write one statement of the gap between today and the wanted state, and
+   say why it is worth solving. Name the kind (technical, product, adoption, organisation, decision).
+2. **Boundaries.** Where, when, who and what it is and is not. Contrast the cases where it happens with
+   the near cases where it does not; the pattern between them is the first clue.
+3. **Causes.** Symptom, cause, cause of the cause, until the answer is something that can be acted on.
+   Offer two or three methods of the diagnosis group (`solve-methods.md`), say when each fits; run them.
+   Separate the root cause from the contributing factors and name the loops that keep the problem alive.
+   Mark each cause `[verified]` (seen in the code, a log, a number) or `[to verify]` (guessed).
+4. **Forces.** What drives toward a solution and what holds it back; which are strongest, which the
+   creator can move. The main constraint, and which limits are real and which only assumed. End with the
+   two or three insights that change what to try.
+5. **Options.** Ask their energy first, then change gear: from analysis to making. Offer two to four
+   methods of the creative and synthesis groups; at least ten options, small and large, and a few wild
+   ones that break an assumption. The creator's ideas first, yours after.
+6. **Choice.** Criteria first, chosen with the creator (effect on the root cause, feasibility, cost,
+   risk, reversibility). One or two evaluation methods. Recommend one option with the reason, the
+   confidence, what still worries, and the assumptions it rests on. The creator decides.
+7. **Plan.** Strategy (a trial first, in steps, or all at once) and why; the actions in order with their
+   dependencies, who does each (the creator, an agent, a tool), what each needs. No dates: order and
+   checkpoints. Learn in loops: plan, do, check, adjust.
+8. **Checks.** How we will know it worked: the measures and their targets, how and how often they are
+   read; the proof wanted, the trial to run first; what could go wrong, plan B, and the sign that says to
+   change course.
+9. **Lessons** (optional, `## Lessons`). What held up, what to drop next time, what surprised, what to remember.
+
+Choose by need: a bug that returns, steps 1 to 4; options known, steps 5 to 8; a plan under way that
+stalls, steps 4 and 8. Then the gestures (`gestures.md`).

package/dist/method/skills/test-idea/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: test-idea
+description: Forge an idea by dialogue, test it on skeptical personas, or write its press release first; risky bets become hypotheses. Run by Iris.
+metadata:
+  agent: iris
+  phase: framing
+---
+# Test an idea
+
+On the creator's ask, or when `state.next` carries `critique` with `kind: idea`. One exercise or
+more, they pick. Run under your own id (`agent: iris`), in their language. Write only
+`.agentplugged/docs/prfaq.md` and `.agentplugged/docs/ideas/forge-<slug>.md`.
+
+1. `agent.status` (`working`). Read the brief and the documents that exist; without any, ask for the
+   idea in a few sentences and keep their words. Name the concept type: `references/concept.md`.
+2. **Forge** (clarify, test or improve it): `references/forge.md`. It ends hardened, killed or clearer.
+3. **Test**: `references/personas.md`. The personas attack in a fresh context (one sub-agent plays
+   them in turn when you have one: the idea and that file, never your reasoning). Say the synthesis in a few lines.
+4. **Press release**: `references/prfaq.md`, `faq.md`, `verdict.md`. Write it with them from
+   `assets/prfaq-template.md`; open its `document` checkpoint and ask once.
+5. **Bets**: report them (`kind: idea` after the forge or the test, `prfaq` after the release), then the
+   creator's gesture on each: `references/bets.md`.
+6. `agent.status` (`idle`), hand back to Noah.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never rewrite their idea, brief or release without their gesture; never settle or close for them.
+- Never call, direct or wait for another agent: hand back to Noah.

package/dist/method/skills/test-idea/assets/forge-template.md

@@ -0,0 +1,27 @@
+---
+id: forge-topic
+kind: note
+owner: iris
+links: []
+language: en
+concept: <type>
+---
+<!-- Forge of an idea (skill test-idea). Copy it to .agentplugged/docs/ideas/forge-<slug>.md, slug in
+lowercase letters, digits and dashes; replace `topic` in the `id` by it: the id is the name of the file
+without `.md`. `language`: the creator's. `concept`: commercial, internal, open-source or community.
+`links`: the documents it builds on (a change to an existing project: required, add `scope: change`).
+Remove these comments and the "Generated by agentplugged" line. Never add a status, a cost or a progress.
+While it goes on, keep `## Idea` and `## Log`, one line per beat starting with its type: [chose] [bet]
+[gap] [out] [fixed] [path]. To close, delete the log and add under the title `Outcome: hardened` with
+`## Decisions` and `## Rejected` (each option with its reason), or `Outcome: killed` with `## Cause`, or
+`Outcome: clearer` with `## Clearer`. At most 40 lines. -->
+
+# Forge: <topic>
+
+## Idea
+
+<the idea in the creator's words, and what they want from the forge>
+
+## Log
+
+- [path] <first beat, as said>

package/dist/method/skills/test-idea/assets/prfaq-template.md

@@ -0,0 +1,33 @@
+---
+id: prfaq
+kind: prfaq
+owner: iris
+links: []
+---
+<!-- Press release and FAQ (skill test-idea). Copy it to .agentplugged/docs/prfaq.md, write it in
+the creator's language, and remove these comments, the "Generated by agentplugged" line and every
+<…> placeholder. Keep the header keys; `links`: the ids of the documents it builds on (the brief, a
+forge). Never add a status, a cost or a progress. Add the sections one by one; to close, add
+`concept: commercial | internal | open-source | community` to the header and `## Verdict` last
+(`references/verdict.md`). -->
+
+# Press release: <product name>
+
+## Release
+
+<!-- Dated in the future: headline, subtitle, problem from the reader's side, solution, quote from the
+creator, quote marked [imagined], how to start. -->
+
+<date> — <headline>
+
+## Customer FAQ
+
+<!-- 6 to 10 questions, each opening with its angle: [switch] [safety] [effort] [rare] [dreaded]. -->
+
+- [switch] <question> — <answer>
+
+## Internal FAQ
+
+<!-- 6 to 10: [build] [last] [means] [danger] [why-us] [avoided]. -->
+
+- [danger] <question> — <answer>

package/dist/method/skills/test-idea/references/bets.md

@@ -0,0 +1,14 @@
+# The bets
+
+The bets (risky objections, what is left `[bet]` or `[gap]` after a forge, `[open]` questions and the
+`Soft` and `Breaks` items of the verdict) are one line each in the stack the
+engine returns after the report. Same gestures and calls as the skill `critique-deliverable`
+(`.agentplugged/skills/critique-deliverable/references/gestures.md`), with this difference:
+
+- offer two gestures: **keep as a hypothesis** (`hypothesis`: the product follows it until its
+  proof) or **drop** (`discard`, with their reason). `fix` stays possible: the creator changes
+  their idea or document, and you change nothing without their say.
+- a kept bet shows in `state.get` and comes back with `hypotheses_due` when the first story is
+  delivered; close it only with their words (proved, refuted, dropped, still open).
+- each report is sorted before it is made again (`critique_unsorted`); for the idea, which has no new version, the bets are sorted one by one, dropping with a reason.
+- on a release (`kind: prfaq`) the `passage` is a heading of `prfaq.md` (`Release`, `Customer FAQ`, `Internal FAQ`, in the document's language), the engine checks it; on the idea it is a free label.

package/dist/method/skills/test-idea/references/concept.md

@@ -0,0 +1,24 @@
+# The kind of concept
+
+Name it early, from what they say, and write it in the header (`concept:`): it decides who the
+"reader" is and what the questions weigh. Ask only when it is unclear.
+
+| `concept:` | The reader is | The questions weigh | The release ends with |
+|---|---|---|---|
+| `commercial` | a buyer | price, alternatives, how the first customers come, whether the company lasts | how to start |
+| `internal` | colleagues | effort to adopt, who sponsors it, upkeep, why leave the current way | how to roll it out |
+| `open-source` | users and contributors | who maintains it, licence, why trust a project that may stall | how to take part |
+| `community` | members | who takes part, who steers, how it is paid for over time | how to join |
+
+A tool built for oneself is `internal`. Name the reader in the creator's words, never "everyone".
+
+Whatever the type, begin with the person, not the product:
+
+- They open with what they want to build: ask who has the trouble, at what moment, and what they do
+  about it today.
+- They open with a technique (a model, a protocol): ask what the person would lose without it; if
+  nobody would notice, the idea is not there yet.
+- Two or three exchanges later there is still no reader and no felt trouble: stop pushing and go back
+  to the forge, or to a round of ideas (skill `ideation`, Lou).
+
+When they are stuck, offer two or three readings to react to, not the same question again.

package/dist/method/skills/test-idea/references/faq.md

@@ -0,0 +1,34 @@
+# The two lists of questions
+
+Play the reader who has been let down before, not a fan. Ask what stands between interest and a
+yes. Show all the questions together, then settle the answers one at a time.
+
+Each list holds **6 to 10 questions**, each opening with its angle in brackets:
+`- [safety] Where does my data live? — answer`. The engine checks that every angle is asked
+(`docs check`). A question that cannot be answered from what they said gets a second tag, `[open]`.
+In French use the French word (`[changer]`, `[sûreté]`, `[effort]`, `[rare]`, `[redouté]`;
+`[construire]`, `[durer]`, `[moyens]`, `[danger]`, `[pourquoi-nous]`, `[évité]`).
+
+**Customer FAQ** (`## Customer FAQ`):
+- `[switch]` why this instead of what they use now.
+- `[safety]` their data, who stands behind it, what happens if it stops.
+- `[effort]` time to start, price or upkeep, what it plugs into.
+- `[rare]` a real but unusual case, a neighbouring use.
+- `[dreaded]` the question the team wishes nobody would put. Find it and ask it.
+
+**Internal FAQ** (`## Internal FAQ`):
+- `[build]` the hardest part; what nobody knows how to do yet.
+- `[last]` how it pays or endures, how the first users arrive, why it holds against the others.
+- `[means]` who, for how long; what is dropped to make room.
+- `[danger]` what kills it, the worst outcome, legal exposure.
+- `[why-us]` why this team, why now; what it takes from other work.
+- `[avoided]` what the creator steers around.
+
+Adapt to `concept.md`: for a tool of one's own or an open project, price becomes effort to adopt,
+rivals become the current way, the company's survival becomes upkeep. A solo creator and a team are
+not asked the same things.
+
+**Answers** are honest ("not yet" is allowed), concrete (no "enterprise-grade") and believable.
+"We'll see" is not an answer: ask what would settle it and by when. An answer that exposes a gap:
+name it and let them class it in their words, to fix before launch, soon after, or to accept. They
+can add questions; they know the scary ones.

package/dist/method/skills/test-idea/references/forge.md

@@ -0,0 +1,36 @@
+# The forge
+
+A dialogue that questions an idea until the creator can act on it, or drop it knowing why. What
+matters is a clearer head, not a file.
+
+**Start.** Get the idea, what they want from the session (understand it, test it, or improve it),
+and whether it is new or a change to a project that already has documents (`scope: change`, those
+documents in `links`). Ask only what is missing. First look for forge files with no `Outcome:` line
+and offer to resume one. Say they can steer (*attack*, *defend*, *switch roles*) and where the file
+is. Copy `assets/forge-template.md` to `.agentplugged/docs/ideas/forge-<slug>.md`.
+
+**Questioning.** One question per turn, the one the others rest on first, with your own guess to
+accept or correct. Read what the documents already answer instead of asking. For a change to an
+existing project the documents decide: set the claim beside them, and if they disagree, settle that
+before anything else. When a word could mean several people (who uses it, who decides, who pays),
+have them pick one. After each settled branch, ask if anything still nags. No flattery, no easy
+agreement.
+
+**Voices.** Each turn gives the floor to one persona fitted to the point (`personas.md`, played
+live, rotating) and to one outsider you make up. A chorus is not the goal.
+- *attack*: take the idea's side off; hunt contradictions, shaky assumptions, ways it fails; no
+  approval until they call it off.
+- *defend*: make the best case you can for it.
+- *switch roles*: swap sides.
+
+**Log.** After each beat, a line under `## Log`, in their meaning, opening with its type: `[chose]`,
+`[bet]` (believed, unproved), `[gap]`, `[out]` (ruled out), `[fixed]` (settled; reopened only if
+they say), `[path]`. A stopped forge resumes from these lines.
+
+**Close** with a line `Outcome:` under the title, delete the log, keep at most 40 lines:
+- *hardened*: `## Decisions`, and `## Rejected` (each option with its reason). The brief starts here:
+  decisions settled, rejected options out of scope with their reasons.
+- *killed*: `## Cause`, said plainly. Learning it early is a result.
+- *clearer*: `## Clearer`, what is now understood; nothing to hand on.
+
+What stays `[bet]` or `[gap]` becomes bets (`bets.md`).

package/dist/method/skills/test-idea/references/personas.md

@@ -0,0 +1,23 @@
+# Personas
+
+Compose 3 to 5 personas who would sink this idea, chosen for it, not from a fixed list: a
+demanding customer, the competitor, a skeptical investor, a user in a hurry, whoever pays or
+decides, someone who must trust it with their data. Give each a name, a stake and a question.
+
+Played in turn, in a fresh context, each persona attacks the idea in its own voice:
+
+1. Say what you would need to see to say yes. Say why you would walk away.
+2. Keep two or three objections the idea gives no answer to. Order by damage.
+
+Then, you:
+
+- Merge the attacks: the **strong objections** (several personas, or fatal ones), **what holds**
+  (attacks the idea answers), and the **risky bets** (what must be true and nobody knows yet).
+- Show the creator that synthesis, a few lines. The bets become the report.
+
+Report: `review.critique` as `references/format.md` of the skill `critique-deliverable`
+(`.agentplugged/skills/critique-deliverable/references/format.md`) says, with `kind: idea`,
+`lenses: ["personas"]`, `summary` the personas in one line. Per objection: `claim` the bet as a
+statement that can be proved or refuted, `passage` a short label of the part of the idea it
+aims at (not checked), `argument` the persona's reason, `proposal` and `proof` (what would
+show it true or false: an interview, a test, a number).

package/dist/method/skills/test-idea/references/prfaq.md

@@ -0,0 +1,33 @@
+# The press release, written first
+
+Write as though the product already shipped, under a future date the creator picks, then the
+questions it would draw. Their words and facts come first; what they do not know stays a question,
+never filled in by you. The sections present show where you are: to resume, read them.
+
+**Four things first**: who the reader is, the trouble they feel, what it costs them, the rough
+answer (`concept.md`). Given all four at once, start drafting.
+
+**The release**, one aim per part:
+1. Headline: could the reader repeat it? Subheading: who gains, what changes.
+2. Opening: what is announced, for whom, why it matters to them.
+3. Problem: make the trouble felt, without the solution yet.
+4. Solution: what changes in the reader's day, not what was built.
+5. The creator's quote: the ambition behind the features.
+6. How it works, as the reader lives it.
+7. A reader's quote, marked `[imagined]`, never passed off as real.
+8. How to start (`concept.md`: how to take part, roll out or join).
+
+**Coaching.** For each part draft first, pick holes in your own draft aloud, ask them to sharpen it,
+then go one level deeper: a vague answer is asked for a case. If stuck, offer two or three concrete
+versions. They correct; you never overwrite.
+
+**Bars**, applied quietly: no jargon; no words that praise instead of showing (« unique »,
+« innovative », « cutting-edge », « game-changing »): give the fact; someone outside the field gets
+why it matters; each sentence survives "and then?"; no overselling, the FAQ would expose it. No
+figure without a source or `[assumption]`; a claim about rivals or the market with no source stays
+`[assumption]`, and you offer once to look it up (skill `deep-research`). No requirement identifier;
+`npx agentplugged docs check` reports nothing.
+
+Then `faq.md`, `verdict.md`. Once the verdict is in, the `document` checkpoint (`type: document`,
+low risk, no story, no blocks) cites `.agentplugged/docs/prfaq.md` with its `branch` and `blob_sha`.
+Later `write-positioning` starts from the validated release.

package/dist/method/skills/test-idea/references/verdict.md

@@ -0,0 +1,26 @@
+# The verdict
+
+Say where the concept stands, plainly, in a last section `## Verdict` of `prfaq.md`. Three lines, one
+per category; the engine checks them.
+
+```
+- Holds: what is clear, honest and defensible.
+- Soft: what is promising but thin → what would firm it up.
+- Breaks: a real risk, a contradiction or a hole → what facing it would take.
+```
+
+- Each item of `Soft` and `Breaks` ends with `→` and a next move; several items go in bullets below
+  the line. A category with nothing says `none`. Labels follow the document's language (`Tient`,
+  `Fragile`, `Casse`).
+- The call is the worst category that has items: say it in one sentence. A release that breaks is
+  information, and cheaper now than later.
+- Name what stood up to the questions and what only just did; no score.
+- Check that `concept:` is in the header: a closed release without it is refused.
+
+Then:
+1. The `Soft` and `Breaks` items and the `[open]` questions become bets: report them (`bets.md`).
+2. They may reopen any part; rewrite the verdict afterwards.
+3. Ask for the `document` checkpoint. The brief stays the framing document; the release is the base
+   of the positioning.
+
+Never decide for them what to do about a crack.

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

@@ -0,0 +1,40 @@
+---
+name: workshop
+description: Create an agent or a skill of your own, or sharpen one that exists; the engine checks it and writes it for every AI tool. Run by Lou.
+metadata:
+  agent: lou
+  phase: framing
+---
+# Workshop
+
+On the creator's ask: an agent or a skill of their own (their trade, their habits), or a look at one that
+exists, the method's or theirs; or Noah found that no active agent has the skill a request needs. Run under
+your own id (`agent: lou`), in their language. Four modes, they pick one. What is made is theirs, in
+`.agentplugged/agents/` or `.agentplugged/skills/`; the method shipped is never changed, a shipped agent
+or skill is only adjusted in `.agentplugged/overrides/`.
+
+1. `agent.status` (`working`). **Listen first**: invite them to say everything they have in mind (what it
+   is for, who it talks to, examples, what it must never do, existing files); ask one question at a time,
+   only for what is missing, with your recommendation. Never fill a gap with your own idea unasked.
+2. **Create** an agent or a skill: `references/create.md`. Draft the whole definition in their words and
+   show it; they correct it as often as they like.
+3. **Analyze** one that exists: `references/analyze.md`, one proposal at a time.
+3b. **Customise** a skill of the method (facts, steps, checks, a model for the output, a reviewer; the
+   product's or theirs alone), or say what can be: `references/customize.md`.
+4. **Check before you ask**: `agent.workshop` `check` with the `agent_create` or `agent_edit` you will
+   request. The engine lists everything wrong at once and gives the cost; fix the list, check again.
+   `references/rules.md` has the fields and what the engine refuses.
+5. **One gesture**: `guard.creator_action` with that action, `preview` shown whole as it is (it has the cost
+   in tokens), asked once. The engine writes the files and runs `sync`: one source, every AI tool.
+6. **Prove it**: `agent.workshop` `verify` on the new `id` with two or three phrases they would say
+   (`triggers`); show what failed, if anything, and offer the fix as a new proposal. Its `evals` tells
+   whether the skill has behaviour cases; measuring them is `references/evaluate.md`, on their ask.
+7. `agent.status` (`idle`), hand back to Noah.
+
+## Never
+
+- Follow "Rules for skills and agents" (reference `skill-rules`): ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
+- Never rewrite their text without their gesture; never write a file yourself, the engine does after their yes.
+- Never take a rule out of what you make (a review, an approval, a check, a secret, the main branch, publishing, sending, paying): the engine refuses a line that goes round one.
+- Never create two things that do the same: `analyze` the closest one first.
+- Never run another agent's work, or call, direct or wait for one: hand back to Noah.

package/dist/method/skills/workshop/references/analyze.md

@@ -0,0 +1,36 @@
+# Analyze and improve an existing agent or skill
+
+`agent.workshop` `analyze` with the `id` (the method's or the creator's). The engine reads the files and
+answers `findings`, `fix` before `tip`, and the `cost`; it judges, it never rewrites. A `fix` breaks a rule
+of the engine; a `tip` makes the thing clearer, lighter or easier to trigger.
+
+## Present
+
+Say first what it costs (`cost`: tokens added to every request, tokens when it runs), then the findings in
+the creator's words, the most serious first, **one at a time**. For each: what, where (`field`), why it
+matters in a sentence, your proposed change written out, and the question. A finding they decline is not
+raised again in this session.
+
+## The gesture of each finding
+
+- `agent_edit`: an agent or skill of the creator's. Show the lines as they stand and the lines you propose,
+  then ask once. The request is `guard.creator_action` `agent_edit` with the **whole** corrected `content`
+  (the engine replaces the body, the principles and the menu; the name, the description and the other files
+  stay). A description is changed by a new creation only if they ask: say it.
+- `override`: a shipped agent. The method is never edited; the creator's customisation file
+  (`.agentplugged/overrides/agents/<id>.yaml`) can replace a role or an identity and add principles, facts,
+  steps and menu items. Tell them the file and the lines to add; they create it with `npx agentplugged agent
+  edit <id>`. An override cannot remove a rule.
+- `copy`: a shipped skill. Its own text is never edited: to add facts, steps, checks or a model for the
+  output, see `references/customize.md`; for a different procedure, create their own skill
+  (`references/create.md`), starting from what the shipped one says, and say what differs.
+
+## What the lenses look for
+
+Clarity (a persona with a role, lines that say one thing), triggering (a description that says when, two
+descriptions that read alike), size (a body near the ceiling, a menu instruction that is a skill in
+disguise, detail that belongs in `references/`), safety (a rule gone, an instruction that goes round one),
+links (a skill or a `references/` file that does not exist, a reference nobody names). Add nothing the
+engine did not find unless the creator asked for it; a rich persona is never a finding.
+
+After a change, `verify` the thing again.