common-documentation

name	common-documentation
description	Write effective code comments, READMEs, and technical documentation following intent-first principles. Use when adding comments, writing docstrings, creating READMEs, or updating any documentation.
metadata	{"triggers":{"keywords":["comment","docstring","readme","documentation"]}}

Documentation Standards

Priority: P2 (MEDIUM)

1. Intent-First Comments

• Explain "Why" logic exists. Avoid "What" mechanics.
• Use triple-slash (Dart/Swift) or JSDoc (TS/JS) for public members.
• Delete commented-out code. Use Git history.
• Format: TODO(username): description. Link tickets.
• For retry backoff, explain that jitter prevents the thundering herd; document intent rather than restating the delay calculation.

2. README Structure

• Mission: Project purpose (one sentence).
• Onboarding: Prerequisites, installation, usage (exact).
• Maintenance: Document inputs/outputs, known quirks, fixes.
• Sync: Documentation ships with feature.

3. ADRs & Architecture

• ADRs: Document rationale for system changes in docs/adr/.
• Docstrings: Include Args, Returns, and Usage examples (>>>).
• Diagrams: Use Mermaid.js inside Markdown.

4. API Docs

• Use Swagger/OpenAPI for REST.
• Provide copy-pasteable examples for endpoints.
• Define contract before implementation.

Anti-Patterns

• No "what" comments: Explain intent. Refactor mechanics.
• No orphan TODOs: Require owner and ticket.
• No stale docs: Document during development.

Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:

• JSDoc
• Usage
• why