agileflow-adr

Convert discussed architectural decisions into MADR-formatted ADR files.

7|1|Updated Oct 16, 2025
One-click install
npx skills add https://github.com/xloxn69/AgileFlow --skill agileflow-adr
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: agileflow-adr
Source: https://github.com/xloxn69/AgileFlow/tree/main/skills/agileflow-adr
Command: npx skills add https://github.com/xloxn69/AgileFlow --skill agileflow-adr

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Key architectural and technical decisions are often lost or poorly documented, leading to re-debates, inconsistent patterns, and a critical lack of historical context for future teams.

Core Features & Use Cases

  • Automated ADR Generation: Detects decision discussions and formats them into formal Architecture Decision Records (ADRs).
  • Context & Trade-offs: Documents the problem, decision drivers, considered options, and consequences (positive and negative).
  • Use Case: Your team is debating between PostgreSQL and MongoDB for the primary database. This skill captures the discussion, documents the pros and cons of each, and records the final decision with its justification, creating a transparent and durable record.

Quick Start

Use the agileflow-adr skill to document our decision to use React for the frontend, outlining the alternatives and trade-offs.

Frequently Asked Questions about agileflow-adr

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

FAQPage Schema
How do I document architectural decisions from team discussions?

Architecture Decision Records (ADRs) capture architectural choices by documenting the problem, considered options, decision drivers, and consequences. This skill detects decision discussions in conversations and automatically formats them into structured MADR-formatted ADRs with a clear problem statement, trade-offs analysis, and final decision status, stored under docs/03-decisions/.

What goes into an Architecture Decision Record?

An ADR includes the problem statement, decision drivers (what factors influenced the choice), all considered options, consequences (positive and negative outcomes), and decision status. This skill generates these sections automatically from conversation context, ensuring trade-offs and justifications are explicitly recorded for future reference.

When should I use ADRs instead of just documenting decisions in wikis or chat?

ADRs prevent re-debated decisions and knowledge loss by creating a formal, timestamped record with structured context: options considered, rationale, and consequences. Use them for technology choices (PostgreSQL vs MongoDB), architecture patterns (REST vs GraphQL), and framework decisions (React vs Vue) where historical reasoning matters for future teams.

Can I use this skill to document decisions about infrastructure choices?

Yes. This skill applies to infrastructure and framework decisions including cloud providers (AWS vs GCP), databases, APIs, and build tools. It detects these debates in conversation and generates formal ADRs that capture the trade-offs and decision drivers behind your infrastructure selections.

Does this skill require any setup or dependencies before generating ADRs?

No external dependencies are required. The skill detects architectural discussions directly from conversations and generates MADR-formatted ADRs automatically. It requests user confirmation before writing files to docs/03-decisions/, giving you control over the final ADR creation.

How do trade-offs get documented in the ADR output?

This skill captures trade-offs by documenting each option's pros and cons in the decision drivers and consequences sections. It records what was considered, why alternatives were rejected, and what positive and negative outcomes result from the chosen decision, creating transparent reasoning for architectural choices.