Decision ledger
Agent Skill for searchable decision ledgers, rejected approaches, skill/CLI routing, and evidence-based self-reflection
npx -y skills add TaoCultivator/decision-ledger-skill --skill decision-ledgerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use this skill to retrieve, create, or reconcile project-owned decision records when work depends on prior accepted, rejected, or proposed choices; repeatable operational experience; incident lessons; specification decisions; or avoiding a previously failed approach. Also use it when maintaining the decision-ledger workflow itself. Do not use it for routine implementation, generic memory questions, or ordinary tool selection unless project history is materially relevant.
The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.3 KB, as published. Nobody here has run it
Decision Ledger
Purpose
Keep durable project decisions searchable without loading full conversation history. A ledger is project-owned evidence: it records what was proposed, accepted, rejected, or learned from repeatable operational failures.
Use personal memory for long-lived user preferences and conversational context. Use a decision ledger for shared project history that needs paths, status, evidence, and lifecycle.
Activation Boundary
Use this workflow when the task depends on at least one of these:
- a prior project decision or rejected approach;
- a repeated tool, environment, publishing, or validation failure;
- a decision that must be synchronized into a specification;
- an explicit request to record, retrieve, audit, or improve project decision history.
Skip it for routine implementation, one-off troubleshooting with no history signal, generic memory questions, and ordinary skill or tool selection. A ledger lookup should remove uncertainty, not become ceremony on every task.
Core Workflow
- Extract exact retrieval anchors: project, scope, module, file, symbol, command, error text, symptom, metric, decision status, and user wording.
- Locate the compact project index, preferring
docs/decision-ledger/index.jsonlor the repository's documented equivalent. - Search the index before opening note bodies. Use exact keyword and metadata filters first;
scripts/ledger_search.pyis the dependency-free helper. - Open only the best 1-3 notes unless results conflict or the user requests a broad audit.
- Surface relevant
experienceandrejectedrecords before recommending a path that may repeat a known failure. Treatproposedrecords as unverified. - State the result:
- name the matching status and conclusion; or
- say
未找到相关 ledger 记录/No relevant ledger record found.
- If the task is discussion-only, stop after reporting the history. Do not edit code, specifications, or ledger records without a requested change.
- When a decision is implemented and validated, update the full note, compact index, and authoritative specification in the same pass. Rewrite conflicting current guidance; preserve superseded history through links.
Read retrieval-workflow.md when the index is missing, large, multilingual, filtered, or produces conflicting results.
Read record-maintenance.md before creating records, changing status, initializing a ledger, or synchronizing specifications.
Record States
proposed: discussion or research that is not yet validated.accepted: implemented or otherwise verified, with evidence and authoritative-spec alignment.rejected: an approach that should not be reused by default, including the failure condition and any reconsideration boundary.experience: a repeatable operational lesson with trigger signals, root cause, safe resolution, and validation.
Rank by relevance first. Among similarly relevant results, inspect repeatable experience and rejected guardrails before accepted, then proposed.
Guardrails
- Project-owned records outrank skill-owned examples.
- Verify remembered operational fixes with cheap read-only checks before applying them.
- Never promote model intuition directly into accepted guidance.
- Preserve attribution when a user identifies a gap or proposes an improvement.
- Avoid destructive commands copied from historical notes; re-evaluate them against current paths and permissions.
- Keep growing project history outside this skill.
On-Demand References
- Use discussion-memo-template.md for discussion-only conclusions.
- Use accepted-decision-template.md after implementation and validation.
- Use rejected-approach-template.md when an approach should not be repeated by default.
- Use experience-memory-template.md for repeatable operational failures and workflow lessons.
- Read workflow-self-iteration.md only when the user asks to improve this workflow, a validation failure reveals a reusable gap, or a planned review needs current external evidence.
- Read publishing-workflow-experience.md only when maintaining or debugging this skill's public mirror.
Closure Check
Before finalizing substantial ledger work:
- Confirm that lookup scope stayed compact and the reported status matches the record.
- Check that rejected or experience guardrails were not missed.
- For writes, validate frontmatter,
index.jsonl, referenced paths, evidence, and authoritative-spec consistency. - Report what changed, what evidence supports it, and what remains proposed or out of scope.