decisions

Record architectural decisions with context, alternatives, and rationale in docs/decisions.md.

48|8|Updated Oct 17, 2025
One-click install
npx skills add https://github.com/maragudk/skills --skill decisions
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: decisions
Source: https://github.com/maragudk/skills/tree/main/decisions
Command: npx skills add https://github.com/maragudk/skills --skill decisions

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill ensures that significant architectural and design decisions are consistently documented, providing a clear, chronological record of choices, their rationale, and evaluated tradeoffs, preventing knowledge loss and improving project clarity and maintainability.

Core Features & Use Cases

  • Structured Decision Logging: Records decisions in docs/decisions.md using a standardized format, including context, alternatives, and rationale.
  • Intelligent Triggering: Proactively suggests documenting decisions when major architectural choices are made (e.g., database selection, framework adoption).
  • Flexible Detail Levels: Adapts the level of detail for each entry, from brief summaries to comprehensive analyses of complex tradeoffs.
  • Use Case: During a discussion, the team decides to switch from a monolithic architecture to microservices. This skill prompts the user to record this decision, then guides them in documenting the context, alternatives considered, and the rationale for the microservices choice, creating a permanent, searchable record for future reference and onboarding.

Quick Start

Example of a detailed decision entry

2025-10-23: Choose SQLite for primary database

After evaluating PostgreSQL and SQLite, we chose SQLite for the following reasons:

Context: Need a reliable database for the application that handles moderate traffic (< 1000 concurrent users) and simple relational data.

Alternatives considered:

  • PostgreSQL: More features and better for high concurrency, but adds operational complexity
  • SQLite: Simpler deployment, embedded database, sufficient performance for our scale

Tradeoffs: SQLite has limitations with high write concurrency and some advanced features, but offers zero-configuration deployment and excellent read performance. Given our expected load and preference for operational simplicity, these tradeoffs favor SQLite.

Decision: Use SQLite with WAL mode enabled for improved concurrency. We can migrate to PostgreSQL later if scaling needs change.

Frequently Asked Questions about decisions

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

FAQPage Schema
How do I document architectural decisions systematically?

Document architectural decisions by recording them in a structured format within docs/decisions.md, capturing context, alternatives considered, tradeoffs, rationale, and the final decision. This creates a chronological, searchable record that preserves design reasoning and supports future onboarding and governance.

What should be included in an architectural decision entry?

Each decision entry must include title, description, context (the problem and constraints), alternatives evaluated, tradeoffs analyzed, rationale for the choice, date, and the final decision. This standardized format ensures completeness and makes decisions retrievable for downstream reference.

When should I log a decision versus skipping it?

Log decisions that materially affect long-term architecture—such as database systems, frameworks, core design patterns, and major structural changes. Document explicit requests to record a decision or proactively log when a choice creates dependencies that influence future development.

Can I apply different detail levels to different decisions?

Yes, decision entries adapt in detail—from brief summaries for minor choices to comprehensive analyses for complex tradeoffs affecting multiple systems. The format remains consistent while depth varies based on decision significance and complexity.

How does decision logging prevent knowledge loss on teams?

A chronological decisions log preserves the reasoning, context, and alternatives behind architectural choices, preventing institutional knowledge from leaving with team members. New contributors can understand past decisions without reconstructing the thought process.

What's the best way to migrate between databases while documenting the decision?

Record the migration decision by documenting the original database choice (context and rationale), the trigger for reconsideration, alternatives evaluated for the new system, tradeoffs of the migration, and the final decision. This maintains visibility into why the original choice was made and why it changed.