skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/product-manager/skills/success-metrics/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: success-metrics
+description: 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. Use 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.
+---
+
+# success-metrics
+
+Answers "how will we know it worked?" *before* build, when the answer can still change what gets built — and makes the measurement honest by pre-committing the decision rule, naming the counter-metric that catches gaming, and writing the instrumentation plan so launch day isn't the day someone discovers no event fires. Expands the one-line success criteria in a `prd-draft` into the full measurement design.
+
+## How to respond
+
+1. **Extract the goal** from the PRD, brief, or conversation. Ask at most 2 questions, spent on **baseline** ("what's the number today, and where does it live?") and **decision authority** ("who acts if the target is missed?"). No goal articulated yet → stop and route to `prd-draft`; metrics for an unstated goal measure noise. Non-interactive run (no user to ask): a stated-but-vague goal gets sharpened and tagged `[assumption]`; no goal at all → emit `BLOCKED: need the feature's goal` — never invent one.
+
+2. **Pick exactly one primary metric.** More than one primary means none — when they diverge, nobody pre-agreed which wins. The primary is an **outcome the user experiences or the business banks**, not an output the team ships. ✅ *"Median support-ticket handle time"* — ❌ *"Number of dashboard features launched"* — ❌ *"Dashboard page views"* (attention is not outcome). Every other contender becomes a secondary, guardrail, or gets cut.
+
+3. **Give the primary its three numbers**: **baseline** (today's value + source; if unknown, the first milestone of the plan is *measuring it* — a target without a baseline is a guess about a guess), **target** (the value that means "worked"), **timeframe** (when judged, plus the patience window — how long after launch before the data is trusted: novelty effects, weekly cycles, cohort maturity).
+
+4. **Add leading indicators** — 2–3 metrics that move within days and plausibly predict the primary, each with its causal sentence: ✅ *"% of tickets where the agent opens the unified view — if agents don't adopt it, handle time can't drop"*. Leading indicators are for steering mid-flight; only the primary decides success.
+
+5. **Set guardrails and the counter-metric.** Guardrails: 2–4 things the feature must **not** degrade (error rate, page latency, adjacent-flow conversion, support volume), each with its current value and an alert threshold. For a **brand-new surface with no prior value** (e.g. the feature's own latency), the guardrail says "baseline measured in week 1, threshold set then" — the same escape hatch the primary metric gets; don't invent a current number that can't exist pre-launch. Counter-metric: the specific way the primary could be gamed, and the metric that catches it — ✅ *"Handle time could drop via premature ticket closure → watch reopen rate"*. A primary without a counter-metric invites exactly the behavior it can't see.
+
+6. **Write the instrumentation plan** — for every metric: the event name (consistent scheme, e.g. `domain.object.action`), its properties (incl. the dimensions you'll slice by: tenant, plan, platform), where it fires, and whether it **exists today or must be built**. The must-build list is a launch dependency, not a fast-follow: shipped-then-instrumented features have no week-one data and a contaminated baseline. Dashboard owner and review cadence named.
+
+7. **Pre-commit the decision rule.** One sentence, agreed before launch, naming the action: ✅ *"If primary improvement < 10% at day 60 with ≥70% agent adoption, we run the iteration review; < 10% with low adoption, we fix adoption first; guardrail breach at any point pauses rollout"*. Without it, every result becomes an argument and every miss becomes "directionally positive."
+
+8. **Emit with [`templates/metrics-plan.md`](templates/metrics-plan.md)** in one message: metric tree (primary → leading → guardrails/counter), the three numbers, instrumentation table, decision rule, and review cadence.
+
+## Useful references in this skill
+
+- [`templates/metrics-plan.md`](templates/metrics-plan.md) — the metric tree, instrumentation table, and decision-rule skeleton
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ A PRD's goals need their full measurement design
+- ✅ "How do we know this feature worked?" / "define the KPIs for X"
+- ✅ Pre-launch instrumentation planning — what events must exist on day one
+- ✅ Retro-fitting honest metrics onto a feature that shipped without any
+
+## When NOT to use this skill
+
+- ❌ 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
+
+## Anti-patterns to avoid
+
+- ❌ **Twelve "key" metrics.** A dashboard where everything is key lets every outcome be declared a win. One primary; the rest serve it.
+- ❌ **Targets without baselines.** "Increase activation to 40%" — from what? If today is 38%, the feature is a rounding error wearing a goal.
+- ❌ **Vanity metrics as primary.** Page views, sign-ups, sessions — countable, reportable, and silent on whether anyone's life improved.
+- ❌ **Instrumentation as fast-follow.** "We'll add tracking next sprint" = no week-one data, contaminated baseline, and a success debate held on vibes.
+- ❌ **Post-hoc decision rules.** Deciding what the numbers must show *after* seeing them — the moment measurement becomes marketing.
+- ❌ **Ignoring the patience window.** Judging at day 7 what needs a 60-day cohort — novelty spikes and weekly cycles read as signal.
+- ❌ **Proxy laundering.** Using clicks as a proxy for value and then forgetting it's a proxy — label proxies as proxies, every time they're cited.
+- ❌ **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.
+- ❌ **A bare `BLOCKED` line.** Keep the `BLOCKED: need <X>` line, then write for a person: what is missing in plain words, what you will produce once you have it, and anything the request already lets you say.

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

@@ -0,0 +1,11 @@
+[
+  { "query": "How do we know this feature worked? Define the KPIs", "should_trigger": true },
+  { "query": "Set up success criteria and an instrumentation plan before we launch", "should_trigger": true },
+  { "query": "What should we measure to judge the new onboarding flow?", "should_trigger": true },
+  { "query": "Define the success metrics for this PRD's goals", "should_trigger": true },
+
+  { "query": "Cascade company OKRs down to the teams", "should_trigger": false },
+  { "query": "Analyze last month's launch results", "should_trigger": false },
+  { "query": "Design the eval harness for our LLM feature", "should_trigger": false },
+  { "query": "Calculate the sample size for this A/B test", "should_trigger": false }
+]

skilldrop_cli/data/packs/product-manager/skills/success-metrics/evals/evals.json

@@ -0,0 +1,27 @@
+{
+  "skill_name": "success-metrics",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Define success metrics for this feature: a unified customer view for our support agents, merging tickets, orders, and chat history into one screen. Goal from the PRD: cut median ticket handle time. Current handle time lives in our Zendesk dashboard.",
+      "assertions": [
+        "Exactly one primary metric, and it is an outcome (handle time), not an output or vanity count — with the runner-up named and the choice justified",
+        "The primary has baseline (with source), target, and timeframe including a patience window — or measuring the baseline is explicitly milestone 1",
+        "2-3 leading indicators, each with a causal sentence",
+        "2-4 guardrails with current values and alert thresholds (or a week-1 baseline plan for brand-new surfaces)",
+        "A counter-metric names the specific gaming path (e.g. premature ticket closure → reopen rate)",
+        "Every metric maps to a named event marked exists/must-build, and must-build events are launch blockers",
+        "A pre-committed, action-shaped decision rule names who does what at which threshold"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "[Non-interactive run — no user available to answer questions] Define success metrics.",
+      "assertions": [
+        "No metrics are invented — with no goal stated, the output is BLOCKED: need the feature's goal",
+        "The BLOCKED output routes to prd-draft (or names the goal as what to rerun with)",
+        "No primary metric, instrumentation table, or decision rule appears"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/success-metrics/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "success-metrics",
+  "version": "0.1.1",
+  "description": "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. Use 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.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["prd-draft"],
+  "tags": ["metrics", "kpi", "instrumentation", "measurement", "analytics", "success-criteria"],
+  "model": { "tier": "standard", "rationale": "Structured measurement design; the primary-metric and counter-metric choices need judgment but the template bounds it. Escalate via ambiguous-input when the goal itself is contested." }
+}

skilldrop_cli/data/packs/product-manager/skills/success-metrics/templates/metrics-plan.md

@@ -0,0 +1,55 @@
+# Metrics-plan template
+
+One primary. Everything else exists to steer toward it or to catch it lying.
+
+```markdown
+# Success metrics: {feature}
+
+**Goal (from PRD):** {the outcome this feature exists to cause}
+**Decision authority:** {role who acts on the decision rule} `[reported]`
+
+## Primary metric (exactly one)
+
+**Metric:** {outcome the user experiences or the business banks}
+**Why this over {runner-up}:** {one sentence}
+**Proxy?** {no | yes — proxy for {real outcome}; label it as proxy wherever cited}
+
+| Baseline | Target | Judged at | Patience window |
+|---|---|---|---|
+| {value + source, or "MILESTONE 1: measure baseline by {date}"} | {value} | {date / days post-launch} | {why not earlier — novelty, weekly cycle, cohort maturity} |
+
+## Leading indicators (steering only — they never declare success)
+
+| Metric | Moves within | Causal sentence |
+|---|---|---|
+| {e.g. % agents opening unified view} | days | {if this doesn't move, primary can't} |
+
+## Guardrails (must not degrade)
+
+| Metric | Current | Alert threshold | Action on breach |
+|---|---|---|---|
+| {error rate / latency / adjacent conversion / support volume} | {value, or "measure wk 1" for a new surface} | {value} | pause rollout / page owner |
+
+## Counter-metric (the gaming catch)
+
+**Primary could be gamed by:** {the behavior}
+**Caught by:** {metric + threshold} — reviewed alongside the primary, every review.
+
+## Instrumentation plan (launch dependency, not fast-follow)
+
+| Event | Properties (incl. slice dimensions) | Fires where | Status |
+|---|---|---|---|
+| `domain.object.action` | {tenant, plan, platform, …} | {surface/service} | exists / **must build** |
+
+**Must-build events are launch blockers.** Dashboard: {where} · Owner: {role} · Review cadence: {weekly until judged-at date}
+
+## Decision rule (pre-committed — action-shaped)
+
+- If {primary condition} at {judged-at} with {adoption/leading condition} → {action}
+- If {primary misses} but {adoption low} → fix adoption first, re-judge at {date}
+- Guardrail breach at any time → {action}
+
+## Out of scope for measurement
+
+- {what this plan deliberately doesn't measure, and why}
+```

skilldrop_cli/data/packs/product-manager/skills/user-journey-map/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: user-journey-map
+description: 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. Use 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".
+---
+
+# user-journey-map
+
+Maps what one customer experiences on the way to one outcome — outside-in, frontstage only — and converts the map's pains into a **ranked improvement target**, because a journey map that ends as wall art has failed. The emotional low points get found and named (peak-end rule: users judge an experience by its worst moment and its ending, not its average), so downstream design knows exactly which two stages to fix first. Sibling of `architecture-diagrams` (systems, not people) and upstream of `prd-draft` / `user-story-splitter` when an opportunity becomes committed work.
+
+## How to respond
+
+1. **Anchor persona, outcome, and evidence level.** Ask at most 2 questions, spent on the weakest anchors: *"whose journey — one specific persona?"* and *"what outcome are they trying to reach?"* No persona or outcome → don't draft; a journey for "users" toward "using the product" has no stage boundaries. Non-interactive run (no user to ask): derive a specific persona and outcome from the input if defensible and tag them `[assumption]`; underivable → emit `BLOCKED: need persona + outcome` naming both. Tag the whole map's **evidence level**: `[observational]` (interviews, session recordings), `[survey/analytics]`, or `[assumption-based]` (team hypothesis). Assumption-based is legitimate — it's a hypothesis that directs research — but it must say so at the top, not masquerade as findings.
+
+2. **Fix the journey's edges.** Start trigger (the event that puts the persona on this path — in their life, not on your site: ✅ *"payroll fails on the last Friday of the month"*) and end state (what "done" means *to the persona* — ❌ "completes checkout" if their outcome is "salary problem solved"). Wrong edges are the most common defect: starting at the landing page amputates the discovery pain, ending at purchase hides the abandonment cliff in activation.
+
+3. **Divide into 3–6 named stages.** Stages are coarse phases of the persona's goal — *discover, evaluate, start, get value, return* — never screens or clicks. More than 6 stages means the altitude has dropped to flow level; that's `user-story-splitter` / flow-design territory, say so and re-chunk.
+
+4. **Fill the four rows per stage** — this table is the artifact's core:
+   - **Actions**: what the persona does, in their words, frontstage only. What the org does backstage ("support reviews the request") is out of scope — note it in the hand-off, don't map it.
+   - **Emotion**: score 1–5 with the *reason*: ✅ *"2 — asked for the same information a third time"* — ❌ *"2 — frustrated"*.
+   - **Pains**: friction, confusion, dead ends — each tagged with the step-1 evidence level if it differs from the map's default.
+   - **Opportunities**: what would change the experience if the pain were removed — stated as an outcome, not a solution: ✅ *"never re-enter data the system already has"* — ❌ *"add autofill"* (that's a design decision that belongs downstream).
+
+5. **Mark the peaks, then rank.** From the emotion row: the **1–2 steepest dips** and the **single highest peak**, plus the *ending* emotion (peak-end rule counts it double). Rank the opportunities: severity of the dip × how many personas/journeys hit it × evidence strength. Top 2 opportunities become the named improvement targets; the rest are listed but explicitly deprioritized — an unranked list re-delegates the judgment to the reader.
+
+6. **Render and emit** with [`templates/journey-map.md`](templates/journey-map.md), in one message: the stage table, a Mermaid `journey` diagram (one `section` per stage, scored actions drawing the emotion arc), ranked opportunities with the two named targets, and hand-offs — target becomes committed work → `prd-draft` or `user-story-splitter`; measurement for a fix → `success-metrics`; backstage causes implicated → name them for the service owner. See [`examples/b2b-saas-onboarding.md`](examples/b2b-saas-onboarding.md) for the full pattern.
+
+## Useful references in this skill
+
+- [`templates/journey-map.md`](templates/journey-map.md) — stage table, Mermaid journey skeleton, ranked-opportunities block
+- [`examples/b2b-saas-onboarding.md`](examples/b2b-saas-onboarding.md) — worked example: trial-to-activation journey, assumption-based, with ranked targets
+
+## Quality bar
+
+- **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.
+
+## When to use this skill
+
+- ✅ "Map the customer journey through onboarding/purchase/support"
+- ✅ "Where do users feel the most friction?" — with or without research data
+- ✅ Before a redesign: agree on the as-is experience and where it hurts most
+- ✅ Turning scattered user feedback into one shared picture of the path
+
+## When NOT to use this skill
+
+- ❌ 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`
+
+## Anti-patterns to avoid
+
+- ❌ **One stage per screen.** "Landing → Signup form → Email verify → Dashboard" is a screen list, not a journey — stages are phases of the persona's goal.
+- ❌ **Mapping the org, not the customer.** "Support triages the ticket" is backstage; the customer's row says *"waits two days, chases twice"*.
+- ❌ **Hypothesis dressed as research.** An assumption-based map presented without its tag poisons every decision built on it. The tag is load-bearing.
+- ❌ **Happy-path-only journeys.** A map with no dip below 3 didn't look — errors, waits, and re-entry live in every real journey.
+- ❌ **Solutioning in the opportunities row.** "Add SSO" pre-empts design with a guess; "signing in stops being the reason trials stall" keeps the problem open and measurable.
+- ❌ **The unranked pain inventory.** Fourteen equal pains means the reader does the prioritizing — the map's whole job was to do it for them.
+- ❌ **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/user-journey-map/evals/eval_queries.json

@@ -0,0 +1,12 @@
+[
+  { "query": "Map the customer journey through our onboarding flow", "should_trigger": true },
+  { "query": "Where do users feel the most friction in the purchase experience?", "should_trigger": true },
+  { "query": "Create a journey map for a new user's first week", "should_trigger": true },
+  { "query": "Turn this pile of user feedback into a customer experience map", "should_trigger": true },
+  { "query": "Map the touchpoints from trial signup to activation", "should_trigger": true },
+
+  { "query": "Design the screen-by-screen flow for the checkout wizard", "should_trigger": false },
+  { "query": "Diagram how the order service talks to the payment service", "should_trigger": false },
+  { "query": "Map our internal ticket-escalation process", "should_trigger": false },
+  { "query": "Write the PRD for the onboarding redesign", "should_trigger": false }
+]

skilldrop_cli/data/packs/product-manager/skills/user-journey-map/evals/evals.json

@@ -0,0 +1,30 @@
+{
+  "skill_name": "user-journey-map",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Map the customer journey for freelance designers trying our invoicing app. We believe they drop off between signup and sending their first invoice. No research data yet — this is the team's hypothesis.",
+      "assertions": [
+        "One specific persona and one outcome are named in the map's title",
+        "Evidence level is declared as assumption-based at the top and framed as a hypothesis that directs research",
+        "The start trigger is an event in the persona's life (e.g. a client asks for an invoice), not 'visits the landing page'",
+        "3-6 stages, each a phase of the persona's goal — not one stage per screen",
+        "Every stage has all four rows: actions (persona's words, frontstage only), emotion score 1-5 with a reason, pains, opportunities",
+        "Opportunities are outcome-shaped, not feature suggestions like 'add a button'",
+        "The steepest dips, the highest peak, and the ending emotion are explicitly marked",
+        "A Mermaid journey diagram is emitted with valid syntax: one section per stage, actions scored 1-5",
+        "Opportunities are ranked and exactly 1-2 are named as targets; the rest are explicitly deprioritized with reasons",
+        "Hand-offs route committed work to prd-draft/user-story-splitter and measurement to success-metrics"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "[Non-interactive run — no user available to answer questions] Map the journey.",
+      "assertions": [
+        "No journey is drafted — with no persona or outcome derivable, the output is BLOCKED: need persona + outcome",
+        "The BLOCKED output names both missing anchors and what to rerun with",
+        "No invented persona, stages, or Mermaid diagram appear"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/product-manager/skills/user-journey-map/examples/b2b-saas-onboarding.md

@@ -0,0 +1,69 @@
+# Worked example: trial-to-activation journey for a B2B monitoring SaaS
+
+**Input given to the skill:**
+
+> Map the journey for engineering managers trialing our infrastructure-monitoring product. We think most trials stall before the first dashboard shows real data. No user research yet — this is what the growth team believes is happening. Trial starts when an alerting incident burns the team; success is the manager seeing their own production data on a dashboard and sharing it with the team.
+
+**Output:**
+
+---
+
+# Journey map: Engineering manager "Priya" → own production data on a shared dashboard
+
+> Evidence level: `[assumption-based]` — growth-team hypothesis, no primary research yet. This map directs research; treat pains as hypotheses to verify, not findings.
+> Start trigger: a production incident goes unnoticed for 40 minutes and the postmortem lands on Priya's desk · End state: Priya shares a dashboard of her own production data with her team
+
+## Stages
+
+| | Feel the burn | Evaluate options | Start the trial | Connect real data | First shared win |
+|---|---|---|---|---|---|
+| **Actions** | Reads the postmortem; asks "why didn't we see this?"; searches "kubernetes monitoring alerts" | Skims 3 vendor sites; asks peers in a Slack community; shortlists 2 | Signs up with work email; lands on an empty dashboard | Installs the agent on a staging cluster; hunts for the right Helm values; waits for data | Sees staging metrics; wants prod but needs security sign-off; shares a screenshot in team channel |
+| **Emotion (1–5 + why)** | 2 — on the hook for an outage nobody saw | 3 — options exist, but every site says the same words | 4 — signup was fast, feels like progress | 2 — empty dashboard + config hunt; unclear if it's working or broken | 3 — win is real but staging-only; prod approval looms |
+| **Pains** | Postmortem pressure with no tooling answer | Undifferentiated marketing; can't tell depth from demos | **Empty dashboard with no next step** | **No feedback during agent setup — silence until data arrives**; Helm docs assume expertise | Security review blocks prod; sharing is screenshot-only |
+| **Opportunities** | Meet the searcher with the incident story, not a feature tour | Let Priya see the product on realistic data before signup | First session ends with data visible, even if sample | Setup progress is visible minute-by-minute; failure states name their fix | The shared artifact is live, not a screenshot; security answers are self-serve |
+
+## Emotion arc
+
+```mermaid
+journey
+    title Priya → own production data on a shared dashboard
+    section Feel the burn
+      Read the postmortem: 2: Priya
+      Search for tooling: 3: Priya
+    section Evaluate options
+      Compare vendors: 3: Priya
+    section Start the trial
+      Sign up: 4: Priya
+      Land on empty dashboard: 2: Priya
+    section Connect real data
+      Install agent, wait in silence: 2: Priya
+    section First shared win
+      See staging data: 4: Priya
+      Hit prod sign-off wall: 3: Priya
+```
+
+## Peaks and ending
+
+- **Steepest dips:** signup-high (4) → empty dashboard (2) — the sharpest single drop in the journey; agent install silence (2) — longest time spent at the bottom
+- **Highest peak:** staging data appears (4)
+- **Ending emotion:** 3 — a real win immediately blunted by the prod-approval wall; the journey *ends* on friction, which the peak-end rule says colors the whole trial
+
+## Opportunities, ranked
+
+| # | Opportunity (outcome-shaped) | Dip severity | Reach | Evidence | Target? |
+|---|---|---|---|---|---|
+| 1 | The first session ends with data on the dashboard, even sample data | 4→2, sharpest drop | every trial | `[assumption-based]` | ✅ named target |
+| 2 | Setup progress is visible minute-by-minute; silence never means "unknown" | 2, longest dwell | every self-serve install | `[assumption-based]` | ✅ named target |
+| 3 | Security answers are self-serve so prod approval starts during trial | ending friction | enterprise segment | `[assumption-based]` | deprioritized — smaller reach; revisit after research |
+| 4 | Evaluation shows the product on realistic data pre-signup | 3, mild | top of funnel | `[assumption-based]` | deprioritized — funnel, not activation |
+
+## Hand-off
+
+- Target #1 → verify with session recordings first (`[assumption-based]` — 5 recordings would confirm the drop), then `prd-draft` for the empty-state experience
+- Target #2 → `user-story-splitter` (install-feedback states are already story-shaped)
+- Fix measurement → `success-metrics`: candidate first-success event is "real data visible in first session"
+- Backstage causes implicated: agent packaging (Helm defaults), security-review process → platform team, security team
+
+---
+
+**Why this output passes the quality bar:** one persona, one outcome, both in the title; evidence level declared and repeated where it matters (the map admits it's a hypothesis and names the research that would confirm it); stage edges live in Priya's life (the postmortem, not the landing page); every emotion score has a reason; opportunities are outcomes ("first session ends with data"), not features ("add sample data mode"); dips, peak, and ending are marked; exactly two targets are named and the rest explicitly deprioritized.

skilldrop_cli/data/packs/product-manager/skills/user-journey-map/manifest.json

@@ -0,0 +1,15 @@
+{
+  "name": "user-journey-map",
+  "version": "0.1.1",
+  "description": "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. Use 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\".",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["architecture-diagrams", "prd-draft", "reverse-architecture", "success-metrics", "user-story-splitter"],
+  "handoff": [
+    { "to": "prd-draft", "when": "a friction point on the journey is worth fixing", "purpose": "Turn the named friction into numbered requirements.", "fallback": "If prd-draft is absent, write the requirements inline as numbered, testable statements and note that prd-draft in skilldrop would structure them." },
+    { "to": "success-metrics", "when": "the fix needs a measure before it is built", "purpose": "Design the measurement for the journey step being changed.", "fallback": "If success-metrics is absent, state one baseline and one target per fixed step inline." }
+  ],
+  "tags": ["journey-map", "customer-experience", "ux", "touchpoints", "mermaid", "personas"],
+  "model": { "tier": "standard", "rationale": "Structured synthesis into a fixed four-row stage model plus bounded ranking judgment. Escalate via ambiguous-input when the persona or outcome is contested or research inputs conflict." }
+}

skilldrop_cli/data/packs/product-manager/skills/user-journey-map/templates/journey-map.md

@@ -0,0 +1,47 @@
+# Journey map: {persona} → {outcome}
+
+> Evidence level: `[observational]` / `[survey/analytics]` / `[assumption-based]`
+> Start trigger: {event in the persona's life} · End state: {what done means to the persona}
+
+## Stages
+
+<!-- 3–6 stages — add or remove columns to match the journey; four here is a placeholder, not a required count. -->
+
+| | {Stage 1} | {Stage 2} | {Stage 3} | {Stage 4} |
+|---|---|---|---|---|
+| **Actions** | {what the persona does, their words} | | | |
+| **Emotion (1–5 + why)** | {3 — reason} | | | |
+| **Pains** | {friction; tag if evidence differs} | | | |
+| **Opportunities** | {outcome, not feature} | | | |
+
+## Emotion arc
+
+```mermaid
+journey
+    title {persona} → {outcome}
+    section {Stage 1}
+      {action}: {1-5}: {persona-short-name}
+      {action}: {1-5}: {persona-short-name}
+    section {Stage 2}
+      {action}: {1-5}: {persona-short-name}
+```
+
+## Peaks and ending
+
+- **Steepest dips:** {stage/action, score, reason} · {stage/action, score, reason}
+- **Highest peak:** {stage/action, score, reason}
+- **Ending emotion:** {score, reason — peak-end rule counts this double}
+
+## Opportunities, ranked
+
+| # | Opportunity (outcome-shaped) | Dip severity | Reach | Evidence | Target? |
+|---|---|---|---|---|---|
+| 1 | {…} | {…} | {…} | {tag} | ✅ named target |
+| 2 | {…} | {…} | {…} | {tag} | ✅ named target |
+| 3 | {…} | {…} | {…} | {tag} | deprioritized — {why} |
+
+## Hand-off
+
+- Target #1 → `prd-draft` / `user-story-splitter` when committed
+- Fix measurement → `success-metrics`
+- Backstage causes implicated: {named systems/teams} → service owner

skilldrop_cli/data/packs/research/pack.json

@@ -0,0 +1,52 @@
+{
+  "description": "Take a question from vague to answered: plan the research around the decision it serves, synthesise the sources with every claim cited, and rank rival explanations by the evidence against them.",
+  "display_name": "Research",
+  "keywords": ["research", "literature review", "synthesis", "citations", "hypotheses", "evidence"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/research/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "non-technical",
+    "prerequisites": ["A question you need answered and the decision it feeds; for synthesis, the text of your sources, not just titles"],
+    "starter-task": "Turn a vague research request into a plan you can finish",
+    "starter-prompt": "I need to research whether our 14-person support team should move to a four-day week. Our COO decides by 1 November. I have about 20 hours and can pull ticket data from Zendesk.",
+    "verification": "research-plan writes a plan that opens with the decision, the decider and the date, then gives three to six sub-questions, each with a finding that would change the decision, a method, search strings, and a stopping rule with a budget cap.",
+    "recovery": "If you get a plan built around a decision you didn't give, say who decides what and by when, and run it again. If research-plan does not activate, ask for it by name (\"use research-plan\")."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You've been asked to look into something before a decision, and you need an answer you can defend, with sources.",
+    "you_bring": [
+      "the decision the research feeds, who makes it, and by when",
+      "the time you have",
+      "the sources you collect: papers, reports, articles or interview transcripts, as text",
+      "any data or observations, if the question is why something happened"
+    ],
+    "time": "An hour to plan and an hour to synthesise, plus however long the research takes",
+    "steps": [
+      {
+        "skill": "research-plan",
+        "you_do": "Say what decision the research is for, then give it the topic and your time budget.",
+        "you_get": "A two-page plan: the precise question, sub-questions with the finding that would change the decision, a method for each, inclusion criteria, search strings, and a stopping rule.",
+        "decide": "Agree the thresholds before you start, so the findings can't be read to fit."
+      },
+      {
+        "skill": "source-synthesis",
+        "you_do": "Hand it the sources you collected, as text, with the plan's question.",
+        "you_get": "Findings with every claim cited to a source and page, agreement and disagreement made explicit, a strength rating per finding, the gaps, and a citation check report."
+      },
+      {
+        "skill": "hypothesis-comparison",
+        "you_do": "If the question is why something happened, give it the observation and the cited findings.",
+        "you_get": "A consistency matrix ranking the explanations by the evidence against them, the evidence the ranking rests on, and the next observation that would tell the leaders apart.",
+        "decide": "Act on the leading explanation, or run the next observation first."
+      }
+    ],
+    "you_end_with": "A decision-led plan, a cited synthesis you can check line by line, and, for why-questions, a ranked set of explanations with the next test to run."
+  }
+}

skilldrop_cli/data/packs/research/skills/hypothesis-comparison/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: hypothesis-comparison
+description: Compare rival explanations for an observation with analysis of competing hypotheses (ACH) — list the hypotheses and the evidence, build a consistency matrix (consistent / inconsistent / neutral), rank hypotheses by how little evidence contradicts them rather than how much supports them, name the diagnostic evidence and the linchpins, and say which next observation would tell the leaders apart. Use when the user asks "why did X happen", "which explanation fits the evidence", "what's really causing this", wants to stop arguing over a favourite theory, or says "compare these hypotheses", "competing explanations", "ACH".
+---
+
+# hypothesis-comparison
+
+You help the user decide between rival explanations without falling for the first one that
+fits. The method is analysis of competing hypotheses (ACH), described by Richards Heuer in
+*Psychology of Intelligence Analysis*: put every hypothesis against every piece of evidence,
+and keep the hypothesis with the **least evidence against it**. Evidence that fits every
+hypothesis feels persuasive and proves nothing, so the matrix makes that visible. The output
+is a ranked matrix, the evidence the ranking rests on, and the next observation to make.
+
+This skill explains a past or current observation. To choose between options going forward,
+use `tech-comparison-matrix` (technology) or `strategy-analysis` (market position). To gather
+the evidence in the first place, plan it with `research-plan` and summarise sources with
+`source-synthesis`.
+
+## How to respond
+
+1. **Ask once for what's missing.** You need three things: the **observation** to explain,
+   stated as a fact with a time and a size (✅ *"Mobile conversion fell 18% from 8 Sep"* — ❌
+   *"sales are weird"*); the **evidence** the user has; and any **hypotheses** already on the
+   table. Ask for all missing ones in one message, at most two questions. If the user gives a
+   synthesis from `source-synthesis`, take its findings as the evidence list, with citations.
+
+2. **Write at least four hypotheses, and make them rivals.** Include the user's favourite,
+   the obvious alternative, a "nothing changed, it's measurement" hypothesis (tracking,
+   definitions, sampling), and a "chance or normal variation" hypothesis where the numbers
+   allow it. Each hypothesis is one sentence that could be false. If two hypotheses predict
+   the same thing for every piece of evidence, merge them. If they overlap, say how the
+   matrix treats them (for example "H1 and H2 can both be true; rated as if each acts alone").
+
+3. **List the evidence as observations, not conclusions.** One row per item, each with its
+   source. Include **absences**: something that should have happened under a hypothesis and
+   didn't is often the most diagnostic row. Add assumptions that carry weight as rows too,
+   marked `[assumption]`. Give each row a weight from 0.5 to 2 for credibility and relevance;
+   a rumour is 0.5, a primary record is 2. Say why for anything not 1.
+
+4. **Fill the matrix one row at a time, across all hypotheses.** For each piece of evidence,
+   ask: "if this hypothesis were true, how likely is this observation?" Rate it `CC` (very
+   consistent), `C`, `N` (neutral), `I` (inconsistent), `II` (very inconsistent) or `NA`.
+   Work across a row, not down a column, so you judge the evidence and not your favourite
+   hypothesis. Rules in [`reference.md`](reference.md).
+
+5. **Score it.** Save the matrix as a CSV in the shape of
+   [`templates/matrix.csv`](templates/matrix.csv) and run:
+
+   ```bash
+   # Claude Code
+   python3 "${CLAUDE_SKILL_DIR}/scripts/ach_matrix.py" matrix.csv -o ach-report.md
+   # Other IDEs (from the skill folder)
+   python3 scripts/ach_matrix.py matrix.csv -o ach-report.md
+   ```
+
+   The script ranks by weighted inconsistency (`I` = 1 × weight, `II` = 2 × weight, the rest
+   0), marks non-diagnostic rows, and drops each row in turn to find the **linchpins** whose
+   removal changes first place. If no script can run, do the same three steps by hand and
+   show the arithmetic.
+
+6. **Read the result, don't just report it.**
+   - **Rank by inconsistency.** The leader is the hypothesis hardest to rule out, not the one
+     with the most `C` ratings. Say so when the two differ.
+   - **Name the diagnostic evidence**: the rows rated differently across the leading
+     hypotheses. Name the non-diagnostic rows too, and stop citing them as support.
+   - **Check the linchpins.** For each one, say where it came from and what would happen if it
+     were wrong or misread. A ranking that rests on one weak row is a lead, not a conclusion.
+   - **Say what kills each survivor:** the observation that would move each top hypothesis to
+     `I` or `II`.
+
+7. **Name the next observation that discriminates.** Pick the cheapest check that the top two
+   hypotheses predict differently, and write it as a test: what to look at, what result
+   supports which hypothesis, who can get it, and how long it takes. ✅ *"Pull iOS Safari
+   checkout errors from the payment SDK logs for 7–9 Sep. H1 predicts a spike after 22:00 on
+   the 7th; H4 predicts none."*
+
+8. **Write it up with [`templates/hypothesis-comparison.md`](templates/hypothesis-comparison.md)**:
+   the observation, hypotheses, the matrix, the ranking with scores, diagnostic and
+   non-diagnostic evidence, linchpins, the conclusion with a confidence word and why, and the
+   next observation. Keep the conclusion tentative where the evidence is thin, and say how
+   thin.
+
+**Non-interactive runs** (subagent, CI, headless): a missing observation emits
+`BLOCKED: need the observation to explain, with its time and size`. Missing hypotheses are
+generated per step 2 and tagged `[assumption]`. If the user supplied no evidence at all, emit
+`BLOCKED: need the evidence to rate`, because a matrix of invented evidence ranks nothing.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — the ACH steps, how to rate a cell, weighting, diagnosticity, the usual failure modes, and when ACH is the wrong tool
+- [`templates/matrix.csv`](templates/matrix.csv) — the CSV the script reads
+- [`templates/hypothesis-comparison.md`](templates/hypothesis-comparison.md) — the write-up skeleton
+- [`scripts/ach_matrix.py`](scripts/ach_matrix.py) — scores the matrix, flags non-diagnostic rows, finds linchpins (stdlib only)
+- [`examples/conversion-drop.md`](examples/conversion-drop.md) — worked example: a checkout conversion drop, four hypotheses, nine pieces of evidence, real script output
+
+## Quality bar
+
+- **At least four rival hypotheses,** including a measurement one, each a sentence that could be false.
+- **Evidence rows are observations with a source,** including at least one absence where one exists. Nothing in the matrix is evidence the user didn't supply, except rows tagged `[assumption]`.
+- **The ranking is by inconsistency.** The write-up never argues for a hypothesis by counting its `C` ratings.
+- **Non-diagnostic evidence is named and set aside,** not used as support.
+- **Linchpins are named and checked:** the rows whose removal changes the leader, with where each came from.
+- **The conclusion carries a confidence word and a reason,** and stays tentative when one row holds it up.
+- **The next observation discriminates between the top two,** with the result each one predicts.
+
+## When to use this skill
+
+- ✅ "Why did conversion / churn / latency / incident rate change?" with several plausible causes
+- ✅ A team stuck arguing for favourite explanations, and needing a neutral way to rank them
+- ✅ Making sense of a finished `source-synthesis` when the sources point to different explanations
+- ✅ Deciding what to investigate next when you can't check everything
+
+## When NOT to use this skill
+
+- ❌ Choosing between technologies, vendors or approaches for the future — `tech-comparison-matrix`
+- ❌ Market or competitive position, SWOT, Five Forces — `strategy-analysis`
+- ❌ Planning what evidence to collect before you have any — `research-plan`
+- ❌ Summarising what a set of sources says — `source-synthesis`
+- ❌ Reviewing someone's written argument for weak spots — `doc-critique`
+- ❌ Writing up an incident's timeline and causes once they're known — `postmortem-generator`
+
+## Anti-patterns to avoid
+
+- ❌ **Counting support.** "H1 is consistent with 7 of 9 items" says little if those items fit every hypothesis.
+- ❌ **Two hypotheses, one of them a straw man.** Rivals have to be plausible enough to lose to.
+- ❌ **Leaving out "it's the measurement".** Tracking changes, new definitions and sampling explain more drops than anyone expects.
+- ❌ **Filling the matrix column by column.** You end up rating evidence by how well it fits your favourite.
+- ❌ **Evidence that is really a conclusion,** like "the release was buggy". Write what was observed.
+- ❌ **A confident verdict resting on one linchpin** nobody has checked.
+- ❌ **"More research needed"** as the next step. Name the one observation and what each result means.