Executive Summary Skill
Create formal, narrative-driven executive summaries for leadership and stakeholders. This skill handles two primary workflows: synthesizing GitHub conversations (issues, pull requests, discussions) and distilling meeting transcripts (Zoom, Teams, etc.) into concise, decision-focused summaries.
Related Skills
Use brain-operating-system skill for:
- Output directory structure and naming conventions (
Executive Summaries/YYYY-MM-DD/)
- Date folder creation patterns and file numbering
Use voice-and-tone skill for:
- Narrative construction and paragraph patterns
- First-person framing when appropriate
- Crediting collaborators and showing impact
Use github-interaction skill for:
- Fetching complete GitHub conversations (issues, PRs, discussions)
- Comment and review retrieval patterns
- Pagination handling
Core Principles
All executive summaries follow these unifying principles, regardless of source:
Narrative-Driven Prose
- Structure content as dense, logically-connected paragraphs in formal, authoritative tone
- Avoid bullet points, subheaders, or lists
- Each paragraph builds on the previous, conveying a cohesive narrative of evolution from initial topic through decisions and next steps
- Limit length to 3–5 structured paragraphs (GitHub summaries may run longer for complex decisions)
Impact & Decision Focus
- Include only details that significantly influenced direction, decisions, or outcomes
- Omit administrative commentary, routine pleasantries, subscription messages, procedural remarks, superficial technical minutiae (code diffs, exact timestamps), or automation events
- Center on key debates, decisions, constraints, resolutions, and business/user impact
- Clearly articulate alternatives explored, current status, next steps, and individual responsibilities
Contextual Linking
- Every piece of cited information must link to its source
- Attribute statements to individuals by name (no @ symbol on names themselves)
- Links follow the statement or are integrated into sentences
- Ensure readers can drill into source material for deeper context
Formal Tone & Authority
- Use complete, well-structured sentences
- Integrate all references and links seamlessly without extraneous formatting
- Write for educated, time-constrained readers
Workflow: GitHub Conversations
For GitHub issues, pull requests, and discussions:
Fetch the complete conversation using the github-interaction skill. This ensures you capture all comments, reviews, and state changes necessary for context.
Identify the narrative arc: What was the initial problem/request? How did the conversation evolve? What decisions were made?
Apply the rules from references/github-conversations.md, which details:
- How to structure GitHub-specific summaries
- Linking patterns for comments, events, and status changes
- Handling alternative solutions and partial resolutions
- Ignoring bot-generated events
Save the summary to the correct location (see "Output Location & Naming" section below)
Workflow: Meeting Transcripts
For Zoom, Teams, or other meeting transcripts:
Fetch the transcript from the provided URI using HTTP or platform-specific tools
Parse and prepare the transcript: Extract speaker attributions, timestamps, and key discussion points
Apply the rules from references/transcript-summaries.md, which details:
- Attribution patterns for named participants
- How to reference shared documents or screens
- Handling decisions and action items
- Appropriate scope and constraints for transcript summaries
Save the summary to Executive Summaries/YYYY-MM-DD/##.md (use today's date; sequential numbering within each date folder)
Quick Reference: Which Workflow?
| Source |
Use This Workflow |
Notes |
| GitHub issue, PR, discussion URL |
GitHub Conversations |
Fetch using github-interaction skill; apply GitHub-specific rules |
| Zoom/Teams transcript or recording URI |
Meeting Transcripts |
Fetch transcript; parse for speakers; apply transcript-specific rules |
| Email thread, Slack conversation |
GitHub Conversations (adapted) |
If available as a GitHub discussion or converted to one, use GitHub workflow; otherwise, treat as narrative text input |
Tips for Quality Summaries
- Start by understanding the arc: Skim the conversation or transcript to understand the trajectory before drafting
- Prioritize decision impact: What changed as a result of this conversation? Lead with that
- Use participant names strategically: Name decision-makers and key contributors; anonymize or skip minor commenters
- Link judiciously but comprehensively: Every claim should be traceable; avoid standalone links
- Edit for density: Remove connecting words, tighten sentences, but preserve clarity
1---2name: executive-summary3description: Create formal executive summaries from GitHub conversations or meeting transcripts. Use when generating leadership-ready summaries that distill key decisions, alternatives, outcomes, and next steps from complex conversations or meetings. Supports GitHub issues/PRs and transcript URIs (Zoom, Teams, etc.). Outputs are saved to Executive Summaries/ with date-organized structure.4---5
6# Executive Summary Skill
7
8Create formal, narrative-driven executive summaries for leadership and stakeholders. This skill handles two primary workflows: synthesizing GitHub conversations (issues, pull requests, discussions) and distilling meeting transcripts (Zoom, Teams, etc.) into concise, decision-focused summaries.
9
10## Related Skills
11
12**Use `brain-operating-system` skill** for:
13- Output directory structure and naming conventions (`Executive Summaries/YYYY-MM-DD/`)
14- Date folder creation patterns and file numbering
15
16**Use `voice-and-tone` skill** for:
17- Narrative construction and paragraph patterns
18- First-person framing when appropriate
19- Crediting collaborators and showing impact
20
21**Use `github-interaction` skill** for:
22- Fetching complete GitHub conversations (issues, PRs, discussions)
23- Comment and review retrieval patterns
24- Pagination handling
25
26## Core Principles
27
28All executive summaries follow these unifying principles, regardless of source:
29
30### Narrative-Driven Prose
31
32- Structure content as **dense, logically-connected paragraphs** in formal, authoritative tone
33- Avoid bullet points, subheaders, or lists
34- Each paragraph builds on the previous, conveying a cohesive narrative of evolution from initial topic through decisions and next steps
35- Limit length to **3–5 structured paragraphs** (GitHub summaries may run longer for complex decisions)
36
37### Impact & Decision Focus
38
39- Include **only details that significantly influenced direction, decisions, or outcomes**
40- Omit administrative commentary, routine pleasantries, subscription messages, procedural remarks, superficial technical minutiae (code diffs, exact timestamps), or automation events
41- Center on **key debates, decisions, constraints, resolutions, and business/user impact**
42- Clearly articulate **alternatives explored, current status, next steps, and individual responsibilities**
43
44### Contextual Linking
45
46- Every piece of cited information must link to its source
47- Attribute statements to individuals by name (no @ symbol on names themselves)
48- Links follow the statement or are integrated into sentences
49- Ensure readers can drill into source material for deeper context
50
51### Formal Tone & Authority
52
53- Use complete, well-structured sentences
54- Integrate all references and links seamlessly without extraneous formatting
55- Write for educated, time-constrained readers
56
57## Workflow: GitHub Conversations
58
59For GitHub issues, pull requests, and discussions:
60
611. **Fetch the complete conversation** using the [`github-interaction` skill](../github-interaction/SKILL.md). This ensures you capture all comments, reviews, and state changes necessary for context.
62
632. **Identify the narrative arc**: What was the initial problem/request? How did the conversation evolve? What decisions were made?
64
653. **Apply the rules from [references/github-conversations.md](references/github-conversations.md)**, which details:
66 - How to structure GitHub-specific summaries
67 - Linking patterns for comments, events, and status changes
68 - Handling alternative solutions and partial resolutions
69 - Ignoring bot-generated events
70
714. **Save the summary** to the correct location (see "Output Location & Naming" section below)
72
73## Workflow: Meeting Transcripts
74
75For Zoom, Teams, or other meeting transcripts:
76
771. **Fetch the transcript** from the provided URI using HTTP or platform-specific tools
78
792. **Parse and prepare the transcript**: Extract speaker attributions, timestamps, and key discussion points
80
813. **Apply the rules from [references/transcript-summaries.md](references/transcript-summaries.md)**, which details:
82 - Attribution patterns for named participants
83 - How to reference shared documents or screens
84 - Handling decisions and action items
85 - Appropriate scope and constraints for transcript summaries
86
874. **Save the summary** to `Executive Summaries/YYYY-MM-DD/##.md` (use today's date; sequential numbering within each date folder)
88
89## Quick Reference: Which Workflow?
90
91| Source | Use This Workflow | Notes |
92| --- | --- | --- |
93| GitHub issue, PR, discussion URL | GitHub Conversations | Fetch using `github-interaction` skill; apply GitHub-specific rules |
94| Zoom/Teams transcript or recording URI | Meeting Transcripts | Fetch transcript; parse for speakers; apply transcript-specific rules |
95| Email thread, Slack conversation | GitHub Conversations (adapted) | If available as a GitHub discussion or converted to one, use GitHub workflow; otherwise, treat as narrative text input |
96
97## Tips for Quality Summaries
98
99- **Start by understanding the arc**: Skim the conversation or transcript to understand the trajectory before drafting
100- **Prioritize decision impact**: What changed as a result of this conversation? Lead with that
101- **Use participant names strategically**: Name decision-makers and key contributors; anonymize or skip minor commenters
102- **Link judiciously but comprehensively**: Every claim should be traceable; avoid standalone links
103- **Edit for density**: Remove connecting words, tighten sentences, but preserve clarity
majiayu000