skilldrop-cli 1.3.0 → 1.5.0

package/packs/career/loops/apply/LOOP.md

@@ -1,97 +0,0 @@
----
-name: apply
-description: Take one job posting and one resume to an application ready to send — an honest fit check, a tailored resume, a cover letter and the answers to the application form — with the candidate deciding whether to apply before any writing, and confirming every claim is true before anything is sent. Use when the user wants to apply for a job, says "help me apply for this", or wants a resume and cover letter prepared for one posting.
----
-
-# apply
-
-One application, start to send, for any job. It opens with a gate because the cheapest
-application is the one you decide not to write, and it closes with one because the candidate
-signs these documents and answers for them at interview. Both gates are **human**: an agent
-can say what the resume shows, but only the candidate knows what is true and what they want.
-
-## Stages
-
-| # | Stage | Type | Skills | Gate |
-|---|---|---|---|---|
-| 1 | `fit` | gate | [`job-fit-analysis`](../../skills/job-fit-analysis/SKILL.md) | **G6** human |
-| 2 | `tailor` | generate | [`resume-tailor`](../../skills/resume-tailor/SKILL.md) | — |
-| 3 | `letter` | generate | [`cover-letter`](../../skills/cover-letter/SKILL.md) | — |
-| 4 | `form` | generate | [`application-form-answers`](../../skills/application-form-answers/SKILL.md) | — |
-| 5 | `confirm` | verify | [`output-hygiene`](../../../core/skills/output-hygiene/SKILL.md) | **G6.1** human |
-
-## How to run this loop
-
-1. **Check the fit and stop.** Run `job-fit-analysis` on the posting, the resume and any
-   other material of the candidate's: a LinkedIn summary, a portfolio, a project. Put its
-   verdict, what could get the application rejected and its questions to the candidate,
-   including whether anything outside the resume covers a gap, then wait at G6.
-   - `PROCEED`: they are applying. Go on.
-   - `PROCEED WITH CONDITIONS`: they are applying and have answered the questions. Save
-     their answers to `notes.md`; from here on those answers are source material alongside
-     the resume.
-   - `RECONSIDER`: they are not applying. The loop ends here, and that is a good outcome.
-2. **Tailor the resume.** Run `resume-tailor` with the resume, the posting and `notes.md`
-   if it exists. It works in the resume's own format, on a copy. Carry forward its three
-   lists: "Not claimed", "Cut" and "Added from outside the resume".
-3. **Write the letter.** Run `cover-letter` with the tailored resume, the posting, `notes.md`
-   and the candidate's reason for wanting the job if they gave one. Skip this stage when the
-   posting says not to send a letter.
-4. **Answer the form.** When the application has a form with questions beyond uploading
-   the documents, run `application-form-answers` with those questions and the tailored
-   resume. Skip this stage when there is no form.
-5. **Clean the documents.** Run `output-hygiene` on the resume and the letter.
-6. **Confirm at G6.1.** Show the candidate the documents with four short lists: what the
-   posting asks for that the documents do not claim; every fact added from outside the
-   resume and where it came from; every line cut from the resume; and the form questions
-   that are theirs alone to answer. Ask them to confirm every line is true. `NOT READY` returns to `tailor` with their
-   corrections added to `notes.md`. The candidate sends the application; the loop never does.
-
-## Verdicts
-
-Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G6 emits
-`PROCEED`, `PROCEED WITH CONDITIONS`, `RECONSIDER` or `BLOCKED`. G6.1 emits `READY`,
-`NOT READY` or `BLOCKED`. `RECONSIDER` leaves the loop: the candidate's time goes to a
-better posting.
-
-## Non-interactive runs
-
-With no person present, neither gate can be satisfied. Run `fit`, deliver the analysis and
-emit `BLOCKED: need the candidate's decision to apply`. Do not decide for them, and do not
-produce documents carrying their name that they have not confirmed.
-
-## When a stage's skill is not installed
-
-Name the missing skill and skilldrop as its source, do the minimal inline version of that
-stage under the same rule (nothing the candidate didn't supply), and record that it ran
-degraded. Never skip G6.1.
-
-## Run log (opt-in)
-
-Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
-gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
-sent anywhere. When the variable isn't set, or you can't read it, skip this section.
-
-```bash
-printf '%s\n' '{"ts":"2026-10-05T14:03:00Z","loop":"apply","stage":"fit","gate":"G6","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
-```
-
-Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
-gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
-The log holds verdicts only: never the posting, the resume or the candidate's name.
-
-## Quality bar
-
-- **The candidate decides to apply before anything is written.** A tailored resume for a job they would have skipped is wasted work.
-- **Every claim in both documents traces to the resume or to something the candidate said.** Answers given at G6 are written to `notes.md`, so the trace exists.
-- **The resume, the letter and the form agree.** Same titles, dates and numbers in all three.
-- **The candidate confirms and sends.** G6.1 is their signature; the loop never submits an application.
-
-## Anti-patterns to avoid
-
-- ❌ **Skipping `fit` because the candidate is keen.** The screening requirements are what they most need to see before investing the time.
-- ❌ **Treating a `Not shown` item as true** because the candidate proceeded. Only what they answered goes in.
-- ❌ **Writing the letter from the original resume.** The letter follows the tailored one, or the two will disagree.
-- ❌ **Answering a declaration on the form** for the candidate, or leaving out the list of what was added and cut.
-- ❌ **Self-confirming at G6.1.** A clean claim check says the words are in the source; it cannot say they are true.
-- ❌ **Submitting the application.** Sending is the candidate's act.

package/packs/career/loops/apply/evals/eval_queries.json

@@ -1,9 +0,0 @@
-[
-  {"query": "help me apply for this job", "should_trigger": true},
-  {"query": "run the apply loop on this posting and my resume", "should_trigger": true},
-  {"query": "I want a tailored resume and cover letter for this role", "should_trigger": true},
-  {"query": "get my application for this job ready to send", "should_trigger": true},
-  {"query": "is this job a good fit for me?", "should_trigger": false},
-  {"query": "just write a cover letter for this", "should_trigger": false},
-  {"query": "turn these notes into a finished document", "should_trigger": false}
-]

package/packs/career/loops/apply/evals/evals.json

@@ -1,27 +0,0 @@
-{
-  "loop_name": "apply",
-  "evals": [
-    {
-      "id": "stops-at-the-fit-gate",
-      "prompt": "Run the apply loop. My resume is in resume.md and the job is in posting.md. [a warehouse supervisor's resume with a high school diploma; a posting that requires a bachelor's degree]",
-      "assertions": [
-        "Starts with job-fit-analysis and delivers its verdict before any resume or letter is written",
-        "Names the unmet bachelor's degree as a screening requirement",
-        "Stops at G6 and asks the candidate whether to apply; does not tailor the resume in the same turn",
-        "Does not advise claiming the degree or adding any keyword the resume does not support"
-      ]
-    },
-    {
-      "id": "answers-become-source-material",
-      "prompt": "Continuing the apply loop: yes I want to apply. To your questions: I do speak Spanish, and no, I've never used SAP. [same resume and posting]",
-      "assertions": [
-        "Records the gate verdict as PROCEED WITH CONDITIONS and saves the answers to notes.md",
-        "The tailored resume includes Spanish and does not claim SAP",
-        "The cover letter is written after the tailored resume and uses the same titles, dates and numbers",
-        "Runs output-hygiene on both documents before the final gate",
-        "Stops at G6.1 and asks the candidate to confirm every line is true; does not submit or send anything",
-        "Lists what the posting asks for that neither document claims"
-      ]
-    }
-  ]
-}

package/packs/career/loops/apply/loop.json

@@ -1,52 +0,0 @@
-{
-  "$comment": "RFC-0042. One job application, start to send. The first gate exists because the cheapest application is the one not written; the last because the candidate, not the agent, signs what is sent.",
-  "name": "apply",
-  "version": "0.3.0",
-  "description": "Take one job posting and one resume to an application ready to send — an honest fit check, a tailored resume, a cover letter and the answers to the application form — with the candidate deciding whether to apply before any writing, and confirming every claim is true before anything is sent. Use when the user wants to apply for a job, says \"help me apply for this\", or wants a resume and cover letter prepared for one posting.",
-  "entrypoint": "LOOP.md",
-  "kind": "loop",
-  "cap": 3,
-  "stages": [
-    {
-      "id": "fit",
-      "type": "gate",
-      "intent": "Say honestly where the candidate stands against the posting, then let them decide whether this application is worth writing.",
-      "skills": ["job-fit-analysis"],
-      "gate": {
-        "id": "G6",
-        "kind": "human",
-        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "RECONSIDER", "BLOCKED"]
-      }
-    },
-    {
-      "id": "tailor",
-      "type": "generate",
-      "intent": "Rewrite the resume for this posting from what the candidate has done and nothing else.",
-      "skills": ["resume-tailor"]
-    },
-    {
-      "id": "letter",
-      "type": "generate",
-      "intent": "Write the letter from the tailored resume, the posting and the candidate's own reason for wanting the job.",
-      "skills": ["cover-letter"]
-    },
-    {
-      "id": "form",
-      "type": "generate",
-      "intent": "Draft the application form's answers from the tailored resume, and hand back the declarations that are the candidate's alone.",
-      "skills": ["application-form-answers"]
-    },
-    {
-      "id": "confirm",
-      "type": "verify",
-      "intent": "Strip what the machine left behind, then have the candidate confirm that every line in the documents is true and theirs, and that anything added from outside the resume is right.",
-      "skills": ["output-hygiene"],
-      "gate": {
-        "id": "G6.1",
-        "kind": "human",
-        "verdicts": ["READY", "NOT READY", "BLOCKED"],
-        "revise_to": "tailor"
-      }
-    }
-  ]
-}

package/packs/product-manager/loops/discover/LOOP.md

@@ -1,82 +0,0 @@
----
-name: discover
-description: Take raw signal — interviews, journeys, a strategy question — to a requirement a human has ratified, so design starts from an agreed problem rather than an assumed one. Use when the user is deciding what to build, scoping a feature, or turning stakeholder conversations into requirements.
----
-
-# discover
-
-The first loop of the lifecycle, and the cheapest one to run twice. Everything downstream
-inherits whatever this loop got wrong, which is why it ends at a **human** gate rather than a
-script: no check can tell you that you solved the wrong problem well.
-
-## Stages
-
-| # | Stage | Type | Skills | Gate |
-|---|---|---|---|---|
-| 1 | `gather` | generate | [`requirements-interview`](../../skills/requirements-interview/SKILL.md), [`user-journey-map`](../../skills/user-journey-map/SKILL.md), [`strategy-analysis`](../../skills/strategy-analysis/SKILL.md), [`feedback-synthesis`](../../skills/feedback-synthesis/SKILL.md) | — |
-| 2 | `structure` | generate | [`brief-intake`](../../../core/skills/brief-intake/SKILL.md) | — |
-| 3 | `specify` | generate | [`prd-draft`](../../skills/prd-draft/SKILL.md) | — |
-| 4 | `ratify` | gate | [`doc-critique`](../../../core/skills/doc-critique/SKILL.md) | **G0** human |
-
-## How to run this loop
-
-1. **Gather from whichever direction the signal arrives.** A stakeholder conversation →
-   `requirements-interview`. An existing experience with known friction → `user-journey-map`.
-   An open strategic question → `strategy-analysis`. A pile of tickets, survey verbatims or
-   interview notes already collected → `feedback-synthesis`. Run one; running several on the
-   same input produces several views of the same thing and no more information.
-2. **Structure once.** `brief-intake` tags every field `[explicit]` / `[implied]` /
-   `[inferred]` / `[missing]` with verbatim quotes. The tags are the deliverable — an
-   untagged brief hides which parts are somebody's assumption.
-3. **Resolve the missing before specifying.** `brief-intake` ends with what the downstream
-   skill will refuse to start without. Answer those; do not let `prd-draft` invent them.
-4. **Specify.** `prd-draft` turns the brief into numbered requirements a design can be held to.
-5. **Ratify at G0.** Run `doc-critique` against the PRD, then put the decision to a human.
-   The critique informs; the human decides. `REVISE` returns to `structure`, not to `specify`
-   — a weak PRD almost always means a thin brief.
-
-## Verdicts
-
-Defined in [`contracts/terminals.json`](../../../../contracts/terminals.json). G0 emits `PROCEED`,
-`PROCEED WITH CONDITIONS`, `REVISE`, `RECONSIDER`, or `BLOCKED`. `RECONSIDER` leaves the loop:
-the problem itself is wrong, and no amount of re-briefing fixes that.
-
-## Non-interactive runs
-
-With no human present, G0 cannot be satisfied. Emit `BLOCKED: need ratification of <the
-brief's central claim>` and stop. Do not self-ratify — a fabricated goal corrupts every
-artifact the other four loops produce.
-
-## When a stage's skill is not installed
-
-Name the missing skill and skilldrop as its source, do the minimal inline version of that
-stage, and record that it ran degraded. Never skip G0.
-
-## Run log (opt-in)
-
-Only when the environment variable `SKILLDROP_LOOP_LOG` is set to a file path: after each
-gate's verdict, append one JSON line to that file. Nothing else is recorded, and nothing is
-sent anywhere. When the variable isn't set, or you can't read it, skip this section.
-
-```bash
-printf '%s\n' '{"ts":"2026-10-01T14:03:00Z","loop":"discover","stage":"ratify","gate":"G0","verdict":"PROCEED","round":1}' >> "$SKILLDROP_LOOP_LOG"
-```
-
-Fields: `ts` (UTC), `loop`, `stage`, `gate` (`null` for a stage without one), `verdict` (the
-gate's exact word), and `round` (1 for the first attempt, counting returns under the cap).
-`skilldrop loop-stats` summarises the file: which gates pass first time, which loop back, and
-which end in `BLOCKED`.
-
-## Quality bar
-
-- **Every field carries a provenance tag.** A brief that does not distinguish quoted from inferred cannot be ratified, only believed.
-- **`[missing]` is resolved or stated, never filled.** Inventing the goal, the customer, or the success measure is the one failure this loop exists to prevent.
-- **The requirements are numbered and testable.** "Fast" is not a requirement; a latency target is.
-- **A human ratifies before design starts.** G0 is the loop's only reason to exist — an unratified brief is a draft, whatever the critique said.
-
-## Anti-patterns to avoid
-
-- ❌ **Running every `gather` skill to be thorough.** Three lenses on one input is not three inputs; pick the one that matches where the signal came from.
-- ❌ **Letting `prd-draft` fill a `[missing]` field.** That converts an open question into a fact nobody agreed to.
-- ❌ **Treating `doc-critique`'s `SHIP IT` as ratification.** The critique judges the document; G0 judges the problem.
-- ❌ **Returning `REVISE` to `specify`.** Re-writing the PRD from the same thin brief reproduces the same gaps in better prose.

package/packs/product-manager/loops/discover/evals/eval_queries.json

@@ -1,30 +0,0 @@
-[
-  {
-    "query": "turn these stakeholder notes into requirements",
-    "should_trigger": true
-  },
-  {
-    "query": "run the discover loop on this complaint",
-    "should_trigger": true
-  },
-  {
-    "query": "what problem are we actually solving here?",
-    "should_trigger": true
-  },
-  {
-    "query": "get this idea to a ratified brief",
-    "should_trigger": true
-  },
-  {
-    "query": "split this epic into stories",
-    "should_trigger": false
-  },
-  {
-    "query": "write the design doc for this",
-    "should_trigger": false
-  },
-  {
-    "query": "review my pull request",
-    "should_trigger": false
-  }
-]

package/packs/product-manager/loops/discover/evals/evals.json

@@ -1,26 +0,0 @@
-{
-  "loop_name": "discover",
-  "evals": [
-    {
-      "id": "refuses-to-specify-on-a-thin-brief",
-      "prompt": "Run the discover loop. An account manager says enterprise customers keep hitting our API limits and are complaining.",
-      "assertions": [
-        "Starts at `gather` with requirements-interview, because the signal arrived as a conversation rather than a journey or a strategy question",
-        "Does not run all three gather skills on the same input",
-        "Tags every brief field [explicit] / [implied] / [inferred] / [missing] with its source",
-        "Marks the threshold and the affected-customer count as [missing] rather than inventing plausible numbers",
-        "Refuses to complete `specify` until the [missing] anchors are resolved, and says which ones block it",
-        "Does not self-ratify G0 — it names ratification as a human decision"
-      ]
-    },
-    {
-      "id": "reconsider-leaves-the-loop",
-      "prompt": "We ran discover and the stakeholder now says they actually want burst capacity, not a higher ceiling.",
-      "assertions": [
-        "Classifies this as RECONSIDER, a redirect-class verdict",
-        "States that a redirect leaves the loop rather than revising within it",
-        "Does not route back to `structure` for another brief on the original problem"
-      ]
-    }
-  ]
-}

package/packs/product-manager/loops/discover/loop.json

@@ -1,41 +0,0 @@
-{
-  "$comment": "RFC-0028. The first loop of the lifecycle: nothing is designed or built until a human has ratified what problem is being solved. Cheapest loop to redo and the most expensive to skip.",
-  "name": "discover",
-  "version": "0.3.0",
-  "description": "Take raw signal — interviews, journeys, a strategy question — to a requirement a human has ratified, so design starts from an agreed problem rather than an assumed one. Use when the user is deciding what to build, scoping a feature, or turning stakeholder conversations into requirements.",
-  "entrypoint": "LOOP.md",
-  "kind": "loop",
-  "cap": 3,
-  "stages": [
-    {
-      "id": "gather",
-      "type": "generate",
-      "intent": "Collect the raw signal from whichever direction it arrives: a stakeholder conversation, an existing user journey, or a strategic question.",
-      "skills": ["requirements-interview", "user-journey-map", "strategy-analysis", "feedback-synthesis"]
-    },
-    {
-      "id": "structure",
-      "type": "generate",
-      "intent": "Turn the mess into one brief with every field tagged explicit / implied / inferred / missing, so downstream can see what was assumed.",
-      "skills": ["brief-intake"]
-    },
-    {
-      "id": "specify",
-      "type": "generate",
-      "intent": "Turn the ratified brief into numbered requirements a design can be held to.",
-      "skills": ["prd-draft"]
-    },
-    {
-      "id": "ratify",
-      "type": "gate",
-      "intent": "A human agrees this is the problem worth solving. The critique informs that decision; it does not make it.",
-      "skills": ["doc-critique"],
-      "gate": {
-        "id": "G0",
-        "kind": "human",
-        "verdicts": ["PROCEED", "PROCEED WITH CONDITIONS", "REVISE", "RECONSIDER", "BLOCKED"],
-        "revise_to": "structure"
-      }
-    }
-  ]
-}

package/packs/product-manager/skills/lean-canvas/SKILL.md

@@ -1,162 +0,0 @@
----
-name: lean-canvas
-description: Turn a startup or internal-product idea into a lean canvas that finds what could kill it — the nine boxes filled only from what the user said, each entry tagged evidence-backed (with its source) or assumption, the assumptions ranked by how likely each is wrong times how badly the idea fails if it is, the cheapest test with a pass/fail line set in advance for the top ones, a computed unit-economics check when price and costs are given, and a plain call when the idea should change before anything is built. Use when the user says "lean canvas", "help me think through my startup idea", "what are the riskiest assumptions", "how do I validate this idea", "is this idea worth building", or "poke holes in my business model".
----
-
-# lean-canvas
-
-The canvas is the vehicle; the product is the assumption work. A filled-in grid tells the
-founder what they already believe. This skill tells them which belief is most likely to sink
-the idea, and the cheapest way to find out this week. For a costed invest/defer decision with
-NPV and options, use `business-case`; for the press release and FAQ of an idea already
-approved, `prfaq`; for market and competitor frameworks, `strategy-analysis`; for measuring a
-feature after it ships, `success-metrics`.
-
-## How to respond
-
-**Four rules come before the steps and outrank them:**
-
-- **Answer what was asked, first.** Open with the answer, the decision or the artifact, in plain words. Scores, matrices, frameworks and tags come after it, and anything that doesn't change the answer is cut.
-- **Use only what you were given.** Don't add facts, names, numbers, incidents, history, steps or sections the input doesn't contain. What you need and don't have is left out of the artifact and listed once at the end under "To confirm".
-- **Deliver from what you have.** When the request gives you something to work on, state your assumptions in a line and produce the result. When it gives you nothing to work on, ask for it in one or two plain sentences and say what you will do once you have it.
-- **Write for someone who has never heard of this skill.** No skill names, no paths or scripts from this folder, no internal terms, and nothing about how the run was set up. A next step is one plain sentence at the end that describes the work.
-- **For this skill:** A box with nothing behind it says so. "Unfair advantage: none yet" is a correct entry; an invented moat, channel or metric is a wrong one.
-
-1. **Fill the nine boxes from the input only.** Problem (top 1–3), customer segments with the
-   **early adopter** named separately, unique value proposition, solution, channels, revenue
-   streams, cost structure, key metrics, unfair advantage. Tag every entry `[evidence: <source
-   the user gave>]` or `[assumption]`. A box the user left empty gets `[not stated]`, not a
-   filler. Internal products: revenue becomes the budget or saving that funds it, and the
-   customer is the team that has to adopt it.
-
-2. **Grade the evidence before trusting it.** Evidence counts for a box only when it comes
-   from the stated early adopter and records behaviour, not opinion.
-   - ✅ *"7 of the 20 cycle commuters we stopped at the office rack paid for a repair in the last three months"* — behaviour, right segment.
-   - ❌ *"12 people from my running club said they'd definitely sign up"* — wrong segment (runners, not cycle commuters) and stated intent. Tag it `[evidence: running-club chat — wrong segment, intent only]` and rate the box as an assumption.
-   - A third-party statistic (*"a council survey says 2,000 people cycle to the business district"*) sizes the segment; it doesn't show they feel the problem enough to pay.
-   - A lifetime or retention figure is evidence only if the data covers that long and every
-     customer. A six-month average from a three-month pilot, or from "the ones who stuck
-     with it", is an assumption; the real lifetime is unknown and probably shorter.
-
-3. **Test the claimed unfair advantage.** An unfair advantage can't be copied or bought by a
-   funded competitor within a year: insider information, an existing audience or customer
-   base, a network effect, a community, exclusive access or contract, a team member's
-   authority. A feature, an algorithm, "AI", "first mover", "better UX" or "passion" is not
-   one; it moves to Solution or UVP. Write ✅ *"Unfair advantage: none yet. The folding
-   repair stand is a feature — any mechanic can buy or copy one. A candidate: exclusive
-   access to office car parks, if landlords grant it."* ❌ *"Unfair advantage: our
-   proprietary stand design."*
-
-4. **Check every channel against the early adopter.** For each stated channel, ask: do these
-   people go there? A channel aimed at a different buyer (a procurement conference for ward
-   nurses who buy nothing themselves, Instagram ads for commuters the input says are offline
-   all day) is a mismatch. Name it, and say who the channel does reach. If **no** stated channel reaches the early adopter, that is a change-before-building
-   finding (step 7).
-
-5. **Compute the unit economics when price and costs are given.** Never estimate. Run:
-
-   ```bash
-   # Claude Code
-   python3 "${CLAUDE_SKILL_DIR}/scripts/unit_economics.py" --price 12 --variable-cost 7 --cac 90 --lifetime 6 --fixed 6000
-   # Other IDEs (from the skill folder)
-   python3 scripts/unit_economics.py --price 12 --variable-cost 7 --cac 90 --lifetime 6 --fixed 6000
-   ```
-
-   Derive inputs from what the user gave and show the derivation (✅ *"CAC $90 = $900 ad
-   spend ÷ 10 sign-ups"*). Use one currency and one period throughout. Add `--churn` instead of `--lifetime` when churn is given,
-   `--market-customers` when the user sizes the market. The script returns gross margin,
-   LTV, CAC payback, LTV:CAC, the most a customer can cost to acquire, break-even customers
-   and where the numbers don't close. If no script can run, do the same arithmetic by hand
-   and show every line. Price or cost missing → skip this step, list what's missing under
-   "To confirm", and write no number the user didn't give.
-
-6. **Rank the assumptions by risk = likelihood wrong × impact if wrong.** Likelihood: high
-   (no evidence, wrong-segment evidence, or opinion only), medium (right segment but few
-   people or indirect), low (observed behaviour from the right segment). Impact: fatal (the
-   idea fails), pivot (a box has to change), tune (a number moves). Score 3/2/1 each and sort.
-   The riskiest assumption sits in problem, customer or channel far more often than in
-   solution, because a solution can be rebuilt in a sprint while a problem nobody has can't
-   be fixed by building. Say in one sentence why the top one beats the others **for this
-   idea**. A solution assumption ("can the matching algorithm be accurate?") ranks first only
-   when the problem and customer are already backed by behaviour. Ties: the assumption the
-   others depend on goes first (a channel test means nothing until the problem holds).
-
-7. **Say plainly when the idea should change before anything is built.** Triggers: no stated
-   channel reaches the early adopter; CAC payback is longer than the customer lifetime;
-   break-even needs more customers than the stated market holds; the only problem evidence is
-   from a different segment. Write one sentence per trigger with what has to change.
-   ✅ *"Change before building: each member costs $90 to acquire and returns $30 over six
-   months, so every sign-up adds a $60 loss."* Silence on a finding the numbers show is a
-   failure. An assumption the user's own numbers already disprove is a finding here, not a
-   test to run: a $90 CAC against a $10 ceiling needs a new channel, not more of the old one.
-
-8. **Design the cheapest test that could prove each of the top 1–3 assumptions wrong.**
-   Each test names: what to do, the sample, the pass/fail line **set before running**, the
-   cost, the time, and what changes if it fails. Use counts, not percentages, for small
-   samples. Take thresholds from step 5 where possible (the most a customer can cost to
-   acquire is the channel test's fail line). Test menu and interview rules in
-   [`reference.md`](reference.md).
-   - ✅ *"Stand at two office bike racks for a morning and ask 20 cyclists about the last
-     time their bike needed fixing; never pitch. If fewer than 6 paid for a repair in the
-     past three months, the problem is wrong. Cost: $0. Time: two mornings."*
-   - ✅ *"Put a sign-up sheet with the $12 price and a card form at one rack for a week. Fail
-     if fewer than 5 of the cyclists who stop pay the first month."*
-   - ❌ *"Validate the market."* ❌ *"Run a survey to gauge interest."* ❌ *"Build an MVP and see."*
-
-9. **Write the reply in this order.** Keep it lean: under about 500 words unless a document
-   was asked for, and shorter when the user says "quick" or "short".
-   1. **Riskiest assumption and its test**: two to four lines, first in the reply.
-   2. **Change before building**: one line per trigger from step 7, or omitted when none fired.
-   3. **Canvas**: nine rows, one line each, every entry tagged.
-   4. **Next assumptions and tests**: numbers 2–3, same shape as the first, with the risk score.
-   5. **Unit economics**: the computed lines and the flags, only when step 5 ran.
-   6. **To confirm**: what was missing, once.
-
-**Non-interactive runs** (subagent, CI, headless): a missing early adopter, channel or price
-is not asked about; the most defensible reading of the input is used, tagged `[assumption]`,
-and ranked as an assumption to test. No idea at all — no problem and no customer — emits
-`BLOCKED: need the idea: who has the problem and what the problem is`, because a canvas of
-invented boxes tests nothing.
-
-## Useful references in this skill
-
-- [`reference.md`](reference.md) — the test menu, how to set a pass/fail line, interview rules, what counts as an unfair advantage, internal-product reading of the boxes
-- [`scripts/unit_economics.py`](scripts/unit_economics.py) — gross margin, LTV, CAC payback, break-even customers and the flags (stdlib only)
-- [`examples/bike-repair.md`](examples/bike-repair.md) — worked example: an on-site bike repair subscription where the payback outruns the lifetime
-
-## Quality bar
-
-- **The first lines are the riskiest assumption and its test**, not the canvas.
-- **Every canvas entry carries a tag**, and every `[evidence]` names the source the user gave.
-- **Wrong-segment and opinion-only evidence is downgraded** and said to be.
-- **A feature claimed as an unfair advantage is moved out**, and the box reads "none yet" if nothing else qualifies.
-- **Each channel is checked against the early adopter**, mismatches named.
-- **Unit economics are computed with the derivation shown**, and payback longer than lifetime is flagged.
-- **Each top test has a sample, a pre-set pass/fail line, a cost and a time.**
-- **Nothing is invented**: no market sizes, competitors, prices, churn or channels the user didn't give.
-
-## When to use this skill
-
-- ✅ A founder's or intrapreneur's idea in their own words: "is this worth building?"
-- ✅ "Fill in a lean canvas for…" or "what are my riskiest assumptions?"
-- ✅ Planning what to test before writing code or asking for budget
-- ✅ An internal tool pitch where adoption by another team is the real bet
-
-## When NOT to use this skill
-
-- ❌ An investment case with options, NPV, payback ranges and a sponsor — `business-case`
-- ❌ The press release and FAQ for an idea that is already approved — `prfaq`
-- ❌ Market attractiveness, competitors, SWOT or Five Forces — `strategy-analysis`
-- ❌ How to measure a feature that has shipped or is about to — `success-metrics`
-- ❌ Turning interview notes or tickets already collected into themes — `feedback-synthesis`
-
-## Anti-patterns to avoid
-
-- ❌ **The tidy grid.** Nine confident boxes and no ranking: the founder learns nothing they didn't write.
-- ❌ **Accepting the moat.** "Our AI" as unfair advantage. Funded competitors copy features.
-- ❌ **Counting "they'd use it" as evidence.** Opinion about the future is the weakest signal there is.
-- ❌ **Estimating the economics.** "Margins look healthy" when a $90 CAC against $30 of lifetime margin loses money on every customer.
-- ❌ **Riskiest assumption = will the tech work.** The usual killer is that the people can't be reached or don't care enough to pay.
-- ❌ **Tests with no fail line.** "Talk to some customers" can't fail, so it can't teach.
-- ❌ **Inventing a channel or a market size** to make a box look complete.
-- ❌ **Burying "change this first"** under the canvas, or leaving it out to be encouraging.

package/packs/product-manager/skills/lean-canvas/evals/eval_queries.json

@@ -1,42 +0,0 @@
-[
-  {
-    "query": "Fill in a lean canvas for my idea: a subscription app that plans weekly meals for parents of kids with food allergies",
-    "should_trigger": true
-  },
-  {
-    "query": "What are the riskiest assumptions in my startup idea, and how do I test them before I write any code?",
-    "should_trigger": true
-  },
-  {
-    "query": "Poke holes in my business model — $49/month, we pay about $300 to get each customer, they stay around five months",
-    "should_trigger": true
-  },
-  {
-    "query": "I want to pitch an internal tool to the ops leadership team. Is it worth building, and what should I validate first?",
-    "should_trigger": true
-  },
-  {
-    "query": "How do I validate this idea cheaply this month? It's a marketplace for renting camping gear between neighbours",
-    "should_trigger": true
-  },
-  {
-    "query": "Write the business case for the new routing platform with build, buy and do-nothing options and NPV for the steering committee",
-    "should_trigger": false
-  },
-  {
-    "query": "The exec team approved the idea — write the press release and FAQ working backwards from launch",
-    "should_trigger": false
-  },
-  {
-    "query": "Run a Five Forces analysis on the meal-kit market before we decide whether to enter",
-    "should_trigger": false
-  },
-  {
-    "query": "What should we measure to know whether the new onboarding checklist worked after it ships?",
-    "should_trigger": false
-  },
-  {
-    "query": "Here are 30 customer interview notes — find the themes and what we should fix first",
-    "should_trigger": false
-  }
-]