skilldrop-cli 0.2.0

package/skills/audience-profile/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: audience-profile
+description: Translate an audience type (exec, board, technical, sales, investor, internal, partner, customer) into structural rules — slide count, density, tone, must-have sections, things to avoid. Reusable across deck-builder, slide-outliner, and exec-summary. Use whenever a stakeholder communication deliverable is being designed for a specific audience.
+---
+
+# audience-profile
+
+You help the user (or another skill) pick the right *shape* for a communication deliverable based on who's receiving it. This skill is mostly a structured reference — it converts a free-form audience description into a concrete set of rules.
+
+## How to respond
+
+1. **Map the free-form audience to an archetype.** Common ones in [`reference.md`](reference.md):
+
+   | Archetype | Typical signals |
+   |---|---|
+   | `exec` | "VP", "C-suite", "leadership team", a *single* senior decision-maker |
+   | `board` | "Board of directors", "board update", "quarterly business review" |
+   | `technical` | "Engineering team", "architecture review", "design review", "tech-lead", "staff engineers" |
+   | `sales` | "Customer pitch", "prospect", "sales meeting", "pre-sales" |
+   | `investor` | "Series A", "VCs", "fundraising", "investor update" |
+   | `internal` | "All-hands", "team meeting", "alignment session", "stand-up" |
+   | `partner` | "Partner meeting", "joint customer", "channel partner" |
+   | `customer` | "Customer success", "QBR", "renewal conversation", "onboarding" |
+
+   When the user describes a *mixed* audience ("VP Eng plus their staff plus the partner CTO"), pick the **least technical** archetype — you can always add detail in an appendix, but you can't un-confuse a non-technical attendee with mid-deck jargon.
+
+2. **Emit a structured profile.** When invoked, return the archetype's full ruleset:
+
+   ```
+   Audience archetype: <name>
+   Slide count target: <range>
+   Bullet density: <max bullets per slide>, <max words per bullet>
+   Tone: <descriptor>
+   Title style: <assertion / descriptive / outcome / benefit>
+   Must-have sections: <ordered list>
+   Layouts to favour: <list>
+   Layouts to avoid: <list>
+   Things to never include: <list>
+   ```
+
+3. **Be opinionated.** This skill exists to *make decisions* for the user. If they push back, fine — but don't hedge in the initial response. "Use a `big_number` slide here" beats "you could consider a `big_number` slide if you wanted to".
+
+4. **Hand off cleanly.** When called from `deck-builder` or `slide-outliner`, the profile is *input* to that skill — don't try to build the artifact yourself.
+
+## When to use this skill
+
+- ✅ Before drafting a deck, exec summary, or design review.
+- ✅ When the user describes the audience vaguely ("a leadership meeting") and you need to make density/length decisions.
+- ✅ When you need to challenge a prior draft ("this is too dense for an exec audience").
+
+## When NOT to use this skill
+
+- ❌ For peer engineering communication where the "audience" is just "another engineer reading the doc". The standard documentation style is fine.
+- ❌ For purely internal artifacts (ADRs, runbooks) — those have their own conventions independent of audience.
+
+## Useful references
+
+- [`reference.md`](reference.md) — full archetype matrix with all eight profiles
+
+## Quality bar
+
+- **Profile output is concrete.** "Slide count: 8–12" beats "keep it short".
+- **Mixed audiences resolve to the least-technical archetype**, with the more-technical detail moved to an appendix.
+- **Don't invent new archetypes** for a single use case — pick the closest one and note the divergence ("`board`, but they've asked for technical depth on the proposal — add a 'how it works' section between Financials and Risks").
+
+## Anti-patterns to avoid
+
+- ❌ **Treating "executives" as one archetype regardless of context.** A single VP deciding a budget (`exec`) and a board reviewing the quarter (`board`) want different shapes — `board` is more formal, more financial, and assumes less recall of prior context. Match the setting, not the seniority label.
+- ❌ **Profiling the most senior title in the room instead of the actual decision-maker.** If the VP is there to rubber-stamp what their staff engineer recommends, the staff engineer is the audience. Profile who the deliverable must *convince*, not who has the grandest title.
+- ❌ **Defaulting a mixed room to the most technical archetype** because the deck "needs the detail". A non-technical attendee lost on slide 3 is lost for the whole meeting; resolve to the least-technical archetype and push depth to an appendix.
+- ❌ **Hedged, generic output.** "Know your audience and keep it appropriately concise" is a fortune cookie, not a profile. Emit the numbers: slide count, bullet density, the must-have sections in order.
+- ❌ **Building the artifact instead of the profile.** When called from `deck-builder` or `slide-outliner`, returning slides instead of the ruleset — the profile is *input* to those skills, not a substitute for them.
+- ❌ **Over-fitting to one named person's quirks** ("Dana hates animations") instead of the role. Profiles are reusable because they're keyed to the archetype; bake in one individual's preferences and the profile dies when Dana changes jobs. Note the personal quirk as a one-line override, keep the archetype intact.

package/skills/audience-profile/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "audience-profile",
+  "version": "0.1.0",
+  "description": "Translate an audience type (exec, board, technical, sales, investor, internal, partner, customer) into structural rules — slide count, density, tone, must-have sections, things to avoid. Reusable across deck-builder, slide-outliner, and exec-summary. Use whenever a stakeholder communication deliverable is being designed for a specific audience.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["deck-builder", "slide-outliner"],
+  "tags": ["audience", "stakeholder-communication", "reference"],
+  "model": { "tier": "light", "rationale": "Maps fixed audience archetypes to structural rules. Lookup against a rubric, not synthesis." }
+}

package/skills/audience-profile/reference.md

@@ -0,0 +1,175 @@
+# Audience archetype matrix
+
+Eight archetypes covering the common stakeholder-communication situations an architect runs into. Each has rules dense enough to drive concrete structural choices in `deck-builder`, `slide-outliner`, or `exec-summary`.
+
+---
+
+## `exec`
+
+A single senior decision-maker (VP, SVP, C-suite) or a small leadership team. They have 15–30 minutes max and want to leave with a decision.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 6–10 (decision review) or 3–5 (quick update) |
+| Bullets / slide | 3 max |
+| Words / bullet | ≤ 8 |
+| Tone | Direct, opinionated, outcomes-first |
+| Title style | **Assertion** — "Postgres meets our latency target" |
+| Must-have sections | The Ask • TL;DR • Business impact • Risks • What we need from you |
+| Favour layouts | `big_number`, `content` (sparse), `closing` |
+| Avoid layouts | `quote` (rarely lands), dense `two_column` |
+| Never include | Technical jargon without translation, "team" slides, agenda slides |
+
+**Opening rule:** First slide after the cover must state the Ask. If the exec stops listening after slide 2, they should still know what you wanted.
+
+---
+
+## `board`
+
+Board of directors or steering committee. Quarterly cadence, mixed business/financial fluency, often skim before the meeting.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 8–12 (quarterly) |
+| Bullets / slide | 3 max |
+| Words / bullet | ≤ 6 |
+| Tone | Polished, business-led, transparent about risks |
+| Title style | **Outcome** — "$24M ARR protected by Q3" |
+| Must-have sections | Cover • TL;DR • Strategic context • Financials • Risks • Ask |
+| Favour layouts | `big_number`, `two_column` (before/after), `quote` (testimonials), `closing` |
+| Avoid layouts | Dense `content` slides |
+| Never include | Hidden bad news, sandbagged numbers, unfounded optimism |
+
+**Risk rule:** Always include a risks slide with mitigations. Boards trust presenters who name risks; they distrust presenters who pretend there are none.
+
+---
+
+## `technical`
+
+Engineering peers, architecture review, design review, staff/principal-level audience. Wants depth, expects pushback.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 12–20 (full design review) |
+| Bullets / slide | 5–6 |
+| Words / bullet | ≤ 14 |
+| Tone | Precise, neutral, evidence-first |
+| Title style | **Descriptive ok** — "Migration approach" — or assertion |
+| Must-have sections | Context • Goals/non-goals • Proposal (3–5 slides) • Alternatives considered • Risks • Rollout • Open questions |
+| Favour layouts | `content`, `two_column` (compare options), `section` (chapter breaks) |
+| Avoid layouts | `big_number` (overkill), `quote` (out of place) |
+| Never include | Hand-waving on hard problems, "trust me" assertions without evidence |
+
+**Alternatives rule:** Always show at least 2 alternatives with why-not. Skipping this section is the single biggest credibility killer in a technical review.
+
+---
+
+## `sales`
+
+Customer or prospect in a pre-sale or expansion conversation. Mixed business/technical, optimising for "what does this do for me".
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 8–12 |
+| Bullets / slide | 3–4 |
+| Words / bullet | ≤ 10 |
+| Tone | Story-arc, benefits-led, social proof |
+| Title style | **Benefit-led** — "Cut close time by 40%" |
+| Must-have sections | Hook • Their pain (in their language) • Our solution • Proof (logos/quotes) • Pricing tease • Close |
+| Favour layouts | `big_number` (proof points), `quote` (customer testimonials), `two_column` (before/after) |
+| Avoid layouts | `section` (kills momentum), dense `content` |
+| Never include | Feature lists without business translation, internal roadmap detail, competitor bashing |
+
+**Hook rule:** Slide 2 must be about *their* problem, not about us. If we don't earn their attention here, the rest of the deck is wasted.
+
+---
+
+## `investor`
+
+Fundraising audience — VCs, angels, strategic investors. Cynical, pattern-matching, looking for reasons to say no.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 10–15 (full deck), 5–7 (teaser) |
+| Bullets / slide | 3–4 |
+| Words / bullet | ≤ 10 |
+| Tone | Confident, evidence-heavy, narrative-driven |
+| Title style | **Assertion + number** where possible |
+| Must-have sections | Problem • Market • Product • Traction • Business model • Team • Ask |
+| Favour layouts | `big_number` (traction, market size), `content`, `two_column` (us vs. status quo) |
+| Avoid layouts | `section` (slows momentum), `closing` (use a definite Ask slide instead) |
+| Never include | TAM math without bottom-up validation, vanity metrics, "no competition" claims |
+
+**Team rule:** Team slide goes near the end (after traction) — investors evaluate the team *in the context of* what the team has built, not as an opening trust statement.
+
+---
+
+## `internal`
+
+All-hands, team meetings, alignment sessions. The audience already trusts the presenter and shares context.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 5–10 |
+| Bullets / slide | 4–5 |
+| Words / bullet | ≤ 12 |
+| Tone | Collaborative, candid, action-oriented |
+| Title style | **Topic ok** — "Q3 priorities" |
+| Must-have sections | Context (often skip — they know it) • Proposal • Discussion topics • Action items |
+| Favour layouts | `content`, `two_column`, brief `quote` (e.g. customer signal that motivated the change) |
+| Avoid layouts | `closing` (instead end on "discussion") |
+| Never include | Over-polished language that suggests the deck is also for an external audience |
+
+**Discussion rule:** End on a slide that *invites* discussion — listed questions, decisions to make as a group, etc. — not a thank-you.
+
+---
+
+## `partner`
+
+Joint meeting with a strategic partner, channel, integrator, or co-seller. Both sides have agendas.
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 8–12 |
+| Bullets / slide | 3–4 |
+| Words / bullet | ≤ 10 |
+| Tone | Mutual benefit, joint outcomes |
+| Title style | **Mutual benefit** — "Joint customers see X% faster onboarding" |
+| Must-have sections | Mutual context • What we're each bringing • Joint outcomes • Concrete next steps |
+| Favour layouts | `two_column` (us / them or before / after), `quote` (joint customer if you have one) |
+| Avoid layouts | Roadmap detail beyond integration touchpoints |
+| Never include | One-sided "what we offer" pages, internal strategy detail |
+
+**Reciprocity rule:** Every slide should reference *both* sides' contribution, not just ours. If a slide is fully about your company's product, it doesn't belong here.
+
+---
+
+## `customer`
+
+Existing customer in QBR, renewal conversation, or success check-in. Audience knows the product, wants to know "what's next for me".
+
+| Dimension | Rule |
+|---|---|
+| Slide count | 6–10 (QBR), 3–5 (success check-in) |
+| Bullets / slide | 3–4 |
+| Words / bullet | ≤ 12 |
+| Tone | Outcomes (theirs), partnership tone |
+| Title style | **Outcome for them** — "You'll save 12 engineer-hours/week" |
+| Must-have sections | Their results to date • What's new for them • What's next together • Asks (both sides) |
+| Favour layouts | `big_number` (their numbers), `two_column` (last quarter / next quarter), `content` |
+| Avoid layouts | `section`, dense roadmap pages |
+| Never include | Generic product updates not relevant to this customer, churn-flavoured language |
+
+**Specificity rule:** Every number on this deck should be *their* number, not industry averages or aggregated benchmarks.
+
+---
+
+## Picking when audiences mix
+
+When you have a mixed room ("VP Eng + the partner CTO + their procurement lead"):
+
+1. Identify the *decision-maker* — the person whose yes/no matters most. That's your archetype.
+2. Add an **appendix** with the depth the technical attendees will want.
+3. Don't try to serve every archetype in the main flow — you'll satisfy none of them.
+
+Exception: for a `technical + exec` mix where both are key decision-makers, use `exec` for the main flow and put technical detail in slides labelled as appendix. Engineers tolerate light main decks more than execs tolerate heavy ones.

package/skills/brief-intake/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: brief-intake
+description: Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, deck-builder, tech-comparison-matrix) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need.
+---
+
+# brief-intake
+
+You help the user (or the next skill in the chain) absorb raw unstructured input and emit a clean, structured brief shaped for whatever artifact comes next. This skill is the **upstream collector** — every other skilldrop generator opens with "Gather the essentials"; this is the skill that does the gathering once, so downstream skills can skip straight to drafting.
+
+## How to respond
+
+1. **Identify the downstream target.** Ask if the user hasn't said: *"What are you going to do with this brief?"* Map the answer to one of:
+
+   | Downstream skill | Trigger phrases |
+   |---|---|
+   | `adr-generator` | "ADR", "decision record", "capture a decision", "we decided X" |
+   | `design-doc` | "design doc", "tech proposal", "one-pager for review", "RFC" |
+   | `runbook-generator` | "runbook", "on-call doc", "operational doc", "prod-readiness" |
+   | `tech-comparison-matrix` | "compare X vs Y", "vendor selection", "tech selection" |
+   | `exec-summary` | "exec summary", "1-pager for the VP", "board update" |
+   | `deck-builder` / `slide-outliner` | "deck", "slides", "presentation", "pitch", "review meeting" |
+   | `decision-log` | "decisions and action items", "follow-ups from the meeting" |
+   | _(generic)_ | None of the above — emit the generic brief and let the user pick later |
+
+2. **Ingest the source.** The user will paste text, give a file path, or describe verbally. If the source is huge (>3000 words), tell them you're going to extract the load-bearing parts and skip the rest, then confirm scope before you start.
+
+3. **Extract once, into the target's shape.** Each downstream skill needs a specific set of fields. Use the matching template:
+
+   - `templates/brief-adr.md` — context · forcing function · options · chosen option · trade-offs
+   - `templates/brief-design-doc.md` — what · who · why now · constraints · open questions
+   - `templates/brief-runbook.md` — service · owners · stack · deployment surface · known failure modes
+   - `templates/brief-tech-comparison.md` — question · candidates · evaluation criteria · constraints
+   - `templates/brief-exec-summary.md` — ask · audience · business impact · what you need
+   - `templates/brief-deck.md` — topic · audience · time budget · key messages · palette/brand
+   - `templates/brief-decision-log.md` — source · scope · today's date
+   - `templates/brief-generic.md` — fallback when target is unknown
+
+4. **Mark every field with a confidence tag.** Each extracted field is tagged inline:
+
+   - `[explicit]` — stated outright in the source
+   - `[implied]` — clearly inferable from the source (quote the snippet)
+   - `[inferred]` — your judgement, not in the source — the user should verify
+   - `[missing]` — not in the source; the downstream skill will need to ask
+
+   This is the audit trail. The downstream skill (or the user) can then trust `[explicit]` fields and challenge the `[inferred]` ones.
+
+5. **Surface the gaps explicitly.** End with a "🚩 Missing for downstream" section listing fields that came back `[missing]` and which ones are load-bearing enough that the downstream skill will refuse to start without them. For example: "`adr-generator` will refuse to draft without at least 2 considered options — only 1 found in the source."
+
+6. **Don't draft the artifact yourself.** This skill stops at the structured brief. Hand off explicitly: *"Brief ready. Run `/adr-generator` with this brief as input."*
+
+## Quality bar
+
+- **Quote, don't paraphrase, when extracting.** When a field is `[explicit]` or `[implied]`, include a 5–15 word verbatim snippet from the source so the downstream skill (and the user) can verify nothing was hallucinated.
+- **Convert relative dates to absolute dates.** "Next Friday", "EOQ", "the sprint after this one" all become `YYYY-MM-DD` with `(implied)` if you had to compute it. Today's date is in the system context — use it.
+- **Don't invent people.** If the source says "someone from platform should…", the owner is `unowned`, not a guess.
+- **Don't merge across sources unless the user asked.** If the user pastes a Slack thread *and* a doc, ask whether you should treat them as one brief or extract separately.
+- **Strip noise aggressively.** Greetings, off-topic banter, "lol", and emoji reactions get dropped. The brief is the signal, not the conversation.
+
+## When to use this skill
+
+- ✅ Before invoking any other skilldrop generator when the input is messy.
+- ✅ When a user pastes a 90-minute transcript and says "I need an ADR from this".
+- ✅ When the next step's `SKILL.md` says "Gather the essentials" and the user has unstructured source material.
+- ✅ As a checkpoint after `decision-log` — to turn a single extracted decision into an `adr-generator` brief.
+
+## When NOT to use this skill
+
+- ❌ When the user has already given a clean, structured brief — go straight to the downstream skill.
+- ❌ For pure summarization — that's not what this is. The output is shaped for a *specific next step*, not a generic summary.
+- ❌ For raw transcript cleanup. If the user wants meeting notes cleaned up, use `decision-log`.
+
+## Anti-patterns to avoid
+
+- ❌ Padding `[inferred]` fields to make the brief look complete. Empty `[missing]` is more honest and more useful.
+- ❌ Restating the source verbatim. The brief is *shaped*, not a copy.
+- ❌ Skipping the gaps section because the brief looks fine — the gaps are the *most useful output* for the user about to invoke the downstream skill.
+- ❌ Asking 4+ clarifying questions. If the source is too thin, say so once and let the user decide whether to add material or proceed with gaps flagged.
+- ❌ Emitting the brief in prose. Downstream skills want structured fields, not paragraphs.

package/skills/brief-intake/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "brief-intake",
+  "version": "0.1.0",
+  "description": "Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, deck-builder, tech-comparison-matrix) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": ["adr-generator", "decision-log", "deck-builder", "design-doc", "exec-summary", "runbook-generator", "slide-outliner", "tech-comparison-matrix"],
+  "tags": ["intake", "brief", "extraction", "preprocessing", "pipeline"],
+  "model": { "tier": "standard", "rationale": "Extraction + [explicit]/[implied]/[inferred] tagging. The tagging needs care — above haiku, below opus." }
+}

package/skills/brief-intake/templates/brief-adr.md

@@ -0,0 +1,41 @@
+# Brief: ADR
+
+> Target downstream skill: `adr-generator`
+
+## Decision
+{One-sentence noun phrase — the decision, not the question} [explicit|implied|inferred|missing]
+> "{verbatim snippet from source}"
+
+## Context / forcing function
+{Why is a decision needed *now*? What changed?} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Decision drivers
+- {Driver 1 — constraint, requirement, or non-negotiable} [explicit|implied|inferred|missing]
+- {Driver 2}
+- {Driver 3}
+
+## Options considered
+- **Option A** — {one-line description} [explicit|implied|inferred|missing]
+- **Option B** — {one-line description}
+- **Option C** — {one-line description, or omit if only two were considered}
+
+## Chosen option
+**{Option name}** — because {one-sentence rationale tied to a driver above} [explicit|implied|inferred|missing]
+
+## Consequences / trade-offs
+- ✅ {what becomes easier} [explicit|implied|inferred|missing]
+- ⚠️ {acceptable trade-off}
+- ❌ {what becomes harder or constrains future choices}
+
+## Format hint
+{`MADR` (default) | `Nygard` (if source frames it as a simple decision)}
+
+## Numbering hint
+{ADR directory mentioned in source, e.g. `docs/adr/` — or `unknown` so adr-generator asks}
+
+---
+
+## 🚩 Missing for downstream
+- {field: why it matters to adr-generator}
+- {e.g. "Only 1 option captured — adr-generator requires ≥2 considered options"}

package/skills/brief-intake/templates/brief-decision-log.md

@@ -0,0 +1,35 @@
+# Brief: Decision Log
+
+> Target downstream skill: `decision-log`
+
+This brief is lightweight — most of `decision-log`'s work is *its own* extraction. `brief-intake` mostly normalizes the source before handing it over.
+
+## Source
+- **Type:** {Slack thread | meeting transcript | email chain | Notion page | mixed} [explicit|implied|inferred|missing]
+- **Date of meeting / thread:** {YYYY-MM-DD} [explicit|implied|inferred|missing]
+- **Attendees / participants:** {names if stated, "unknown" otherwise} [explicit|implied|inferred|missing]
+- **Length:** {word count or minutes if known} [inferred]
+
+## Scope the user wants extracted
+- [ ] Decisions
+- [ ] Action items
+- [ ] Open questions
+- [ ] Risks raised
+
+(Default: all four if user didn't specify.)
+
+## Today's date
+{YYYY-MM-DD} — needed for converting relative dates ("next Friday", "EOQ") to absolute. [explicit]
+
+## Sprint / fiscal context
+- **Current sprint ends:** {YYYY-MM-DD} [explicit|implied|inferred|missing]
+- **Quarter ends:** {YYYY-MM-DD} [explicit|implied|inferred|missing]
+
+## Cleaned source
+{Paste the source with the obvious noise stripped — greetings, off-topic banter, emoji-only messages. Keep ambiguous parts; decision-log decides what's load-bearing.}
+
+---
+
+## 🚩 Missing for downstream
+- {e.g. "No date — decision-log can't convert 'Friday' to an absolute date"}
+- {e.g. "Attendees unknown — owners can't be attributed to names"}

package/skills/brief-intake/templates/brief-deck.md

@@ -0,0 +1,43 @@
+# Brief: Deck
+
+> Target downstream skills: `slide-outliner` → `deck-builder` (and `audience-profile` for the structural rules)
+
+## Topic / working title
+{One line} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Audience
+- **Free-form description from source:** {as quoted} [explicit|implied|inferred|missing]
+- **Mapped archetype:** {exec | board | technical | sales | investor | internal | partner | customer} [inferred]
+- **If mixed audience:** least-technical archetype above + appendix for the rest
+
+## Time budget
+- **Speaking time:** {minutes} [explicit|implied|inferred|missing]
+- **Reading time (if pre-read):** {minutes} [explicit|implied|inferred|missing]
+- **Implied slide count:** {derived from time × audience archetype}
+
+## The one thing the audience should leave with
+{Single sentence — the headline message} [explicit|implied|inferred|missing]
+
+## Key messages (3–5)
+1. {Message} [explicit|implied|inferred|missing]
+2. {Message}
+3. {Message}
+
+## Evidence available
+- **Quantified data:** {numbers the source provides — for `big_number` slides} [explicit|implied|inferred|missing]
+- **Quotes:** {customer / exec / analyst quotes for `quote` slides} [explicit|implied|inferred|missing]
+- **Diagrams:** {existing diagrams that should be embedded} [explicit|implied|inferred|missing]
+
+## Brand / palette
+- **Palette source:** {named preset | hex values | "use our brand colors"} [explicit|implied|inferred|missing]
+- **Specific colors mentioned:** {hex / role} [explicit|implied|inferred|missing]
+
+## Constraints
+- {e.g. "no logos other than ours", "must include compliance disclaimer", "30s pre-roll for the cover"} [explicit|implied|inferred|missing]
+
+---
+
+## 🚩 Missing for downstream
+- {e.g. "Audience not specified — deck-builder will refuse to start"}
+- {e.g. "No palette — deck-builder will ask before building"}

package/skills/brief-intake/templates/brief-design-doc.md

@@ -0,0 +1,48 @@
+# Brief: Design Doc
+
+> Target downstream skill: `design-doc`
+
+## What we're building
+{One sentence} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Who's affected
+- **Users / callers:** {who consumes this} [explicit|implied|inferred|missing]
+- **Teams:** {who owns or depends on it}
+- **Systems:** {upstream/downstream services}
+
+## Why now (forcing function)
+{What changed? Outage, regulatory, scaling cliff, competitor, deadline} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Goals
+- {Goal 1} [explicit|implied|inferred|missing]
+- {Goal 2}
+- {Goal 3}
+
+## Non-goals
+- {Real non-goal — something a reasonable reader might assume you *are* doing} [explicit|implied|inferred|missing]
+- {Another non-goal}
+
+## Constraints
+- {Hard constraint — tech, regulatory, budget, timeline} [explicit|implied|inferred|missing]
+- {Soft constraint}
+
+## Alternatives the source mentions
+- {Alternative 1 — and why-not if stated} [explicit|implied|inferred|missing]
+- {Alternative 2}
+
+## Risks raised in the source
+- {Risk — and any proposed mitigation} [explicit|implied|inferred|missing]
+
+## Open questions
+- {Question — and who should answer if stated} [explicit|implied|inferred|missing]
+
+## Target length
+{1-pager | 2–5 pages (default) | longer with explicit reason}
+
+---
+
+## 🚩 Missing for downstream
+- {field: why it matters}
+- {e.g. "No 'why now' captured — design-doc refuses to draft without a forcing function"}

package/skills/brief-intake/templates/brief-exec-summary.md

@@ -0,0 +1,47 @@
+# Brief: Exec Summary
+
+> Target downstream skill: `exec-summary`
+
+## The Ask
+{One line — what decision / approval / resource are we requesting?} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Audience
+- **Role:** {VP / C-suite / board / partner CTO / steering committee} [explicit|implied|inferred|missing]
+- **Technical depth:** {none / light / fluent} [explicit|implied|inferred|missing]
+- **Reading time:** {30s / 1 min / 3 min — default 60s for a 1-pager} [explicit|implied|inferred|missing]
+- **What they already know:** {context to skip} [explicit|implied|inferred|missing]
+
+## The project, in one sentence
+{What it is — plain language, no jargon} [explicit|implied|inferred|missing]
+
+## Why now
+{Forcing function — competitor, regulation, outage, market window} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Recommendation
+{What you want them to agree to} [explicit|implied|inferred|missing]
+
+## Business impact (quantified where possible)
+- **Revenue:** {$X ARR / $Y new revenue / 0 if n/a} [explicit|implied|inferred|missing]
+- **Cost:** {savings or spend} [explicit|implied|inferred|missing]
+- **Risk:** {what's at stake if we *don't* do this} [explicit|implied|inferred|missing]
+- **Time:** {when does the impact land} [explicit|implied|inferred|missing]
+
+## Cost & timeline
+- **Investment:** {$ / FTEs / months} [explicit|implied|inferred|missing]
+- **Timeline:** {phases + dates} [explicit|implied|inferred|missing]
+
+## Top 3 risks (project-specific, not generic)
+1. {Risk} — mitigation: {mitigation} [explicit|implied|inferred|missing]
+2. {Risk} — mitigation: {mitigation}
+3. {Risk} — mitigation: {mitigation}
+
+## What we need from the audience
+- {Concrete ask — money / headcount / decision / introduction} [explicit|implied|inferred|missing]
+
+---
+
+## 🚩 Missing for downstream
+- {field: why it matters}
+- {e.g. "No quantified business impact — exec-summary will have to use 'directional' language"}

package/skills/brief-intake/templates/brief-generic.md

@@ -0,0 +1,45 @@
+# Brief: Generic
+
+> Target downstream skill: _unknown_ — emit this when the user hasn't picked a next step yet.
+
+This is the fallback shape. It's a superset of the most useful fields across all targets — the user (or you, next turn) picks the downstream skill and the relevant fields move into its specific brief.
+
+## One-line summary
+{What is this about?} [explicit|implied|inferred|missing]
+> "{verbatim snippet}"
+
+## Type of artifact the user might want next
+{Best guess based on the source — and why}
+- {e.g. "Looks like a decision being captured → adr-generator"}
+- {e.g. "Looks like a runbook brief — service name + on-call mentioned"}
+
+## Subject
+- **What it's about (object):** {service / decision / project / vendor selection} [explicit|implied|inferred|missing]
+- **Who's involved:** {teams, people, customers} [explicit|implied|inferred|missing]
+- **Why now:** {forcing function if any} [explicit|implied|inferred|missing]
+
+## Key facts (load-bearing)
+- {Fact 1 — quote} [explicit|implied|inferred|missing]
+- {Fact 2}
+- {Fact 3}
+
+## Decisions / asks present in the source
+- {Anything that looks like a decision or an ask} [explicit|implied|inferred|missing]
+
+## Open questions / unknowns
+- {Things explicitly unresolved in the source} [explicit|implied|inferred|missing]
+
+## Dates / deadlines
+- {Date → what it's tied to (absolute, with `(implied)` if computed)} [explicit|implied|inferred|missing]
+
+## Names / owners
+- {Name → role / responsibility} [explicit|implied|inferred|missing]
+
+## Numbers / metrics
+- {Number → what it measures} [explicit|implied|inferred|missing]
+
+---
+
+## 🚩 Next step
+Pick a downstream skill, then run `brief-intake` again with that target to get the precisely-shaped brief. Suggested:
+- {Skill name} — because {reason from this source}