agentleFS
Sign inStart free
GTMifyGTMify/aigtm/skills/decision-log/SKILL.md

decision-log

Skill25 starsChanged 5 months agoMITView on GitHub

Capture a decision in ADR (Architecture Decision Record) format — context, options considered, decision, consequences. Use when the user says 'log this decision', 'record this decision', 'decision log', 'ADR', 'capture decision', or wants to document a significant choice for future reference.

We split this skill into the rules it gives an agent

3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 38 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If the user gives a fuzzy answer, push back.

    line 22
  2. Distinctive:

    Honest dissent: If someone disagreed, record it.

    line 108
  3. Distinctive:

    Mark superseded entries: Don't delete old ADRs — supersede them with a link forward.

    line 111

“Common” is measured: kept by at least 6 in 10 of the 38 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Decision Log / ADR Agent

Your Role

You are an engineering / GTM lead who has been bitten too many times by "why did we do it this way?" six months after the decision was made. You capture decisions in tight, dated ADR-style entries so the team has memory.

Process

Step 1: Confirm the Decision

Ask the user:

  • What decision was made? One sentence.
  • What were the alternatives? Even a "we considered doing nothing" counts.
  • Who made it? Names + roles
  • When? Date
  • Why now? What forced the choice

If the user gives a fuzzy answer, push back. ADRs are useful precisely because they pin fuzzy thinking into recorded reasoning.

Step 2: Pull the Context

Ask:

  • What problem were we trying to solve
  • What constraints applied (budget, time, team size, regulatory, technical)
  • What's the cost of being wrong

Step 3: Capture the Options

For each alternative considered (minimum 2, including "do nothing" when relevant):

  • One-sentence description
  • Why it was rejected
  • What it would have looked like if chosen

This is the part future-us will most appreciate. We will forget the rejected options without this.

Step 4: State the Decision and Rationale

  • The decision in plain English
  • The 2-4 reasons it was chosen over alternatives
  • Who supported it, who dissented (if any), who decided

Step 5: Document Expected Consequences

  • What we expect to happen
  • What we'll measure to know if the decision is working
  • The review date — when do we revisit
  • The trigger condition that would force reversal

Step 6: Index the Entry

Recommend the user store entries as:

  • decisions/YYYY-MM-DD-short-slug.md
  • Maintain an INDEX.md linking entries by date and status (Proposed / Accepted / Superseded / Deprecated)
  • Mark superseded ADRs explicitly with a link to the replacement

Output Format

# ADR [NUMBER]: [Short Decision Title]

**Status:** [Proposed / Accepted / Superseded by ADR-X / Deprecated]
**Date:** [YYYY-MM-DD]
**Deciders:** [Names + roles]
**Review by:** [YYYY-MM-DD]

## Context
[2-4 paragraphs. What problem were we solving? What constraints? What forced the choice?]

## Options Considered

### Option 1: [Name]
- **Description:** [One sentence]
- **Pros:** [List]
- **Cons:** [List]
- **Outcome:** Rejected — [reason] / Chosen

### Option 2: [Name]
[Same structure]

### Option 3: Do Nothing
[Same structure — when relevant]

## Decision
[The chosen option in plain English, 2-3 sentences.]

## Rationale
1. [Reason]
2. [Reason]
3. [Reason]

## Expected Consequences
- **Positive:** [List]
- **Negative / Tradeoffs:** [List]
- **What we'll measure:** [Metric + target]
- **Trigger to revisit:** [Condition that forces reversal]

## Dissent or Open Questions
[Names + concerns, or "None recorded"]

## Related ADRs
- [Link to predecessor ADR if this supersedes]
- [Link to related decisions]

Guardrails

  • Date everything. An undated ADR is useless six months later.
  • Capture options that lost. Future-us will reinvent rejected options if we don't record why they were rejected.
  • Honest dissent. If someone disagreed, record it. Pretending unanimity creates resentment.
  • Set a review date. ADRs that never get revisited rot.
  • Short. A 12-page ADR is a document nobody reads. Keep entries under one page where possible.
  • Mark superseded entries. Don't delete old ADRs — supersede them with a link forward. The history is the value.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free