skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/dev-team/skills/test-plan-generator/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: test-plan-generator
+description: Generate a risk-based test plan for a feature, PR, or release — risks ranked by likelihood × impact, test cases pushed to the lowest pyramid level that catches the failure, every acceptance criterion mapped to a test, and an explicit "not tested" list. Use when the user asks for a test plan, test cases, a QA strategy for a change, "how should we test this", or pre-release test coverage.
+---
+
+# test-plan-generator
+
+Produces a test plan that says what to test *first*, what to test *where* (unit vs integration vs e2e), and — the part most plans omit — what is deliberately not tested and why. Downstream of `user-story-splitter` (its ACs map straight into the coverage table); sibling of `feature-implement-loop` (which writes the tests this plan prioritizes).
+
+## How to respond
+
+1. **Ingest the change.** Accepts any of: a story/brief with acceptance criteria, a diff or PR, a release scope, or a prose feature description. If given a diff, read it before planning — the plan must name the actual surfaces touched, not generic areas. Ask at most 2 clarifying questions; tag every other unknown `[assumption]`.
+
+2. **Rank risks before writing a single test case.** Build the risk table first: for each area the change touches, what could go wrong, likelihood (H/M/L), impact (H/M/L), and the resulting priority — **P1** (H/H or H/M), **P2** (M/M or H/L), **P3** (everything else). Test-case effort follows priority: P1 gets concrete cases, P2 gets cases or charters, P3 gets a one-line exploratory note or an explicit "accept the risk".
+
+3. **Push each test to the lowest pyramid level that can catch the failure.** Unit if the logic is reachable in isolation; integration if the failure lives in a boundary (DB, queue, API contract); e2e only for journeys that genuinely cross systems. ✅ *"Discount rounding — unit test on the pricing function"* — ❌ *"Discount rounding — e2e checkout test"* (slow, flaky, and the assert is three layers from the bug).
+
+4. **Map every acceptance criterion to at least one test case.** Emit the AC → test coverage table; an AC with no row is a finding, not an omission. Where the input has no formal ACs, derive them from the described behavior and tag them `[derived]`.
+
+5. **Sweep the edge-case taxonomy against P1/P2 areas** — boundaries (0, 1, max, max+1), empty/null/missing, duplicates and idempotency, concurrent access, permission denied, dependency down or slow, clock/timezone/DST, oversized input, unicode. Only write cases for the ones that apply; name the ones skipped as not applicable so the reader sees the sweep happened.
+
+6. **Write observable entry/exit criteria.** Entry: what must be true to start (env up, test data loaded, feature flag state). Exit: pass/fail conditions a release manager can verdict — ✅ *"All P1 cases pass; no open defects of severity major+ in the touched areas"* — ❌ *"QA signs off"*.
+
+7. **Emit the plan with [`templates/test-plan.md`](templates/test-plan.md)** in one message: scope (in/out), risk table, AC coverage table, test cases grouped by pyramid level, test data + environment needs, entry/exit criteria, and **Not tested — accepted risks** with a one-line justification each.
+
+## Useful references in this skill
+
+- [`templates/test-plan.md`](templates/test-plan.md) — the full plan skeleton with the risk and coverage tables
+
+## Quality bar
+
+- **Risk table precedes test cases, and effort tracks priority.** A plan that gives equal depth to every area was written by coverage habit, not risk.
+- **Every test case has a concrete expected result.** ✅ *"Then the response is 422 with error code `DUPLICATE_SKU`"* — ❌ *"Then an appropriate error is shown"*.
+- **Every AC appears in the coverage table.** Uncovered ACs are listed as gaps at the top of the plan, never silently absent.
+- **The "Not tested" section is non-empty.** A plan that tests everything is a plan that prioritized nothing — naming accepted risks is the deliverable.
+- **Pyramid placement is justified by failure location**, not by what's easiest to write. Each e2e case states why no lower level could catch it.
+
+## When to use this skill
+
+- ✅ A feature/story is ready for test planning before or during implementation
+- ✅ A PR or release needs a documented QA pass and exit criteria
+- ✅ "How should we test this?" for a risky change (migration, payment flow, auth)
+- ✅ Turning `user-story-splitter` output into a test strategy for the sprint
+
+## When NOT to use this skill
+
+- ❌ Writing the test code itself — hand the plan to `feature-implement-loop` or a human
+- ❌ Adversarial review of code already written — that's `devils-advocate`
+- ❌ Static-analysis or quality-gate findings — that's `sonar-review`
+- ❌ A trivial change (typo, copy edit) — the plan would cost more than the risk
+
+## Anti-patterns to avoid
+
+- ❌ **Coverage theater.** Fifty shallow cases that all walk the happy path while the one migration risk gets a single line.
+- ❌ **"Verify it works correctly" as an expected result.** If a new tester couldn't verdict pass/fail from the words alone, rewrite it.
+- ❌ **Everything at e2e level.** The slowest, flakiest layer should hold the fewest tests, not the whole plan.
+- ❌ **Omitting the not-tested list** because it feels like admitting weakness. Unstated gaps get discovered in production; stated ones get a conscious decision.
+- ❌ **Test data as an afterthought.** "Use prod-like data" is not a data plan — name the records, states, and volumes the P1 cases need.
+- ❌ **Exit criteria that name people instead of conditions.** Sign-off follows the criteria; it isn't one.

skilldrop_cli/data/packs/dev-team/skills/test-plan-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write a test plan for this feature",
+    "should_trigger": true
+  },
+  {
+    "query": "What should we test before this release, ranked by risk?",
+    "should_trigger": true
+  },
+  {
+    "query": "Map these acceptance criteria to test cases",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate a risk-based QA plan for this PR",
+    "should_trigger": true
+  },
+  {
+    "query": "Split this epic into user stories with acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Review my code and tell me which tests are missing",
+    "should_trigger": false
+  },
+  {
+    "query": "Run the Sonar scan on my branch",
+    "should_trigger": false
+  },
+  {
+    "query": "Draft the PRD for this feature",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/test-plan-generator/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "test-plan-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the test plan for this release — a new discount-code feature touching checkout, pricing, and the orders API.",
+      "assertions": [
+        "A risk table ranked by likelihood times impact precedes the test cases, and depth of coverage tracks that ranking rather than being uniform",
+        "Every test case states a concrete expected result — a specific status code, error code, or value, not 'an appropriate error is shown'",
+        "Every acceptance criterion appears in a coverage table, with uncovered ACs listed explicitly rather than omitted",
+        "Each test is pushed to the lowest pyramid level that would catch the failure",
+        "Out-of-scope areas are named rather than silently skipped"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/skills/test-plan-generator/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "test-plan-generator",
+  "version": "0.1.0",
+  "description": "Generate a risk-based test plan for a feature, PR, or release — risks ranked by likelihood × impact, test cases pushed to the lowest pyramid level that catches the failure, every acceptance criterion mapped to a test, and an explicit \"not tested\" list. Use when the user asks for a test plan, test cases, a QA strategy for a change, \"how should we test this\", or pre-release test coverage.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["devils-advocate", "feature-implement-loop", "sonar-review", "user-story-splitter"],
+  "tags": ["testing", "test-plan", "qa", "risk-based", "test-cases", "quality"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a structured plan from a change description. Risk ranking needs judgment but is bounded; escalate via ambiguous-input on contested or high-stakes releases." }
+}

skilldrop_cli/data/packs/dev-team/skills/test-plan-generator/templates/test-plan.md

@@ -0,0 +1,83 @@
+# Test plan template
+
+Sections in the order a reviewer reads them: what's at stake first, cases later. Keep every section; an empty one gets a stated reason, not deletion.
+
+```markdown
+# Test plan: {feature / PR / release name}
+
+**Source:** {story ID, PR link, or brief}
+**Date:** {YYYY-MM-DD}
+[assumption] {any defaults picked; omit if none}
+
+## Coverage gaps found in the input
+
+{ACs with no testable behavior, contradictions, missing error specs — or "none".}
+
+## Scope
+
+**In scope:** {surfaces this plan covers}
+**Out of scope:** {touched-adjacent areas deliberately excluded} → see "Not tested"
+
+## Risk table
+
+| Area | What could go wrong | Likelihood | Impact | Priority |
+|---|---|---|---|---|
+| {surface} | {failure mode, specific} | H/M/L | H/M/L | P1/P2/P3 |
+
+## Acceptance-criteria coverage
+
+| AC | Test case(s) | Level |
+|---|---|---|
+| AC1 {short text} | TC-1, TC-4 | unit / integration / e2e |
+| AC2 `[derived]` {…} | TC-2 | … |
+
+## Test cases
+
+### Unit
+
+- **TC-1 (P1)** — {name}
+  - Given {…} When {…} Then {concrete expected result}
+
+### Integration
+
+- **TC-4 (P1)** — {name}
+  - Setup: {fixture / contract state}
+  - Steps: {…}
+  - Expected: {observable result, exact codes/values}
+
+### End-to-end
+
+- **TC-7 (P1)** — {journey name}
+  - Why e2e: {the cross-system failure no lower level catches}
+  - Steps / Expected: {…}
+
+### Exploratory charters (P2/P3)
+
+- **CH-1** — Explore {area} for {risk}; timebox {30–60 min}; note anything where {tripwire}.
+
+## Test data
+
+| Need | Detail |
+|---|---|
+| {record/state} | {exact shape, volume, how created or seeded} |
+
+## Environment & flags
+
+{Env, feature-flag states, third-party sandbox/stub mode.}
+
+## Entry criteria
+
+- {observable precondition}
+
+## Exit criteria
+
+- All P1 cases pass.
+- {defect threshold, e.g. "no open major+ defects in touched areas"}
+- {anything else a release manager can verdict without interpretation}
+
+## Not tested — accepted risks
+
+| Skipped | Why acceptable |
+|---|---|
+| {area or taxonomy item} | {one line: low likelihood/impact, covered elsewhere, or cost > risk} |
+```

skilldrop_cli/data/packs/dev-team/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.

skilldrop_cli/data/packs/dev-team/skills/user-story-splitter/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Split this epic into user stories",
+    "should_trigger": true
+  },
+  {
+    "query": "Break this feature down into independently shippable slices",
+    "should_trigger": true
+  },
+  {
+    "query": "Turn this PRD section into stories with Gherkin acceptance criteria",
+    "should_trigger": true
+  },
+  {
+    "query": "What's the right build order for these stories?",
+    "should_trigger": true
+  },
+  {
+    "query": "Write the product requirements document for this feature",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the test plan covering these acceptance criteria",
+    "should_trigger": false
+  },
+  {
+    "query": "Plan the phased rollout of this schema change",
+    "should_trigger": false
+  },
+  {
+    "query": "Turn this bug report into an actionable ticket",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/dev-team/skills/user-story-splitter/evals/evals.json

@@ -0,0 +1,16 @@
+{
+  "skill_name": "user-story-splitter",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Split this epic into shippable stories: 'Customers can save their cart, return later on any device, and check out with a saved payment method.'",
+      "assertions": [
+        "Every story is demoable to a non-engineer — a story whose demo is 'look at this database table' is re-cut as a vertical slice",
+        "Every acceptance criterion is pass/fail without interpretation and written in Gherkin",
+        "Acceptance criteria are concrete enough that a tester who has not seen the epic can verdict them",
+        "Dependencies between stories are stated, and a recommended build order follows from them",
+        "Stories are independently shippable rather than layered horizontally (all backend, then all frontend)"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/dev-team/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.

skilldrop_cli/data/packs/dev-team/skills/user-story-splitter/manifest.json

@@ -0,0 +1,14 @@
+{
+  "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"],
+  "handoff": [
+    { "to": "feature-implement-loop", "when": "a story has acceptance criteria a test can assert", "purpose": "Implement the slice through a capped generate-verify loop.", "fallback": "If feature-implement-loop is absent, implement inline but still challenge the result and cap the rounds at three." }
+  ],
+  "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." }
+}

skilldrop_cli/data/packs/dev-team/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.
+```

skilldrop_cli/data/packs/experience-design/pack.json

@@ -0,0 +1,68 @@
+{
+  "description": "The experience around a product: the structure people navigate, the content and interface words they read, the components they use, and the service behind it all.",
+  "display_name": "Experience design",
+  "keywords": ["ux", "information-architecture", "ux-writing", "content-design", "design-system", "service-design"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/experience-design/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "non-technical",
+    "prerequisites": ["A current menu, page list or feature list for the product, and who uses it"],
+    "starter-task": "Restructure a menu users get lost in, and get the test that proves the new one works",
+    "starter-prompt": "Our help centre menu has grown to 15 items and customers can't find refunds or delivery tracking. Current menu: Getting Started, Account, Orders, Shipping, Delivery, Returns, Refunds, Payments, Gift Cards, Promotions, Membership, Privacy, Terms, Contact Us, Community. Design the information architecture and the tree test to validate it.",
+    "verification": "information-architecture returns an inventory with a keep/merge/cut status for every item, a sitemap tree and a Mermaid diagram that match, a label rationale table, findability risks for refunds and tracking, and tree-test tasks that don't use the menu's words.",
+    "recovery": "If you get a journey map instead, ask for it by name (\"use information-architecture\"). If labels look invented, give it your search terms or support ticket themes and ask it to tag every label's evidence."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You're designing or fixing the experience around a product or service: how it's organised, what it says, how its components behave, and what happens behind the scenes.",
+    "you_bring": [
+      "who the users are and their top tasks",
+      "the current menu, page list or feature list",
+      "existing page text, screenshots or wireframes for the flow you're working on",
+      "your design tokens or brand kit, if you have one",
+      "what you know about the teams and systems that deliver the service"
+    ],
+    "time": "1–3 hours for one product area",
+    "steps": [
+      {
+        "skill": "information-architecture",
+        "you_do": "Hand over the content or feature list and the users' top tasks.",
+        "you_get": "A sitemap and nav model with a label rationale table, findability risks, and a tree-test plan.",
+        "decide": "Run the tree test before building, or accept the structure as a hypothesis."
+      },
+      {
+        "skill": "content-design",
+        "you_do": "Pick a key page from the sitemap and give it the current text or the facts it must contain.",
+        "you_get": "User-need statements, the questions in priority order, a plain-language draft with a before/after readability check, and a cut list."
+      },
+      {
+        "skill": "ux-writing",
+        "you_do": "Give it the flow's screens or steps and your voice.",
+        "you_get": "A string table with budgets and variants for every button, label, error and empty state, plus a terminology list."
+      },
+      {
+        "skill": "design-system-spec",
+        "you_do": "Name a component the flow needs and your token set.",
+        "you_get": "A component spec with anatomy, every state by token, keyboard and ARIA behaviour cited to WCAG 2.2, and open questions for engineering."
+      },
+      {
+        "skill": "service-blueprint",
+        "you_do": "Describe one customer scenario and what you know about the teams and systems behind it.",
+        "you_get": "A blueprint table and Mermaid diagram with fail points, waits, pains traced to causes, and 2–3 ranked fixes.",
+        "decide": "Which fix becomes committed work."
+      },
+      {
+        "skill": "doc-critique",
+        "you_do": "Run it on any of the specs before you share them.",
+        "you_get": "A verdict and severity-tagged findings with a fix for each."
+      }
+    ],
+    "you_end_with": "A tested-or-testable structure, the content and strings for a key page and flow, a buildable component spec, and a service blueprint with the fixes ranked."
+  }
+}