Claude
Skills
Sign in
Back

executive-brief-code

Included with Lifetime
$97 forever

Structure engineering communication (PR descriptions, commit messages, RFCs, design docs, architecture decision records, incident escalations, postmortems, status updates to eng leadership) so a busy reviewer or decision-maker can act with minimal cognitive load. Use this in a dev context whenever the user is writing something a human must read and decide on, with requests like "write the PR description", "draft an RFC for this", "I need to escalate this incident", "write up the postmortem", "summarize this change for review", or "write a design doc". Also use when the user names a method directly such as BLUF, SBAR, SCQA, Minto Pyramid, completed staff work, or decision brief. This is the Claude Code version; output is markdown suited to a terminal, repo, or ticket.

Design

What this skill does


# Executive Brief — Code

A reviewer reading your PR, an on-call lead reading your incident page, a staff engineer reading your RFC — all of them are context-switching from something else and have limited time. Structure the artifact so they grasp the point and the ask immediately.

## Workflow

1. **Pick the method.**
   - If the user named one (BLUF, SBAR, SCQA, Minto, completed staff work, decision brief), use it. Manual choice always wins.
   - Otherwise read `references/method-router.md`, then apply the dev-artifact mapping below.

2. **Load the chosen method.** Read its file in `references/` and apply the template.

3. **Write the artifact** as markdown.

## Dev-artifact mapping (auto-routing for code work)

| Artifact | Method | Why |
| :-- | :-- | :-- |
| Commit message, PR title/description, short status to leadership | **BLUF** | Reviewer has context; lead with what changed and why, details below. |
| Incident escalation, paging an on-call, "prod is broken" | **SBAR** | Live problem; receiver needs status + ask before background. |
| RFC, design doc, proposal for an unfamiliar reviewer | **SCQA** opening + **Minto** body | Rebuild context, then structure the argument gap-free. |
| Approval to merge/ship a risky change | **Completed Staff Work** | Present analyzed options + your recommendation; reviewer approves or rejects. |
| Architecture Decision Record, formal choice between approaches | **FM 6-0 Decision Brief** | Formal COA selection; scale depth to the reader's familiarity. |
| Postmortem | **SBAR** (timeline) or **Minto** (analysis) | SBAR for the incident narrative; Minto when the focus is root-cause reasoning + actions. |

The user can always override this mapping by naming a method.

## Code conventions

- **Output markdown** suited to the destination (PR body, `.md` file in the repo, ticket comment). Match the repo's existing doc style if visible.
- **Lead with the bottom line.** First line states what changed / what's broken / what you recommend.
- **Strip insider jargon for the intended reader.** A PR for the whole team needs more context than a comment to a co-author. Define non-obvious terms with a concrete example.
- **Take a position.** A design doc that lists options without a recommendation pushes the thinking back onto the reader — exactly the load this skill removes.
- **Keep code and prose separate.** Put the brief in prose; let code blocks and diffs carry the detail.

## When the input is too thin

If you can't fill the method (unclear what decision is needed, no options analyzed, no failure detail), say what's missing in one line and ask for just that.

Related in Design