agentleFS
davekilleendavekilleen/Dex/.agents/skills/decision-log/SKILL.md

decision-log

Skill509 starsChanged 3 months agoMITView on GitHub

Capture an important decision with its context, options, rationale, and review date, then find it again when it matters.

46 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use pre-mortem, retrospective and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Ingramradical235Skill

    pre-mortem

    Pre-mortem analysis, scenario planning, future state narratives, and contingency frameworks. Use before finalizing any Strategy Kernel, when planning major initiatives, or when preparing Plan B triggers.

    Also in 3 projects that use this

  • MicrosoftSkill

    retrospective

    Review how work went and improve the next round. USE WHEN asked for a retro, delays, or process lessons. DO NOT USE for code review or transcript replay.

    Also in 4 projects that use this

  • Microsoft AzureSkill

    test

    Also in 3 projects that use this

  • HashiCorpSkill

    changelog

    Add a `.changelog/<PR_NUMBER>.txt` entry for a GitHub Pull Request, commit, and push.

    Also in 3 projects that use this

  • genomewalkerSkill

    learn

    Learn from web sources, generate SKILL.md, and store key patterns in soul memory. Trigger keywords: learn, skill-gen, web-learn, documentation, tutorial.

    Also in 3 projects that use this

  • photon-groveSkill

    unslop

    Detects and rewrites generic, overly polished, or AI-sounding prose while preserving meaning. Use when the user asks to "unslop", humanize, de-AI, tighten, or review whether writing sounds generated.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 0 are common, 14 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 39 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run inline in the current conversation by default, so this work can see what the user has already discussed, decided, or settled this …

    line 10
  2. Distinctive:

    Keep important decisions from disappearing into meetings, messages, or memory.

    line 18
  3. Distinctive:

    Use this for decisions that would be costly, confusing, or time-consuming to reconstruct later.

    line 20
  4. Distinctive:

    Before recording a new decision, search for the topic in:

    line 32
  5. Distinctive:

    If semantic search is available, use it to find decisions expressed in different words.

    line 39
  6. Distinctive:

    If anything important is missing, ask one question at a time.

    line 54
  7. Distinctive:

    Use the narrowest useful location:

    line 58
  8. Distinctive:

    If the best project is unclear → ask before filing it

    line 62
  9. Distinctive:

    Create the parent folder or file when it does not exist.

    line 64
  10. Very specific:

    If no review is needed, write Review: No planned review rather than leaving the field blank.

    line 88
  11. Distinctive:

    Keep the entry factual and compact.

    line 90
  12. Distinctive:

    If the decision creates follow-up work, offer to add the next action through the normal task flow.

    line 101
  13. Distinctive:

    Never rewrite an older entry to make history look cleaner

    line 111
  14. Distinctive:

    When a decision changes, add a new entry and link the earlier one

    line 112
  15. Distinctive:

    Keep sensitive personal details out unless the user explicitly wants them recorded

    line 114

“Common” is measured: kept by at least 6 in 10 of the 39 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
<!-- Generated from `.claude/skills/decision-log/SKILL.md` by `scripts/generate-agents-skills.py`. Do not edit. -->

Execution mode

Run inline in the current conversation by default, so this work can see what the user has already discussed, decided, or settled this session. Do not fork merely because this skill was selected. Only run in the background when the user explicitly asks for a background run or the host has already obtained a specific background-work approval for this run.

Purpose

Keep important decisions from disappearing into meetings, messages, or memory. Record what was decided, why it made sense at the time, and when it should be looked at again.

Use this for decisions that would be costly, confusing, or time-consuming to reconstruct later. Do not turn every small preference into a formal entry.

When to Use

  • The user says "we decided", "I chose", or "the call is"
  • A meeting ends with a meaningful choice
  • Several options were considered and the reasoning may matter later
  • A past decision is shaping today's work
  • The user asks why something was done

Step 1: Look for Relevant Past Decisions

Before recording a new decision, search for the topic in:

  1. The active project's files under 04-Projects/
  2. 06-Resources/Decisions/Decision_Log.md
  3. Recent meeting notes under 00-Inbox/Meetings/
  4. Related person or company pages when the decision concerns them

If semantic search is available, use it to find decisions expressed in different words. Otherwise use a careful text search.

Surface a past decision only when it is genuinely relevant. Say what was decided, when, and whether the new choice confirms, changes, or replaces it.

Step 2: Confirm the Decision

Gather the minimum information needed for a useful record:

  • Decision: the choice in one clear sentence
  • Context: what made the choice necessary
  • Options considered: the real alternatives, including keeping things as they are when relevant
  • Rationale: why this option won
  • Review date: a date or a clear statement that no review is needed
  • Related work: project, goal, people, company, or meeting

If anything important is missing, ask one question at a time. Do not invent options or reasoning the user did not give.

Step 3: Choose the Right Home

Use the narrowest useful location:

  • A decision that belongs to one active project → append to that project's Decisions.md
  • A decision that applies across projects or to the user's wider work → append to 06-Resources/Decisions/Decision_Log.md
  • If the best project is unclear → ask before filing it

Create the parent folder or file when it does not exist. Append to an existing file; never replace earlier decisions.

Step 4: Write the Entry

Use this structure:

## YYYY-MM-DD — Decision title

**Decision:** One sentence stating the choice.

**Context:** The situation, constraint, or question that prompted it.

**Options considered:**
- Option A — the main benefit or trade-off
- Option B — the main benefit or trade-off

**Rationale:** Why this choice made the most sense with the information available.

**Review:** YYYY-MM-DD — what would justify revisiting it

**Related:** [[Project, goal, meeting, person, or company]]

If no review is needed, write **Review:** No planned review rather than leaving the field blank.

Keep the entry factual and compact. Preserve uncertainty: if the choice was a trial, say so.

Step 5: Close the Loop

After saving, confirm:

  • The decision in one sentence
  • Where it was saved
  • The review date, if any
  • Any earlier decision it replaces

If the decision creates follow-up work, offer to add the next action through the normal task flow. Do not create a task without the user's confirmation.

Connection to /week-review

Entries with a review date, a changed assumption, or an unresolved follow-up are designed to be surfaced during /week-review. When this skill records one of those, mention that /week-review can bring it back at the right time. This is a connection between the two skills; do not edit the week-review files.

Rules

  • Record the user's decision, not your preferred answer
  • Separate facts from assumptions
  • Never rewrite an older entry to make history look cleaner
  • When a decision changes, add a new entry and link the earlier one
  • Use absolute dates
  • Keep sensitive personal details out unless the user explicitly wants them recorded

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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.