documentation-and-adrs

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

Updated Aug 22, 2026
One-click install
npx skills add https://github.com/MSC72m/DevForge --skill documentation-and-adrs-msc72m
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/MSC72m/DevForge/tree/main/skills/documentation-and-adrs
Command: npx skills add https://github.com/MSC72m/DevForge --skill documentation-and-adrs-msc72m

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, public API changes, and design trade-offs so future engineers and AI agents can understand the codebase without re-litigating settled choices. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Create sequentially numbered ADRs with status, context, decision, alternatives considered, and consequences, while matching any existing project convention for location, numbering, and headings. - Inline and API Documentation: Write why-focused comments, JSDoc/TSDoc annotations, and OpenAPI specifications for public interfaces. - Project Documentation: Structure READMEs with quick start and commands, and maintain changelogs for shipped features. - Use Case: After choosing PostgreSQL over MongoDB for a new service, use this Skill to write an ADR documenting the requirements, rejected alternatives, and consequences so the decision is never re-debated. ## Quick Start Write an ADR documenting the decision to use tRPC instead of REST for the new API, following the existing docs/decisions convention.

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 status, date, context, the decision, alternatives considered with rejection reasons, and consequences. Store it in docs/decisions with sequential numbering, or match the project's existing ADR convention for location and naming.

When should I write an ADR for a project?▼

Write an ADR when choosing frameworks, databases, authentication strategies, API architectures, or any decision expensive to reverse. Skip ADRs for obvious choices and throwaway prototypes.

Should I update or delete an old ADR when a decision changes?▼

Never delete old ADRs since they capture historical context. Write a new ADR that references and supersedes the old one, following the lifecycle PROPOSED to ACCEPTED to SUPERSEDED or DEPRECATED.

What code comments are worth writing?▼

Comment the why, not the what. Explain non-obvious intent, constraints, and known gotchas, but never restate self-explanatory code, leave stale TODOs, or keep commented-out code that git history already preserves.

How do I document a public API in TypeScript?▼

Use inline TSDoc annotations describing parameters, return values, thrown errors, and usage examples. For REST APIs, maintain an OpenAPI specification defining request bodies, response schemas, and status codes.