documentation-and-adrs

Record architectural decisions and supporting documentation for future engineers and AI agents.

42|3|Updated May 8, 2026
One-click install
npx skills add https://github.com/KevinKE93/Dev_Agent_OPC --skill documentation-and-adrs-kevinke93
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: documentation-and-adrs
Source: https://github.com/KevinKE93/Dev_Agent_OPC/tree/main/dev-agent/skills/documentation-and-adrs
Command: npx skills add https://github.com/KevinKE93/Dev_Agent_OPC --skill documentation-and-adrs-kevinke93

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It solves the problem of losing the “why” behind engineering choices, which makes future changes slower, riskier, and harder for both humans and AI agents to execute correctly.

Core Features & Use Cases

  • Architecture Decision Records (ADRs): Capture context, constraints, alternatives, and consequences for significant decisions like dependencies, API architecture, and infrastructure choices.
  • Inline and Agent-Focused Documentation: Document non-obvious gotchas and keep agent rules/specs aligned so agents don’t repeat prior reasoning or fall into known traps.
  • API and README Documentation Standards: Ensure public interfaces and onboarding materials include the essentials (quick start, commands, architecture overview, and rationale links).

Use it when you are preparing to ship a feature that changes user-facing behavior, updating or changing a public API, or making a major architectural decision that will be costly to reverse later.

Quick Start

Use the documentation-and-adrs skill to produce an ADR for your next architectural change by capturing the decision, context, alternatives considered, and consequences.

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 ADR for a new architecture decision?

To write an ADR, capture the decision context, constraints, alternatives considered, and consequences to preserve the rationale for future engineers and AI agents.

When do I need to document architecture decisions for my codebase?

You need to document architecture decisions when shipping user-facing behavior changes, updating public APIs, selecting frameworks, or making major infrastructure choices that are costly to reverse.

How do I document API changes and known gotchas for agent onboarding?

Document API changes and known gotchas by maintaining README and API documentation standards, ensuring quick start guides, commands, architecture overviews, and rationale links remain discoverable.

Why do I need to record architecture decisions for future engineers?

Recording architecture decisions solves the problem of losing the why behind engineering choices, which makes future changes slower, riskier, and harder for both humans and AI agents to execute correctly.

What's the best way to keep AI agents from repeating prior reasoning in active codebases?

The best way to prevent AI agents from repeating prior reasoning is to document non-obvious gotchas and maintain aligned agent rules and specifications alongside your ADRs.

What should be included in API documentation for public interfaces?

API documentation for public interfaces should include essentials like quick start guides, commands, architecture overviews, and rationale links to ensure public interfaces and onboarding materials are complete.