Stage 1 · discover

Product manager pack reference

Every skill in the Product manager pack — what it makes, when to use it, what it needs, its quality bar, and what it hands off to.

Direction to requirements: PR/FAQs, strategy frameworks, OKRs, business cases, interviews, PRDs, journey maps, and success measurement.

Skills

business-case

Build a business case for a build/buy/defer investment decision — do-nothing always included as the baseline, benefits quantified as re-runnable calculations with confidence tags, full costs (build + run + opportunity), ranges instead of false precision, and the flip-assumption named.

Tier heavy · v0.1.1 · SKILL.md · skill page

Use it when the user needs to justify an investment, write a business case, compare build vs buy vs defer, or get budget/sponsor approval for an initiative.

A good result:

• Option 0 is present and costed. A case that doesn't price the status quo hasn't established there's a problem worth money.
• Every benefit is a re-runnable calculation with sourced inputs and a confidence tag. Reviewers check arithmetic; they can't check adjectives.
• Outputs are ranges; the case says which end is likelier. False precision fails the doc even when the direction is right.
• All three cost layers appear per option — build, run, opportunity — with the displaced work named, not waved at.
• The flip-assumption is identified and, where confidence on it is low, a de-risking step is proposed before full commitment.
• The recommendation is singular and the runner-up's best argument is stated fairly. A case that strawmans the alternative converts no skeptics.
• The ask is the first thing read — option, cost, benefit range, deadline, in under 40 words.

Not for:

• The investment decision is already made — go to prd-draft
• Choosing between technologies for an approved initiative — the investment is already decided; compare the options directly
• Compressing an existing case for execs — exec-summary
• Trivial cost ("should we buy a $400/yr tool") — the case costs more than the decision; just decide

feedback-synthesis

Turn raw customer feedback — interview notes, support tickets, NPS or CSAT verbatims, app-store reviews, sales-call notes — into ranked themes a product decision can rest on, each a problem statement rather than a feature request, counted by distinct people or accounts not mentions, with segments, severity kept separate from frequency, verbatim quotes with source IDs, what people value, where sources disagree, what the sample cannot tell, and the questions for the next interviews. A stdlib script computes the counts.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it when the user says "what are customers telling us", "synthesise this feedback", "find the themes in these tickets / reviews / NPS comments", "affinity map these interview notes", or "what should we fix first based on feedback".

Needs: Python 3 for its scripts (standard library only).

A good result:

• Every count is distinct people or accounts, computed from the coded items, and says which unit; mentions appear only beside it.
• The ranking puts severity before frequency and says so where the two disagree.
• Every theme title is a falsifiable problem statement naming who and what it costs; no theme is titled with a proposed feature.
• Every quote is verbatim with a source ID; paraphrase never sits inside quotation marks.
• Segments are reported per theme, and a one-segment theme is called out.
• Each source's sampling bias is named, and no percentage of the whole user base is drawn from a self-selected sample.
• What people value and where the sources disagree are both present.
• Interview questions are tied to themes, open, and include one that could disconfirm the top theme.
• Nothing is invented: no quote, count, segment, reason or customer that isn't in the input.

Hands off to: brief-intake when the ranked themes and their evidence are agreed; requirements-interview when the synthesis ends with open questions that only new interviews can answer.

Not for:

• Planning or running the interviews themselves, or writing the question guide — requirements-interview
• Mapping the stages of a journey a customer goes through — user-journey-map
• Answering a research question from papers, reports or articles — source-synthesis
• Ranking rival explanations for a metric change ("why did churn rise in March?") — hypothesis-comparison
• Turning agreed findings into a brief for a PRD or design doc — brief-intake
• Cleaning up a tracker backlog: duplicates, stale tickets, ordering — backlog-triage

lean-canvas

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.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it 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".

Needs: Python 3 for its scripts (standard library only).

A good result:

• 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.

Hands off to: feedback-synthesis when the problem interviews from the top test have been run and the notes are in; business-case when the riskiest assumptions have passed their tests and the idea needs money or headcount approved.

Not for:

• 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

okr-cascade

Cascade company OKRs to team-level OKRs — with a gap registry for objectives no team credibly owns, and a causal metric tree connecting each team KR to the north-star it's supposed to move.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it when the user wants to set or cascade OKRs, align team goals to company goals, "turn strategy into quarterly objectives", or audit existing OKRs for gaps and vanity metrics.

A good result:

• Company OKRs appear verbatim, and every restated one is marked as restated with the reason.
• Every team KR has its causal sentence naming the company KR it feeds and the mechanism. "Aligns with company goals" is not a mechanism.
• Every team KR is scorable 0.0–1.0 and measurable at the team's own scope. Binary deliverables are tasks — they can live under a KR, not as one.
• Output KRs are flagged at every level, each with the outcome it presumably serves.
• The gap registry is present and ranked — even when its honest content is "none found; here's why that's suspicious".
• The metric tree has one north-star, and every KR is attached, labeled guardrail, or explicitly cut.

Not for:

• Measuring one feature's success — success-metrics (it declares org OKRs out of scope; this skill returns the favor)
• No strategy exists to cascade — strategy-analysis or prfaq first
• Sprint/backlog prioritization — OKRs are aims, not a work queue
• Individual performance goals — cascading OKRs to persons turns a steering tool into a rating tool, and both break

prd-draft

Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc.

A good result:

• The problem statement passes the alternative-solution test. If only one solution could follow from it, it's a spec, not a problem.
• Every requirement is verifiable — a tester can demo it pass/fail. Implementation choices and adjective requirements both fail.
• Won't-have list is non-empty and specific. "Out of scope: everything else" is an empty gesture; name the tempting things.
• Every goal has a success line with a number and a timeframe. "Improve agent efficiency" is a hope; "median handle time −25% within 60 days of GA" is a goal.
• Evidence is tagged to its source — [reported by X], [data: Y], [assumption]. A PRD's authority is exactly as good as its weakest untagged claim.
• It reads in 30 minutes. Length is a tax on every reviewer; appendices exist for the rest.

Hands off to: nfr-spec when the functional requirements are agreed; user-story-splitter when the requirements are ready to become units of work; design-doc when the what is agreed and the how is open.

Not for:

• The technical how — architecture, stack, data model → design-doc
• Splitting into sprint-sized work → user-story-splitter (after the PRD)
• Whether to invest at all → business-case; the PRD assumes the investment decision is made
• A tiny change that needs a ticket, not a doc → user-story-splitter or bug-triage

prfaq

Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus the customer FAQ and internal FAQ that force the hard questions before engineering starts.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it when the user wants a PRFAQ, a working-backwards document, a "write the press release first" exercise, or needs to align stakeholders on what a product must be before committing a team to build it.

A good result:

• The problem paragraph is in the customer's words. If it contains a term the customer wouldn't say out loud, it fails.
• The first-success event is behavioral and observable — you could watch a session recording and mark the moment it happened.
• The solution names a mechanism, not a category. "Uses AI" describes a decade of products; what does this one do differently?
• At least one customer-FAQ answer concedes a trade-off. Honesty in the FAQ is what separates a forcing function from a pitch.
• The internal-FAQ success metric counts the first-success event — not sign-ups, not launches, not page views.
• The kill condition is named. A PRFAQ that can't say what failure looks like hasn't confronted the riskiest assumption.
• No spec content. Zero API shapes, acceptance criteria, or backlog items — those belong downstream in prd-draft.

Not for:

• The product is committed and needs requirements — that's prd-draft
• The question is invest/defer with costed options — that's business-case
• Real launch marketing copy for a product that exists — this is a thinking tool, not copywriting
• Org-level strategy or portfolio questions — strategy-analysis

requirements-interview

Generate per-stakeholder interview kits for feature discovery — ≤7 questions per stakeholder ranked by how much the answer changes the design, each naming the decision it informs, with at least one disconfirming question per script and an assumptions-to-validate ledger.

Tier standard · v0.1.0 · SKILL.md · skill page

Use it when the user is gathering business requirements, preparing stakeholder or user interviews, or asks "what should I ask the sponsor/users/ops before we build this".

A good result:

• ≤7 questions per stakeholder, ranked, each annotated with the decision it informs and how the answer moves the design. Unannotated questions don't ship.
• Zero leading questions in discovery position. Anything shaped "wouldn't it be great if…" or answerable with a polite yes fails the kit.
• Every script contains a kill-question — and the kit says what a kill-answer looks like, so the interviewer recognizes it instead of softening it.
• End-user scripts open with a concrete recent episode, never "typically".
• Every assumption in the ledger has a falsification condition. "We'll validate adoption appetite" without what-would-disprove-it is theater.
• The synthesis path is named. Kits that don't say where the notes go produce interviews that end at the notes.

Hands off to: brief-intake when the interview is done and the notes are raw.

Not for:

• The answers already exist in tickets, analytics, or support logs — mine those first; interviews are for what data can't say
• Synthesizing notes after the interviews — that's brief-intake + decision-log
• Writing the requirements themselves — prd-draft, after the interviews
• Usability testing of an existing design — different method; this is problem discovery

strategy-analysis

Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PESTLE — on a product, company, or market question, choosing the right framework for the question and forcing every cell to carry evidence and a so-what.

Tier heavy · v0.1.3 · SKILL.md · skill page

Use it when the user asks for a SWOT, a competitive/market analysis, "should we enter this market", "what's our position against X", or a macro-environment scan.

A good result:

• The framework fits the question, and the doc says why in one line. A SWOT that should have been Five Forces is a category error, not a style choice.
• Every cell passes specific/evidenced/consequential. One untagged, implication-free cell is a defect; a grid of them is a horoscope.
• SWOT always arrives as TOWS. Four lists with no crossings is inventory, not strategy.
• Every Five Forces rating names the mechanism. "Rivalry: high" without who/why is a vibe with a color.
• The implications are ranked and action-shaped, tied to the named decision — not "consider monitoring the competitive landscape".
• The verdict takes a side and names what would change it. An analysis that ends "it depends" has refused its job.

Hands off to: business-case when the direction is chosen and needs costing before approval.

Not for:

• Choosing between named technologies or vendors — the strategic question is already answered; compare the options directly
• A costed build/buy/defer decision — business-case
• Testing a specific product concept — prfaq
• Quarterly goal-setting — okr-cascade

success-metrics

Define how a feature's success will be measured before it's built — one primary metric with target, timeframe, and baseline; guardrail and counter-metrics; an instrumentation plan naming every event; and a pre-committed decision rule for what happens if the target is missed.

Tier standard · v0.1.1 · SKILL.md · skill page

Use it when the user asks "how do we know this worked", needs KPIs or success criteria for a feature, or wants a measurement/instrumentation plan before launch.

A good result:

• Exactly one primary metric, and it's an outcome, not an output or a vanity count. The doc states why it was chosen over the runner-up.
• Baseline, target, timeframe all present — or "measure baseline" is explicitly milestone 1. No target hangs in the air.
• Every metric maps to a named event marked exists/must-build. A metric without an event is fiction with a chart placeholder.
• The counter-metric names the gaming path. "Could this number improve while the user's life gets worse?" has a written answer.
• The decision rule is action-shaped and pre-committed — who does what at which threshold — not "we'll review the data".
• Guardrails have current values and alert thresholds, so "don't degrade X" is checkable, not sentimental.

Not for:

• No goal exists yet — prd-draft first; metrics can't rescue an unstated goal
• Org/quarterly OKR setting — this skill measures one feature, not a company
• Analyzing results after the fact — this designs the measurement; analysis is a conversation with the data
• A/B-test statistics (power, sample size) — name the need, hand to the data team; don't improvise math

user-journey-map

Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first.

Tier standard · v0.1.2 · SKILL.md · skill page

Use it when the user wants a journey map, customer experience map, "map the user's path through onboarding", touchpoint analysis, or "where do users feel friction".

A good result:

• One persona, one outcome, both named in the title. A map for "users" is a map of nothing.
• The evidence level is declared at the top and every pain that deviates from it is tagged individually.
• Stage edges live in the persona's life, not on the product's surface — the trigger precedes the product; the end state is the persona's outcome.
• Every emotion score carries its reason. A bare number row is decoration.
• Opportunities are outcomes, not features. The moment "add a button" appears, the map has started doing design's job without design's process.
• The dips, the peak, and the ending are explicitly marked, and exactly 1–2 opportunities are named as the targets. Ranking is the deliverable.
• The Mermaid renders. Scores 1–5, one section per stage — check syntax before emitting.

Hands off to: prd-draft when a friction point on the journey is worth fixing; success-metrics when the fix needs a measure before it is built.

Not for:

• Screen-by-screen interaction or flow design — that's below this altitude; the map hands off to it
• Internal/employee process mapping — this skill is outside-in; org-internal flows are a process diagram (architecture-diagrams sequence flows)
• Backstage service wiring behind the touchpoints — reverse-architecture / architecture-diagrams
• A committed feature needing requirements — prd-draft

Loops

discover

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.

Cap: 3 returns before BLOCKED. LOOP.md

Included from core

Installed with this pack. Details: Core pack reference.

• brief-intake: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake.
• context-graph: Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist.
• council-review: Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council."
• doc-critique: Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.
• output-hygiene: Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite.

Edit this page on GitHub · View source