AI Prompts for Documentation

You are a technical writer creating API documentation for {{api_name}}.

For each endpoint below, produce documentation in this format:

## {{METHOD}} {{path}}

**Description:** One-sentence summary of what this endpoint does.

**Authentication:** {{auth_type}}

**Request:**
- Headers (required and optional)
- Path parameters with types and constraints
- Query parameters with defaults
- Request body schema (JSON) with field descriptions

**Response:**
- Success response (status code + example JSON)
- Error responses (each status code + example body + when it occurs)

**Example:**
A complete curl command and its response.

Endpoints to document:
{{endpoint_list}}

Write for an audience of {{audience}} developers. Use precise language. Every field must have a type annotation. Include rate limit info if applicable.

Write a README.md for {{project_name}}, a {{project_type}} that {{one_sentence_purpose}}.

Structure:
1. **Title + badges** (build status, version, license)
2. **One-paragraph overview** — what it does, who it's for, and why it exists
3. **Quickstart** — get from zero to working in under 5 minutes. Include:
   - Prerequisites ({{prerequisites}})
   - Installation (exact commands)
   - Minimal working example with expected output
4. **Configuration** — table of environment variables / config options with defaults
5. **Usage examples** — 3 real-world use cases with code
6. **API reference** — if applicable, link or inline the key functions/methods
7. **Contributing** — how to set up a dev environment, run tests, submit a PR
8. **License** — {{license_type}}

Tech stack: {{tech_stack}}
Target audience: {{audience}}

Write in a direct, friendly tone. Avoid filler. Every section must be useful on its own.

You are a release manager writing a changelog entry for version {{version}} of {{project_name}}.

Below is the raw list of commits/PRs since the last release:
{{commit_list}}

Produce a changelog in Keep a Changelog format:

## [{{version}}] - {{release_date}}

Group entries into these categories (omit empty categories):
### Added — new features
### Changed — changes to existing functionality
### Fixed — bug fixes
### Deprecated — features that will be removed
### Removed — features removed in this release
### Breaking Changes — anything that requires user action to upgrade

For each entry:
- Write one clear sentence from the user's perspective (not developer perspective)
- Reference the PR/issue number in parentheses if available
- For breaking changes, include a migration note: what to change and why

Audience: {{audience}}
Tone: Professional but concise. No marketing language.

Write an Architecture Decision Record (ADR) for the following decision:

**Title:** {{decision_title}}
**Context:** {{project_context}}
**Decision date:** {{date}}
**Status:** {{status}} (Proposed | Accepted | Deprecated | Superseded)

Use this structure:

## ADR-{{number}}: {{decision_title}}

### Context
Describe the forces at play — technical constraints, business requirements, team capabilities, timeline pressure. What problem are we solving?

### Decision
State the decision clearly in one sentence, then explain the reasoning. Include:
- Options considered (at least {{num_options}} alternatives)
- Evaluation criteria used (e.g., performance, maintainability, cost, team expertise)
- Tradeoffs table: option vs. criteria matrix
- Why the chosen option won

### Consequences
- **Positive:** What this enables
- **Negative:** What this costs or limits
- **Risks:** What could go wrong and how we will monitor for it

### Alternatives Rejected
For each rejected option, one sentence on why it was ruled out.

The alternatives considered were:
{{alternatives}}

Technical context:
{{technical_details}}

Create an operational runbook for handling {{incident_type}} in {{system_name}}.

Audience: On-call engineers who may not be familiar with this system.

## Runbook: {{incident_type}}

### 1. Detection
- How this incident is typically detected (alerts, dashboards, user reports)
- Key metrics to check: {{key_metrics}}
- Dashboard links: {{dashboard_links}}

### 2. Severity Assessment
Define severity levels for this incident type:
| Severity | Criteria | Response Time |
|----------|----------|---------------|
| P1 | ... | ... |
| P2 | ... | ... |
| P3 | ... | ... |

### 3. Immediate Actions (first 5 minutes)
Step-by-step commands/actions. Each step must include:
- The exact command or action
- Expected output
- What to do if the output is unexpected

### 4. Investigation
- Common root causes ranked by frequency
- Diagnostic queries/commands for each
- How to identify which root cause applies

### 5. Resolution
For each common root cause, provide:
- Fix steps (exact commands)
- Verification that the fix worked
- Rollback procedure if the fix makes things worse

### 6. Post-Incident
- Who to notify: {{stakeholders}}
- Data to collect for the post-mortem
- Follow-up items to create

Environment: {{environment}}
Infrastructure: {{infrastructure}}

Create a developer onboarding guide for new engineers joining the {{team_name}} team working on {{project_name}}.

Assume the new hire has experience with {{assumed_skills}} but no prior context on this project.

## Week 1: Getting Oriented

### Day 1 — Environment Setup
- Step-by-step local development setup (repo clone to first successful build)
- Access requests needed: {{access_list}}
- Tools to install and configure
- Verification: how to confirm everything works

### Day 2-3 — Codebase Tour
- Architecture overview (explain the system in 3 levels of detail: 1 sentence, 1 paragraph, 1 page)
- Key directories and what lives in each
- The 5 most important files to read first and why
- Data flow: how a {{typical_request}} travels through the system

### Day 4-5 — First Contribution
- Suggested starter tasks: {{starter_tasks}}
- How to run tests locally
- PR process and review expectations
- Deploy process and how to verify in staging

## Week 2-4: Building Context
- Key domain concepts and terminology glossary
- Team rituals (standups, planning, retros) and what to expect
- Who to ask about what (people directory by area of expertise)
- Common gotchas that trip up every new hire
- Reading list: {{key_documents}}

Write in a welcoming, practical tone. Prioritize "do this" over "understand this."