documentation-and-adrs

Write architecture decision records, API documentation, READMEs, and changelogs for codebases.

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill documentation-and-adrs-kunj-sharma03
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/Kunj-Sharma03/agent-contextify/tree/main/templates/skills/documentation-and-adrs
Command: npx skills add https://github.com/Kunj-Sharma03/agent-contextify --skill documentation-and-adrs-kunj-sharma03

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code shows what was built but not why it was built that way. This Skill captures the reasoning behind architectural decisions, API designs, and project conventions so future engineers and AI agents understand the context, constraints, and rejected alternatives behind the codebase. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Write numbered ADRs with context, decision, alternatives considered, and consequences, while matching any existing project convention for location, numbering, and format. - Inline and API Documentation: Add comments that explain intent rather than restating code, plus JSDoc-style annotations and OpenAPI specs for public interfaces. - Project Documentation: Structure READMEs with quick start and commands, maintain changelogs, and keep agent-facing rules files like CLAUDE.md current. - Use Case: After choosing PostgreSQL over MongoDB for a new service, use this Skill to write an ADR documenting the requirements, the alternatives evaluated, and the consequences so the decision is never re-debated months later. ## Quick Start Write an ADR documenting the decision to use PostgreSQL with Prisma as the primary database for this project.

Frequently Asked Questions about documentation-and-adrs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write an architecture decision record?

An ADR documents the status, date, context, decision, alternatives considered, and consequences of a significant technical choice. Store it as a numbered Markdown file, for example in docs/decisions/, and mark superseded decisions rather than deleting them.

When should I write an ADR?

Write an ADR when choosing frameworks or major dependencies, designing data models, selecting authentication strategies, deciding API architecture, or making any decision that would be expensive to reverse. Trivial or easily reversible choices do not need one.

What should code comments explain?

Comments should explain why code behaves a certain way, not restate what it does. Document non-obvious intent, known gotchas, and constraints, and avoid TODO comments for work you should do now or commented-out dead code.

Should I match an existing ADR format in my project?

Yes. Before creating an ADR, inspect the repository for existing ADRs, an .adr-dir file, or related tooling, and match the established directory, numbering sequence, filename pattern, and section headings rather than introducing a new scheme.

When should I not write documentation?

Skip documentation for self-explanatory code, throwaway prototypes, and comments that merely restate what the code already says. Documentation earns its place when it captures intent, trade-offs, or context that the code cannot express.