skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/product-manager/skills/prfaq/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: prfaq
+description: 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. Use 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.
+---
+
+# prfaq
+
+The working-backwards forcing function: write the launch press release *before* the product exists, then answer the questions a real customer and a skeptical insider would ask. If the press release can't be written specifically — a nameable customer, a problem in their words, a benefit you could measure — the product isn't ready to spec, and surfacing that is the deliverable. Sits upstream of `prd-draft` (requirements for a committed product) and `business-case` (invest/defer decision): the PRFAQ decides whether the idea deserves either.
+
+## How to respond
+
+1. **Pin the three anchors** — customer, problem, differentiator. Ask at most 2 questions, spent on the weakest anchors: *"Who exactly is the customer, and what do they do today instead?"* and *"What does this do that the thing they use today doesn't?"* A PRFAQ for "everyone" with a problem stated in industry jargon produces a marketing document, not a forcing function — don't start drafting until all three anchors are concrete. Non-interactive run (no user to ask): derive missing anchors from the input where defensible and tag them `[assumption]` at the top; an anchor with no defensible derivation → emit `BLOCKED: need <anchor>` naming what to rerun with, instead of fabricating a customer.
+
+2. **Write the press release** — one page, datelined with a city and a realistic launch date; no product name exists yet → invent a plausible working name and mark it as a placeholder. The blocks:
+   - **Headline**: product name + the customer benefit in one sentence. ✅ *"Acme Contracts cuts routine contract review from three days to twenty minutes for in-house legal teams"* — ❌ *"Acme launches AI-powered legal platform"*.
+   - **Sub-headline**: the one key detail the headline compressed (who it's for, what it replaces, or the mechanism).
+   - **Problem paragraph**: the customer's current pain *in their words*. ✅ *"I can't close a deal until legal clears the paperwork, and legal is three days behind"* — ❌ *"lack of operational visibility into contract workflows"*.
+   - **Solution paragraph**: what the product does and what it does *differently* from the alternative the customer already uses. "AI-powered" is not a differentiator; the mechanism is.
+   - **Leadership quote**: one sentence naming the strategic rationale, attributed to a role (*"our VP of Product"*), never a placeholder name. If the rationale can't be articulated, that's a finding — report it.
+   - **Customer quote**: a named-persona customer describing the before/after in concrete terms — a specific moment, not adjectives.
+   - **Call to action**: what the customer does next to get started.
+
+3. **Derive the adoption hypothesis** — two lines that make the press release falsifiable:
+   - **First-success event**: the one *customer* action that proves first value landed, observable within a session. ✅ *"Legal counsel approves their first AI-reviewed contract without re-reading it line by line"* — ❌ *"user completes onboarding"* — ❌ *"we launch to beta"* (that's the team's action, not the customer's).
+   - **Repeat-value behavior**: what brings the customer back after first success.
+
+   Can't name a first-success event → the problem paragraph is too vague; go back to step 2 before continuing.
+
+4. **Write the customer FAQ** — 3–5 questions a real buyer asks before switching: price, switching cost, reliability, "how is this different from `<what they use today>`", data/privacy. Answer honestly, and **at least one answer must concede a real trade-off**. A FAQ where every answer is good news is an ad.
+
+5. **Write the internal FAQ** — the questions a skeptical insider asks, each with a committed answer:
+   - The **riskiest assumption** — the belief that, if wrong, kills the product — and how it will be tested first.
+   - The **hardest technical or operational problem** and why it's believed solvable.
+   - The **acquisition path** — how the first 10 customers concretely arrive (not "marketing").
+   - The **success metric** — traceable to the first-success event from step 3. "User count" when first success is an approval event is a vanity metric; the metric must count the event.
+   - **What would make us kill this** — a named condition, not "if it doesn't work out".
+
+6. **Run the read-aloud pass, then emit** with [`templates/prfaq.md`](templates/prfaq.md): could a non-technical reader retell the problem and solution after one read? Is every claim in the press release either measurable or attributed? Anything failing gets rewritten before the artifact ships. Close with the hand-off line: idea survives → `prd-draft` (requirements) or `business-case` (the investment ask); riskiest assumption unproven → the test for it comes first.
+
+## Useful references in this skill
+
+- [`templates/prfaq.md`](templates/prfaq.md) — press release blocks, adoption hypothesis, and both FAQ skeletons
+
+## Quality bar
+
+- **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`.
+
+## When to use this skill
+
+- ✅ A product or feature concept exists but no team is committed yet — test the direction before the spec
+- ✅ "Write the press release first" / "do a working-backwards doc" / "Amazon-style PRFAQ"
+- ✅ Stakeholders disagree about what a product *is* — the press release forces one answer
+- ✅ A founder or PM needs to discover whether an idea survives its own hard questions
+
+## When NOT to use this skill
+
+- ❌ 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`
+
+## Anti-patterns to avoid
+
+- ❌ **PRFAQ as a spec.** The moment acceptance criteria or API shapes appear, it's stopped forcing direction and started doing `prd-draft`'s job badly.
+- ❌ **Jargon-laundered problems.** "Lack of cross-functional visibility" is how a vendor talks. "I can't tell if my team is blocked" is how a customer talks. Only the second belongs in the press release.
+- ❌ **Placeholder quotes.** "[CEO name]: 'We're excited…'" defeats the exercise — the quote exists to force the strategic rationale into one attributable sentence.
+- ❌ **Launch-as-adoption.** "Ship to beta" as first success conflates the team's delivery with the customer's value. First success is something the *customer* does.
+- ❌ **Moat without mechanism.** Claiming defensibility without naming what makes it hard to copy — data advantage, network effect, workflow lock-in — is a wish wearing a strategy's clothes.
+- ❌ **All-good-news FAQs.** If the customer FAQ reads like the pricing page, the hard questions were dodged and the document proves nothing.
+- ❌ **Showing the machinery.** The reply and the artifact are for the person who asked. Don't mention this skill, its files, templates, caps or internal terms, or that the run is non-interactive. Name another skill once, at the end, as a suggested next step, never inside the artifact.

skilldrop_cli/data/packs/product-manager/skills/prfaq/evals/eval_queries.json

@@ -0,0 +1,13 @@
+[
+  { "query": "Write a PRFAQ for our new product idea", "should_trigger": true },
+  { "query": "I want to write the press release before the product exists", "should_trigger": true },
+  { "query": "Help me do an Amazon-style working-backwards doc for this concept", "should_trigger": true },
+  { "query": "We need to align stakeholders on what this product actually is before engineering starts", "should_trigger": true },
+  { "query": "Write the press release and FAQ for this idea and tell me if it survives its own hard questions", "should_trigger": true },
+
+  { "query": "Draft the product requirements doc for the new feature", "should_trigger": false },
+  { "query": "Write a business case for building vs buying this tool", "should_trigger": false },
+  { "query": "Write the marketing copy for our launch homepage", "should_trigger": false },
+  { "query": "Run a SWOT analysis on our product line", "should_trigger": false },
+  { "query": "Write release notes for what we shipped this sprint", "should_trigger": false }
+]

skilldrop_cli/data/packs/product-manager/skills/prfaq/evals/evals.json

@@ -0,0 +1,32 @@
+{
+  "skill_name": "prfaq",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write a PRFAQ for an AI-powered contract review tool aimed at in-house legal teams at mid-market companies. The problem: legal teams spend 60% of their time on low-complexity contract review that blocks deal closure.",
+      "assertions": [
+        "Press release contains all blocks: headline, sub-headline, problem paragraph, solution paragraph, leadership quote, customer quote, call to action",
+        "The headline names the product and a customer benefit — not a category claim like 'launches AI-powered platform'",
+        "The problem paragraph is in the customer's words with no industry jargon",
+        "The solution paragraph names a mechanism, not just 'uses AI'",
+        "The leadership quote is attributed to a role (not a placeholder name) and states a strategic rationale",
+        "An adoption hypothesis names a first-success event that is a customer action, observable within a session — not 'signs up', 'completes onboarding', or a team action like 'launch'",
+        "A repeat-value behavior is named",
+        "Customer FAQ has 3-5 questions and at least one answer concedes a real trade-off",
+        "Internal FAQ names the riskiest assumption with a test, the hardest technical problem, a concrete acquisition path, and a kill condition",
+        "The internal-FAQ success metric counts the first-success event, not a vanity metric",
+        "No acceptance criteria, API shapes, or backlog items appear anywhere",
+        "The output ends with a hand-off pointing to prd-draft or business-case"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "[Non-interactive run — no user available to answer questions] Write a PRFAQ.",
+      "assertions": [
+        "No press release is fabricated — with no customer, problem, or differentiator derivable, the output is a BLOCKED response",
+        "The BLOCKED output names the missing anchors (customer, problem, differentiator) and what to rerun with",
+        "No invented product, customer segment, or problem statement appears"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/prfaq/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "prfaq",
+  "version": "0.1.1",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["business-case", "prd-draft", "strategy-analysis"],
+  "tags": ["prfaq", "working-backwards", "press-release", "product-strategy", "product-direction", "amazon"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a press release and FAQs from a product concept against a fixed format. The specificity discipline needs care but the template bounds it; escalate via ambiguous-input when the concept itself is contested." }
+}

skilldrop_cli/data/packs/product-manager/skills/prfaq/templates/prfaq.md

@@ -0,0 +1,60 @@
+# PR/FAQ: {Product name}
+
+> Status: DRAFT — working-backwards document, not a spec.
+> Author: {role} · Date: {date} · Imagined launch date: {launch-date}
+
+## Press release
+
+**{Headline: product name + customer benefit in one sentence}**
+
+*{Sub-headline: the key detail the headline compressed}*
+
+{CITY} — {launch-date} — {Problem paragraph: the customer's current pain, in their words. What do they do today, and where does it hurt?}
+
+{Solution paragraph: what the product does, and the mechanism that makes it different from what the customer uses today.}
+
+"{Leadership quote: one sentence naming the strategic rationale}," said {role, e.g. "the VP of Product"}.
+
+"{Customer quote: a named persona describing a concrete before/after moment}," said {persona name, role at company-type}.
+
+{Call to action: what the customer does next to get started.}
+
+## Adoption hypothesis
+
+- **First-success event:** {the one customer action that proves first value — behavioral, observable within a session}
+- **Repeat-value behavior:** {what brings the customer back after first success}
+
+## Customer FAQ
+
+<!-- 3–5 questions a real buyer asks before switching. At least one answer concedes a trade-off. -->
+
+**Q: How is this different from {what they use today}?**
+A: {honest answer, mechanism not category}
+
+**Q: What does it cost / what's the switching cost?**
+A: {…}
+
+**Q: {reliability / data / privacy question}**
+A: {answer that concedes the real trade-off}
+
+## Internal FAQ
+
+**Q: What's the riskiest assumption, and how do we test it first?**
+A: {the belief that kills the product if wrong} → {the cheapest test}
+
+**Q: What's the hardest technical/operational problem?**
+A: {…, and why we believe it's solvable}
+
+**Q: How do the first 10 customers concretely arrive?**
+A: {named path, not "marketing"}
+
+**Q: What's the success metric?**
+A: {a count of the first-success event, with a target and timeframe}
+
+**Q: What would make us kill this?**
+A: {a named condition}
+
+## Hand-off
+
+- Idea survives → `prd-draft` (requirements) or `business-case` (the investment ask)
+- Riskiest assumption unproven → design its test before anything else

skilldrop_cli/data/packs/product-manager/skills/requirements-interview/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: requirements-interview
+description: 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. Use 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".
+---
+
+# requirements-interview
+
+Builds the elicitation kit for the conversations *before* the PRD — so the answers come back in a shape `brief-intake` and `prd-draft` can consume, instead of as ten pages of agreement with the roadmap. The discipline: every question names the decision it informs, problems are asked about instead of solutions, and every script tries at least once to kill the feature.
+
+## How to respond
+
+1. **Pin the feature idea and identify the stakeholder cast.** From the idea, derive who holds which unknowns — typically: **sponsor** (success definition, constraints, appetite), **end users** (the actual workflow and workarounds — interview the people who do the work, not their manager), **ops/support** (failure modes, ticket reality, operational cost), **security/compliance/legal** (data constraints, regulatory floor), **finance/commercial** (pricing, cost ceiling) when money moves. Ask the user at most 2 questions — who's available, and what's already known — then build kits only for stakeholders who hold *open* unknowns. No interview exists to confirm what's already evidenced.
+
+2. **Write ≤7 questions per stakeholder, ranked by design impact.** Rank 1 is the answer that most changes what gets built. Each question carries two annotations: **informs** (the decision) and **if-answer-is-X-then** (how the design moves). A question that wouldn't change anything regardless of answer doesn't make the seven. ✅ *"Walk me through the last time you handled a refund request — every tool you touched."* (informs: scope of integration; if 3+ tools → unified view is the core, not a nicety) — ❌ *"Would a refund dashboard be useful?"* (everyone says yes to free things).
+
+3. **Ask about problems and the past, never solutions and the hypothetical.** People are reliable witnesses of what they *did* and unreliable predictors of what they'd *use*. ✅ *"What did you do the last time X failed?"* — ❌ *"Would you use a feature that prevents X?"*. Solutions offered by stakeholders get recorded as evidence of pain, then converted back into the underlying problem.
+
+4. **Include at least one disconfirming question per script** — the question whose answer could kill or shrink the feature: ✅ *"If this never gets built, what would you do instead — and how bad is that, honestly?"* / *"Who would be annoyed if we built this?"*. A kit with no kill-question is a confirmation ritual with a calendar invite.
+
+5. **Add the workflow-walkthrough opener for end users.** First substantive question is always a concrete recent episode ("the last time", "yesterday's"), not a generality ("typically", "usually") — generalities retrieve self-image; episodes retrieve facts. Instruct the interviewer to capture **verbatim quotes** — they become the evidence tags in `prd-draft`.
+
+6. **Build the assumptions-to-validate ledger.** Every assumption the feature idea rests on, each mapped to: which stakeholder's which question validates it, and **what answer falsifies it**. An assumption no question can falsify gets flagged — it needs data or a prototype, not an interview.
+
+7. **Emit with [`templates/interview-kit.md`](templates/interview-kit.md)**: one kit per stakeholder (30-minute shape: opener episode → ranked questions → kill-question → "who else should I talk to"), the assumptions ledger, and the synthesis instruction — notes go to `brief-intake` (one brief per interview, then merge) and decisions surface via `decision-log`.
+
+## Useful references in this skill
+
+- [`templates/interview-kit.md`](templates/interview-kit.md) — per-stakeholder kit skeleton + the assumptions ledger
+
+## Quality bar
+
+- **≤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.
+
+## When to use this skill
+
+- ✅ Discovery phase before a PRD — deciding what to ask whom
+- ✅ "What should I ask the sponsor / users / ops about this feature?"
+- ✅ A feature idea built on untested assumptions that interviews could falsify
+- ✅ Preparing a requirements workshop's pre-read questions
+
+## When NOT to use this skill
+
+- ❌ 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
+
+## Anti-patterns to avoid
+
+- ❌ **The 25-question interrogation.** Past seven, answers degrade into politeness; the ranking exists because time runs out before questions do.
+- ❌ **Confirmation safari.** Every question shaped so yes means "build it" — discovery that can't disconfirm isn't discovery.
+- ❌ **Asking for the solution.** "What should we build?" outsources design to whoever's loudest; ask what hurts, design later.
+- ❌ **Interviewing the manager about the worker's workflow.** Managers describe the process diagram; workers describe the workarounds — the requirements live in the workarounds.
+- ❌ **Skipping ops/support.** They hold the failure-mode requirements nobody else knows exist, and they're the cheapest interview on the list.
+- ❌ **Hypothetical futures.** "Would you use…" — the answer is always yes and always worthless; ask about the last time, not the next time.
+- ❌ **One loud stakeholder = the requirements.** The kit covers the cast precisely so one vivid interview doesn't become the spec.

skilldrop_cli/data/packs/product-manager/skills/requirements-interview/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Build interview questions for our stakeholders on this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Who should we talk to for this discovery, and what should we ask them?",
+    "should_trigger": true
+  },
+  {
+    "query": "Create a discovery interview kit per stakeholder",
+    "should_trigger": true
+  },
+  {
+    "query": "I need non-leading questions that would actually change the design",
+    "should_trigger": true
+  },
+  {
+    "query": "Draft the PRD for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Structure this existing raw input into a brief",
+    "should_trigger": false
+  },
+  {
+    "query": "Map the customer's journey through onboarding",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the design doc for the billing migration",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/product-manager/skills/requirements-interview/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "requirements-interview",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're scoping a billing-migration feature. Build interview kits for the stakeholders we should talk to.",
+      "assertions": [
+        "Each stakeholder script has at most 7 questions, ranked by how much the answer changes the design",
+        "Every question is annotated with the decision it informs and how the answer moves the design",
+        "No leading questions in discovery position — nothing answerable with a polite yes",
+        "Every script contains a kill-question, and the kit states what a kill-answer would mean",
+        "Stakeholders are chosen and named by role, with a reason each one is on the list"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/requirements-interview/manifest.json

@@ -0,0 +1,14 @@
+{
+  "name": "requirements-interview",
+  "version": "0.1.0",
+  "description": "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. Use 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\".",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["brief-intake", "decision-log", "prd-draft"],
+  "handoff": [
+    { "to": "brief-intake", "when": "the interview is done and the notes are raw", "purpose": "Collect the transcript into a tagged brief before any generator sees it.", "fallback": "If brief-intake is absent, tag each captured field [explicit]/[implied]/[inferred]/[missing] inline and say which downstream skill the brief is shaped for." }
+  ],
+  "tags": ["discovery", "interviews", "requirements", "elicitation", "stakeholders", "user-research"],
+  "model": { "tier": "standard", "rationale": "Question banks are rubric-shaped, but ranking by design impact and deriving falsification conditions for the specific feature is synthesis — above light." }
+}

skilldrop_cli/data/packs/product-manager/skills/requirements-interview/templates/interview-kit.md

@@ -0,0 +1,63 @@
+# Interview-kit template
+
+One kit per stakeholder. 30-minute shape: episode opener → ranked questions → kill-question → referral close. Capture verbatim quotes — they become `prd-draft` evidence tags.
+
+```markdown
+# Interview kit: {feature idea}
+
+**Stakeholders covered:** {list — only those holding open unknowns}
+**Already known (don't re-ask):** {evidence that exists: analytics, tickets, prior research}
+
+---
+
+## Kit: {stakeholder role, e.g. "End user — support agent"}
+
+**Holds the unknowns about:** {what only this person can answer}
+**Time:** 30 min · **Record verbatim quotes**
+
+### Opener (end users: concrete recent episode, never "typically")
+
+1. "Walk me through the last time you {did the task}. Every tool you touched, start to finish."
+   - *informs:* {decision} · *if {answer-shape} then:* {how the design moves}
+
+### Ranked questions (≤7 total including opener and kill-question)
+
+2. "{question}"
+   - *informs:* {decision} · *if X then:* {design consequence}
+3. …
+
+### Kill-question (mandatory)
+
+n. "If this never gets built, what would you do instead — honestly, how bad is that?"
+   - *a kill-answer looks like:* {e.g. "shrug + existing workaround under 2 min" → feature shrinks or dies; write it down, don't soften it}
+
+### Close
+
+- "Who else should I talk to who'd see this differently?"
+- "What didn't I ask about that I should have?"
+
+---
+
+## Assumptions-to-validate ledger
+
+| Assumption the idea rests on | Validated by (stakeholder · Q#) | Falsified if |
+|---|---|---|
+| {e.g. agents lose ≥15 min/ticket to tool-switching} | end user · Q1 | episode shows < 5 min or a fast workaround |
+| {assumption no interview can falsify} | ⚠ not interview-validatable | needs {data pull / prototype} instead |
+
+## Synthesis path (the kit isn't done until this runs)
+
+1. Each interview's notes → `brief-intake` (one brief per interview; quotes verbatim).
+2. Merge briefs; conflicts between stakeholders are surfaced as open questions, not averaged away.
+3. Decisions and follow-ups → `decision-log`. Requirements → `prd-draft`.
+```
+
+## Question-shape cheat-sheet
+
+| ❌ Don't ask | ✅ Ask instead |
+|---|---|
+| "Would you use a dashboard that…?" | "What did you do the last time you needed {that info}?" |
+| "Is X a problem for you?" | "Tell me about the most recent time X happened." |
+| "What should we build?" | "What's the most annoying part of {task} today?" |
+| "How often does X typically happen?" | "When did X last happen? And before that?" |
+| "Do you agree this would save time?" | "What would have to be true for you to stop using {workaround}?" |

skilldrop_cli/data/packs/product-manager/skills/strategy-analysis/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: strategy-analysis
+description: 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. Use 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.
+---
+
+# strategy-analysis
+
+Runs the classic strategy frameworks the way a good strategist does and a bad deck doesn't: the framework is chosen to fit the question, every cell carries evidence and an implication, and the output ends in ranked, committal so-whats — not a filled-in grid. The grid is the working, never the deliverable. Sibling of `tech-comparison-matrix` (tech selection between named options) and `business-case` (a costed invest/defer decision); this skill is for the strategic question *before* options are named.
+
+## How to respond
+
+1. **Classify the question, then pick ONE framework** (two only when the question genuinely spans both, and say why):
+
+   | The question is about… | Framework |
+   |---|---|
+   | Our position: what to exploit, fix, or defend, feeding a near-term decision | **SWOT → TOWS** (SWOT alone is banned — see step 3) |
+   | Industry attractiveness / profit pressure: "should we enter", "why are margins thin", "can we defend" | **Porter's Five Forces** |
+   | Macro environment: regulation, technology shifts, demographics affecting a multi-year bet | **PESTLE** |
+
+   The user asked for a framework by name and it fits → run it. It doesn't fit → say so in one line and run the fitting framework instead — the quality bar treats a misfit framework as a category error, and a "SWOT" request that's really "should we enter this market" is Five Forces work; then give the framework they asked for as well, after it and shorter (a SWOT still arrives as TOWS). They asked for it by name, and a reply that withholds it reads as not listening. Portfolio-allocation questions across many products (BCG-matrix territory) → name it, note it needs per-product market-share and growth data, and run it only if that data is supplied.
+
+2. **Collect the evidence base before filling anything.** Name what is known `[data: …]`, reported `[reported by …]`, drawn from general market knowledge `[market: …]`, and assumed `[assumption]`. The `[market: …]` tag exists because on a short prompt most cells are filled from the model's own market knowledge — that's legitimate, but it must stay distinguishable from the user's facts and from guesses. Ask at most 2 questions, spent on the decision the analysis feeds ("what decision does this inform, and by when?") and the competitive set ("who do customers actually compare you to?"). No decision named → the analysis has no ranking criterion; get one before proceeding. Non-interactive run (no user to ask): derive the most plausible decision from the input, state it as `[assumption]` at the top, and rank against it; none derivable → emit `BLOCKED: need the decision this analysis feeds` rather than an unranked survey.
+
+3. **Fill the framework with cells that pass the three tests.** Every entry must be (a) **specific** — a competitor, number, or named capability, not a category; (b) **evidenced** — carrying one of the step-2 tags; (c) **consequential** — with a one-line "so:" implication. ✅ *"S: 4,000 paying tenants' workflow data no rival can train on `[data: billing]` — so: the switching cost is the moat to invest in"* — ❌ *"S: strong team"*. Framework-specific rules:
+   - **SWOT** never ships alone — cross it into **TOWS** actions: S×O (attack), S×T (defend), W×O (fix to unlock), W×T (the exposed flank, named honestly). The TOWS quadrants are the output; the SWOT grid is scaffolding.
+   - **Five Forces**: each force gets a pressure rating (🟥 high / 🟧 medium / 🟨 low) *with the mechanism* — who holds the power and why (concentration, switching costs, differentiation, substitutes' price-performance). Rate all five; "N/A" is not a rating. Complements/platforms noted where they change the picture.
+   - **PESTLE**: only factors that plausibly move *this* decision within its time horizon, each with direction, timeframe, and the exposed asset. Six sections of filler is the classic failure — 3 sharp factors beat 18 generic ones; empty letters say "no material factor identified".
+
+4. **Rank the implications and commit.** End with **Implications, ranked** — 3–5 entries ordered by impact on the named decision, each an action-shaped sentence with an owner-shaped subject: ✅ *"Price the enterprise tier before Q3: supplier power is rising (🟥) and the S×O attack window closes when the incumbent's contract cycle renews"*. Then a one-paragraph **verdict** answering the user's actual question, taking a side, and naming what evidence would change it.
+
+5. **Emit in one message**: evidence base (tag summary), the framework grid(s), ranked implications, verdict. Flag every `[assumption]` that appears in a top-3 implication — those are the validation targets. Hand off: options now named and comparable → `tech-comparison-matrix`; investment decision to cost → `business-case`; product direction to test → `prfaq`.
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ "Run a SWOT on our developer-tools product" (arrives as SWOT→TOWS)
+- ✅ "Should we enter the SMB payroll market?" / "why are margins compressing?"
+- ✅ "What macro trends threaten this 3-year platform bet?"
+- ✅ A strategy offsite needs a rigorous pre-read instead of a brainstorm
+
+## When NOT to use this skill
+
+- ❌ Choosing between named technologies or vendors — `tech-comparison-matrix`
+- ❌ A costed build/buy/defer decision — `business-case`
+- ❌ Testing a specific product concept — `prfaq`
+- ❌ Quarterly goal-setting — `okr-cascade`
+
+## Anti-patterns to avoid
+
+- ❌ **Framework theater.** Running all three frameworks "for completeness" — each unfits the others' question, and the reader drowns. One question, one framework, one verdict.
+- ❌ **Horoscope cells.** "Strength: experienced team. Weakness: limited resources. Opportunity: growing market." True of every company that ever existed, therefore informative about none.
+- ❌ **SWOT as the deliverable.** The four quadrants are raw material; the TOWS crossings are where a decision lives. Shipping the grid alone ships the homework, not the answer.
+- ❌ **Unranked implications.** Ten equal-weight bullets delegate the actual judgment to the reader — the ranking *is* the analysis.
+- ❌ **Threat inflation.** Every macro trend rated critical so nothing is. Severity must be calibrated to the named decision's time horizon and exposed assets.
+- ❌ **Evidence-free confidence.** A verdict resting on untagged claims. The tag discipline exists so the reader can see exactly which legs are load-bearing guesses.

skilldrop_cli/data/packs/product-manager/skills/strategy-analysis/evals/eval_queries.json

@@ -0,0 +1,13 @@
+[
+  { "query": "Run a SWOT analysis on our product", "should_trigger": true },
+  { "query": "Should we enter the SMB payroll market?", "should_trigger": true },
+  { "query": "Do a Porter's Five Forces on the ride-sharing industry", "should_trigger": true },
+  { "query": "What macro trends could threaten our 3-year platform bet?", "should_trigger": true },
+  { "query": "Why are our margins compressing — analyze the competitive pressure", "should_trigger": true },
+  { "query": "I need a PESTLE analysis for the board offsite", "should_trigger": true },
+
+  { "query": "Compare Postgres vs DynamoDB for our new service", "should_trigger": false },
+  { "query": "Write a business case for acquiring this tooling vendor", "should_trigger": false },
+  { "query": "Write a PRFAQ for our new product idea", "should_trigger": false },
+  { "query": "Cascade our company OKRs down to the platform team", "should_trigger": false }
+]

skilldrop_cli/data/packs/product-manager/skills/strategy-analysis/evals/evals.json

@@ -0,0 +1,36 @@
+{
+  "skill_name": "strategy-analysis",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Run a SWOT on our product: a developer-tools startup with 4,000 paying tenants, strong CI/CD integration data, a small sales team, and a well-funded incumbent (CircleCI) moving into our niche. The decision this feeds: where to focus the next two quarters.",
+      "assertions": [
+        "SWOT is crossed into TOWS quadrants (S×O, S×T, W×O, W×T) — the four raw lists are not the final output",
+        "Every cell is specific (names a competitor, number, or capability), carries an evidence tag ([data]/[reported]/[assumption]), and has a 'so:' implication",
+        "No horoscope cells like 'strong team' or 'growing market' without specifics",
+        "Implications section is ranked (3-5 entries) and each is action-shaped, tied to the two-quarter focus decision",
+        "A verdict paragraph takes a side and names what evidence would change it",
+        "Assumptions appearing in top-ranked implications are flagged as validation targets",
+        "A hand-off to tech-comparison-matrix, business-case, or prfaq is offered where apt"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Give me a SWOT to decide whether we should enter the SMB payroll market in Germany.",
+      "assertions": [
+        "The skill flags that market-entry attractiveness is a Five Forces question and suggests it before or instead of SWOT",
+        "If Five Forces is run, all five forces get a pressure rating with the mechanism (who holds power and why) — no force rated 'N/A'",
+        "The output ends with a committal verdict on entering, not 'it depends'"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "[Non-interactive run — no user available to answer questions] Run a Porter's Five Forces on the European ride-sharing market. This feeds our decision on whether to expand our driver-scheduling SaaS into that segment next year.",
+      "assertions": [
+        "The skill proceeds (the decision IS named in the input) instead of blocking",
+        "Assumptions replacing the capped clarifying questions (e.g. competitive set) are tagged [assumption] and stated at the top",
+        "Market facts drawn from general knowledge are tagged [market: ...], distinguishable from user-supplied facts and assumptions"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/strategy-analysis/examples/market-entry-tows.md

@@ -0,0 +1,42 @@
+# Worked example — SWOT arriving as TOWS for a market-entry decision
+
+Input → output oracle for `strategy-analysis`. Shows the framework justified in one
+line, evidenced/consequential cells, the mandatory SWOT→TOWS crossings, ranked
+action-shaped implications tied to the decision, and a verdict that takes a side.
+
+## Input
+
+> "Should [Acme], a mid-market B2B analytics vendor, enter the SMB self-serve
+> segment next year? Decision owner wants a go / no-go with conditions."
+
+## Framework fit (one line)
+
+**SWOT→TOWS**, not Five Forces: the question is about *our* fit to a new segment (internal capabilities vs. external openings), not the structural attractiveness of the industry.
+
+## SWOT (every cell specific · evidenced · consequential)
+
+| | Helpful | Harmful |
+|---|---|---|
+| **Internal** | **S1** Self-serve onboarding already built for mid-market trials (evidence: 40% of trials activate with zero sales touch) → *marginal cost to serve SMB is low.* | **W1** Pricing starts at $2k/mo (evidence: current floor plan) → *5–10× above SMB willingness-to-pay; no viable entry SKU.* |
+| **External** | **O1** No incumbent owns SMB self-serve analytics in this niche (evidence: top 3 competitors are all sales-led, $10k+ ACV) → *an unserved segment with a wedge.* | **T1** Two horizontal BI tools added SMB free tiers this year (evidence: their changelogs) → *the window is closing; a free tier resets price expectations.* |
+
+## TOWS crossings (the strategy — inventory becomes moves)
+
+- **S1 × O1 (invest):** Package the existing zero-touch onboarding as a low-price self-serve SKU to claim the unserved niche before it's contested.
+- **W1 × T1 (defend/decide):** The $2k floor collides head-on with free tiers — a new SMB SKU is a *prerequisite*, not an option; without it, don't enter.
+- **S1 × T1 (hedge):** Low cost-to-serve means an SMB tier can be near-free to run, so a defensive free/low tier is affordable if a competitor forces it.
+- **W1 × O1 (fix-first):** The opportunity is real but unreachable until pricing is solved — so pricing is the gating workstream, not marketing.
+
+## Ranked implications (action-shaped, tied to the go/no-go)
+
+1. **Gate the decision on a validated SMB SKU** (target ≤ $99/mo, positive unit economics at self-serve volume). No SKU → no-go. *(from W1×T1, W1×O1)*
+2. **Run a 60-day self-serve pilot** on the existing onboarding to test activation without sales. *(S1×O1)*
+3. **Pre-commit a free-tier response** so a competitor's move doesn't catch us flat. *(S1×T1)*
+
+## Verdict (takes a side + what would change it)
+
+**Conditional GO** — enter *only* after a sub-$100 SKU clears a unit-economics test in a 60-day pilot; the low cost-to-serve and the open niche make the upside real, but the pricing gap is disqualifying until fixed. **What flips it to no-go:** the pilot shows self-serve activation < 20% (the zero-touch advantage doesn't transfer), or a horizontal BI tool ships a *vertical* SMB tier first (the wedge closes).
+
+## Why this passes the quality bar
+
+The framework choice is justified; every cell is specific, evidenced, and carries a "→ so what"; SWOT is delivered *as TOWS* with real crossings; implications are ranked and tied to the named decision; and the verdict commits with a falsifiable flip-condition instead of "it depends."

skilldrop_cli/data/packs/product-manager/skills/strategy-analysis/manifest.json

@@ -0,0 +1,15 @@
+{
+  "name": "strategy-analysis",
+  "version": "0.1.1",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["business-case", "okr-cascade", "prfaq", "tech-comparison-matrix"],
+  "handoff": [
+    { "to": "tech-comparison-matrix", "when": "the options are named and need comparing on stated criteria", "purpose": "Score the named options against weighted criteria.", "fallback": "If tech-comparison-matrix is absent, build a plain criteria-by-option table inline and state the weights." },
+    { "to": "business-case", "when": "the direction is chosen and needs costing before approval", "purpose": "Cost the chosen option against a do-nothing baseline.", "fallback": "If business-case is absent, state option 0 and the three cost layers (build, run, opportunity) inline." }
+  ],
+  "tags": ["strategy", "swot", "tows", "five-forces", "pestle", "competitive-analysis", "market-analysis"],
+  "model": { "tier": "heavy", "rationale": "Framework selection plus evidenced multi-factor judgment ending in a ranked, committal verdict. Cheaper models fill cells with generic filler, skip the TOWS crossings, and refuse to take a side. Never downgrade." }
+}