skilldrop-cli 0.2.0

package/skills/postmortem-generator/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: postmortem-generator
+description: Generate a blameless incident postmortem from raw material (Slack thread, pager timeline, notes) — quantified impact, UTC timeline with detection/mitigation gaps, contributing factors instead of a single root cause, and ≤8 verifiable action items. Use after an incident or outage when the user needs a postmortem, RCA, incident review, or "lessons learned" doc.
+---
+
+# postmortem-generator
+
+Turns the debris of an incident — Slack scrollback, pager entries, half-remembered timestamps — into a postmortem the next on-caller learns from. Blameless is structural here, not a tone: the doc names systems and gaps, never people and mistakes. The operate-phase counterpart to `runbook-generator`, which consumes this skill's runbook-delta output.
+
+## How to respond
+
+1. **Ingest the raw material.** Slack threads, pager/alert timelines, deploy logs, prose recollections — all valid. Ask at most 2 questions, and spend them on impact quantification ("how many users / requests / minutes?") — it's the data people forget fastest and the section read first. Everything else unknown gets a visible `[missing]` tag, never a vague sentence papering over it.
+
+2. **Strip blame structurally while drafting.** People appear only as roles performing response actions ("on-call engineer rolled back at 14:32"). Errors are attributed to the system that allowed them. ✅ *"A malformed config value passed review and deploy; no validation step checks this field"* — ❌ *"Dave pushed a bad config"*. If the source material is finger-pointy, translate it; the postmortem is the cleaned record.
+
+3. **Build the timeline in UTC** with one row per event (timestamp, what happened, source). Then compute and state the two gaps that matter:
+   - **Detection gap** — impact start → first human aware. If users noticed before monitoring did, say so in those words.
+   - **Mitigation gap** — detection → impact ended.
+   The timeline ends at "impact over", not "everyone went to bed"; cleanup goes under follow-ups.
+
+4. **Write contributing factors, not a root cause.** Minimum 2, typically 3–5, using "why was that possible?" chains. **"Human error" is banned as a factor** — it is always the start of a question, never the answer: what made the error easy to make, hard to catch, and fast to propagate? Each factor states the condition, not the act.
+
+5. **Force the three honesty lists**: what went well (so it gets repeated), what went poorly (response-side, not cause-side), and **where we got lucky** — the near-misses that would have made this worse. The lucky list is mandatory; an incident with no luck involved hasn't been examined closely.
+
+6. **Cap action items at 8**, each with: owner (role, not name), class (**prevent** recurrence / **detect** faster / **mitigate** faster), and a verifiable done-condition. ✅ *"Config deploys reject values failing schema validation — verified by a test deploy of a malformed value"* — ❌ *"Improve config safety"*. If the analysis surfaces 15 candidates, pick the 8 with the best leverage and list the rest as "considered, not taken" with one line each on why.
+
+7. **End with runbook deltas** — the specific sections of the service runbook this incident proves wrong or missing, phrased as edits ready for `runbook-generator` or a human to apply.
+
+8. **Emit with [`templates/postmortem.md`](templates/postmortem.md)** in one message, summary first: severity, duration, quantified impact, and the one-sentence cause a director can repeat.
+
+## Useful references in this skill
+
+- [`templates/postmortem.md`](templates/postmortem.md) — the full doc skeleton with the gap calculations and action-item table
+
+## Quality bar
+
+- **Impact is numbers or `[missing]`.** Duration, users/requests affected, SLO burn, revenue if known. "Significant impact" is not a measurement.
+- **No person is named in a causal sentence.** Roles appear in response actions only. One named-blame sentence fails the doc.
+- **Detection and mitigation gaps are computed and stated.** They are the two numbers the next incident will be judged against.
+- **At least 2 contributing factors, zero of them "human error".** A single root cause means the chain of "why was that possible?" stopped one question early.
+- **Every action item is verifiable and owned.** A reader can check it's done without asking anyone's opinion; an item without a done-condition is a wish.
+- **"Where we got lucky" is non-empty.** Naming the near-miss is how it gets fixed before it's the next incident's headline.
+
+## When to use this skill
+
+- ✅ After an incident/outage, turning the response scrollback into the postmortem doc
+- ✅ "Write the RCA for yesterday's outage"
+- ✅ Preparing the incident-review meeting doc
+- ✅ Retroactively documenting an old incident before the details evaporate
+
+## When NOT to use this skill
+
+- ❌ During the incident — mitigate first; the postmortem starts when impact ends
+- ❌ A performance-management record — the doc is structurally blameless; misusing it kills honest reporting
+- ❌ Project retrospectives with no production incident — different ritual, different doc
+- ❌ Writing the runbook itself — emit the deltas and hand to `runbook-generator`
+
+## Anti-patterns to avoid
+
+- ❌ **Single root cause.** "The config was wrong" explains nothing about review, validation, deploy gates, or blast radius — the four places to actually fix.
+- ❌ **"Human error" / "should have been more careful".** Careful is not a control. Name the missing guardrail instead.
+- ❌ **The 20-item action list.** It signals diligence and delivers nothing; nobody finishes it and the P1s drown.
+- ❌ **Timeline theater.** Forty rows of who-said-what-in-Slack instead of the ten events that changed system state.
+- ❌ **Quiet heroics as a fix.** "An engineer noticed by luck at 2am" is a detection gap wearing a cape — the action item is monitoring, not gratitude.
+- ❌ **Skipping the postmortem because impact was "minor".** Near-misses are the cheapest lessons; severity gates the meeting, not the doc.

package/skills/postmortem-generator/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "postmortem-generator",
+  "version": "0.1.0",
+  "description": "Generate a blameless incident postmortem from raw material (Slack thread, pager timeline, notes) — quantified impact, UTC timeline with detection/mitigation gaps, contributing factors instead of a single root cause, and ≤8 verifiable action items. Use after an incident or outage when the user needs a postmortem, RCA, incident review, or \"lessons learned\" doc.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["runbook-generator"],
+  "tags": ["postmortem", "incident", "rca", "sre", "blameless", "outage"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a structured doc from incident notes. Contributing-factor chains need judgment but are bounded; escalate via large-input on huge scrollbacks." }
+}

package/skills/postmortem-generator/templates/postmortem.md

@@ -0,0 +1,67 @@
+# Postmortem template
+
+Summary first — it's the only section most readers finish. All timestamps UTC. Unknowns get `[missing]`, never prose camouflage.
+
+```markdown
+# Postmortem: {one-line incident title, symptom-first — "Checkout 500s for EU users", not "Config issue"}
+
+**Status:** draft | reviewed | actions-tracked
+**Severity:** SEV{1–4} · **Date:** {YYYY-MM-DD} · **Author role:** {e.g. incident commander}
+
+## Summary
+
+{3–5 sentences a director can repeat: what broke for whom, for how long, why in one
+clause, and the headline fix. No jargon that needs the timeline to decode.}
+
+## Impact
+
+| Measure | Value |
+|---|---|
+| Duration (impact start → end) | {Xh Ym} |
+| Users / customers affected | {number or %, or [missing]} |
+| Requests failed / degraded | {number, or [missing]} |
+| SLO / error budget burn | {e.g. "34% of monthly budget", or [missing]} |
+| Revenue / contractual | {value, "none known", or [missing]} |
+
+## Timeline (UTC)
+
+| Time | Event | Source |
+|---|---|---|
+| {hh:mm} | {impact begins — state change, not Slack chatter} | {alert/log/deploy} |
+| {hh:mm} | {first human aware} | {page/user report} |
+| {hh:mm} | {mitigation applied} | … |
+| {hh:mm} | {impact ends} | … |
+
+**Detection gap:** {impact start → first human aware} — {if users reported it before
+monitoring fired, say exactly that}
+**Mitigation gap:** {detection → impact end}
+
+## Contributing factors (2+; "human error" is not one)
+
+1. **{Condition, not act}** — {why this made the incident possible/worse; the guardrail
+   that was absent or didn't fire}
+2. **{…}** — {…}
+
+## What went well / poorly / where we got lucky
+
+**Well:** {response behaviors worth repeating}
+**Poorly:** {response-side gaps — paging, comms, tooling — not the cause itself}
+**Lucky:** {mandatory — the near-miss: "happened at 3am low traffic", "the one engineer
+who knew X was awake", "rollback happened to be safe"}
+
+## Action items (≤8)
+
+| # | Action | Class | Owner (role) | Done when |
+|---|---|---|---|---|
+| 1 | {specific change} | prevent / detect / mitigate | {team or role} | {verifiable condition} |
+
+**Considered, not taken:** {candidate} — {one line why not}
+
+## Runbook deltas
+
+- {Runbook section} → {the edit this incident proves necessary — paste-ready}
+
+## Open questions
+
+- {anything still [missing] that follow-up should resolve, with who can answer it}
+```

package/skills/prd-draft/SKILL.md

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

package/skills/prd-draft/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "prd-draft",
+  "version": "0.1.0",
+  "description": "Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal. Use when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["brief-intake", "bug-triage", "business-case", "design-doc", "nfr-spec", "success-metrics", "user-story-splitter"],
+  "tags": ["prd", "requirements", "product", "discovery", "moscow", "non-goals"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a structured requirements doc from a brief. The solution-language discipline needs care; bounded by the template. Escalate via ambiguous-input on contested scope." }
+}

package/skills/prd-draft/templates/prd.md

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

package/skills/prfaq/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: prfaq
+description: Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus the customer FAQ and internal FAQ that force the hard questions before engineering starts. Use when the user wants a PRFAQ, a working-backwards document, a "write the press release first" exercise, or needs to align stakeholders on what a product must be before committing a team to build it.
+---
+
+# prfaq
+
+The working-backwards forcing function: write the launch press release *before* the product exists, then answer the questions a real customer and a skeptical insider would ask. If the press release can't be written specifically — a nameable customer, a problem in their words, a benefit you could measure — the product isn't ready to spec, and surfacing that is the deliverable. Sits upstream of `prd-draft` (requirements for a committed product) and `business-case` (invest/defer decision): the PRFAQ decides whether the idea deserves either.
+
+## How to respond
+
+1. **Pin the three anchors** — customer, problem, differentiator. Ask at most 2 questions, spent on the weakest anchors: *"Who exactly is the customer, and what do they do today instead?"* and *"What does this do that the thing they use today doesn't?"* A PRFAQ for "everyone" with a problem stated in industry jargon produces a marketing document, not a forcing function — don't start drafting until all three anchors are concrete. Non-interactive run (no user to ask): derive missing anchors from the input where defensible and tag them `[assumption]` at the top; an anchor with no defensible derivation → emit `BLOCKED: need <anchor>` naming what to rerun with, instead of fabricating a customer.
+
+2. **Write the press release** — one page, datelined with a city and a realistic launch date; no product name exists yet → invent a plausible working name and mark it as a placeholder. The blocks:
+   - **Headline**: product name + the customer benefit in one sentence. ✅ *"Acme Contracts cuts routine contract review from three days to twenty minutes for in-house legal teams"* — ❌ *"Acme launches AI-powered legal platform"*.
+   - **Sub-headline**: the one key detail the headline compressed (who it's for, what it replaces, or the mechanism).
+   - **Problem paragraph**: the customer's current pain *in their words*. ✅ *"I can't close a deal until legal clears the paperwork, and legal is three days behind"* — ❌ *"lack of operational visibility into contract workflows"*.
+   - **Solution paragraph**: what the product does and what it does *differently* from the alternative the customer already uses. "AI-powered" is not a differentiator; the mechanism is.
+   - **Leadership quote**: one sentence naming the strategic rationale, attributed to a role (*"our VP of Product"*), never a placeholder name. If the rationale can't be articulated, that's a finding — report it.
+   - **Customer quote**: a named-persona customer describing the before/after in concrete terms — a specific moment, not adjectives.
+   - **Call to action**: what the customer does next to get started.
+
+3. **Derive the adoption hypothesis** — two lines that make the press release falsifiable:
+   - **First-success event**: the one *customer* action that proves first value landed, observable within a session. ✅ *"Legal counsel approves their first AI-reviewed contract without re-reading it line by line"* — ❌ *"user completes onboarding"* — ❌ *"we launch to beta"* (that's the team's action, not the customer's).
+   - **Repeat-value behavior**: what brings the customer back after first success.
+
+   Can't name a first-success event → the problem paragraph is too vague; go back to step 2 before continuing.
+
+4. **Write the customer FAQ** — 3–5 questions a real buyer asks before switching: price, switching cost, reliability, "how is this different from `<what they use today>`", data/privacy. Answer honestly, and **at least one answer must concede a real trade-off**. A FAQ where every answer is good news is an ad.
+
+5. **Write the internal FAQ** — the questions a skeptical insider asks, each with a committed answer:
+   - The **riskiest assumption** — the belief that, if wrong, kills the product — and how it will be tested first.
+   - The **hardest technical or operational problem** and why it's believed solvable.
+   - The **acquisition path** — how the first 10 customers concretely arrive (not "marketing").
+   - The **success metric** — traceable to the first-success event from step 3. "User count" when first success is an approval event is a vanity metric; the metric must count the event.
+   - **What would make us kill this** — a named condition, not "if it doesn't work out".
+
+6. **Run the read-aloud pass, then emit** with [`templates/prfaq.md`](templates/prfaq.md): could a non-technical reader retell the problem and solution after one read? Is every claim in the press release either measurable or attributed? Anything failing gets rewritten before the artifact ships. Close with the hand-off line: idea survives → `prd-draft` (requirements) or `business-case` (the investment ask); riskiest assumption unproven → the test for it comes first.
+
+## Useful references in this skill
+
+- [`templates/prfaq.md`](templates/prfaq.md) — press release blocks, adoption hypothesis, and both FAQ skeletons
+
+## Quality bar
+
+- **The problem paragraph is in the customer's words.** If it contains a term the customer wouldn't say out loud, it fails.
+- **The first-success event is behavioral and observable** — you could watch a session recording and mark the moment it happened.
+- **The solution names a mechanism**, not a category. "Uses AI" describes a decade of products; what does *this one* do differently?
+- **At least one customer-FAQ answer concedes a trade-off.** Honesty in the FAQ is what separates a forcing function from a pitch.
+- **The internal-FAQ success metric counts the first-success event** — not sign-ups, not launches, not page views.
+- **The kill condition is named.** A PRFAQ that can't say what failure looks like hasn't confronted the riskiest assumption.
+- **No spec content.** Zero API shapes, acceptance criteria, or backlog items — those belong downstream in `prd-draft`.
+
+## When to use this skill
+
+- ✅ A product or feature concept exists but no team is committed yet — test the direction before the spec
+- ✅ "Write the press release first" / "do a working-backwards doc" / "Amazon-style PRFAQ"
+- ✅ Stakeholders disagree about what a product *is* — the press release forces one answer
+- ✅ A founder or PM needs to discover whether an idea survives its own hard questions
+
+## When NOT to use this skill
+
+- ❌ The product is committed and needs requirements — that's `prd-draft`
+- ❌ The question is invest/defer with costed options — that's `business-case`
+- ❌ Real launch marketing copy for a product that exists — this is a thinking tool, not copywriting
+- ❌ Org-level strategy or portfolio questions — `strategy-analysis`
+
+## Anti-patterns to avoid
+
+- ❌ **PRFAQ as a spec.** The moment acceptance criteria or API shapes appear, it's stopped forcing direction and started doing `prd-draft`'s job badly.
+- ❌ **Jargon-laundered problems.** "Lack of cross-functional visibility" is how a vendor talks. "I can't tell if my team is blocked" is how a customer talks. Only the second belongs in the press release.
+- ❌ **Placeholder quotes.** "[CEO name]: 'We're excited…'" defeats the exercise — the quote exists to force the strategic rationale into one attributable sentence.
+- ❌ **Launch-as-adoption.** "Ship to beta" as first success conflates the team's delivery with the customer's value. First success is something the *customer* does.
+- ❌ **Moat without mechanism.** Claiming defensibility without naming what makes it hard to copy — data advantage, network effect, workflow lock-in — is a wish wearing a strategy's clothes.
+- ❌ **All-good-news FAQs.** If the customer FAQ reads like the pricing page, the hard questions were dodged and the document proves nothing.

package/skills/prfaq/evals/eval_queries.json

@@ -0,0 +1,13 @@
+[
+  { "query": "Write a PRFAQ for our new product idea", "should_trigger": true },
+  { "query": "I want to write the press release before the product exists", "should_trigger": true },
+  { "query": "Help me do an Amazon-style working-backwards doc for this concept", "should_trigger": true },
+  { "query": "We need to align stakeholders on what this product actually is before engineering starts", "should_trigger": true },
+  { "query": "Write the press release and FAQ for this idea and tell me if it survives its own hard questions", "should_trigger": true },
+
+  { "query": "Draft the product requirements doc for the new feature", "should_trigger": false },
+  { "query": "Write a business case for building vs buying this tool", "should_trigger": false },
+  { "query": "Write the marketing copy for our launch homepage", "should_trigger": false },
+  { "query": "Run a SWOT analysis on our product line", "should_trigger": false },
+  { "query": "Write release notes for what we shipped this sprint", "should_trigger": false }
+]

package/skills/prfaq/evals/evals.json

@@ -0,0 +1,32 @@
+{
+  "skill_name": "prfaq",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write a PRFAQ for an AI-powered contract review tool aimed at in-house legal teams at mid-market companies. The problem: legal teams spend 60% of their time on low-complexity contract review that blocks deal closure.",
+      "assertions": [
+        "Press release contains all blocks: headline, sub-headline, problem paragraph, solution paragraph, leadership quote, customer quote, call to action",
+        "The headline names the product and a customer benefit — not a category claim like 'launches AI-powered platform'",
+        "The problem paragraph is in the customer's words with no industry jargon",
+        "The solution paragraph names a mechanism, not just 'uses AI'",
+        "The leadership quote is attributed to a role (not a placeholder name) and states a strategic rationale",
+        "An adoption hypothesis names a first-success event that is a customer action, observable within a session — not 'signs up', 'completes onboarding', or a team action like 'launch'",
+        "A repeat-value behavior is named",
+        "Customer FAQ has 3-5 questions and at least one answer concedes a real trade-off",
+        "Internal FAQ names the riskiest assumption with a test, the hardest technical problem, a concrete acquisition path, and a kill condition",
+        "The internal-FAQ success metric counts the first-success event, not a vanity metric",
+        "No acceptance criteria, API shapes, or backlog items appear anywhere",
+        "The output ends with a hand-off pointing to prd-draft or business-case"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "[Non-interactive run — no user available to answer questions] Write a PRFAQ.",
+      "assertions": [
+        "No press release is fabricated — with no customer, problem, or differentiator derivable, the output is a BLOCKED response",
+        "The BLOCKED output names the missing anchors (customer, problem, differentiator) and what to rerun with",
+        "No invented product, customer segment, or problem statement appears"
+      ]
+    }
+  ]
+}

package/skills/prfaq/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "prfaq",
+  "version": "0.1.0",
+  "description": "Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus the customer FAQ and internal FAQ that force the hard questions before engineering starts. Use when the user wants a PRFAQ, a working-backwards document, a \"write the press release first\" exercise, or needs to align stakeholders on what a product must be before committing a team to build it.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["business-case", "prd-draft", "strategy-analysis"],
+  "tags": ["prfaq", "working-backwards", "press-release", "product-strategy", "product-direction", "amazon"],
+  "model": { "tier": "standard", "rationale": "Synthesizes a press release and FAQs from a product concept against a fixed format. The specificity discipline needs care but the template bounds it; escalate via ambiguous-input when the concept itself is contested." }
+}

package/skills/prfaq/templates/prfaq.md

@@ -0,0 +1,60 @@
+# PR/FAQ: {Product name}
+
+> Status: DRAFT — working-backwards document, not a spec.
+> Author: {role} · Date: {date} · Imagined launch date: {launch-date}
+
+## Press release
+
+**{Headline: product name + customer benefit in one sentence}**
+
+*{Sub-headline: the key detail the headline compressed}*
+
+{CITY} — {launch-date} — {Problem paragraph: the customer's current pain, in their words. What do they do today, and where does it hurt?}
+
+{Solution paragraph: what the product does, and the mechanism that makes it different from what the customer uses today.}
+
+"{Leadership quote: one sentence naming the strategic rationale}," said {role, e.g. "the VP of Product"}.
+
+"{Customer quote: a named persona describing a concrete before/after moment}," said {persona name, role at company-type}.
+
+{Call to action: what the customer does next to get started.}
+
+## Adoption hypothesis
+
+- **First-success event:** {the one customer action that proves first value — behavioral, observable within a session}
+- **Repeat-value behavior:** {what brings the customer back after first success}
+
+## Customer FAQ
+
+<!-- 3–5 questions a real buyer asks before switching. At least one answer concedes a trade-off. -->
+
+**Q: How is this different from {what they use today}?**
+A: {honest answer, mechanism not category}
+
+**Q: What does it cost / what's the switching cost?**
+A: {…}
+
+**Q: {reliability / data / privacy question}**
+A: {answer that concedes the real trade-off}
+
+## Internal FAQ
+
+**Q: What's the riskiest assumption, and how do we test it first?**
+A: {the belief that kills the product if wrong} → {the cheapest test}
+
+**Q: What's the hardest technical/operational problem?**
+A: {…, and why we believe it's solvable}
+
+**Q: How do the first 10 customers concretely arrive?**
+A: {named path, not "marketing"}
+
+**Q: What's the success metric?**
+A: {a count of the first-success event, with a target and timeframe}
+
+**Q: What would make us kill this?**
+A: {a named condition}
+
+## Hand-off
+
+- Idea survives → `prd-draft` (requirements) or `business-case` (the investment ask)
+- Riskiest assumption unproven → design its test before anything else

package/skills/release-notes/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: release-notes
+description: Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, "what's in this release", a deploy announcement, or to summarize changes since the last tag.
+---
+
+# release-notes
+
+Converts commit history into two artifacts with different readers: **customer-facing release notes** (benefits, no commit-speak) and an **internal changelog** (Keep a Changelog format, every line traceable to a commit). The rule that drives everything: write for the reader who didn't make the change.
+
+## How to respond
+
+1. **Resolve the range.** Default: last tag to HEAD (`git describe --tags --abbrev=0`). If no tags exist, ask for a start ref or take the user's two refs. State the resolved range at the top of the output: "`v1.4.0..HEAD`, 37 commits, 2026-05-02 → 2026-06-10".
+
+2. **Gather the raw material.** `git log <range> --no-merges --pretty='%h|%s|%an|%ad' --date=short` for the commit list; `git log <range> --stat` only when a subject line is too vague to classify. Where the `gh` CLI is available and the repo uses PRs, prefer PR titles over commit subjects (`gh pr list --state merged --search "merged:>={date}"`) — they're written closer to reader language. Don't require `gh`; commits alone are enough.
+
+3. **Classify every change** into Keep-a-Changelog categories plus one local bucket:
+   - **Added / Changed / Fixed / Deprecated / Removed / Security** — reader-visible
+   - **Internal** — refactors, CI, deps, tests; appears in the internal changelog, never in customer notes
+   - **Needs review** — can't tell what it does from the commit; goes in a list for the user, never guessed into customer notes
+
+4. **Hoist breaking changes and migrations to the top** of both artifacts, each with an **Action required** line. A breaking change buried under "Changed" is the cardinal failure of release notes. Detect via `BREAKING`, `!:` conventional-commit markers, migration files, major dependency bumps, and removed public API — and say which signal triggered the flag.
+
+5. **Rewrite, don't transcribe.** Each customer-facing line states what the reader can now do or no longer suffers. ✅ *"Fixed a crash when exporting reports with more than 10,000 rows"* — ❌ *"fix NPE in ReportExporter.flush()"*. Drop ticket numbers and author names from customer notes; keep both in the internal changelog with the short hash on every line.
+
+6. **Emit both artifacts** with [`templates/release-notes.md`](templates/release-notes.md): customer notes first, internal changelog second, then the **Needs review** list. If the user wants only one artifact, emit that one — but the needs-review list is never optional.
+
+## Useful references in this skill
+
+- [`templates/release-notes.md`](templates/release-notes.md) — both artifact skeletons plus the classification cheat-sheet
+
+## Quality bar
+
+- **Breaking changes are first, with an action.** Every breaking entry has "Action required: …" a reader can execute. No action identifiable → it goes to Needs review, not to the top section unverified.
+- **No commit-speak in customer notes.** Class names, function names, internal service names, and ticket IDs are all signals the line wasn't rewritten.
+- **Every internal-changelog line ends in a short hash** (and PR number when available). A claim nobody can trace is a claim nobody can verify.
+- **Internal noise stays internal.** Dependency bumps, refactors, CI, and test-only changes never appear in customer notes — not even as "various improvements".
+- **Nothing is guessed.** A vague commit ("fix stuff", "wip") lands in Needs review with its hash; the skill never invents a user-facing meaning for it.
+- **The range is stated.** Refs, commit count, and date span at the top — so a reader knows exactly what window the notes cover.
+
+## When to use this skill
+
+- ✅ Cutting a release and writing "what's new" for users or customers
+- ✅ Maintaining `CHANGELOG.md` between versions
+- ✅ A deploy/release announcement for internal stakeholders
+- ✅ "Summarize everything merged since the last tag"
+
+## When NOT to use this skill
+
+- ❌ A single PR description — that's one change, just write it
+- ❌ Reviewing the changes for quality or risk — that's `devils-advocate` / `sonar-review`
+- ❌ Stakeholder narrative about *why* the release matters strategically — feed the notes to `exec-summary`
+- ❌ Generating commit messages going forward — this skill reads history, it doesn't write it
+
+## Anti-patterns to avoid
+
+- ❌ **Transcribing commit subjects with bullets in front.** That's `git log` with extra steps — the rewrite into reader language is the entire job.
+- ❌ **"Various bug fixes and improvements."** Either the fix is worth a line or it's internal; the vague catch-all is neither.
+- ❌ **Burying a breaking change** in the middle of "Changed" because the commit didn't shout about it. The detection signals exist precisely for quiet breaks.
+- ❌ **Padding a thin release.** Two real changes get two lines. Inflating with internal noise to look substantial erodes trust in every future release note.
+- ❌ **Marketing adjectives.** "Blazing-fast", "completely redesigned", "supercharged" — state the measurable change ("export is ~3× faster on large reports") or state nothing.
+- ❌ **Silently skipping unparseable commits.** They go to Needs review; the count of skipped commits is part of the output.

package/skills/release-notes/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "release-notes",
+  "version": "0.1.0",
+  "description": "Turn git history between two refs into release notes — a customer-facing version written in reader benefits and an internal Keep-a-Changelog version with commit traceability, breaking changes always first. Use when the user wants release notes, a changelog, \"what's in this release\", a deploy announcement, or to summarize changes since the last tag.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["devils-advocate", "exec-summary", "sonar-review"],
+  "tags": ["release-notes", "changelog", "git", "release", "deploy", "communication"],
+  "model": { "tier": "standard", "rationale": "Classifies commits and rewrites them for a reader. The audience translation needs judgment; escalate via large-input on very long ranges." }
+}