Documentation
- 1 installs
- 47 repo stars
- Updated July 29, 2026
- aws-samples/sample-claude-code-agent-team
Documentation is a Claude skill that provides technical writing patterns for READMEs, runbooks, and architecture docs with accuracy verification.
About
This skill provides technical writing patterns for READMEs, runbooks, and architecture documentation with accuracy verification. A developer uses it when writing docs, creating runbooks, or documenting system architecture. It supplies concrete templates (README structure, runbook, ADR, OpenAPI API docs) and points to supporting tools for diagrams and accuracy checks.
- Templates for READMEs, runbooks, ADRs, and OpenAPI-style API documentation
- Accuracy verification via context7 and a comment-analyzer plugin after writing docs
- Maps documentation ownership to devops, coding, and SA agents
Documentation by the numbers
- 1 all-time installs (skills.sh)
- Ranked #1,361 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
documentation capabilities & compatibility
- Capabilities
- documentation
- Works with
- github
- Use cases
- documentation
What documentation says it does
Technical writing patterns for READMEs, runbooks, and architecture docs, with accuracy verification.
Use OpenAPI/Swagger. Minimum per endpoint:
npx skills add https://github.com/aws-samples/sample-claude-code-agent-team --skill documentationAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| repo stars | ★ 47 |
| Last updated | July 29, 2026 |
| Repository | aws-samples/sample-claude-code-agent-team ↗ |
What it does
Write project READMEs, runbooks, ADRs, and architecture docs using structured templates.
Who is it for?
Writing documentation, creating runbooks, or documenting system architecture.
When should I use this skill?
A developer is writing a README, runbook, ADR, or architecture documentation.
What you get
Produces structured READMEs, runbooks, ADRs, and API docs and verifies their accuracy.
- README
- Runbook
- Architecture Decision Record
By the numbers
- 4 documentation templates (README, runbook, ADR, API)
Files
Documentation
Use these patterns when writing documentation, creating runbooks, or documenting system architecture.
MCP Servers & Plugins
| Resource | When to Use |
|---|---|
deploy-on-aws diagram skill | Generate architecture diagrams for system documentation and runbooks |
deploy-on-aws:awsknowledge | Reference AWS service docs when writing architecture docs or runbooks — use read_documentation, search_documentation, and recommend to link to official docs rather than paraphrasing |
awslabs.document-loader-mcp-server | Load external reference documents (PDFs, web pages) as source material for documentation |
aws-serverless plugin | Use get_lambda_guidance and get_serverless_templates to document serverless patterns, Lambda configurations, and SAM deployment steps |
databases-on-aws plugin | Use dsql_search_documentation and dsql_recommend to document DSQL schema design, query patterns, and migration procedures |
context7 MCP | Look up library/framework docs to verify technical accuracy in README examples |
pr-review-toolkit:comment-analyzer plugin | After writing any documentation — verifies accuracy, staleness risk, and maintainability |
github plugin | Link to issues, PRs, and discussions from documentation. Create issues for documentation gaps |
README Structure
# Project Name
One-line description of what this does.
## Quick Start
\`\`\`bash
npm install
npm start
\`\`\`
## Configuration
| Variable | Description | Default |
|----------|-------------|---------|
| PORT | Server port | 3000 |
## Usage
[Examples of common operations]
## Development
[How to set up dev environment, run tests]
## License
MITAPI Documentation
Use OpenAPI/Swagger. Minimum per endpoint:
- HTTP method and path
- Request parameters (path, query, body)
- Response codes and schemas
- Authentication requirements
- Example request/response
Runbook Template
# [Service Name] Runbook
## Overview
What this service does, who owns it.
## Architecture
[Use `deploy-on-aws` diagram skill to generate architecture diagram]
## Health Checks
- Endpoint: `GET /health`
- Expected: 200 OK
## Common Issues
### Issue: High latency
**Symptoms**: Response times > 500ms
**Diagnosis**: Check DB connections, cache hit rate
**Resolution**: Scale horizontally, clear cache
## Escalation
- L1: On-call engineer
- L2: Service owner
- L3: Platform teamArchitecture Decision Record (ADR)
# ADR-001: Use PostgreSQL for user data
## Status
Accepted
## Context
Need persistent storage for user accounts.
## Decision
Use PostgreSQL on RDS.
## Consequences
- Pro: ACID compliance, familiar tooling
- Con: Operational overhead vs DynamoDBSpec Artifact Documentation
When documenting within the spec-driven workflow, these artifacts have defined formats (see spec-workflow skill):
| Artifact | Owner | Purpose |
|---|---|---|
spec.md | fullstack-agent | Design decisions, constraints, alternatives considered |
design.md | fullstack-agent | Architecture, repo structure, infrastructure design |
tasks.md | fullstack-agent (authored), all teammates (updated) | Parallelized task groups with completion notes |
review.md | review-agent | Severity-rated findings with PASS/FAIL verdict |
sa-review.md | sa-agent | Well-Architected findings by pillar, cost estimates |
decisions.md | any agent via fullstack-agent | Mid-flight decisions to prevent re-litigation |
When writing documentation for a project that uses the spec workflow, link to relevant specs rather than duplicating their content.
Agent Integration
devops-agentowns READMEs, runbooks, and architecture docs — keeps them next to the code they describecoding-agentwrites inline documentation (function/class/module docs) during implementation- Both agents delegate to
pr-review-toolkit:comment-analyzerafter writing docs to verify accuracy sa-agentproduces architecture review documentation in Well-Architected pillar format, claims and tracks tasks like other teammates- Use
githubplugin to create issues for documentation that needs future updates (e.g., after API changes)
Writing Tips
- Lead with the "what" and "why"
- Use concrete examples over abstract explanations
- Keep it scannable (headers, bullets, tables)
- Update docs when code changes (or automate it)
- Docs are concise and actionable — no filler
- Use the
deploy-on-awsdiagram skill for architecture diagrams — don't describe what a diagram can show - Use
awslabs.document-loader-mcp-serverto load external specs or references rather than copy-pasting content
Related skills
Lark MarkdownInstantly turn any markdown file into clean, formatted Lark/Figma-compatible documents without manual reformatting.488k
Lark DocCreate, read, update, summarize, rewrite and manage Feishu/Lark cloud documents directly from agent workflows.401k16.1kLark WikiCreate, organize, query, and manage documents, spaces, and members inside Lark (Feishu) knowledge bases directly from AI agent workflows.397k16.1k
Domain ModelingBuild and sharpen a project's domain model: pin down domain terminology in a glossary and record architectural decisions as ADRs.318k202k
Opensource Guide CoachGet expert, attribution-safe guidance on launching and sustaining an open-source project.270k71Readme I18nMaintain consistent, updatable language selector blocks across every README variant in a multilingual repository.270k71FAQ
What documentation formats does it cover?
READMEs, runbooks, architecture decision records, and OpenAPI/Swagger API documentation.
How does it verify accuracy?
It delegates to a comment-analyzer plugin after writing docs and uses context7 to verify library and framework examples.