skilldrop-cli 0.2.0

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

package/skills/tech-comparison-matrix/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: tech-comparison-matrix
+description: Produce a weighted comparison matrix for a technology selection question (e.g., "Postgres vs DynamoDB", "Kafka vs Kinesis vs RabbitMQ", "Snowflake vs Databricks"). Surfaces criteria, weights, per-option scores, totals, and a recommended pick. Use when the user is choosing between technologies, vendors, frameworks, or architectural approaches.
+---
+
+# tech-comparison-matrix
+
+You help the user make defensible tech-selection decisions by producing a weighted comparison matrix that they can paste into a design doc, ADR, or steering-committee deck.
+
+## How to respond
+
+1. **Pin down the question.** Make sure you have:
+   - **The options** (2–5 — past 5 the matrix becomes noise; cut the long-shots first)
+   - **The use case in one sentence** ("primary OLTP store for a multi-tenant SaaS app, ~10k writes/sec, latency p99 < 50ms")
+   - **Hard constraints** (e.g., "must run on-prem", "must be open source", "team has zero ops capacity for self-hosting")
+
+   Ask at most 2 clarifying questions. If the user only gave you the options without a use case, ask for the use case — it determines the criteria.
+
+2. **Pick the criteria.** Default to a balanced set across these axes (8–10 criteria is the sweet spot — fewer feels shallow, more becomes noise):
+
+   | Axis | Example criteria |
+   |---|---|
+   | **Capability fit** | Throughput, latency, query model, consistency model, schema flexibility |
+   | **Operational** | Self-hosted vs managed, scaling story, backup/restore, observability |
+   | **Cost** | License, infrastructure, support, total cost of ownership at scale |
+   | **Risk** | Vendor lock-in, ecosystem maturity, hiring market, our team's familiarity |
+
+   Mention any criteria you intentionally **excluded** so the user can challenge it. ("I left out 'community size' — let me know if that matters for you.")
+
+3. **Apply weights.** Use 1–5 (5 = critical to the decision, 1 = nice-to-have). Tie the weights to the use case in writing. *"Latency is weighted 5 because the use case demands sub-50ms p99"* makes the matrix audit-able; bare numbers don't.
+
+4. **Score each option per criterion** on a 1–5 scale. Justify every 5 and every 1 in one phrase — the body of the deliverable is the *reasoning*, not the numbers.
+
+5. **Total it up.** `Total = sum(weight × score)`. Highest total ≠ automatic winner — if the gap is small (< 5%), call that out and let the user pick on gut feel.
+
+6. **Recommend explicitly.** End with a "Recommendation" paragraph: which option, why, and what would change the answer.
+
+## Output format
+
+Use [`templates/matrix.md`](templates/matrix.md) as the skeleton. The deliverable should fit on **one screen** when rendered — if it doesn't, you have too many criteria.
+
+## Quality bar
+
+- **Every score has a one-line justification.** A bare "4/5" is not a comparison.
+- **Tie scores are fine** — don't force differentiation that isn't there.
+- **The recommendation is one sentence, not a paragraph of hedging.**
+- **Show your weights** — a matrix with hidden weights is just an opinion.
+- **No false precision.** If a number is a guess, say "rough" or "directional".
+
+## Anti-patterns to avoid
+
+- ❌ Scoring every criterion 3/5 ("balanced") — the matrix exists to differentiate, not to be polite.
+- ❌ Picking criteria that all favour the option you secretly want to win.
+- ❌ Including "community popularity" as a top-weighted criterion when the use case doesn't care.
+- ❌ Recommending an option whose score wasn't highest, without explaining the override.
+- ❌ Inventing benchmarks. If you don't have a number, say "estimated" and source the estimate.

package/skills/tech-comparison-matrix/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "tech-comparison-matrix",
+  "version": "0.1.0",
+  "description": "Produce a weighted comparison matrix for a technology selection question (e.g., \"Postgres vs DynamoDB\", \"Kafka vs Kinesis vs RabbitMQ\", \"Snowflake vs Databricks\"). Surfaces criteria, weights, per-option scores, totals, and a recommended pick. Use when the user is choosing between technologies, vendors, frameworks, or architectural approaches.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": [],
+  "tags": ["decisions", "comparison", "tech-selection", "vendor-evaluation"],
+  "model": { "tier": "heavy", "rationale": "Weighted multi-criteria judgment with a recommendation. Mis-weighting is the failure mode. Never downgrade." }
+}

package/skills/tech-comparison-matrix/templates/matrix.md

@@ -0,0 +1,45 @@
+# {Decision title — e.g. "Primary OLTP datastore for ProjectX"}
+
+**Use case:** {one sentence describing the workload / constraints — this is what the weights are tuned to}
+
+**Hard constraints:** {bulleted list of things that must be true; an option failing any of these is eliminated, not scored}
+
+**Options evaluated:** {Option A}, {Option B}, {Option C}
+**Options excluded (and why):** {e.g. "MongoDB — single-region writes only, fails the multi-region constraint"}
+
+## Scoring scheme
+
+- **Weight (1–5):** how much this criterion matters for *this* use case. Justified inline.
+- **Score (1–5):** how well the option meets the criterion. Each 5 and 1 has a one-line justification.
+
+## Matrix
+
+| Criterion | Weight | {Option A} | {Option B} | {Option C} |
+|---|---:|---:|---:|---:|
+| Throughput (writes/sec at p99 < 50ms) — *weight 5: directly stated in use case* | 5 | 5 — published bench 50k/s | 3 — caps around 15k/s | 4 — 30k/s with read replicas |
+| Consistency model fit — *weight 5: financial data, no eventual consistency tolerated* | 5 | 5 | 2 — eventual by default | 5 |
+| Operational complexity (self-hosted) — *weight 4: team has 1 SRE* | 4 | 3 | 4 — fully managed | 2 — manual sharding |
+| Cost at projected scale — *weight 3: budget approved but not unlimited* | 3 | 4 | 2 — egress fees | 5 |
+| Team familiarity — *weight 3: shortens ramp* | 3 | 5 | 2 | 3 |
+| Vendor lock-in — *weight 2: prefer portable but not blocking* | 2 | 5 — open source | 2 — proprietary | 4 |
+| Ecosystem / tooling — *weight 2* | 2 | 5 | 4 | 3 |
+| Backup & restore story — *weight 4: compliance requirement* | 4 | 4 | 5 | 3 |
+| **Weighted total** | | **{=Σ w·s}** | **{=Σ w·s}** | **{=Σ w·s}** |
+
+## Justifications for outlier scores
+
+- *{Option A}, Throughput = 5:* {one-line evidence — link to vendor bench, internal load test, or known reference deployment}
+- *{Option B}, Consistency = 2:* {one-line evidence}
+- *{Option C}, Operational complexity = 2:* {one-line evidence}
+
+## Recommendation
+
+**Pick {Option X}** — it's strongest on the two highest-weighted criteria (throughput + consistency) and acceptable on the rest. The gap to {next option} is meaningful (~{N}%), so this is not a close call.
+
+**What would change this answer:**
+- If managed-ness becomes the top constraint (e.g., SRE leaves), reconsider {Option B}.
+- If we relax the latency target above 100ms, {Option C} becomes viable and cheaper.
+
+## Open questions
+
+- {Question for stakeholders — e.g., "Is multi-region active-active in scope for v1, or v2+?"}

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

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

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

package/skills/threat-model/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: threat-model
+description: Produce a STRIDE threat model from a design doc, architecture description, or feature spec — assets and trust boundaries first, threats anchored to boundary crossings with concrete attack scenarios, severity-ranked with verifiable mitigations. Use when the user asks to threat-model a design, run a security review of an architecture, ask "how could this be attacked", or needs security sign-off input before build.
+---
+
+# threat-model
+
+Finds the attacks a design permits *before* the code exists, when fixes are a diagram edit instead of a migration. Design-phase counterpart to `devils-advocate` (which attacks written code); consumes `design-doc` or `reverse-architecture` output directly. Threats live where data crosses a trust boundary — the model is anchored there, not in a generic checklist.
+
+## How to respond
+
+1. **Establish the system before any threats.** From the input, extract and state:
+   - **Assets** — what an attacker wants (credentials, PII, payment data, compute, availability), ranked by damage-if-lost
+   - **Entry points** — every way data or commands get in (APIs, queues, file uploads, admin panels, CI/CD, third-party webhooks)
+   - **Trust boundaries** — every line where the trust level changes (internet→edge, service→service, app→DB, human→system, tenant→tenant)
+   Ask at most 2 questions, and spend them on trust boundaries — misplaced boundaries invalidate the whole model. Tag everything else `[assumption]`.
+
+2. **Enumerate boundary crossings, then run STRIDE per crossing** using the question banks in [`reference.md`](reference.md) — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege. Not every category applies at every crossing; say "n/a" with one word of why rather than padding.
+
+3. **Write each threat as a concrete attack scenario**: actor → path → result. ✅ *"A tenant crafts a report name containing `../`, the export service writes to another tenant's S3 prefix, cross-tenant data exposure"* — ❌ *"Path traversal is possible"*. A threat that can't be narrated as a scenario isn't understood yet.
+
+4. **Severity-rank with the shared markers** — 🟥 critical (unauthenticated or cross-tenant compromise of a top asset), 🟧 high (authenticated bypass, single-tenant data exposure), 🟨 medium (requires chaining or insider position), ⚪ low/accepted. Likelihood × impact, judged against *this* system's assets — not CVSS theater. If everything is 🟥, the ranking failed.
+
+5. **Assess existing mitigations honestly** before recommending new ones. Each threat gets: what already mitigates it (and whether that's verified or assumed), then the recommended mitigation with a **verification step** — ✅ *"Presigned URLs scoped to tenant prefix; verify with a cross-tenant fetch test in CI"* — ❌ *"Use proper access controls"*.
+
+6. **Force the insider and authz passes.** Two systematic blind spots, swept explicitly: what can a *legitimate authenticated user* do to another tenant or to escalate (authn is not authz), and what can a malicious or compromised insider/CI-token do. One finding or an explicit all-clear for each.
+
+7. **Emit the model in one message**: system summary (assets / entry points / boundaries), findings grouped by severity, the n/a ledger, **assumptions**, **out of scope**, and **questions for the team** — the unknowns that block a finding from being confirmed or dismissed. End with the revisit trigger: the model is stale when a new entry point, boundary, or asset class appears.
+
+## Useful references in this skill
+
+- [`reference.md`](reference.md) — STRIDE question banks per boundary type + common-mitigation table
+- [`examples/document-upload.md`](examples/document-upload.md) — worked example: upload feature → 6 ranked findings
+
+## Quality bar
+
+- **Every threat is anchored** to a named trust-boundary crossing or asset. An unanchored finding is checklist residue — cut it.
+- **Every threat narrates a scenario** with actor, path, and result. "X is possible" is not a finding.
+- **Severity spread is honest.** A model where everything is critical (or nothing is) hasn't ranked anything; the 🟥 set is what you'd halt the build for.
+- **Every recommended mitigation has a verification step** a reviewer can run or check. Advice without verification is a wish.
+- **Existing mitigations are credited** — and marked verified vs assumed. A model that ignores what the design already does right teaches the team to ignore the model.
+- **The insider and authz sweeps produced output** — findings or an explicit reasoned all-clear, never silence.
+
+## When to use this skill
+
+- ✅ A design doc or RFC needs security scrutiny before implementation starts
+- ✅ "How could this be attacked?" for a new feature, integration, or entry point
+- ✅ Input for a formal security review / sign-off gate
+- ✅ A `reverse-architecture` extraction of a legacy system that never had a threat model
+
+## When NOT to use this skill
+
+- ❌ Reviewing written code for vulnerabilities — that's `devils-advocate` (its security lens) or `sonar-review`
+- ❌ Compliance attestation (SOC2, PCI evidence) — this models attacks, it doesn't certify controls
+- ❌ Incident analysis after an exploit — that's `postmortem-generator`
+- ❌ Pen-testing a live system — this is paper analysis; it tells the pen test where to aim
+
+## Anti-patterns to avoid
+
+- ❌ **OWASP-checklist dumping** — twenty generic items ("ensure input validation") untied to any boundary in *this* system. Volume isn't rigor.
+- ❌ **Stopping at authentication.** "Users must log in" answers spoofing only; the authz pass (tenant→tenant, user→admin) is where real findings live.
+- ❌ **"Use encryption" as a mitigation.** Of what, where, against which threat? Encryption at rest does nothing for a tampered request in flight.
+- ❌ **Modeling only the happy architecture.** Admin panels, CI/CD pipelines, support tooling, and webhook receivers are entry points — usually the softest ones.
+- ❌ **Inflating severity to be taken seriously.** One cried-wolf 🟥 and the next model gets skimmed.
+- ❌ **One-and-done modeling.** A threat model without a revisit trigger expires silently the first time the design changes.

package/skills/threat-model/examples/document-upload.md

@@ -0,0 +1,56 @@
+# Worked example — document-upload feature → 6 ranked findings
+
+## Input (design-doc excerpt, verbatim)
+
+> New feature: customers upload contract PDFs for e-signing. Browser gets a presigned S3 URL from `upload-api` (authenticated), uploads directly to the `contracts` bucket, then `upload-api` enqueues a message; `doc-processor` consumes it, runs OCR via a third-party API, and writes extracted text to Postgres. Support staff can view any customer's documents in the admin panel to help with signing issues. Multi-tenant SaaS, tenant ID in the JWT.
+
+## Output
+
+### System summary
+
+**Assets (ranked):** customer contracts (legal PII — top asset), extracted contract text in Postgres, S3 credentials / presigned-URL minting capability, OCR API key.
+**Entry points:** `upload-api` (authn'd HTTP), direct browser→S3 upload, SQS queue into `doc-processor`, third-party OCR API responses, admin panel.
+**Trust boundaries:** internet→upload-api, internet→S3 (presigned), upload-api→queue→doc-processor, doc-processor→OCR vendor (data leaves our trust domain), doc-processor→Postgres, support-staff→admin panel, tenant→tenant throughout.
+[assumption] Presigned URLs are PUT-only. [assumption] OCR vendor is contractually approved for PII.
+
+### Findings
+
+**🟥 TM-1 — Cross-tenant document read via unscoped presigned URLs** (boundary: internet→S3; STRIDE: I, E)
+Scenario: a tenant inspects their presigned URL, finds object keys are `contracts/{uuid}.pdf` with no tenant prefix; any later GET-capable URL or a key-guessing bug exposes other tenants' contracts — compromise of the top asset.
+Existing mitigation: none stated in the design. Recommended: keys become `contracts/{tenant_id}/{uuid}.pdf`, minted only from the JWT's tenant claim, GET URLs scoped to prefix and ≤5 min. **Verify:** CI test fetches tenant B's key with tenant A's session — must 403.
+
+**🟥 TM-2 — Malicious file detonates in doc-processor** (boundary: queue→doc-processor; STRIDE: T, E)
+Scenario: attacker uploads a crafted PDF (parser exploit, zip bomb, SSRF-triggering embedded URL); doc-processor parses it with vendor-library defaults and processor credentials. RCE here reaches Postgres and the OCR key.
+Existing mitigation: none stated. Recommended: validate content-type + size at presign and on consume; parse inside a sandboxed, least-privilege worker (no Postgres write role until post-parse); pin and patch the parser. **Verify:** corpus of hostile PDFs in CI lands in DLQ, not crash-loop or exec.
+
+**🟧 TM-3 — Support staff can browse any tenant's contracts with no audit trail** (boundary: human→system; STRIDE: I, R; insider pass)
+Scenario: a support login (insider or phished) bulk-reads contracts across tenants; the design grants "view any customer's documents" with no purpose-binding or logging — undetectable until external disclosure.
+Existing mitigation: admin panel is authenticated. Recommended: case-bound access (support sees a document only via an open ticket reference), immutable audit log of every view, MFA on support accounts. **Verify:** admin-action integration test asserts the audit row; access without ticket reference → denied.
+
+**🟧 TM-4 — Queue accepts unauthenticated/poisoned messages** (boundary: upload-api→queue; STRIDE: S, T)
+Scenario: any internal workload (or attacker post-TM-2) enqueues `{tenant_id: victim, s3_key: attacker_file}`; doc-processor trusts the message and writes attacker text into the victim tenant's Postgres rows.
+Existing mitigation: queue is network-internal `[assumption: flat internal trust]`. Recommended: doc-processor re-derives tenant from the S3 key prefix (post-TM-1) instead of trusting the message field; schema-validate on consume; producer allow-list via IAM. **Verify:** message with mismatched tenant/key → rejected with alert.
+
+**🟨 TM-5 — Contract PII leaves trust domain to OCR vendor unminimized** (boundary: doc-processor→vendor; STRIDE: I)
+Scenario: full contracts ship to the vendor; a vendor breach exposes the top asset with no detection on our side. Requires the vendor's failure, hence 🟨 not 🟧.
+Existing mitigation: `[assumption]` contractual DPA. Recommended: confirm the DPA covers this data class; disable vendor-side retention; log per-document egress so exposure is enumerable after a vendor incident. **Verify:** vendor account settings reviewed + egress log row asserted in tests.
+
+**🟨 TM-6 — Unbounded uploads as cost/availability attack** (boundary: internet→S3; STRIDE: D)
+Scenario: a scripted tenant requests thousands of presigned URLs and uploads max-size files; S3 cost spike and OCR-queue saturation delay every tenant's processing (noisy-neighbor DoS).
+Existing mitigation: authn required. Recommended: per-tenant presign rate limit + size cap at presign time; queue depth alarm with per-tenant fairness. **Verify:** load test on the presign endpoint shows throttling before queue saturation.
+
+### n/a ledger
+Repudiation at internet→S3: n/a beyond TM-3's audit log — S3 access logging assumed on. DoS at admin panel: internal user base, marginal.
+
+### Authz / insider pass
+Authz: TM-1, TM-4 (tenant→tenant). Insider: TM-3. Sweeps produced findings — no all-clear claimed.
+
+### Questions for the team
+1. Are presigned URLs PUT-only, and is there any GET path today? (confirms or escalates TM-1)
+2. Does the OCR vendor contract cover contract PII, and is vendor-side retention off? (resolves TM-5's assumptions)
+
+### Out of scope
+E-signing flow itself (separate design); S3 bucket-policy review (assumed account-standard); browser-side threats (XSS) — covered by the web app's existing model.
+
+### Revisit trigger
+New entry point (e.g. email-in ingestion), new document consumer, or any change to support-access rules.

package/skills/threat-model/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "threat-model",
+  "version": "0.1.0",
+  "description": "Produce a STRIDE threat model from a design doc, architecture description, or feature spec — assets and trust boundaries first, threats anchored to boundary crossings with concrete attack scenarios, severity-ranked with verifiable mitigations. Use when the user asks to threat-model a design, run a security review of an architecture, ask \"how could this be attacked\", or needs security sign-off input before build.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["design-doc", "devils-advocate", "postmortem-generator", "reverse-architecture", "sonar-review"],
+  "tags": ["threat-model", "security", "stride", "architecture", "design-review", "trust-boundaries"],
+  "model": { "tier": "heavy", "rationale": "Adversarial reasoning over a design — cheaper models emit checklist residue, miss authz/insider paths, and inflate severity. Never downgrade." }
+}

package/skills/threat-model/reference.md

@@ -0,0 +1,69 @@
+# threat-model reference — STRIDE question banks + mitigation table
+
+Questions are prompts for the analysis, not a checklist to transcribe. A question only becomes a finding when it can be narrated as actor → path → result against a named boundary in the system under review.
+
+## STRIDE by boundary type
+
+### Internet → edge (public API, web app, webhook receiver)
+
+- **S** — Can a caller forge identity? Token audience/issuer validated? Webhook signatures checked, or just a "secret" URL? API keys distinguishable from user auth?
+- **T** — Are request bodies/headers trusted downstream (forwarded `X-User-Id`)? Can query params alter server-side behavior beyond their contract (mass assignment, prototype pollution)?
+- **R** — Are authentication failures and privileged calls logged with caller identity? Could a caller plausibly deny an action?
+- **I** — Do error responses leak stack traces, internal hostnames, versions? Do list endpoints leak other users' resource IDs? Timing differences on auth (user enumeration)?
+- **D** — Unauthenticated endpoints with expensive work (search, export, PDF render)? Rate limits per-IP only (trivially rotated) or per-principal? Payload size caps?
+- **E** — Do any endpoints trust client-supplied role/scope claims? Hidden admin routes guarded by obscurity?
+
+### Service → service (internal APIs, queues, RPC)
+
+- **S** — Does service B verify *which* service is calling, or accept anything inside the network ("flat trust")? mTLS / workload identity, or shared static secrets?
+- **T** — Are queue messages signed or schema-validated, or does the consumer trust whatever's enqueued? Can a compromised producer poison downstream state?
+- **R** — Can an action be traced through the chain (correlation IDs), or does attribution die at the first hop?
+- **I** — Do internal payloads carry more data than the consumer needs (full user record where an ID would do)?
+- **D** — Can one service exhaust another (no backpressure, unbounded fan-out, retry storms)?
+- **E** — Does a low-privilege service hold credentials that grant more than it uses (over-scoped IAM)?
+
+### App → datastore (DB, object storage, cache)
+
+- **S** — Shared DB credentials across services, or per-service identity?
+- **T** — String-built queries anywhere? Can the app write rows/objects outside its tenant scope (key-prefix discipline)?
+- **I** — Tenant isolation by `WHERE` clause convention only? Backups/replicas/cache covered by the same access controls as primaries? Presigned URLs scoped and short-lived?
+- **D** — Unbounded queries reachable from user input (no LIMIT, full scans)? Cache stampede paths?
+- **E** — Does the app account hold DDL/admin rights it never uses?
+
+### Human → system (admin panels, support tooling, CI/CD)
+
+- **S** — Admin auth at the same strength as user auth, or stronger (MFA, hardware keys)? Sessions revocable?
+- **T** — Can CI run arbitrary code with deploy credentials on a PR from a fork? Are build artifacts verifiable (signed, pinned digests)?
+- **R** — Are support/admin actions on user data logged immutably with operator identity?
+- **I** — Can support staff browse data beyond the case at hand (no purpose-binding)?
+- **E** — Path from "support role" to "admin role"? Long-lived personal tokens with org-wide scope?
+
+### Tenant → tenant (multi-tenant SaaS) — run with the authz pass
+
+- IDs guessable/enumerable across tenants (sequential integers, predictable UUIDs in URLs)?
+- Every query path tenant-scoped by construction (middleware/RLS), or by developer discipline?
+- Shared compute side-channels: can one tenant's load degrade another's (noisy neighbor as DoS)?
+- Export/report/search features — the classic cross-tenant leak surfaces.
+
+## Insider / compromised-credential pass
+
+Assume one legitimate credential is attacker-held: a user account, a support login, a CI token, one service's IAM role. For each, what's the blast radius before detection? Findings here are usually 🟧 — they need position, but position is bought cheaply (phishing, leaked token).
+
+## Common mitigations (with the verification that makes them real)
+
+| Threat shape | Mitigation | Verified by |
+|---|---|---|
+| Forged inbound identity | Token validation incl. audience+issuer+expiry; webhook HMAC | Negative test: tampered/expired token rejected in CI |
+| Cross-tenant access | Tenant scoping by construction (RLS, scoped prefixes), not per-query discipline | Cross-tenant fetch test as a permanent CI case |
+| Trusted internal headers | Strip/rewrite identity headers at the edge; sign internal assertions | Request with spoofed header from outside → rejected |
+| Queue poisoning | Schema validation on consume; producer allow-list | Malformed message → DLQ with alert, not crash-loop |
+| Resource exhaustion | Per-principal rate limits, payload caps, timeouts, bounded queries | Load test on the most expensive unauthenticated path |
+| Over-scoped credentials | Per-service identity, least-privilege IAM, short-lived tokens | Periodic automated diff of granted vs used permissions |
+| Silent admin abuse | Immutable audit log, purpose-bound support access | Audit-log entry asserted in admin-action integration tests |
+
+## Severity calibration
+
+- 🟥 **critical** — unauthenticated attacker, or any cross-tenant data compromise, against a top-ranked asset. Halt-the-build territory.
+- 🟧 **high** — authenticated user bypasses authz; single-tenant data exposure; insider blast radius covering a top asset.
+- 🟨 **medium** — requires chaining 2+ weaknesses or unusual position; degraded availability short of outage.
+- ⚪ **low / accepted** — real but marginal; document the acceptance so it's a decision, not an oversight.

package/skills/user-journey-map/SKILL.md

@@ -0,0 +1,64 @@
+---
+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.

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