sickn33/agentic-awesome-skills/documentation-and-adrs
Claude Code and agent skill by sickn33/agentic-awesome-skills
- community
Checking that the SKILL.md file is still in the repository.
Records decisions and documentation. Use when making architectural decisions, changing public APIs, shipping features, or when you need to record context that future engineers and agents will need to understand the codebase.
Install
npx vskill@latest install sickn33/agentic-awesome-skills/documentation-and-adrsSKILL.md
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
- Deciding on an API architecture (REST vs. GraphQL vs. tRPC)
- Choosing between build tools, hosting platforms, or infrastructure
- Any decision that would be expensive to reverse
ADR Template
Follow the repository's existing ADR location and numbering; use docs/decisions/ only if no convention exists. The following decision and alternatives are fictional project assumptions, not universal database rankings:
ADR Lifecycle
- Don't delete old ADRs. They capture historical context.
- When a decision changes, write a new ADR that references and supersedes the old one.
Inline Documentation
When to Comment
Comment the why, not the what:
When NOT to Comment
Document Known Gotchas
API Documentation
For public APIs (REST, GraphQL, library interfaces):
Inline with Types (Preferred for TypeScript)
OpenAPI / Swagger for REST APIs
README Structure
Every project should have a README that covers:
Changelog Maintenance
For shipped features:
Documentation for Agents
Special consideration for AI agent context:
- CLAUDE.md / rules files — Document project conventions so agents follow them
- Spec files — Keep specs updated so agents build the right thing
- ADRs — Help agents understand why past decisions were made (prevents re-deciding)
- Inline gotchas — Prevent agents from falling into known traps
Common Rationalizations
| Rationalization | Reality | |
|---|---|---|
| "The code is self-documenting" | Code shows what. It doesn't show why, what alternatives were rejected, or what constraints apply. | |
| "We'll write docs when the API stabilizes" | APIs stabilize faster when you document them. The doc is the first test of the design. | |
| "Nobody reads docs" | Agents do. Future engineers do. Your 3-months-later self does. | |
| "ADRs are overhead" | A 10-minute ADR prevents a 2-hour debate about the same decision six months later. | |
| "Comments get outdated" | Comments on why are stable. Comments on what get outdated — that's why you only write the former. |
Red Flags
- Architectural decisions with no written rationale
- Public APIs with no documentation or types
- README that doesn't explain how to run the project
- Commented-out code instead of deletion
- TODO comments that have been there for weeks
- No ADRs in a project with significant architectural choices
- Documentation that restates the code instead of explaining intent
Verification
Validate statements against actual code and test output. Draft unresolved decisions as Proposed; do not infer team acceptance. OpenAPI and TypeScript snippets below are excerpts with intentionally omitted schemas/implementations, not standalone runnable files.
After documenting:
- [ ] ADRs exist for all significant architectural decisions
- [ ] README covers quick start, commands, and architecture overview
- [ ] API functions have parameter and return type documentation
- [ ] Known gotchas are documented inline where they matter
- [ ] No commented-out code remains
- [ ] Rules files (CLAUDE.md etc.) are current and accurate
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
Security
- Security scanPassed, 95 of 100Pattern checks on the skill's files.
- Model reviewPassed
Quality evaluation
- Task evaluationNot runNo evaluation yet. Run one in Skill Studio.
Source
- SKILL.md in the repositoryCheckingskills/documentation-and-adrs/SKILL.md
Popularity
- Repository stars
- 47,056
- Repository forks
- 6,853
- 7-day trend score
- 54
Stars and forks are for the whole GitHub repository, not this skill alone. Not refreshed yet.
Works with
Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.
- Claude Code
- Cursor
- GitHub Copilot
- Windsurf
- Codex
- Gemini CLI
- Cline
- Amp
- Roo Code
- Goose
- Continue
- Kilo Code
- Junie
- Trae
- OpenHands
- Qwen Code
- AI Agent
- Tabnine Chat
- Sourcegraph Cody
- Amazon Q
- Firebase Genkit
- Sweep
- Devin
- Phind
- Mentat
- Claude Desktop
- Aider
- GPT Pilot
- Plandex
- bolt.new
- v0
- Replit Agent
- Anse
- TypingMind
- BetterChatGPT
- LibreChat
- Warp AI
- Pieces
- Fig AI
Embed badge
[](https://verified-skill.com/skills/sickn33/agentic-awesome-skills/documentation-and-adrs)