Decision Log

The problem

Engineering and ops teams often lose the "why" behind technical choices, leading to repetitive debates or accidental reversals. Traditional ADRs frequently suffer from "architecture astronautics," becoming bloated with diagrams and non-functional requirements that obscure the actual decision.

What it does

• Extracts specific technical context and candidate options from raw developer dumps or notes.
• Enforces a strict requirement for at least two sourced alternatives to ensure a real choice was made.
• Generates dated, role-attributed ADRs in Markdown format without inventing "do-nothing" filler or dates.
• Identifies gaps like contradictions in the source material or attempts to include out-of-scope architectural diagrams.
• Manages a local decisions.md log, appending new records while maintaining a clear audit trail.

Frameworks & tools

This skill is framework-agnostic. It outputs standard GitHub-flavored Markdown for use in docs/ folders, Git repositories, or engineering wikis.

Why this beats prompting it yourself

General-purpose prompts often hallucinate "standard" options like "do nothing" or invent dates and stakeholders to look complete. This skill uses a strict binding and freezing procedure that refuses to invent data, ensuring your logs reflect reality rather than LLM assumptions.

Use cases

• Logging the selection of a specific database or cloud provider from raw meeting notes.
• Documenting infrastructure changes where exactly one choice was made between two specific tools.
• Capturing the rationale for a breaking API change before the context is lost.

Known limitations

Requires an ISO date, a specific decision title, and a defined role. It will block execution if the source material contains only one option or contradictory winners.