skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/product-manager/skills/business-case/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: business-case
+description: 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. Use 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.
+---
+
+# business-case
+
+Produces the document a sponsor can approve, challenge, or kill on its merits — because every benefit shows its arithmetic, every option includes the one nobody advocates for (doing nothing), and the case names the single assumption that flips the recommendation. Decides *whether to invest*; `tech-comparison-matrix` picks between technologies after, `prd-draft` captures requirements after, `exec-summary` compresses this doc for a board.
+
+## How to respond
+
+1. **Pin the decision and the decider.** What exactly is being decided ("invest ~3 engineer-quarters in X" — not "improve our tooling"), who decides, and by when. Ask at most 2 questions, spent on the **cost of the status quo** ("what does the current state cost per month, in what units?") and the **decision deadline**. A business case without a named decision is an essay.
+
+2. **Always include Option 0: do nothing.** Costed like every other option — the status quo has a price (ongoing pain, growing risk, deferred opportunity) and the case must beat it *explicitly*, not by assumption. Then 2–3 real alternatives (typically build / buy / partial-defer). Every option presented is one someone could genuinely champion; a lineup of two strawmen escorting the preferred option is theater, and reviewers smell it.
+
+3. **Quantify benefits as calculations a reviewer can re-run.** Every benefit shows: the formula, each input with its source tag, and a **confidence tag** (high = measured data, medium = reasonable extrapolation, low = informed guess). ✅ *"40 agents × ~20 min/ticket saved `[data: time study]` × 30 tickets/day → 18–24 FTE-hours/day, confidence: medium (assumes 75–100% of tickets touch the flow)"* — ❌ *"significant efficiency gains"* — an adjective benefit is a benefit that didn't survive arithmetic.
+
+4. **Use ranges, never false precision.** Three estimates multiplied together do not produce "327% ROI" — they produce a range, and the case says which end is likelier and why. State payback as a range too ("breakeven month 7–11"). Single-point outputs from multi-guess inputs are the most reliable sign a case is selling, not informing.
+
+5. **Cost all three layers, per option**: **build** (people × time, the dominant and most-lowballed term — include ramp-up and the integration tail), **run** (infra, licenses, support burden, maintenance — the layer "buy" options hide in year 2+ pricing and "build" options hide in maintenance), and **opportunity** (what these people would otherwise ship — name the displaced thing, don't leave it abstract).
+
+6. **Name the flip-assumption.** The sensitivity question, answered honestly: *which single input, if wrong, reverses the recommendation?* ✅ *"The case rests on ≥60% agent adoption; below ~40%, Option 0 wins — adoption is `[low confidence]`, so we propose a 4-week pilot before full commit."* If no single assumption flips it, say which *pair* does. A case with no flip-condition is claiming certainty it cannot have.
+
+7. **Recommend one option, committally.** The recommendation names the option, the reasoning in two sentences, what was given up (the strongest point of the runner-up, stated fairly), and any de-risking step (pilot, staged commit) tied to the flip-assumption. "It depends" is the analyst's job half-done; the decider can disagree with a recommendation, but they can't disagree with a shrug.
+
+8. **Lead with the ask.** The first lines of the document: the decision requested, the cost, the headline benefit range, the deadline. ✅ *"Ask: approve 3 engineer-quarters (~$210k loaded) for Option B; expected payback month 7–11; decision needed by July 1 to hit Q4 capacity."* Emit with [`templates/business-case.md`](templates/business-case.md), one message.
+
+## Useful references in this skill
+
+- [`templates/business-case.md`](templates/business-case.md) — the skeleton: ask-first structure, option table, benefit-calculation blocks, sensitivity section
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ "Should we build this?" / "write the business case for X"
+- ✅ Build vs buy vs defer with real money or quarters at stake
+- ✅ Budget/headcount approval needs a document, not a hallway pitch
+- ✅ A persistent "we should really fix this" needs its cost of inaction priced
+
+## When NOT to use this skill
+
+- ❌ The investment decision is already made — go to `prd-draft`
+- ❌ Choosing between technologies for an approved initiative — `tech-comparison-matrix`
+- ❌ 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
+
+## Anti-patterns to avoid
+
+- ❌ **Omitting do-nothing.** Every option looks good against an unexamined status quo — that's why it gets omitted.
+- ❌ **Adjective benefits.** "Improved efficiency, better experience, reduced risk" — three claims, zero numbers, nothing a reviewer can challenge.
+- ❌ **False precision.** "327% ROI" from three guesses. Ranges with a stated lean, always.
+- ❌ **Year-one costing.** Build cost without run cost — the buy option's renewal pricing and the build option's maintenance both live in year 2+, which is where cases go to die.
+- ❌ **Sunk-cost scaffolding.** "We've already invested 2 quarters" argues for nothing; the case is forward-looking from today's zero.
+- ❌ **Option theater.** Two deliberately weak alternatives flanking the favorite. Reviewers notice, and the case loses its credibility along with the vote.
+- ❌ **Burying the ask.** Page 4, paragraph 2, "in light of the above we suggest…" — the sponsor read the first five lines; the ask lives there or nowhere.

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

@@ -0,0 +1,30 @@
+[
+  {
+    "query": "Write the business case for building our own feature-flag service versus buying one",
+    "should_trigger": true
+  },
+  {
+    "query": "Should we invest two engineer-quarters in rebuilding search? I need something to take to the sponsor",
+    "should_trigger": true
+  },
+  {
+    "query": "Compare build vs buy vs defer for the new data pipeline, with the cost of doing nothing priced",
+    "should_trigger": true
+  },
+  {
+    "query": "I need budget approval for an observability overhaul — help me justify the spend",
+    "should_trigger": true
+  },
+  {
+    "query": "The investment's approved — now write the PRD for the ML router",
+    "should_trigger": false
+  },
+  {
+    "query": "Pick between Kafka, Kinesis, and Pub/Sub for the approved event bus",
+    "should_trigger": false
+  },
+  {
+    "query": "Compress this 12-page business case into a one-page summary for the board",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/product-manager/skills/business-case/evals/evals.json

@@ -0,0 +1,19 @@
+{
+  "skill_name": "business-case",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the business case for replacing our homegrown support ticket router at Northwind. Today 40 agents each spend about 20 minutes a day manually re-routing misassigned tickets (from a two-week time study). Loaded agent cost is $45/hour. Options on the table: build a ML router (estimate 3 engineers for 2 quarters), buy a vendor tool (Vendor X quoted $60k/year, year-two price unknown), or keep things as they are. The same 3 engineers would otherwise ship the self-serve billing portal. The VP of Support decides by November 15.",
+      "assertions": [
+        "The first lines state the ask — option, cost, benefit range, and the November 15 deadline — in under 40 words",
+        "Option 0 (do nothing) is present and costed using the user's 40 agents x 20 min/day x $45/hour figures",
+        "Every benefit is a re-runnable calculation with formula, sourced inputs, and a confidence tag (high/medium/low)",
+        "Outputs such as ROI and payback are ranges with a stated lean, not single-point figures like '327% ROI'",
+        "Each option shows build, run, and opportunity cost, with the displaced work named as the self-serve billing portal",
+        "The vendor's unknown year-two price is called out as an unknown or flagged assumption, not filled with an invented number",
+        "Names the flip-assumption that would reverse the recommendation, with a de-risking step if its confidence is low",
+        "Recommends exactly one option and states the runner-up's strongest argument fairly"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/business-case/examples/build-vs-buy-flags.md

@@ -0,0 +1,42 @@
+# Worked example — build vs. buy a feature-flag system
+
+Input → output oracle for `business-case`. Shows the ask first (< 40 words), Option 0
+costed, benefits as re-runnable calculations with confidence tags, all three cost
+layers, ranges, the flip-assumption, and a singular recommendation that states the
+runner-up's best argument fairly.
+
+## Input
+
+> "Should [Acme] build an in-house feature-flag system or buy a SaaS one? ~30
+> engineers, currently gating releases with config files and redeploys."
+
+## Output
+
+### The ask
+**Buy the SaaS feature-flag service (~$18–30k/yr).** It pays back in < 3 months against ~$140k of first-year build cost and recurring toil, and frees roadmap capacity now. Decision needed before next quarter's release-velocity commitments.
+
+### Options (Option 0 is costed)
+
+| Option | Build (one-time) | Run (yr 1) | Opportunity cost |
+|---|--:|--:|--:|
+| **0 — Status quo** (config + redeploy) | $0 | ~$60–90k/yr toil | Slow releases → est. 1–2 delayed launches/yr |
+| **1 — Build in-house** | ~$110–160k | ~$25–40k/yr (on-call, maint.) | 2 eng × 3–4 mo off roadmap |
+| **2 — Buy SaaS** | ~$5k (integrate) | ~$18–30k/yr license | ~1 eng-week integration |
+
+### Benefits (re-runnable calculations, sourced, confidence-tagged)
+
+- **Toil removed vs. Option 0:** each gated release currently costs ~1 eng-hr of redeploy coordination × ~15 releases/mo × $120 loaded/hr = **~$22k/yr** recovered. *(confidence: medium — release count from deploy logs; hourly is loaded-cost estimate.)*
+- **Incident reduction:** flag-based instant rollback vs. redeploy shortens mean remediation from ~40 min to ~5 min; at ~6 rollback-worthy incidents/yr that's ~3.5 hrs × team = **~$8–15k/yr** avoided. *(confidence: low — incident count is small-sample; range reflects it.)*
+- **Release velocity:** decoupling deploy from release plausibly removes 1–2 launch slips/yr; value is real but **not costed here** (depends on launch revenue) — flagged for the decision owner.
+
+Totals are ranges; the **lower end is likelier** for the hard-dollar items (toil is the solid number; incident/velocity are directional).
+
+### The flip-assumption
+The case flips to **Build** only if **flag evaluation must run in a data plane the SaaS can't reach** (e.g. strict data-residency or sub-ms in-process evaluation at scale). Confidence that this *doesn't* apply is medium. **De-risking step before committing to Buy:** a 1-week spike confirming the SaaS SDK meets latency + residency requirements — cheap insurance against the one assumption that would reverse the decision.
+
+### Recommendation
+**Buy (Option 2).** Lowest first-year cost, fastest payback, and it returns ~2 engineers to the roadmap that Build would consume. **The runner-up's best argument, stated fairly:** Build is genuinely better *if* flag evaluation becomes a core differentiator or a hard data-residency constraint emerges — in that world the SaaS boundary bites and owning the system is worth the cost. The spike above is what tells us which world we're in.
+
+## Why this passes the quality bar
+
+The ask leads in under 40 words; Option 0 is present and costed; every benefit is a calculation with sourced inputs and a confidence tag; outputs are ranges naming the likelier end; all three cost layers appear per option; the flip-assumption is identified with a de-risking step; and the recommendation is singular while stating the runner-up's strongest case honestly.

skilldrop_cli/data/packs/product-manager/skills/business-case/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "business-case",
+  "version": "0.1.0",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["exec-summary", "prd-draft", "tech-comparison-matrix"],
+  "tags": ["business-case", "investment", "build-vs-buy", "roi", "cost-benefit", "decision"],
+  "model": { "tier": "heavy", "rationale": "Weighted multi-option judgment with a committal recommendation — same failure mode as tech-comparison-matrix: cheaper models mis-weight costs, inflate benefits, and miss the flip-assumption. Never downgrade." }
+}

skilldrop_cli/data/packs/product-manager/skills/business-case/templates/business-case.md

@@ -0,0 +1,60 @@
+# Business-case template
+
+Ask first. Ranges, not points. Every number traceable to a tagged input.
+
+```markdown
+# Business case: {decision, named — "Invest 3 engineer-quarters in unified agent view"}
+
+## The ask (≤40 words)
+
+Approve **{option}** — {cost range, loaded} — expected {headline benefit range},
+payback {range}. Decision needed by **{date}** because {what the deadline forfeits}.
+
+**Decider:** {role} · **Author:** {role} · **Date:** {YYYY-MM-DD}
+
+## The problem, priced
+
+{2–3 sentences: what the status quo costs per month, in units the decider budgets
+in (FTE-hours, churn, incidents, $). Inputs tagged [data:…] / [reported:…] / [estimate].}
+
+## Options
+
+| | Option 0: do nothing | Option A: {…} | Option B: {…} |
+|---|---|---|---|
+| Build cost | — | {range, loaded, incl. ramp + integration tail} | {range} |
+| Run cost (annual, yr 2+) | {status-quo ongoing cost} | {infra + licenses + maintenance} | {…} |
+| Opportunity cost | {what worsens by deferring} | {the displaced work, named} | {…} |
+| Headline benefit | 0 (baseline) | {range + confidence} | {range + confidence} |
+| Time to value | — | {range} | {range} |
+| Champion-able? | yes — {who'd argue it} | yes — {…} | yes — {…} |
+
+## Benefit calculations (re-runnable)
+
+### {Benefit 1, Option A}
+- Formula: {inputs → output}
+- Inputs: {value [data: source]} × {value [estimate]} × …
+- Result: **{range}** · Confidence: {high|medium|low} — {why}
+
+{Repeat per material benefit. A benefit with no calculation block doesn't appear in the option table.}
+
+## Sensitivity — the flip-assumption
+
+**The recommendation flips if:** {single input + the threshold — "agent adoption < ~40%"}
+**Confidence on that input:** {tag} → **De-risking step:** {pilot / staged commit / data pull, with cost and duration}
+{If no single input flips it, name the pair that does.}
+
+## Recommendation (one option)
+
+**{Option}.** {Two sentences of reasoning.}
+**What we give up:** {the runner-up's strongest point, stated fairly.}
+**Conditions:** {the de-risking step above; any staging of the commitment.}
+
+## Risks beyond the numbers
+
+- {execution/organizational/vendor risk} — {mitigation or acceptance, one line each}
+
+## Not in this case
+
+{What was deliberately excluded from the math (unquantifiable strategic upside,
+morale, …) — named so the decider can weigh it qualitatively, not smuggled into the numbers.}
+```

skilldrop_cli/data/packs/product-manager/skills/okr-cascade/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: okr-cascade
+description: 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. Use 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.
+---
+
+# okr-cascade
+
+Turns company objectives into team OKRs that actually roll up — and surfaces what a cascade usually hides: the objectives nobody credibly owns (the **gap registry**) and the KRs that count activity instead of causing outcomes (the **causal metric tree**). Org-level counterpart to `success-metrics`, which owns feature-level measurement — this skill decides *what the teams aim at*; `success-metrics` designs how one feature proves it moved a KR.
+
+## How to respond
+
+1. **Get the company OKRs and the cycle.** From the input or by asking (at most 2 questions, spent on: *"what are the company's top 3–5 objectives this cycle, verbatim?"* and *"which teams are in scope?"*). Record company OKRs **verbatim** — rewriting the company's words without saying so corrupts the roll-up. No company objectives exist at all → stop; that's a strategy conversation (`strategy-analysis`), not a cascade. Non-interactive run (no user to ask): an unstated cycle or team list gets assumed and tagged `[assumption]`; absent company OKRs are never invented — emit `BLOCKED: need the company OKRs, verbatim — rerun with the top 3–5 objectives, their KRs, and the teams in scope` instead.
+
+2. **Grade the company KRs before cascading them.** Each company KR is either an **outcome** (a customer or business result: retention, revenue, time-to-value) or an **output** (a thing shipped: "launch v2", "migrate to k8s"). Outputs at company level get flagged with the outcome they presumably serve — ✅ *"'Launch self-serve onboarding' → presumably serves activation rate; recommend restating as the activation target"*. Cascading an output produces teams that hit every KR while the business stands still.
+
+3. **Derive team OKRs per company objective.** For each in-scope team: an objective (qualitative, motivating, this-cycle) and 2–4 KRs that are (a) **measurable at the team's scope** — the team's work moves the number without needing three other teams to also succeed; (b) **causally upstream** of a company KR, with the causal sentence written out: ✅ *"Cut p95 checkout latency to 800ms — slow checkout is the top named cause of cart abandonment `[data: support tags]`, which feeds company KR 'checkout conversion +2pp'"*; (c) **scored 0.0–1.0 at cycle end** — a KR that can only be "done/not done" is a task wearing a KR's clothes. Not every team maps to every objective — forcing it manufactures alignment theater; a team with no credible contribution to an objective simply doesn't appear under it.
+
+4. **Build the gap registry.** A gap is a company objective or KR with **no team-level expression** after step 3 — no owner, no credible path, or a current-vs-target delta no in-scope team can close. Name each gap (kebab-case slug), state which company KR it starves, and rank gaps by the weight of the objective they block. The registry is a first-class output: a cascade with zero gaps on the first pass usually means step 3 was generous, not that the org is perfectly shaped — say so if it happens.
+
+5. **Draw the causal metric tree.** North-star (the one user-behavioral outcome metric capturing this cycle's most strategic objective — never "features shipped") at the root; each team KR attached at its causal position as a leading indicator; each edge carrying its causal sentence. A KR that can't be attached to the tree is either a guardrail (label it) or measurement theater (cut it, and say which). No credible north-star derivable → report that as the cascade's top finding and recommend naming one before committing OKRs.
+
+6. **Emit with [`templates/okr-cascade.md`](templates/okr-cascade.md)** in one message: company OKRs (verbatim, with output-KR flags), team OKRs with causal sentences, ranked gap registry, metric tree (Mermaid `flowchart` — north-star at root, KRs as leaves), and next steps: each team KR needing full measurement design → `success-metrics`; each gap needing a decision → the owner who must staff or explicitly drop it.
+
+## Useful references in this skill
+
+- [`templates/okr-cascade.md`](templates/okr-cascade.md) — cascade tables, gap registry, and metric-tree skeleton
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ "Cascade our company OKRs to the platform/growth/mobile teams"
+- ✅ Quarterly planning: turning strategy into team objectives
+- ✅ Auditing existing OKRs — which are vanity, which roll up nowhere
+- ✅ "Leadership set five objectives; which have no owner?"
+
+## When NOT to use this skill
+
+- ❌ 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
+
+## Anti-patterns to avoid
+
+- ❌ **Cascading outputs.** "Company: launch v2 → Team: ship 12 features" — everyone hits 100% while retention falls. Flag outputs at intake or inherit the disease.
+- ❌ **Alignment theater.** Every team forced under every objective, with prose doing the aligning that causality can't. Empty cells are information.
+- ❌ **Vanity KRs.** Page views, sign-ups, story points. If the number can improve while the business doesn't, it can't be a KR.
+- ❌ **A gapless first pass.** The registry exists because real orgs have orphaned objectives — a clean sheet means the bar in step 3 slipped.
+- ❌ **KR-as-task-list.** "Complete the migration" scores 0 or 1 and measures effort. What outcome does the migration purchase? That's the KR.
+- ❌ **Metric list instead of metric tree.** "DAU, NPS, churn, revenue" with no causal positions is a dashboard inventory, not a tree — every node needs its edge.
+- ❌ **Silent rewording of company OKRs.** Improving leadership's phrasing without marking it breaks the roll-up contract and hides a real disagreement worth surfacing.

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

@@ -0,0 +1,12 @@
+[
+  { "query": "Cascade our company OKRs down to team level", "should_trigger": true },
+  { "query": "Help me set quarterly OKRs for the platform team that align to company goals", "should_trigger": true },
+  { "query": "Audit our existing OKRs — which ones are vanity metrics?", "should_trigger": true },
+  { "query": "Leadership set five objectives; which have no team owner?", "should_trigger": true },
+  { "query": "Turn our strategy into Q4 objectives for the org", "should_trigger": true },
+
+  { "query": "How do we know this feature worked? Define its success metrics", "should_trigger": false },
+  { "query": "Prioritize our sprint backlog for next iteration", "should_trigger": false },
+  { "query": "Run a SWOT on our market position", "should_trigger": false },
+  { "query": "Set performance goals for my direct reports", "should_trigger": false }
+]

skilldrop_cli/data/packs/product-manager/skills/okr-cascade/evals/evals.json

@@ -0,0 +1,28 @@
+{
+  "skill_name": "okr-cascade",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Cascade these company OKRs to our three teams (platform, growth, mobile). O1: Become the default choice for mid-market DevOps teams — KR1: net revenue retention 115%, KR2: launch the v2 platform. O2: Operational excellence — KR1: 99.95% availability. Cycle: Q4.",
+      "assertions": [
+        "Company OKRs appear verbatim; 'launch the v2 platform' is flagged as an output KR with the outcome it presumably serves",
+        "Each team KR has a written causal sentence naming the company KR it feeds and the mechanism",
+        "Each team KR has baseline → target and is scorable 0.0–1.0 — no binary 'complete the migration' KRs",
+        "Not every team is forced under every objective — teams with no credible contribution are omitted from that objective",
+        "A ranked gap registry is present (or explicitly states none found and why that is suspicious)",
+        "A causal metric tree with exactly one north-star is emitted; every team KR is attached, labeled guardrail, or explicitly cut",
+        "The north-star is user-behavioral, not 'features shipped' or another output",
+        "Next steps route team KRs to success-metrics for measurement design and gaps to a named decision owner"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "[Non-interactive run — no user available to answer questions] Cascade our OKRs to the teams.",
+      "assertions": [
+        "No company OKRs are invented — the output is BLOCKED: need the company OKRs, verbatim",
+        "The BLOCKED output states what to rerun with (the top 3-5 objectives and their KRs, plus teams in scope)",
+        "No cascade tables, gap registry, or metric tree appear"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/okr-cascade/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "okr-cascade",
+  "version": "0.1.1",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["prfaq", "strategy-analysis", "success-metrics"],
+  "tags": ["okr", "goals", "alignment", "north-star", "metric-tree", "quarterly-planning"],
+  "model": { "tier": "standard", "rationale": "Structured derivation against a fixed roll-up discipline; the causal-sentence and gap judgments need care but the template bounds them. Escalate via ambiguous-input when the company objectives themselves are contested." }
+}

skilldrop_cli/data/packs/product-manager/skills/okr-cascade/templates/okr-cascade.md

@@ -0,0 +1,46 @@
+# OKR Cascade — {cycle, e.g. 2026 Q4}
+
+> Teams in scope: {list} · Source of company OKRs: {doc/person} · Status: DRAFT
+
+## Company OKRs (verbatim)
+
+### O1: {objective, verbatim}
+| KR | Type | Note |
+|---|---|---|
+| {KR verbatim} | outcome / **output ⚠** | {if output: the outcome it presumably serves} |
+
+## Team OKRs
+
+### Team: {name}
+
+**O: {team objective — qualitative, motivating, this cycle}** _(feeds company O1)_
+
+| KR | Baseline → Target | Causal sentence (mechanism → company KR) | Scoring |
+|---|---|---|---|
+| {KR} | {x → y} | {why moving this moves company KR n} | {how 0.0–1.0 is graded, e.g. linear on pp gained} |
+
+<!-- A team with no credible contribution to an objective doesn't appear under it. -->
+
+## Gap registry (ranked)
+
+| # | Gap slug | Company KR or objective it starves | Why no team covers it | Decision needed from |
+|---|---|---|---|---|
+| 1 | {kebab-slug} | {KR, or "On (objective-level)"} | {no owner / no credible path / delta too large} | {role} |
+
+## Causal metric tree
+
+North-star: **{one user-behavioral outcome metric}**
+
+```mermaid
+flowchart BT
+    KR1["{team KR}"] -->|"{causal sentence, short}"| NS["{north-star}"]
+    KR2["{team KR}"] -->|"{…}"| NS
+    G1["{guardrail KR}"] -.->|guardrail| NS
+```
+
+Cut from the tree: {KRs that attached nowhere, and why} — or "none".
+
+## Next steps
+
+- {team KR} → run `success-metrics` for full measurement design (baseline, counter-metric, instrumentation)
+- {gap slug} → {owner role} staffs it or explicitly drops it by {date}

skilldrop_cli/data/packs/product-manager/skills/prd-draft/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: prd-draft
+description: 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. Use 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.
+---
+
+# prd-draft
+
+Turns "the business wants X" into the document that aligns everyone on **what problem, for whom, how we'll know** — before anyone argues about how. The missing link in the pipeline: `brief-intake` (raw mess → brief) → **`prd-draft`** → `user-story-splitter` (stories), `nfr-spec` (quality targets), `success-metrics` (measurement), `design-doc` (the how).
+
+## How to respond
+
+1. **Ingest the idea** — a `brief-intake` output, a pitch paragraph, a meeting note. Ask at most 2 questions, spent on the two highest-leverage unknowns: **evidence** ("what tells us users actually have this problem?") and the **binding constraint** ("fixed deadline, fixed scope, or fixed team?"). Everything else: pick a default, tag it `[assumption]`.
+
+2. **Write the problem statement with zero solution nouns.** It names users, their situation, the pain, and the evidence — and survives the test: *could this paragraph justify a completely different solution than the one everyone has in mind?* ✅ *"Support agents spend ~20 min/ticket reconstructing customer order history across three tools `[reported by support lead]`"* — ❌ *"We need an order-history dashboard"* (that's a solution wearing a problem costume).
+
+3. **Name the users specifically enough to find one.** Primary persona + their job-to-be-done; secondary personas listed but explicitly deprioritized. "All users" is not a persona — if the feature really serves everyone, name who feels the pain *most*.
+
+4. **State goals with a success line each.** Every goal carries one measurable "we'll know it worked when …" sentence — target, timeframe, baseline if known. One line here; the full measurement design (instrumentation, guardrails) is `success-metrics`' job — point the user there.
+
+5. **Write requirements that are testable and solution-free**, each with a MoSCoW priority — and the **Won't-have list is mandatory**: ✅ *"M — Agent sees a customer's orders from all channels in one view, ≤3s after lookup"* — ❌ *"M — Use Redis to cache order data"* (implementation, belongs in `design-doc`) — ❌ *"S — The experience is seamless"* (untestable, belongs nowhere). Requirements describe observable behavior or capability; each one is checkable by a tester or demo.
+
+6. **Make non-goals carry weight — minimum 3.** Non-goals are the section that kills scope creep in review instead of in sprint 4. Each names the thing stakeholders will plausibly ask for, and one line on why it's out: ✅ *"Editing orders from this view — read-only for v1; write paths triple the authz surface (revisit after launch metrics)"*.
+
+7. **List open questions with owners and dates** — the unknowns that block requirement freeze, each assigned to a person/role who can actually answer it. An open question without an owner is a future surprise.
+
+8. **Emit the PRD with [`templates/prd.md`](templates/prd.md)** in one message, sized for a 30-minute read. End with the handoff map: stories → `user-story-splitter`, quality targets → `nfr-spec`, measurement → `success-metrics`, technical approach → `design-doc`.
+
+## Useful references in this skill
+
+- [`templates/prd.md`](templates/prd.md) — the PRD skeleton with the solution-language test and MoSCoW table
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ A feature idea needs to become an agreed requirements doc before design starts
+- ✅ "Write a PRD for X" / "capture the business requirements for X"
+- ✅ A `brief-intake` output is ready to be shaped into the canonical product doc
+- ✅ Two teams disagree about what's being built — the PRD is the alignment artifact
+
+## When NOT to use this skill
+
+- ❌ 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`
+
+## Anti-patterns to avoid
+
+- ❌ **Solution-as-problem.** "Problem: we don't have a dashboard." The absence of a solution is never the problem.
+- ❌ **Implementation smuggled into requirements.** "Must use Kafka" — the PRD owns *what*; smuggled *hows* pre-empt design without review.
+- ❌ **Adjective requirements.** Fast, seamless, intuitive, robust — each one either gets a number or gets cut.
+- ❌ **The empty non-goals section.** A PRD that excludes nothing has decided nothing; it's a wish list with a header.
+- ❌ **Stakeholder wish-list flattening.** Every request recorded as "Must" because saying Should felt political — MoSCoW with one priority level is no prioritization.
+- ❌ **The 40-page PRD.** Completeness theater; nobody reviews page 23, so page 23 ships unreviewed.

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

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Draft a PRD for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the product requirements document from this idea",
+    "should_trigger": true
+  },
+  {
+    "query": "I need testable requirements with MoSCoW priorities and non-goals",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this feature idea into a PRD engineering can build from",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the press release before the product exists",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the engineering design doc for this",
+    "should_trigger": false
+  },
+  {
+    "query": "Split this epic into INVEST user stories",
+    "should_trigger": false
+  },
+  {
+    "query": "Write interview questions for our stakeholders",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/product-manager/skills/prd-draft/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "prd-draft",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Draft a PRD for a saved-search feature in our analytics product — users keep re-running the same filters every morning.",
+      "assertions": [
+        "The problem statement contains zero solution language and passes the alternative-solution test — more than one solution could follow from it",
+        "Every requirement is verifiable — a tester can demo it pass or fail; adjective requirements and implementation choices are rejected",
+        "Requirements are MoSCoW-prioritized",
+        "The won't-have list is non-empty and names specific excluded things",
+        "Each goal carries a success line stating how it will be measured",
+        "Claims that need evidence are marked rather than asserted as fact"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/prd-draft/manifest.json

@@ -0,0 +1,16 @@
+{
+  "name": "prd-draft",
+  "version": "0.1.0",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["brief-intake", "bug-triage", "business-case", "design-doc", "nfr-spec", "success-metrics", "user-story-splitter"],
+  "handoff": [
+    { "to": "nfr-spec", "when": "the functional requirements are agreed", "purpose": "Set the quality targets the design will be judged against.", "fallback": "If nfr-spec is absent, state latency, availability and scale targets inline as numbers, not adjectives." },
+    { "to": "user-story-splitter", "when": "the requirements are ready to become units of work", "purpose": "Split into vertically-sliced stories with acceptance criteria.", "fallback": "If user-story-splitter is absent, slice inline and give each story acceptance criteria a test can assert." },
+    { "to": "design-doc", "when": "the what is agreed and the how is open", "purpose": "Design the system that satisfies these requirements.", "fallback": "If design-doc is absent, write the approach, the alternatives, and the trade-offs inline." }
+  ],
+  "tags": ["prd", "requirements", "product", "discovery", "moscow", "non-goals"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a structured requirements doc from a brief. The solution-language discipline needs care; bounded by the template. Escalate via ambiguous-input on contested scope." }
+}

skilldrop_cli/data/packs/product-manager/skills/prd-draft/templates/prd.md

@@ -0,0 +1,66 @@
+# PRD template
+
+Sized for a 30-minute read. Every claim tagged `[reported by …]`, `[data: …]`, or `[assumption]`.
+
+```markdown
+# PRD: {feature name — noun phrase, not a solution name if avoidable}
+
+**Status:** draft | in review | frozen · **Owner:** {role} · **Date:** {YYYY-MM-DD}
+**Binding constraint:** {fixed deadline | fixed scope | fixed team} `[reported|assumption]`
+
+## Problem
+
+{Who, in what situation, suffers what, evidenced by what. Zero solution nouns.
+Test before moving on: could this paragraph justify a completely different
+solution than the one in everyone's head? If not, rewrite.}
+
+## Users
+
+**Primary:** {persona specific enough to find one} — job-to-be-done: {what they're
+trying to accomplish when they hit the problem}
+**Secondary (explicitly deprioritized):** {personas served incidentally, one line on why not primary}
+
+## Goals
+
+| # | Goal | We'll know it worked when |
+|---|---|---|
+| G1 | {outcome, not output} | {metric + target + timeframe; baseline if known, else "[baseline needed]"} |
+
+Full measurement design (instrumentation, guardrails, decision rule): hand to `success-metrics`.
+
+## Requirements
+
+| ID | Requirement (testable, solution-free) | MoSCoW | Maps to goal |
+|---|---|---|---|
+| R1 | {observable behavior/capability a tester can verdict} | M | G1 |
+| R2 | … | S | G1 |
+
+**Won't have (this version):**
+- {the tempting thing} — {one line why out}
+
+## Non-goals (minimum 3 — the scope-creep firewall)
+
+- **{Thing stakeholders will plausibly ask for}** — {why it's out; when it might come back}
+
+## Quality targets
+
+One line each if known; full treatment → `nfr-spec`.
+{e.g. "Agent-facing: p95 lookup < 3s. Availability follows the support-tools tier."}
+
+## Open questions
+
+| Question | Owner | Needed by |
+|---|---|---|
+| {blocker to freezing requirements} | {person/role who can answer} | {date} |
+
+## Assumptions log
+
+- [assumption] {default picked} — challenge by {date/review}
+
+## Handoffs
+
+- Stories & slicing → `user-story-splitter`
+- Quality targets → `nfr-spec`
+- Measurement → `success-metrics`
+- Technical approach → `design-doc`
+```