AgentSkillsCN

Exec Summary

从技术性笔记中生成非技术性的高管摘要

SKILL.md
--- frontmatter
skill: exec-summary
description: Generate non-technical executive summary from technical notes
context: fork
arguments:
  - name: note
    description: Note title or path to summarise
    required: true
  - name: audience
    description: Target audience (optional - exec, manager, stakeholder)
    required: false

/exec-summary Skill

Generate a non-technical executive summary from technical ADRs, Pages, or Project notes.

Purpose

Translate technical architecture content for non-technical stakeholders. Useful for:

  • •Board presentations
  • •Stakeholder updates
  • •Management briefings
  • •Cross-team communication

Usage

code
/exec-summary "ADR - API Gateway Selection"
/exec-summary "Project - AIIncidentProcessor" exec
/exec-summary "Page - Kafka Integration" manager

Instructions

  1. •

    Read the source note completely

  2. •

    Identify the audience (default: exec):

    • •exec - C-suite, board level (business impact, risk, cost)
    • •manager - Department heads (operational impact, timeline, resources)
    • •stakeholder - Project stakeholders (what changes, how affects them)
  3. •

    Extract key information:

    For ADRs:

    • •What decision was made (one sentence)
    • •Why it matters to the business
    • •What it costs / saves
    • •Key risks and mitigations
    • •Timeline / when it takes effect

    For Projects:

    • •What the project delivers
    • •Business benefit
    • •Current status (RAG)
    • •Key milestones
    • •Resources / budget

    For Pages:

    • •What this document describes
    • •Why it matters
    • •Key takeaways
    • •Actions required (if any)
  4. •

    Generate summary using this template:

markdown
# Executive Summary: {{Title}}

**Generated:** {{date}}
**Source:** [[{{source note}}]]
**Audience:** {{audience}}

---

## One-Line Summary

{{Single sentence explaining what this is about in business terms}}

## Why This Matters

{{2-3 sentences on business impact - avoid technical jargon}}

## Key Points

- {{Point 1 - business language}}
- {{Point 2 - business language}}
- {{Point 3 - business language}}

## Impact

| Area | Impact |
|------|--------|
| **Cost** | {{cost impact or "No direct cost impact"}} |
| **Timeline** | {{when does this happen}} |
| **Risk** | {{key risk in plain language}} |
| **Benefit** | {{main business benefit}} |

## Recommendation / Decision

{{What was decided or what action is recommended - one paragraph}}

## Questions This Answers

- {{Question a stakeholder might ask}}
- {{Another likely question}}

---

*This summary was generated from technical documentation. For full details, see [[{{source note}}]].*
  1. •Translation rules (technical → business language):
Technical TermBusiness Translation
APISystem connection / interface
DatabaseData storage
CloudOnline infrastructure
MicroservicesModular system design
LatencyResponse time / speed
ScalabilityAbility to grow
RedundancyBackup systems
MigrationSystem move / upgrade
IntegrationConnecting systems
AuthenticationSecurity / login
EncryptionData protection
AI/MLAutomated intelligence
DevOpsDelivery automation
KubernetesContainer management
KafkaMessage system
  1. •Tone guidelines:
    • •Active voice ("We will..." not "It has been decided...")
    • •Short sentences (max 20 words)
    • •No acronyms without explanation
    • •Focus on outcomes, not process
    • •Quantify where possible (£, %, dates)

Example Output

Input: /exec-summary "ADR - Use PostgreSQL for Customer Data"

Output:

markdown
# Executive Summary: Database Selection for Customer Services

**Generated:** 2026-01-11
**Source:** [[ADR - Use PostgreSQL for Customer Data]]
**Audience:** Executive

---

## One-Line Summary

We're using PostgreSQL as our database for all customer transaction records in the new cloud system.

## Why This Matters

This decision affects how we store and protect customer payment data. PostgreSQL provides the financial-grade security we need while reducing our monthly infrastructure costs by approximately £700 compared to alternatives.

## Key Points

- Customer transaction data will be stored securely with bank-level protection
- Our team already has the skills to manage this system (no additional training needed)
- We can scale to handle 10 million records in the first year without changes

## Impact

| Area | Impact |
|------|--------|
| **Cost** | £2,400/month (£700 saving vs alternative) |
| **Timeline** | Implementation begins Q2 2026 |
| **Risk** | Low - proven technology, team expertise |
| **Benefit** | Secure, cost-effective data storage |

## Recommendation / Decision

Use PostgreSQL on AWS for all customer-facing transaction data. This gives us the security guarantees we need for financial data while leveraging existing team skills and keeping costs competitive.

## Questions This Answers

- How are we protecting customer payment data?
- What's the cost of the new database system?
- Do we have the skills to support this?

---

*This summary was generated from technical documentation. For full details, see [[ADR - Use PostgreSQL for Customer Data]].*

Multiple Notes

To summarise multiple related notes:

code
/exec-summary "Project - Cloud Migration" with-adrs

This will:

  1. •Read the project note
  2. •Find all linked ADRs
  3. •Generate a combined executive summary

Output Location

By default, outputs to conversation. To save as a note:

code
/exec-summary "ADR - API Gateway" --save

Creates: Page - Executive Summary - API Gateway.md