demo-skill

SKILL.md

---
name: demo-doc-generator
description: Generate well-structured technical documents, reports, and summaries with consistent formatting. Use this skill whenever the user asks to write a technical document, API reference, project report, feature spec, meeting minutes, or any structured professional document — even if they just say "help me write a doc" or "create a report". This skill ensures every document is clear, organized, and ready to use.
---

# Demo Document Generator

A skill for generating clean, professional documents with consistent structure.

## When to apply this skill

Use this skill for:
- Technical specifications and feature docs
- Project reports and status updates
- API or module documentation
- Meeting minutes and decision logs
- README files and onboarding guides

## Document Generation Workflow

1. **Understand the document type** — identify what kind of document is needed and who will read it
2. **Gather key information** — ask only the essential questions (purpose, audience, main content points); don't over-ask
3. **Choose the right template** — pick from the templates below based on type
4. **Write the draft** — fill in the template with real content, not placeholder text
5. **Review for clarity** — ensure each section adds value; cut anything redundant

## Templates

### Technical Specification

```
# [Feature/Component Name]

## Overview
One paragraph describing what this is and why it exists.

## Goals
- [Goal 1]
- [Goal 2]

## Non-Goals
- [What this explicitly does NOT cover]

## Design / Approach
Describe the solution, key decisions, and rationale.

## API / Interface (if applicable)
Show the interface, endpoints, or data models.

## Open Questions
- [Unresolved items]

## References
- [Links to related docs or tickets]
```

### Project Status Report

```
# [Project Name] — Status Update ([Date])

## Summary
One sentence on overall health: 🟢 On track / 🟡 At risk / 🔴 Blocked

## Progress This Period
- [Completed item 1]
- [Completed item 2]

## Next Steps
- [Planned item 1]
- [Planned item 2]

## Risks & Blockers
| Issue | Impact | Owner | Status |
|-------|--------|-------|--------|

## Metrics (if applicable)
| Metric | Target | Actual |
|--------|--------|--------|
```

### Meeting Minutes

```
# Meeting: [Topic] — [Date]

**Attendees:** [Names]
**Facilitator:** [Name]

## Agenda
1. [Item 1]
2. [Item 2]

## Discussion & Decisions
### [Topic 1]
- Discussion: ...
- Decision: ...

## Action Items
| Action | Owner | Due |
|--------|-------|-----|
| [Task] | [Name] | [Date] |

## Next Meeting
[Date, time, agenda preview]
```

### README / Onboarding Guide

```
# [Project Name]

> [One-line tagline]

## What is this?
Brief description — what problem does it solve?

## Quick Start
```bash
# Installation and first run
```

## Usage
Core usage examples with real commands or code.

## Configuration
Key options and how to set them.

## Contributing
How to get started contributing.

## License
[License type]
```

## Writing Principles

- **Lead with the "why"** — readers should immediately understand the purpose
- **Use concrete examples** — show real values, real code, real names; avoid `foo/bar` placeholders
- **Keep sections lean** — one section = one idea; if a section feels thin, fold it into another
- **Tables over lists** for structured comparisons; bullet lists for independent items
- **Active voice** — "The API returns X" not "X is returned by the API"

## Output Format

Always produce the document as a markdown code block so it's easy to copy. If the user seems to want a file saved to disk, write it as a `.md` file in the current directory and tell them where it is.