documentation-and-adrs

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

1|Updated May 29, 2026
One-click install
npx skills add https://github.com/memasanz/agent-harness --skill documentation-and-adrs-memasanz
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/memasanz/agent-harness/tree/main/.github/skills/documentation-and-adrs
Command: npx skills add https://github.com/memasanz/agent-harness --skill documentation-and-adrs-memasanz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering decisions and their rationale are often lost, forcing future developers and AI agents to re-litigate settled choices or guess at constraints. This Skill captures the why behind architectural decisions, APIs, and features so context survives team changes. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Provides a full ADR template with status lifecycle, alternatives analysis, and consequences, stored in docs/decisions/ with sequential numbering. - Inline and API Documentation: Guides when to comment (the why, not the what), documents known gotchas, and covers TypeScript doc comments plus OpenAPI/Swagger specs for REST APIs. - Project Documentation: Supplies README structure, changelog format, and agent-facing documentation conventions (CLAUDE.md, spec files). - Use Case: After choosing PostgreSQL over MongoDB for a new service, use this Skill to write ADR-001 capturing the context, rejected alternatives, and consequences so future engineers understand the decision. ## 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?

Create a Markdown file in docs/decisions/ with sequential numbering, covering Status, Date, Context, Decision, Alternatives Considered, and Consequences. Document why each alternative was rejected so future readers understand the trade-offs.

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 expensive to reverse. Skip ADRs for trivial or easily reversible choices.

Should old ADRs be deleted when decisions change?

No, never delete old ADRs since they capture historical context. When a decision changes, write a new ADR that references and supersedes the old one, following the PROPOSED to ACCEPTED to SUPERSEDED lifecycle.

What code comments should I write versus avoid?

Comment the why, not the what: explain non-obvious intent, constraints, and known gotchas. Avoid comments that restate the code, stale TODOs for work you should do now, and commented-out code that git history already preserves.

How do I document a public REST API?

For TypeScript, use inline doc comments with param, returns, throws, and example annotations. For REST APIs generally, maintain an OpenAPI/Swagger specification describing endpoints, request bodies, response schemas, and error codes.