documentation-and-adrs
Records decisions and documentation. Use when you need to document an architecture decision (ADR) or the reasoning behind a design choice, when changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
- Kind
- Skill
- Works with
- Claude Code, Codex, Any agent
- Source
- addyosmani/agent-skills @ 2686b620fc1f
- Path
- skills/documentation-and-adrs/SKILL.md
- License
- MIT
- Jobs
- Documentation
InstallCopy it from the source repository, or sign in and let the assistant adapt it for your project.
# Documentation and ADRs ## Overview Document decisions, not just code. The most valuable documentation captures the *why* — the context, constraints, and trade-offs that led to a decision. Code shows *what* was built; documentation explains *why it was built this way* and *what alternatives were considered*. This context is essential for future humans and agents working in the codebase. ## When to Use - Making a significant architectural decision - Choosing between competing approaches - Adding or changing a public API - Shipping a feature that changes user-facing behavior - Onboarding new team members (or agents) to the project - When you find yourself explaining the same thing repeatedly **When NOT to use:** Don't document obvious code. Don't add comments that restate what the code already says. Don't write docs for throwaway prototypes. ## Architecture Decision Records (ADRs) ADRs capture the reasoning behind significant technical decisions. They're the highest-value documentation you can write. ### When to Write an ADR - Choosing a framework, library, or major dependency - Designing a data model or database schema - Selecting an authentication strategy …