aoa-adr-write

Capture architectural decisions and store them in the repository's ADR directory.

4|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/8Dionysus/aoa-skills --skill aoa-adr-write
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: aoa-adr-write
Source: https://github.com/8Dionysus/aoa-skills/tree/main/.agents/skills/aoa-adr-write
Command: npx skills add https://github.com/8Dionysus/aoa-skills --skill aoa-adr-write

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Teams often lose the rationale behind structural, tooling, or workflow changes, making future maintenance and onboarding difficult. This skill ensures those decisions are clearly recorded, placed in a canonical location, and kept in sync with the actual code changes.

Core Features & Use Cases

  • Decision Capture: Record the context, options, chosen path, and tradeoffs of an architectural or workflow decision.
  • Canonical Placement: Automatically store the ADR in the repository’s decision surface for easy discovery.
  • Verification: Validate that the documented decision aligns with the associated code changes and is reachable from the expected location.
  • Use Case: When introducing a new build system or refactoring a core module, use this skill to document why the change was made and ensure the ADR lives in the project's docs/adr directory.

Quick Start

Use the aoa-adr-write skill to record a new architectural decision and place it in the canonical ADR directory.

Frequently Asked Questions about aoa-adr-write

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

FAQPage Schema
How do I document architectural decisions to preserve the rationale for future contributors?

To document architectural decisions, you need to record the context, options, chosen path, and tradeoffs in an Architecture Decision Record. This creates a searchable record that preserves the rationale behind structural, tooling, or workflow changes for future maintenance and onboarding.

When should I create an ADR for my project?

You should create an ADR when structural, tooling, or process changes require a clear record. Apply this practice when introducing a new build system or refactoring a core module to ensure the decision context and tradeoffs are documented.

How do I verify that an ADR aligns with the actual code changes in my repository?

To verify an ADR aligns with code changes, validate that the documented decision is kept in sync with the implementation. This verification process checks that the recorded rationale matches the actual structural modifications and is reachable from the expected location.

What is the best way to store ADRs so they are easily discoverable by the team?

The best way to store ADRs is by placing them in the repository's canonical decision surface, such as a dedicated docs/adr directory. This ensures the architectural documentation is automatically stored in a location for easy discovery by contributors.

Does this ADR generation process require any specific formatting dependencies?

No specific dependencies are required to generate ADRs. The process focuses on capturing the decision context and placing the concise record directly into the repository's decision surface without relying on external components.