fastapi-adr-generator

Solid

Use when the user wants to record an architectural decision — drafting an Architecture Decision Record (ADR) or RFC, documenting a design choice and its trade-offs, or capturing why an approach was taken. Detects the repo's existing ADR location and template style (MADR or Nygard) and matches it; if none exists, sets one up. Writes the record; it does not change code.

AI & Automation 11 stars 0 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 79/100

Stars 20%
36
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

You are drafting an Architecture Decision Record. An ADR captures one decision: the context that forced it, the choice made, and the consequences accepted. Follow these phases. --- ## Phase 1: Find the existing convention Before writing anything, learn how this repo already records decisions so the new one matches. - Look for an ADR directory: `docs/adr/`, `docs/decisions/`, `docs/architecture/decisions/`, `adr/`, or `rfcs/`. Use Glob/Grep. - If records exist, read the two most recent. Match their template (MADR vs Nygard), heading style, status vocabulary, and filename scheme (`NNNN-title.md` is the common one). - Determine the next sequence number from the highest existing file. - If no ADR directory exists, default to `docs/adr/` with the MADR template below and start at `0001`. Tell the user you're establishing the convention. Do not invent a second competing format when one is already in use. ## Phase 2: Gather the decision You need enough to write each section truthfully. If the user's request already supplies it, don't re-ask — proceed. Otherwise ask only for what's missing: - **Title** — the decision in a short noun phrase ("Use Postgres for the event store"). - **Context** — the forces in play: the problem, constraints, and what made a decision necessary now. - **Options considered** — the alternatives and why each was or wasn't chosen. - **Decision** — the option taken. - **Consequences** — what this makes easier, what it makes harder, and any follow-up work...

Details

Author
steph-dove
Repository
steph-dove/klaussy-agents
Created
4 months ago
Last Updated
yesterday
Language
Python
License
MIT

Integrates with

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Listed

create-adr

Record an architecture/design decision as an ADR (Architecture Decision Record) in the target repository's docs/adr/. Use when the user wants to document a design decision, its alternatives and consequences, or says "record this decision" / "write an ADR".

1 Updated today
atman-33
AI & Automation Solid

adr-generator

Create comprehensive Architectural Decision Records (ADRs). Researches the destination directory to detect existing template conventions, gathers context, determines next ADR number, generates the ADR, validates completeness, and saves. Supports multiple ADR formats (MADR, Nygard, Alexandrian, project canonical). Use when documenting technical decisions, creating new ADR files, or capturing rationale so future readers can revisit a choice. Use when you say "write an ADR", "document this decision", "document these design choices", "record why we chose this", "capture the rationale", or "for future maintainers", or when creating an ADR-like markdown file under docs/decisions/, docs/adr/, docs/architecture/, architecture/decisions/, or .agents/architecture/. Do NOT use to debate or review an existing ADR (use adr-review).

38 Updated today
rjmurillo
DevOps & Infrastructure Solid

adr

Capture architectural decisions as structured ADRs (Architecture Decision Records). Use when user says 'record this decision', 'ADR this', 'why did we choose X', 'document this trade-off', 'we decided to...', or when a significant choice is made between alternatives (framework, database, pattern, API design, infra approach).

6 Updated 5 days ago
anmolnagpal