documentation-and-adrs

Writes ADRs, decisions log entries, and API documentation for software projects.

Updated Jun 13, 2026
One-click install
npx skills add https://github.com/22Teikk/22Teikk-Agent-Skills-Hub --skill documentation-and-adrs-22teikk
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/22Teikk/22Teikk-Agent-Skills-Hub/tree/main/core/skills/documentation-and-adrs
Command: npx skills add https://github.com/22Teikk/22Teikk-Agent-Skills-Hub --skill documentation-and-adrs-22teikk

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Engineering decisions lose their context over time — future engineers and AI agents cannot tell why the codebase was built a certain way, leading to repeated debates and reversed decisions. This Skill captures the reasoning behind architectural choices, API changes, and shipped features in durable, queryable documentation. ## Core Features & Use Cases - Architecture Decision Records (ADRs): Generates sequentially numbered ADRs in .teikk/adr/ with context, alternatives considered, and consequences, following a PROPOSED → ACCEPTED → SUPERSEDED lifecycle. - Decisions Log: Maintains an append-only .teikk/DECISIONS.md for significant implemented decisions, queryable via scripts/decisions.js (list, find, count, JSON output) so you can check whether a topic was already decided before writing a new entry. - Inline and API Documentation: Provides standards for KDoc comments, OpenAPI specs, README structure, and changelogs that explain the why rather than restating code. - Use Case: After choosing Room over SharedPreferences for local storage in an Android project, run this Skill to log the trade-off in DECISIONS.md and write ADR-004 so no one re-litigates the choice six months later. ## Quick Start Ask the agent to record the architectural decision you just made as an ADR and add a corresponding entry to the decisions log.

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 (ADR)?▼

Create a sequentially numbered Markdown file in .teikk/adr/ with sections for Status, Date, Context, Decision, Alternatives Considered, and Consequences. Never delete old ADRs — when a decision changes, write a new ADR that supersedes the old one.

When should I write an ADR versus a decisions log entry?▼

Write a full ADR for decisions that are expensive to reverse, like choosing a database, framework, or API architecture. Use the lightweight DECISIONS.md log for significant implemented decisions that need only 4-6 lines of context, and link to the ADR when one exists.

How do I check if a decision was already made in a project?▼

Run node scripts/decisions.js find <topic> to search every field of the decisions log, or use list and count for an overview. The script reads .teikk/DECISIONS.md by default and supports --json output for tooling.

What code comments should I write and which should I 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.

When should I not write documentation?▼

Skip documentation for obvious self-explanatory code, throwaway prototypes, and routine implementation choices like variable naming or minor refactors. Over-logging small changes devalues the decisions log and creates maintenance burden.