skilldrop-cli 0.16.3__py3-none-any.whl

skilldrop_cli/data/packs/sre-oncall/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}
+```

skilldrop_cli/data/packs/sre-oncall/skills/runbook-generator/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: runbook-generator
+description: Generate an operational runbook for a service — covering deploy/rollback, common incidents, on-call escalation, SLOs, dashboards, and dependencies. Use when the user is launching a new service, onboarding to on-call, or being asked for "the runbook" by SRE or production-readiness review.
+---
+
+# runbook-generator
+
+You help the user produce a runbook that a sleep-deprived on-caller at 3am can actually use.
+
+## How to respond
+
+1. **Understand the service.** Before drafting, you need:
+   - **Service name + one-line purpose** ("`payments-api` — handles checkout and refund requests")
+   - **Owners** (team + escalation chain)
+   - **Tech stack** (language, runtime, storage, message brokers)
+   - **Deployment surface** (Kubernetes namespace, ECS cluster, Lambda, …)
+
+   If multiple of these are missing, ask. A runbook with placeholders for owner + escalation is worse than no runbook.
+
+2. **Use [`templates/runbook.md`](templates/runbook.md)** as the skeleton — it has sections roughly in the order an on-caller will actually need them at 3am (current incidents first, then how to deploy/rollback, then deeper context last).
+
+3. **Bias toward concrete commands over prose.** "Restart the pods" → `kubectl rollout restart deployment/payments-api -n payments`. The runbook should be paste-able.
+
+4. **Cover the "common 5" incidents.** Every service has ~5 failure modes that account for 80% of pages. Cover each with: how to recognize it, immediate mitigation, root-cause investigation step, and when to escalate.
+
+   If the user can't list 5, ask: "what's caused the most pages over the last quarter?" The honest answer is the most valuable section of the runbook.
+
+5. **Link, don't inline.** Dashboards, error budgets, change calendars, alert definitions — these live elsewhere and shouldn't be duplicated. Link with a one-line description so the on-caller knows what they'll find.
+
+## Quality bar
+
+- **Owner info is current.** Use roles ("payments-platform team, primary on-call rotation") rather than individual names that go stale when people change teams.
+- **Every alert listed has a response.** A "what to do when this alert fires" section that doesn't cover all the alerts is worse than no section.
+- **Rollback is one command, or three steps max.** If rollback is complicated, write a script and link to it.
+- **No "TBD" left in the doc when it's published.** Move TBDs to a "known gaps" section so they're explicit, not hidden.
+
+## Anti-patterns to avoid
+
+- ❌ Architecture diagrams in the runbook. (Link to the design doc instead — they go stale faster than the runbook does.)
+- ❌ Long backstory before the operational commands.
+- ❌ "Page X if you're not sure" without saying *what X knows that you don't*.
+- ❌ Listing every metric Prometheus has. Pick the 5–10 that actually predict outages.

skilldrop_cli/data/packs/sre-oncall/skills/runbook-generator/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Write an operational runbook for this service",
+    "should_trigger": true
+  },
+  {
+    "query": "We're launching a service — what does on-call need documented?",
+    "should_trigger": true
+  },
+  {
+    "query": "Document deploy, rollback, and incident response for this system",
+    "should_trigger": true
+  },
+  {
+    "query": "Generate the runbook covering escalation and common failures",
+    "should_trigger": true
+  },
+  {
+    "query": "Design our SLIs, SLOs, and burn-rate alerts",
+    "should_trigger": false
+  },
+  {
+    "query": "We're in an incident right now — draft the status page update",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the postmortem for the outage",
+    "should_trigger": false
+  },
+  {
+    "query": "Sweep the full non-functional requirements catalog",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/sre-oncall/skills/runbook-generator/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "runbook-generator",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Write the operational runbook for our new payments service — it deploys via Argo, pages the payments team, and depends on Stripe and Postgres.",
+      "assertions": [
+        "Ownership is expressed as roles and rotations rather than individual names that go stale",
+        "Every alert listed has a corresponding 'what to do when this fires' response — no alert is left without one",
+        "Rollback is one command or at most three steps",
+        "Dependencies are listed with what breaks when each is unavailable",
+        "Escalation names the path and the trigger for escalating, not just a team name",
+        "Facts not supplied (dashboard links, SLO values) are marked missing rather than invented"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/sre-oncall/skills/runbook-generator/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "runbook-generator",
+  "version": "0.1.0",
+  "description": "Generate an operational runbook for a service — covering deploy/rollback, common incidents, on-call escalation, SLOs, dashboards, and dependencies. Use when the user is launching a new service, onboarding to on-call, or being asked for \"the runbook\" by SRE or production-readiness review.",
+  "entrypoint": "SKILL.md",
+  "deps": { "npm": [], "pip": [] },
+  "env": { "required": [], "optional": [] },
+  "related": [],
+  "tags": ["runbook", "operations", "on-call", "sre"],
+  "model": { "tier": "standard", "rationale": "Operational doc from service facts. Bounded synthesis." }
+}

skilldrop_cli/data/packs/sre-oncall/skills/runbook-generator/templates/runbook.md

@@ -0,0 +1,109 @@
+# Runbook — {service-name}
+
+**Purpose:** {One sentence — what this service does}
+**Owner:** {team name} (primary), {team name} (secondary)
+**On-call escalation:** {PagerDuty rotation / Slack channel for paging}
+**Last reviewed:** {YYYY-MM-DD}
+
+> 📟 **Paged right now?** Skip to [Incident playbooks](#incident-playbooks) below.
+
+## Critical links
+
+| What | Where |
+|---|---|
+| Dashboard (golden signals) | {URL} |
+| Logs | {URL — e.g. Datadog query, CloudWatch link} |
+| Error tracking | {URL — Sentry / Bugsnag / Rollbar project} |
+| Source repo | {URL} |
+| Latest design doc | {URL} |
+| Change calendar | {URL — to check if a recent deploy is the cause} |
+
+## SLOs
+
+| SLI | SLO | Window |
+|---|---|---|
+| Availability | 99.9% | 30 days |
+| Latency p99 | < 100ms | 30 days |
+| Error rate | < 0.1% | 30 days |
+
+**Error budget:** {how much budget is left this period, link to dashboard}
+
+## Deploy
+
+```bash
+# Trigger CI/CD
+{exact command — e.g. `gh workflow run deploy-prod.yml --ref main`}
+
+# Confirm
+{exact command — e.g. `kubectl rollout status deployment/{service} -n {ns}`}
+```
+
+**Pre-deploy checklist:** {anything that must be true before deploying — error budget OK, no incidents open, …}
+
+## Rollback
+
+```bash
+# Last-known-good
+{exact command — e.g. `kubectl rollout undo deployment/{service} -n {ns}`}
+```
+
+**Rollback criteria:** {when to revert without further investigation — e.g. "error rate > 1% sustained 5 min after deploy"}
+
+## Incident playbooks
+
+The most common incidents, with how to recognize → mitigate → investigate.
+
+### 1. {Incident name — e.g. "High p99 latency"}
+
+**Symptom:** {alert text + dashboard pattern}
+**Immediate mitigation:**
+1. {Step — e.g. "Scale up: `kubectl scale deploy/{service} --replicas=20`"}
+2. {Step}
+
+**Investigate:**
+- {Where to look — log query, dashboard, …}
+
+**Escalate when:** {clear condition for paging the next tier}
+
+### 2. {Incident name — e.g. "Database connection saturation"}
+
+**Symptom:** {…}
+**Immediate mitigation:** {…}
+**Investigate:** {…}
+**Escalate when:** {…}
+
+### 3. {Incident name}
+
+{…}
+
+### 4. {Incident name}
+
+{…}
+
+### 5. {Incident name}
+
+{…}
+
+## Dependencies
+
+| Depends on | Type | Failure mode if it's down | Owner |
+|---|---|---|---|
+| {Service / vendor} | {sync API / async queue / data store} | {what happens — does this service degrade, refuse traffic, or break entirely?} | {team} |
+| {Service / vendor} | … | … | … |
+
+## Operations cookbook
+
+Common manual tasks (not incidents):
+
+- **Drain a node / pod:** `{command}`
+- **Replay a failed job:** `{command or runbook link}`
+- **Re-issue an API key:** `{procedure}`
+- **Triage a customer report:** `{escalation path}`
+
+## Known gaps
+
+- {Honest list of "we don't have a good answer for X yet" — better explicit than hidden}
+
+## Change log
+
+- {YYYY-MM-DD} — {what changed in the runbook itself, e.g. "added incident #5 after rollout 2026-04-12 incident"}

skilldrop_cli/data/packs/stakeholder-comms/pack.json

@@ -0,0 +1,60 @@
+{
+  "description": "Non-technical audiences: audience profiling, exec summaries, decision logs, and guides. Decks live in the design pack.",
+  "display_name": "Stakeholder comms",
+  "keywords": ["exec-summary", "deck", "audience", "decision-log"],
+  "links": {
+    "documentation": "https://sananthanarayan.github.io/skilldrop/packs/stakeholder-comms/"
+  },
+  "maintainers": [
+    {
+      "name": "sananthanarayan"
+    }
+  ],
+  "first-value": {
+    "audience-posture": "non-technical",
+    "prerequisites": [],
+    "starter-task": "Turn a long document into a one-page summary for leadership",
+    "starter-prompt": "Turn this design doc into a one-page executive summary for our steering committee: <paste the doc>.",
+    "verification": "exec-summary returns a one-page summary that a time-poor reader can act on in 30 seconds, written without jargon.",
+    "recovery": "If exec-summary does not activate, ask for it by name (\"use exec-summary\") and check that its folder exists in your skills folder (`~/.claude/skills/` by default)."
+  },
+  "requires": ["core"],
+  "journey": {
+    "when": "You need to turn a long document or a meeting into something a non-technical or time-poor audience can act on.",
+    "you_bring": [
+      "the long document, such as a design doc or proposal",
+      "notes or a transcript from the meeting where it was discussed",
+      "who the audience is, such as a steering committee or an exec sponsor"
+    ],
+    "time": "30–60 minutes",
+    "steps": [
+      {
+        "skill": "decision-log",
+        "you_do": "Paste the meeting notes, thread or transcript.",
+        "you_get": "A structured log of decisions, action items, owners and due dates you can paste into a doc or tracker."
+      },
+      {
+        "skill": "audience-profile",
+        "you_do": "Say who will read it, in your own words.",
+        "you_get": "The audience archetype with its rules: length, density, tone, must-have sections and things to never include."
+      },
+      {
+        "skill": "exec-summary",
+        "you_do": "Hand it the long document, the decisions, and the audience profile.",
+        "you_get": "A one-page summary a time-poor reader can act on in 30 seconds, without jargon."
+      },
+      {
+        "skill": "doc-critique",
+        "you_do": "Run it on the summary before it goes out.",
+        "you_get": "A verdict and severity-tagged findings, such as a missing Ask, each with a suggested fix.",
+        "decide": "Ship, ship with the listed changes, or rewrite."
+      },
+      {
+        "skill": "output-hygiene",
+        "you_do": "Run it on the final version.",
+        "you_get": "The text with machine artifacts stripped and any prose tells quoted with rewrites."
+      }
+    ],
+    "you_end_with": "A decision log with owners and dates, and a reviewed one-page summary ready to send."
+  }
+}

skilldrop_cli/data/packs/stakeholder-comms/skills/audience-profile/SKILL.md

@@ -0,0 +1,74 @@
+---
+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.
+- ❌ **Showing the machinery.** The reply and the artifact are for the person who asked. Don't mention this skill, its files, templates, caps or internal terms, or that the run is non-interactive. Name another skill once, at the end, as a suggested next step, never inside the artifact.

skilldrop_cli/data/packs/stakeholder-comms/skills/audience-profile/evals/eval_queries.json

@@ -0,0 +1,34 @@
+[
+  {
+    "query": "Who is my audience and what rules should the deck follow?",
+    "should_trigger": true
+  },
+  {
+    "query": "What are the structural rules for presenting to a board versus engineers?",
+    "should_trigger": true
+  },
+  {
+    "query": "Profile this audience so I know how technical to go",
+    "should_trigger": true
+  },
+  {
+    "query": "We have a mixed exec and technical room — how should I pitch it?",
+    "should_trigger": true
+  },
+  {
+    "query": "Build the PowerPoint for the board meeting",
+    "should_trigger": false
+  },
+  {
+    "query": "Outline the slides for this deck",
+    "should_trigger": false
+  },
+  {
+    "query": "Write the one-page executive summary",
+    "should_trigger": false
+  },
+  {
+    "query": "Map the customer's journey through our product",
+    "should_trigger": false
+  }
+]

skilldrop_cli/data/packs/stakeholder-comms/skills/audience-profile/evals/evals.json

@@ -0,0 +1,15 @@
+{
+  "skill_name": "audience-profile",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're presenting our platform strategy to a mixed room — the board plus two engineering leads. What audience rules should we design to?",
+      "assertions": [
+        "Output is concrete and structural (slide count ranges, density, tone, must-have sections, things to avoid) rather than advice like 'keep it short'",
+        "A mixed audience resolves to the least-technical archetype, with the more-technical material moved to an appendix",
+        "No new archetype is invented for a one-off case — the closest existing one is chosen and the divergence noted",
+        "The profile is reusable across deliverables rather than being a deck or summary itself"
+      ]
+    }
+  ]
+}

skilldrop_cli/data/packs/stakeholder-comms/skills/audience-profile/manifest.json

@@ -0,0 +1,11 @@
+{
+  "name": "audience-profile",
+  "version": "0.1.1",
+  "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." }
+}

skilldrop_cli/data/packs/stakeholder-comms/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.