Document Templates

Document Templates

Generate structured documents based on best practices and industry standards.

Quick Start

Ask for a template by type:

• "Generate a meeting prep sheet"
• "Create an ADR for [decision]"
• "Generate a Design Doc for [feature]"

Templates are self-contained - no external files needed.

Available Templates

1. Meeting Preparation Sheet

When to use: Planning decision meetings, consultations, or information sharing sessions

What it includes:

• Meeting purpose classification
• Decision materials (background, problem, constraints)
• Options comparison table
• Recommendation framework

Usage: "Generate a meeting prep sheet for [decision/​consultation/​sharing]"

Template:

## Meeting Preparation Sheet

### Basic Information
- Meeting Purpose: [ ] Decision / [ ] Consultation / [ ] Information Sharing
- Participants:
- Duration: (minutes)
- Date: YYYY-MM-DD

### 1. Decision Materials

#### Background
- [Why is this meeting necessary?]
- [Current situation]

#### Problem
- [What problem needs to be solved?]
- [What decision needs to be made?]

#### Constraints
- Budget: [amount or "unlimited"]
- Timeline: [deadline]
- Resources: [team size, skills available]
- Compliance: [regulations, standards]

### 2. Options

| Option | Pros | Cons | Timeline | Cost |
|--------|------|------|----------|------|
| A:     |      |      |          |      |
| B:     |      |      |          |      |
| C:     |      |      |          |      |

### 3. Recommendation

Recommended: [Option X]

Reasons:
1. [Specific reason with evidence]
2. [Specific reason with evidence]
3. [Specific reason with evidence]

### 4. Preparation Checklist

Before the meeting:
- [ ] All participants have received background materials
- [ ] Options are clearly defined with pros/​cons
- [ ] Decision criteria are explicit
- [ ] Time allocation is planned (discussion: X min, decision: Y min)
- [ ] Follow-up actions are identified

### 5. Expected Outcomes

- [ ] Decision on [topic]
- [ ] Action items assigned
- [ ] Next steps defined

---

2. ADR (Architecture Decision Record)

When to use: Documenting significant technical decisions that affect architecture, technology choices, or system design

What it includes:

• Decision context and problem statement
• Considered alternatives with trade-offs
• Decision rationale
• Consequences (positive and negative)

Usage: "Create an ADR for [decision title]"

Best practices:

• Avoid vague expressions ("適切に", "柔軟に", "効率的に")
• Include specific trade-off analysis
• Document both positive and negative consequences
• Provide concrete examples and metrics

Template:

# ADR-XXX: [Decision Title]

**Date**: YYYY-MM-DD
**Status**: Proposed / Accepted / Rejected / Superseded
**Deciders**: [List of people involved in decision]

## Context

### Background
[Why is this decision necessary?]
[What is the current situation?]

### Problem Statement
[What specific problem needs to be solved?]
[What are the requirements?]

## Decision

[What was decided? State in 1-2 clear sentences]

## Considered Alternatives

### Option A: [Name]

**Pros**:
- [Specific advantage with evidence/​metrics]
- [Specific advantage with evidence/​metrics]

**Cons**:
- [Specific disadvantage with impact]
- [Specific disadvantage with impact]

**Cost**: [Initial + Ongoing costs]
**Timeline**: [Implementation time]

### Option B: [Name]

**Pros**:
- [Specific advantage]
- [Specific advantage]

**Cons**:
- [Specific disadvantage]
- [Specific disadvantage]

**Cost**: [Initial + Ongoing costs]
**Timeline**: [Implementation time]

### Option C: [Name]

[Same structure as above]

## Decision Rationale

[Why was this option chosen over alternatives?]

**Key factors**:
1. [Factor with specific reasoning]
2. [Factor with specific reasoning]
3. [Factor with specific reasoning]

**Trade-offs accepted**:
- [What we're giving up and why it's acceptable]

## Consequences

### Positive
- [Specific positive impact]
- [Specific positive impact]

### Negative
- [Specific negative impact and mitigation plan]
- [Specific negative impact and mitigation plan]

### Neutral
- [Changes that are neither clearly positive nor negative]

## Implementation Notes

[How will this decision be implemented?]
[Any migration plan needed?]

## Related Decisions

- ADR-XXX: [Related decision]
- [Links to related documentation]

## Review Date

[When should this decision be revisited?]

---

## Checklist

Before finalizing:
- [ ] All alternatives are documented with pros/​cons
- [ ] Decision rationale is specific and evidence-based
- [ ] Both positive and negative consequences are listed
- [ ] No vague expressions (check for "適切に", "柔軟に", etc.)
- [ ] Concrete metrics or examples are provided
- [ ] Related decisions are linked

---

3. Design Document

When to use: Designing new features, major refactorings, or system changes that require detailed planning

What it includes:

• Feature overview and goals
• Detailed design with architecture diagrams
• Alternatives considered
• Implementation and testing plan
• Rollout strategy

Usage: "Generate a Design Doc for [feature name]"

Best practices:

• Use diagrams (Mermaid recommended)
• Include concrete examples and use cases
• Define measurable success criteria
• Document risks and mitigation

Template:

# [Feature Name] Design Document

**Author**: [Name]
**Date**: YYYY-MM-DD
**Reviewers**: [Names]
**Status**: Draft / In Review / Approved
**Last Updated**: YYYY-MM-DD

## Overview

[3-sentence summary of the feature]

**TL;DR**: [One sentence describing the feature and its value]

## Background

### Context
[Why is this feature needed?]
[What problem does it solve?]

### Current State
[What is the current situation?]
[What are the pain points?]

## Goals and Non-Goals

### Goals
- [Specific, measurable goal]
- [Specific, measurable goal]
- [Specific, measurable goal]

### Non-Goals
- [What this design explicitly does NOT aim to do]
- [What is out of scope]

### Success Metrics
- [Measurable metric: e.g., "Reduce latency to <200ms"]
- [Measurable metric: e.g., "Handle 10K requests/​sec"]
- [Measurable metric: e.g., "99.9% uptime"]

## Detailed Design

### Architecture Overview

```mermaid
graph TD
    A[Component A] --> B[Component B]
    B --> C[Component C]

[Description of architecture]

Components

Component 1: [Name]

Responsibility: [What it does] Technology: [Tech stack] API: [Key interfaces]

Component 2: [Name]

[Same structure]

API Design

Endpoint 1

POST /​api/​v1/​resource
Content-Type: application/​json

{
  "field": "value"
}

Response:

{
  "id": "123",
  "status": "created"
}

Data Model

CREATE TABLE resources (
  id UUID PRIMARY KEY,
  name VARCHAR(255),
  created_at TIMESTAMP
);

Data Flow

sequenceDiagram
    User->>API: Request
    API->>Database: Query
    Database->>API: Result
    API->>User: Response

Security Considerations

• [Authentication/​Authorization approach]
• [Data encryption (at rest, in transit)]
• [Input validation]
• [Rate limiting]

Alternatives Considered

Alternative 1: [Name]

Description: [Brief description]

Pros:

• [Advantage]
• [Advantage]

Cons:

• [Disadvantage]
• [Disadvantage]

Why not chosen: [Specific reason]

Alternative 2: [Name]

[Same structure]

Implementation Plan

Phase 1: [Name] (Week 1-2)

• Task 1
• Task 2
• Task 3

Phase 2: [Name] (Week 3-4)

• Task 1
• Task 2

Dependencies

• [External dependency 1]
• [External dependency 2]

Testing Strategy

Unit Tests

• [What will be unit tested]
• [Target coverage: e.g., 80%]

Integration Tests

• [What will be integration tested]
• [Test scenarios]

End-to-End Tests

• [Critical user flows]

Performance Tests

• [Load testing plan]
• [Expected metrics]

Rollout Plan

Stage 1: Internal Testing (Week 1)

• Deploy to staging
• Internal dogfooding
• Performance validation

Stage 2: Beta Release (Week 2)

• 10% of users
• Feature flag: enable_new_feature
• Monitoring dashboard

Stage 3: General Availability (Week 3)

• 100% rollout
• Monitoring and alerts

Rollback Plan

[How to rollback if issues arise]

Risks and Mitigation

Open Questions

• Question 1: [Unresolved item requiring discussion]
• Question 2: [Unresolved item requiring discussion]

Appendix

References

• [Related design docs]
• [External documentation]
• [Research papers]

Glossary

• Term 1: Definition
• Term 2: Definition

---

Checklist

Before review:

• All sections are complete
• Architecture diagrams are included
• API examples are concrete and executable
• Success metrics are measurable
• Alternatives are documented with reasoning
• Security considerations are addressed
• Testing strategy is comprehensive
• Rollout plan includes monitoring and rollback

---

## Usage Examples

### Example 1: Meeting Prep

**Request**: "Generate a meeting prep sheet for deciding on database technology"

**Output**: Complete meeting prep sheet with:
- Purpose: Decision
- Decision materials section for database context
- Options table for PostgreSQL/​MongoDB/​etc.
- Recommendation framework

### Example 2: ADR

**Request**: "Create an ADR for adopting PostgreSQL"

**Output**: Complete ADR with:
- Context about database requirements
- Alternatives (PostgreSQL, MongoDB, MySQL, DynamoDB)
- Trade-off analysis
- Decision rationale with specific metrics
- Consequences (positive: ACID compliance; negative: higher ops complexity)

### Example 3: Design Doc

**Request**: "Generate a Design Doc for user authentication system"

**Output**: Complete Design Doc with:
- Overview of authentication needs
- Architecture with JWT tokens
- API design for login/​logout/​refresh
- Security considerations
- Implementation phases
- Testing strategy

## Best Practices

### Do
- Fill in all sections (don't leave placeholders)
- Use specific, measurable criteria
- Include concrete examples
- Provide diagrams for complex systems
- Document trade-offs explicitly

### Don't
- Use vague expressions ("適切に", "柔軟に", "効率的に")
- Skip alternatives analysis
- Omit negative consequences
- Leave questions unresolved without noting them
- Copy-paste without customization

## Integration with Other Skills

This skill works with:
- `document-quality`: Auto-reviews generated documents
- `tech-doc-reviewer`: Provides detailed feedback
- `principle-guide`: Helps make decisions for ADRs

## Success Criteria

A well-generated document has:
- Complete sections (no TODOs)
- Specific, actionable content
- Concrete examples and metrics
- Trade-offs explicitly documented
- Clear next steps