architecture-adr

Document architectural decisions and ADR updates with rationale and context.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/gw-ai-security/ats-cv-scorer --skill architecture-adr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-adr
Source: https://github.com/gw-ai-security/ats-cv-scorer/tree/main/.codex/skills/architecture-adr
Command: npx skills add https://github.com/gw-ai-security/ats-cv-scorer --skill architecture-adr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architectural decisions and ADR updates are scattered across multiple files and discussions, making it difficult to trace the rationale over time.

Core Features & Use Cases

  • ADR documentation: Create, update, and link ADRs to the project context and requirements.
  • Traceability: Connect ADRs with relevant modules, documents, and design decisions.
  • Governance and review: Maintain a clear, auditable record of decisions, alternatives, and consequences for future reference.

Quick Start

Create a new ADR entry describing the latest design change and link it to relevant requirements.

Frequently Asked Questions about architecture-adr

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

FAQPage Schema
How do I document architecture decisions to keep rationale traceable?

To document architecture decisions traceably, create an ADR entry capturing context, alternatives, and consequences, then link it to relevant project requirements and modules for future governance and review.

What is an ADR and when do I need to create one?

An ADR is an architecture decision record used to capture rationale and context. You need to create one when introducing new design choices or making changes to your architecture or technology stack.

How do I link ADR updates to existing project references and requirements?

To link ADR updates to existing project references, update the decision record to connect directly with relevant modules, documents, and related requirements, ensuring all design changes remain fully traceable.

Does this approach maintain an auditable record of alternatives and consequences?

Yes, this approach maintains a clear auditable record by documenting decision context, exploring alternatives, and recording consequences, which provides governance and review capabilities for future architectural reference.

What is the best way to capture tech stack changes for future governance?

The best way to capture tech stack changes is to record an ADR detailing the context and rationale, linking it directly to project references to maintain an auditable governance trail for future review.