documentation-and-adrs

Name: documentation-and-adrs
Availability: InStock
Author: sapatamuku-creator

Writes architecture decision records, API documentation, READMEs, and changelogs for software projects.

Updated May 13, 2026

Search Tags:#changelog #documentation #technical writing #adr #readme #architecture decisions #api documentation

Ready to run

npx skills add https://github.com/sapatamuku-creator/mastersapatamuku --skill documentation-and-adrs-sapatamuku-creator

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/sapatamuku-creator/mastersapatamuku/tree/main/releases/v2.7/.agents/skills/documentation-and-adrs
Command: npx skills add https://github.com/sapatamuku-creator/mastersapatamuku --skill documentation-and-adrs-sapatamuku-creator

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering decisions and their rationale are often lost, forcing future developers and AI agents to re-debate settled questions or guess why the codebase looks the way it does. This Skill captures the context, constraints, and trade-offs behind decisions in durable written form. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Write numbered ADRs with status, context, decision, alternatives considered, and consequences, while matching any existing project convention for location, numbering, and format. - Inline and API Documentation: Add why-focused code comments, JSDoc-style function documentation, and OpenAPI specs 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 future engineers understand the reasoning. ## Quick Start Write an ADR documenting the decision to use PostgreSQL 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 in docs/decisions/ with sequential numbering, or match your project's existing ADR convention for location and format.

When should I write an ADR?▼

Write an ADR when choosing frameworks, databases, authentication strategies, API architectures, or any decision expensive to reverse. Skip ADRs for trivial or easily reversible choices.

Should old ADRs be deleted when a decision changes?▼

No, old ADRs should be kept because they capture historical context. When a decision changes, write a new ADR that references and supersedes the previous one, following the lifecycle from 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 rather than restating what the code does. Avoid TODO comments for work you should do now and delete commented-out code instead of leaving it.

What should a project README include?▼

A README should include a one-paragraph project description, quick start steps, a commands table, an architecture overview linking to ADRs, and contributing guidelines. This gives new engineers and agents enough context to run and understand the project.