skilldrop-cli 0.2.0

package/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"
+      ]
+    }
+  ]
+}

package/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.

package/skills/user-journey-map/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "user-journey-map",
+  "version": "0.1.0",
+  "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"],
+  "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." }
+}

package/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

package/skills/user-story-splitter/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: user-story-splitter
+description: Split an epic, feature request, or PRD chunk into independently shippable user stories with testable Gherkin acceptance criteria and a recommended build order. Use whenever the user wants to "break this down", turn an epic or PRD into a backlog, slice a feature for sprint planning, or write acceptance criteria for a story.
+---
+
+# user-story-splitter
+
+Turns one oversized requirement into a set of vertical slices a team can ship and demo one at a time. Upstream of `feature-implement-loop` — each story this skill emits is shaped to be handed straight to it (or to a human) with no re-interpretation.
+
+## How to respond
+
+1. **Ingest whatever the user has.** An epic title, a PRD section, a Slack thread, a one-paragraph idea — all valid inputs. Ask at most 2 clarifying questions, and only when the answer changes how the epic is cut (e.g. "is anonymous checkout in scope?"). Everything else: pick a default and tag it `[assumption]` inline.
+
+2. **Cut vertical slices, never horizontal layers.** Every story must deliver observable behavior end-to-end — something demoable to a non-engineer. ✅ *"Shopper pays with a saved card"* — ❌ *"Build the payments database schema"*. Use the SPIDR patterns to find the cut lines, in this order of preference:
+   - **Path** — split by user path / scenario ("pay with saved card" vs "pay with new card")
+   - **Rules** — relax a business rule into a later story ("any currency" → "USD only" first)
+   - **Data** — subset of data first ("import CSV" before "import CSV + Excel + API")
+   - **Interface** — one channel first ("web" before "web + mobile + email")
+   - **Spike** — only when genuine unknowns block estimation; timebox it and state the question it must answer
+
+3. **Make story #1 the walking skeleton.** The thinnest end-to-end path through the whole feature, even if it's embarrassingly minimal. It de-risks integration and gives every later story something working to build on.
+
+4. **Write each story with [`templates/story.md`](templates/story.md).** Per story: Connextra statement ("As a… I want… so that…"), 3–7 Gherkin acceptance criteria, out-of-scope list, and dependencies. Every story must include **at least one negative or edge-case criterion** — a story with only happy-path ACs is not done being written. (Spikes are the one exception: they carry a question and a timebox instead of acceptance criteria — see the spike variant in the template.)
+
+5. **Apply the split-again rule.** A story with more than 7 acceptance criteria, more than one persona, or an "and" in its title is two stories. Split until each one fits; stop splitting when a further cut would no longer be demoable on its own.
+
+6. **Emit the full output in one message**: a summary table (ID, title, slice pattern used, depends on, build order), then each story in full, then an **Out of scope / not covered** section listing what the epic mentioned that no story delivers — explicitly, so nothing silently disappears.
+
+## Output shape
+
+```markdown
+# Story map: {epic title}
+
+| # | Story | Slice | Depends on | Order |
+|---|-------|-------|------------|-------|
+| S1 | … (walking skeleton) | Path | — | 1 |
+| S2 | … | Rules | S1 | 2 |
+
+## S1 — {title}
+**As a** … **I want** … **so that** …
+[assumption] {any defaults picked}
+
+### Acceptance criteria
+- **AC1** Given … When … Then …
+- **AC2 (edge)** Given … When … Then …
+
+### Out of scope
+- … (covered by S3)
+
+## Out of scope / not covered by any story
+- …
+```
+
+## Useful references in this skill
+
+- [`templates/story.md`](templates/story.md) — the per-story skeleton
+- [`examples/notifications-epic.md`](examples/notifications-epic.md) — worked example: a 2-paragraph epic split into 5 stories
+
+## Quality bar
+
+- **Every story is demoable to a non-engineer.** If the demo is "look at this table in the database", it's a horizontal slice — re-cut it.
+- **Every acceptance criterion is pass/fail without interpretation.** A tester who has never seen the epic can verdict it. ✅ *"Then the order total shows the discounted price within 2s"* — ❌ *"Then the discount works correctly"*.
+- **Dependency graph is a chain or shallow tree, never a web.** No story depends on more than one other story; if it needs two, the cut is wrong.
+- **Assumptions are tagged, not embedded.** Every default the skill picked appears as a visible `[assumption]`, so planning can challenge it.
+- **The epic is fully accounted for.** Everything in the input is either inside a story or named in "Out of scope / not covered" — no silent drops.
+
+## When to use this skill
+
+- ✅ An epic or feature request too big to estimate or fit a sprint
+- ✅ Turning a PRD section into backlog items before planning
+- ✅ Writing acceptance criteria for an existing vague story
+- ✅ Producing input for `feature-implement-loop` — each emitted story is shaped for it
+
+## When NOT to use this skill
+
+- ❌ The work has no user-visible behavior (pure refactor, dependency bump) — write a task list, not stories
+- ❌ The story is already small and clear — go straight to `feature-implement-loop`
+- ❌ Estimating effort in hours/points — this skill orders and sizes by slice, it does not estimate
+- ❌ Writing the implementation — hand the story off instead
+
+## Anti-patterns to avoid
+
+- ❌ **Horizontal layer stories** — "API story", "DB story", "UI story". Three un-demoable thirds of one real story.
+- ❌ **Acceptance criteria that restate the story.** "Given the feature exists, when used, then it works" verifies nothing.
+- ❌ **Implementation details inside Gherkin.** ❌ *"When the user clicks `#submit-btn`"* — ✅ *"When the shopper confirms the order"*. ACs describe behavior, not DOM.
+- ❌ **A "misc / cleanup / polish" story** as a dumping ground for everything that didn't fit. Re-cut, or move it to out-of-scope.
+- ❌ **Splitting below the demoable threshold.** Fifteen confetti stories when six would ship is coordination overhead, not agility.
+- ❌ **A spike without a question.** Every spike states the specific unknown it resolves and a timebox; "investigate the architecture" is neither.

package/skills/user-story-splitter/examples/notifications-epic.md

@@ -0,0 +1,123 @@
+# Worked example — notifications epic → 5 stories
+
+## Input (verbatim from the user)
+
+> Epic: customers keep missing order updates. We want a notification system — order shipped, delivered, delayed. Should support email and SMS, let users pick which events they care about, and marketing wants to reuse it later for promos. Some customers are in the EU so there's consent stuff to think about.
+
+## Output
+
+# Story map: Order-update notifications
+
+| # | Story | Slice | Depends on | Order |
+|---|-------|-------|------------|-------|
+| S1 | Customer gets an email when an order ships (walking skeleton) | Path | — | 1 |
+| S2 | Customer gets emails for delivered and delayed events | Rules | S1 | 2 |
+| S3 | Customer chooses which order events to receive | Path | S2 | 3 |
+| S4 | Customer receives notifications by SMS | Interface | S3 | 4 |
+| S5 | EU customer consent is captured before any notification | Rules | S1 | 2 (parallel with S2) |
+
+## S1 — Customer gets an email when an order ships (walking skeleton)
+
+**As a** customer with a placed order
+**I want** an email the moment my order ships
+**so that** I know it's on the way without checking the site
+
+**Slice pattern:** Path
+**Depends on:** —
+[assumption] Email comes from the existing transactional-email provider; no new vendor selection in this epic.
+
+### Acceptance criteria
+
+- **AC1** Given a customer with a confirmed order and a valid email address, When the order's status changes to *shipped*, Then the customer receives a shipped email containing the order number and carrier tracking link within 5 minutes.
+- **AC2** Given an order that changes to *shipped* twice due to a status replay, When the duplicate event arrives, Then no second email is sent.
+- **AC3 (edge)** Given a customer whose email address hard-bounces, When a shipped event occurs, Then no retry storm occurs and the failure is visible in the service's logs/metrics.
+
+### Out of scope for this story
+
+- Delivered/delayed events → S2
+- Channel or event preferences → S3, S4
+- Consent gating → S5
+
+## S2 — Customer gets emails for delivered and delayed events
+
+**As a** customer with a shipped order
+**I want** emails when my order is delivered or delayed
+**so that** I'm not surprised by either outcome
+
+**Slice pattern:** Rules (relaxes "shipped only" to all three events)
+**Depends on:** S1
+
+### Acceptance criteria
+
+- **AC1** Given a shipped order, When its status changes to *delivered*, Then the customer receives a delivered email within 5 minutes.
+- **AC2** Given a shipped order, When the carrier reports a delay, Then the customer receives a delayed email containing the new estimated date.
+- **AC3 (edge)** Given an order that goes *delayed* then *delivered* within 10 minutes, When both events arrive, Then the customer receives both emails in event order, not interleaved.
+
+### Out of scope for this story
+
+- Customer choosing which of the three events to receive → S3
+
+## S3 — Customer chooses which order events to receive
+
+**As a** customer
+**I want** to pick which order events notify me
+**so that** I only get the updates I care about
+
+**Slice pattern:** Path
+**Depends on:** S2
+[assumption] Default for existing customers is all order events ON — opt-out, not opt-in (overridden by S5 for EU customers).
+
+### Acceptance criteria
+
+- **AC1** Given a logged-in customer on notification settings, When they turn *delayed* off and save, Then subsequent delay events produce no email and the setting survives logout/login.
+- **AC2** Given a customer with all events off, When any order event occurs, Then no notification of any kind is sent.
+- **AC3 (edge)** Given a settings save that fails server-side, When the customer saves, Then the UI shows the failure and the previous settings remain in effect — no silent partial save.
+
+### Out of scope for this story
+
+- Per-channel preferences (email vs SMS separately) → S4
+
+## S4 — Customer receives notifications by SMS
+
+**As a** customer who prefers texts
+**I want** order notifications by SMS
+**so that** I see them without opening email
+
+**Slice pattern:** Interface (adds a channel to existing behavior)
+**Depends on:** S3
+[assumption] One SMS provider, chosen by the team's existing vendor list; international SMS limited to countries the store ships to.
+
+### Acceptance criteria
+
+- **AC1** Given a customer with a verified phone number and SMS enabled, When a subscribed order event occurs, Then they receive an SMS within 5 minutes containing order number and a short status line.
+- **AC2** Given a customer with both channels enabled, When an event occurs, Then they receive both email and SMS for that event.
+- **AC3 (edge)** Given an unverified phone number, When the customer enables SMS, Then sending is blocked until verification completes and the UI says so.
+
+### Out of scope for this story
+
+- Quiet hours / time-zone batching → not covered, listed in epic out-of-scope
+
+## S5 — EU customer consent is captured before any notification
+
+**As an** EU customer
+**I want** to be asked for consent before receiving notifications
+**so that** my communication preferences are lawful and mine
+
+**Slice pattern:** Rules (tightens the default-on rule for one jurisdiction)
+**Depends on:** S1
+
+### Acceptance criteria
+
+- **AC1** Given a customer whose account country is in the EU and who has not consented, When any order event occurs, Then no notification is sent on any channel.
+- **AC2** Given an EU customer presented the consent prompt, When they accept, Then the consent decision, timestamp, and scope are stored and notifications begin from the next event.
+- **AC3 (edge)** Given an EU customer who previously consented, When they withdraw consent, Then notifications stop from the next event and the withdrawal is stored with a timestamp.
+
+### Out of scope for this story
+
+- Legal review of the consent copy — flagged for the compliance team, not an engineering AC.
+
+## Out of scope / not covered by any story
+
+- **Marketing/promo notifications** — the epic mentions marketing reuse "later"; nothing here builds promo sending. The event-driven design keeps it possible.
+- **Push notifications** — only email and SMS were requested.
+- **Quiet hours / batching** — not requested; revisit if SMS complaint volume appears.

package/skills/user-story-splitter/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "user-story-splitter",
+  "version": "0.1.0",
+  "description": "Split an epic, feature request, or PRD chunk into independently shippable user stories with testable Gherkin acceptance criteria and a recommended build order. Use whenever the user wants to \"break this down\", turn an epic or PRD into a backlog, slice a feature for sprint planning, or write acceptance criteria for a story.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["feature-implement-loop"],
+  "tags": ["user-stories", "agile", "backlog", "acceptance-criteria", "planning", "sprint"],
+  "model": { "tier": "standard", "rationale": "Decomposes an epic into INVEST slices with testable ACs. Structured synthesis; escalation rules cover large or contradictory PRDs." }
+}

package/skills/user-story-splitter/templates/story.md

@@ -0,0 +1,40 @@
+# Story template
+
+Copy per story. Keep every field; delete nothing silently — if a field is empty, say why.
+
+```markdown
+## S{n} — {Outcome noun phrase, e.g. "Shopper pays with a saved card"}
+
+**As a** {one persona — if you need two, split the story}
+**I want** {capability in the user's language, no implementation}
+**so that** {the value — if you can't fill this, the story may not be worth building}
+
+**Slice pattern:** {Path | Rules | Data | Interface | Spike}
+**Depends on:** {one story ID, or —}
+[assumption] {any default picked while writing this story; omit the line if none}
+
+### Acceptance criteria (3–7; at least one edge/negative)
+
+- **AC1** Given {precondition} When {action} Then {observable, pass/fail outcome}
+- **AC2 (edge)** Given {boundary or failure precondition} When {action} Then {graceful observable outcome}
+
+### Out of scope for this story
+
+- {thing a reviewer will ask about} → {covered by S{m} | not covered, listed in epic out-of-scope}
+```
+
+Spike variant — replace acceptance criteria with:
+
+```markdown
+### Question this spike answers
+
+{The single specific unknown, phrased so the answer is decidable.}
+
+### Timebox
+
+{e.g. 1 day. The spike ends when the timebox does, answered or not.}
+
+### Output
+
+A written recommendation that lets {the blocked story ID} be estimated.
+```