/exec-summary Skill

SkillDocs & knowledge

Generate non-technical executive summary from technical notes

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the /exec-summary Skill skill

What this skill tells your AI

The instructions your AI receives, as published by davidroliverba/architectkb in .claude/skills/exec-summary/SKILL.md and read by ahel’s review.

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

/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:

# 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:

# 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:

/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:

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

Creates: Page - Executive Summary - API Gateway.md

Signals

GitHub stars
52
Forks
12
Last commit
Mar 2026
Advanced
Catalog kind
skill
Gateway key
exec-summary
Source
github.com/davidroliverba/architectkb