SPB Git

spb/ultra-sharp-agent-skills Public

Ultra-Sharp Agent Skills — a research-first skill-authoring system + 72 production-ready skills for AI agents.

Python 100%

# name: writing-executive-summaries description: Writes one-page executive summaries in a bottom-line-up-front house style — recommendation in sentence one, quantified impact, options with a clear pick. Use when the user asks for an executive summary, a TL;DR for leadership, a decision brief, a one-pager for executives, or to condense a report or analysis for senior stakeholders. Do not use for full reports or analyses, blog posts, or meeting notes.

# Writing Executive Summaries

# When to use / when NOT to use

  • Use for: decision briefs, one-pagers, leadership TL;DRs, the summary section at the top of a longer document.
  • Do NOT use for: the full report itself, blog posts, or meeting minutes (a separate writing-meeting-notes skill covers those). If the audience is peers who need the method, write the full analysis instead.

# House rules

  1. BLUF — bottom line up front. The recommendation or result is sentence one, not the destination of the document.

    • ✅ "Recommendation: migrate to vendor B, saving $210k/yr with a 6-week transition."
    • ❌ "This document examines our current vendor landscape and evaluates several options…"
  2. Answer the three executive questions, in order: what should we do → why → what does it cost/risk. Nothing else earns space on the page.

    • ✅ Sections: Recommendation / Rationale / Cost & Risk.
    • ❌ Sections: Background / Methodology / Stakeholders consulted / Timeline of events.
  3. One page maximum. If it doesn't fit, the summary isn't done; cut until it fits.

    • ✅ 250–400 words, 3–5 headed blocks.
    • ❌ "Executive summary (pages 1–4)".
  4. Numbers over adjectives, with confidence named. Quantify impact; state how sure you are.

    • ✅ "Cuts onboarding time from 12 days to 4 (measured across 40 accounts; high confidence)."
    • ❌ "Significantly improves onboarding efficiency."
  5. Options come with a pick. Present alternatives if they exist, but always recommend one — a menu without a recommendation delegates your job to the reader.

    • ✅ "Option A (recommended): … Option B: … We recommend A because the risk in B is unbounded."
    • ❌ "Options A, B and C are presented for consideration."
  6. Risks stated plainly, each with a mitigation. Naming risks builds credibility; hiding them destroys it in the Q&A.

    • ✅ "Risk: key engineer departure mid-migration → mitigation: 2-week shadow period, docs by day 5."
    • ❌ Omitting risks, or "some challenges may arise."
  7. No methodology before conclusions. How you got the answer goes in an appendix or the full report.

    • ✅ "Details and methodology: appendix B."
    • ❌ Opening with survey design and sample sizes.

# Workflow

  1. Write the recommendation sentence first, alone. If you can't, the analysis isn't finished — stop and say so.
  2. List the 3 strongest reasons, each with a number attached; discard the rest.
  3. Add cost, timeline, and the top 2–3 risks with mitigations.
  4. Assemble: Recommendation → Rationale → Cost & Risk → Next step (owner + date).
  5. Self-review: sentence one is the bottom line; every claim has a number or a named confidence level; fits on one page; each option has a pick. Fix violations and re-check.

# Edge cases

  • The data doesn't support a recommendation yet → say exactly that in sentence one, state what decision-relevant information is missing and the date you'll have it. Never fake certainty.
  • Two options are genuinely tied → recommend the reversible one and say that's the tiebreaker.
  • Hostile audience for the conclusion → the bottom line still goes first; add the single strongest counterargument and your answer to it in the rationale.

# References

Extended before/after examples: see references/examples.md.