Help us improve
Share bugs, ideas, or general feedback.
From architecture-documentation
This skill should be used when creating presentation outlines or debrief documents for technical audiences (engineers, PMs, CTOs). It applies when the user needs to present project work, architecture decisions, POC results, or system redesigns. Triggers include requests like "prepare a debrief", "create a presentation outline", "help me present this to stakeholders", or "outline a walkthrough of the system".
npx claudepluginhub dha201/architecture-documentation-plugin --plugin architecture-documentationHow this skill is triggered — by the user, by Claude, or both
Slash command
/architecture-documentation:technical-debrief-outlineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill generates comprehensive, structured presentation outlines for technical debriefs. It produces documents optimized for presenting complex technical work to mixed audiences (engineers, PMs, executives) with the right level of detail, real examples, and visual diagrams.
Generates ADRs, changelogs, C4/Mermaid architecture diagrams, onboarding docs, stakeholder presentations, and HTML reports for knowledge engineering.
Generates slide deck presentations from briefs with optional research, outline approval, and PPTX export.
Generates self-contained HTML pages for technical diagrams, architecture reviews, diff reviews, plans, and comparisons. Renders complex tables as styled HTML instead of ASCII.
Share bugs, ideas, or general feedback.
This skill generates comprehensive, structured presentation outlines for technical debriefs. It produces documents optimized for presenting complex technical work to mixed audiences (engineers, PMs, executives) with the right level of detail, real examples, and visual diagrams.
Before creating the outline, gather essential information:
Meeting Details
Content Scope
Reference Materials
Use this standard structure:
## Document References
| Topic | Reference Document | Section |
|-------|-------------------|---------|
| Business Requirements | `docs/REQUIREMENTS.md` | Full document |
| Architecture | `docs/architecture.md` | System Overview |
| Output Examples | `reports/output_20260127/` | All files |
| Implementation | `src/module/` | Lines 100-150 |
---
## Section 1: Business Problem & Goals
> "One-sentence elevator pitch of what we're building and why."
### Key Points
**What we're building:**
- Point 1
- Point 2
**Business Goals:**
- Goal 1
- Goal 2
**Acceptance Criteria:**
- Criterion 1
- Criterion 2
---
## Section 2: Domain Context & Prerequisites
### 2A. [First Concept]
### 2B. [Second Concept]
### 2C. [Third Concept]
---
## Section 3: [Current State / POC] Walkthrough
### 3A. High-Level Architecture
### 3B. Output Example
### 3C. Challenges That Led to [Next Version]
---
## Section 4: [New Design / Solution] Architecture
### 4A. [Stage/Component 1]
### 4B. [Stage/Component 2]
### 4C. [Stage/Component 3]
### 4D. Summary: How [New] Solves [Old] Problems
---
## Section 5: Demo & Q&A
---
## Implementation Status
| Component | Status |
|-----------|--------|
| Feature 1 | **Implemented** |
| Feature 2 | **Planned** |
---
## APPENDIX A: Technical Deep Dive
(Detailed technical content for engineer follow-up)
Use inline // comments for annotations:
{
"bill_id": "HR-150", // Unique identifier for the bill
"congress": 118, // Session number (118th = 2023-2025)
"status": "Introduced", // Current legislative stage
"textVersions": {
"count": 3 // Number of versions for evolution analysis
}
}
Use blockquotes for key messages the presenter should say:
> "NRG's Legal team manually tracks legislative bills across 50 states.
> We're automating this with AI - from discovery to actionable recommendations."
Use tables for comparing concepts, versions, or approaches:
| Aspect | POC Approach | Production Approach |
|--------|--------------|---------------------|
| Token Usage | 60K per item | 31K per item (48% reduction) |
| Validation | None | Two-tier with fallback |
| Evidence | Black box | Full audit trail |
Include Mermaid diagrams for architecture sections:
flowchart TD
INPUT[Input Data] --> PROCESS[Processing Stage]
PROCESS --> OUTPUT[Output]
style INPUT fill:#4CAF50,color:#fff
style PROCESS fill:#2196F3,color:#fff
style OUTPUT fill:#9C27B0,color:#fff
classDiagram
class Component {
+field1: type
+field2: type
+method() returnType
}
flowchart TD
CHECK{Condition?}
CHECK -->|Yes| ACTION1[Action 1]
CHECK -->|No| ACTION2[Action 2]
Diagram Guidelines:
For every technical decision or feature, answer:
Example Pattern:
#### Problem: Token Cost Explosion
**The Issue:**
- Each version analyzed independently (no memory)
- 5 versions + 4 diffs = 9 separate analyses
- Each analysis ~6,700 tokens → 60,000+ tokens per item
**Why It's a Problem:**
- Cost: $0.10 per run becomes $1+ with many items
- Latency: 9 sequential calls = 45-90 seconds
- No efficiency gain from prior context
**Solution in v2:**
Sequential memory reduces to 31K tokens (48% savings)
Never use simplified or fake data. Always:
**Real Example from Production:**
> **Reference:** `reports/analysis_20260127/output.json` - Lines 1438-1495
> **Reference:** `src/analysis/scoring.py` lines 246-286 - stability formula
For each section, include questions the audience might ask:
**Questions We Can Answer:**
- Which facts led to this conclusion?
- What sources support this finding?
- What would falsify this interpretation?
- Which assumptions are critical?
After initial draft:
User provides feedback - typically section-by-section
Common refinements:
Handle outdated references:
The final document should be:
OUTLINE_DEBRIEF.md)docs/ directorydocs/data_examples/ or similarStore supporting reference files:
outline_template.md - Blank template with section placeholdersmermaid_patterns.md - Common diagram patterns for technical docsStore example data:
data_examples/ - Real API responses with inline commentssample_outputs/ - Example analysis outputs to reference