docs-adr

Capture architecture decisions and ADRs with context, decision, and consequences.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/claushaas/claus-haas-ai-stuff --skill docs-adr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: docs-adr
Source: https://github.com/claushaas/claus-haas-ai-stuff/tree/main/skills/docs-adr
Command: npx skills add https://github.com/claushaas/claus-haas-ai-stuff --skill docs-adr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill consolidates architecture decisions and ADRs into clear, decision-oriented documentation, preserving rationale and context across future work.

Core Features & Use Cases

  • ADR creation and maintenance for significant architectural decisions.
  • Documentation alignment with code changes, features, and system evolution.
  • Use Case: when a design choice impacts APIs, data flows, or deployment, capture decision details and rationale for future maintainers.

Quick Start

Create a new ADR entry with a concise title, include context, decision, and consequences, and save it to the ADR repository. Example: "ADR: Adopt new caching strategy for API layer" and fill sections accordingly.

Frequently Asked Questions about docs-adr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
What is an architecture decision record and when should I create one?

An architecture decision record (ADR) captures significant design choices, preserving context and rationale. Create an ADR when a design change impacts APIs, data flows, or system deployment to ensure traceable decisions across projects.

How do I document architecture decisions to maintain project rationale?

To document architecture decisions, create an ADR entry with a concise title and fill sections for context, decision, and consequences. This captures decision details and rationale for future maintainers as system evolution occurs.

What is the best way to capture lightweight architecture governance documentation?

The best way to capture architecture governance is using ADRs to consolidate design decisions into clear, decision-oriented records. This satisfies requirements for both formal ADRs and lightweight decision history.

Does this approach work for tracking design decisions during feature introduction?

Yes, capturing architecture decisions applies directly to feature introductions and design changes. Documenting decisions during feature introduction ensures that the rationale remains traceable across future work and system evolution.

When should I not use a formal ADR for software engineering documentation?

You should not use a formal ADR for routine, reversible code changes that do not impact APIs, data flows, or deployment. ADRs are reserved for significant architectural decisions where preserving rationale and context is necessary.