documentation-and-adrs

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

5|Updated Mar 5, 2024
One-click install
npx skills add https://github.com/TRAPZZY/God-Eyes --skill documentation-and-adrs-trapzzy
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/TRAPZZY/God-Eyes/tree/main/.skills/documentation-and-adrs
Command: npx skills add https://github.com/TRAPZZY/God-Eyes --skill documentation-and-adrs-trapzzy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering decisions lose their context over time, leaving future developers and AI agents unable to understand why code was built a certain way. This Skill captures the reasoning behind architectural choices, API designs, and feature changes so that knowledge persists beyond the original author's memory. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Provides a structured template with context, decision, alternatives considered, and consequences, stored in docs/decisions/ with sequential numbering and a proposed-to-accepted lifecycle. - Inline and API Documentation: Guides writing comments that explain why rather than what, JSDoc-style function documentation, and OpenAPI/Swagger specs for REST endpoints. - README and Changelog Standards: Defines a README structure covering quick start, commands, and architecture, plus a changelog format for shipped features. - Use Case: After choosing PostgreSQL over MongoDB for a new service, use this Skill to write ADR-001 documenting the requirements, rejected alternatives, and consequences so the team never re-litigates the decision. ## Quick Start Write an ADR documenting the decision to use FastAPI for the backend, including the alternatives considered and their trade-offs.

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?▼

Write an ADR with sections for status, date, context, decision, alternatives considered, and consequences. Store it in docs/decisions/ with sequential numbering like ADR-001, and never delete old records since they preserve historical context.

When should I write an ADR for a project?▼

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.

What should code comments explain according to best practices?▼

Comments should explain why the code exists, not what it does. Document non-obvious intent, constraints, and known gotchas, while avoiding comments that restate self-explanatory code or leftover TODOs.

Should old ADRs be deleted when a decision changes?▼

No, old ADRs should never be deleted because they capture historical context. When a decision changes, write a new ADR that references and supersedes the previous one, following the proposed to accepted to superseded lifecycle.

What sections 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 covering coding standards and the PR process.