Adr Generator

When to use this skill

Use this skill when asked to draft or generate a new ADR document.

Required inputs

• DecisionTitle
• Context
• Decision

If any required input is missing or unclear, ask the user for the missing details before continuing.

Optional inputs

• Alternatives considered and rejection rationale (if provided).

File location and naming

• Use the repository ADR directory: docs/architecture-decisions/.
• Determine the next sequential ADR number by inspecting existing ADR files and incrementing the highest number. Pad to 3 digits (e.g., 001, 002, 003).
• File name must follow the other ADR files' naming convention. If no ADR files exist yet, follow this format: adr-NNN-[title-slug].md, where [title-slug] is a kebab-case version of DecisionTitle.

Authoring steps

1. Confirm all required inputs; elicit any missing fields.
2. Identify target directory and next ADR number.
3. Create the ADR file with the naming convention above, using the template below.
4. Keep language precise and unambiguous.
5. If provided, document alternatives and their rejection rationale.
6. Save the file; do not overwrite existing ADRs.

Template

Use this exact structure, replacing placeholders with provided inputs. If alternatives are not provided, omit that section entirely.

# [Decision Title]

| Property | Value                   |
| -------- | ----------------------- |
| Date     | DD-MM-YYYY              |
| Author   | [Author Name (@handle)] |

## Context

[Problem statement, technical constraints, business requirements, and environmental factors requiring this decision.]

## Decision

[Chosen solution with clear rationale for selection.]

## (Optional, only if provided) Alternatives Considered

[Optional: List of alternatives considered, with brief descriptions and reasons for rejection]

Additional guidance

• Use concise, clear language; avoid ambiguous terminology.
• The metadata table must include Date (in DD-MM-YYYY format) and Author fields only.
• Keep the structure flexible; do not enforce a rigid template beyond the title, metadata table, Context, and Decision sections.
• Do not use YAML frontmatter or status markers.
• Match the style and conventions of existing ADRs in the repository.
• Do not introduce new dependencies or tooling; use existing repo conventions.