decision-planner
Skill1 starsChanged 4 months agoMITView on GitHub
Surface hidden constraints, expand incomplete option sets, simulate downstream consequences, pre-mortem failure paths, and recommend a calibrated next action. Use when planning or scoping a project, designing a system, choosing among approaches, sequencing work, asking what is missing or what could go wrong, or deciding what to do when consequences depend on uncertain future branches. Do not use for factual lookups, executing a settled plan, creative writing, or a task with one mechanically correct result.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- diagrammingSkill
- project-executionSkill
- project-one-sliderSkill
- project-understandingSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
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
- Distinctive: line 20
Run all four probes:
- Distinctive: line 35
Do not pretend exhaustive coverage.
- Very specific: line 49
Use likely, plausible, and unlikely unless a real base rate supports a number.
- Distinctive: line 51
Read references/decision-records.md for the output template and persistent ledgers.
- Distinctive: line 55
Use current authoritative evidence when a decision depends on unstable facts, prices, regulations, product capabilities, or niche technical …
- Distinctive: line 59
Ask for user input only when the missing choice would materially change the recommendation and cannot be safely inferred.
- Distinctive: line 60
Prefer a reversible probe over prolonged speculation.
- Distinctive: line 61
Do not return a flat “it depends.” State what it depends on, which branch currently dominates, and what to do next.
- Distinctive: line 62
Do not expand a settled decision unless new evidence touches its recorded revisit condition.
- Distinctive: line 69
Verify the recommendation optimizes the stated goal and horizon.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Decision Planner
Turn a vague or overconfident plan into an explicit decision with visible constraints, futures, failure signals, and a testable next step.
Choose the entry mode
- Discover — use when the option set or constraints are still forming: “What are we missing?”, early architecture, scoping, feasibility, or cross-discipline planning.
- Choose — use when the options are substantially known and the user needs a recommendation.
- Full — use Discover and then Choose when a recommendation would otherwise rest on an obviously thin option set.
Scale the prose to the stakes and reversibility. Run every applicable reasoning step, but compress low-stakes decisions to a few lines.
Phase A: discover constraints and options
Run all four probes:
- Resolution zoom — narrate one representative episode of doing the work step by step. Ask where inputs and outputs live, what moves, waits, costs, reruns, fails, and must be reproduced or handed off.
- Expert-lens sweep — identify the specialties the project touches. Ask what each specialist would flag as a naive assumption. Mark constraints caught by only one lens.
- Reference-class bite-list — name the classes this project belongs to and what practitioners repeatedly buy, regret, retrofit, or discover late.
- Design for surprise — find load-bearing assumptions treated as fixed. Identify robustness moves that make whole classes of variation survivable.
Synthesize the result into:
- Act now: cheap now, costly late.
- Robustify: design choices that absorb a class of unknowns.
- Monitor: truly contingent unknowns with warning signals.
- Probe: the smallest experiments that buy the most information.
- Options: distinct paths revealed by the sweep, including waiting or doing nothing when real.
Do not pretend exhaustive coverage. The goal is to expose foreseeable unknowns and make residual surprises non-fatal.
Phase B: simulate and decide
- Frame — state the decision, inferred or stated goal, important constraints, and time horizon.
- Enumerate — keep two to four genuinely distinct options. Include the null option when credible.
- Roll forward — for each option, trace:
- Immediate consequence.
- At least one second-order consequence.
- Pivotal uncertainty and plausible branches.
- What the option forecloses or makes expensive to reverse.
- Pre-mortem — assume each path failed. Name the likely failure, earliest observable warning, and a preventive or recovery action.
- Compare and commit — compare paths against the goal, recommend one path, calibrate confidence, name what would change the recommendation, and specify the cheapest next test.
Use likely, plausible, and unlikely unless a real base rate supports a number. Clean structure is not evidence; label domain uncertainty.
Read references/decision-records.md for the output template and persistent ledgers.
Research boundary
Use current authoritative evidence when a decision depends on unstable facts, prices, regulations, product capabilities, or niche technical claims. Separate sourced facts from simulated consequences. Do not browse merely to decorate a framework.
Interaction rules
- Ask for user input only when the missing choice would materially change the recommendation and cannot be safely inferred.
- Prefer a reversible probe over prolonged speculation.
- Do not return a flat “it depends.” State what it depends on, which branch currently dominates, and what to do next.
- Do not expand a settled decision unless new evidence touches its recorded revisit condition.
- For large decisions, show the branch structure compactly enough that the user can substitute private knowledge.
Quality gate
Before delivering:
- Verify the recommendation optimizes the stated goal and horizon.
- Confirm the option set is not merely cosmetic variants of one path.
- Confirm each rollout reaches second-order effects.
- Confirm every failure mode has a warning signal and response.
- Confirm the pivotal unknown could actually flip the decision.
- Confirm the next test is cheaper or faster than prematurely committing.
- State confidence and the evidence or assumptions it rests on.
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
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.

