decision-room
Skill5 starsChanged 12 days agoMITView on GitHub
Examine a decision or proposition through four voices chosen for the topic. Use for "four people in a room," decision quadrants, competing arguments, or requests to expose weak reasoning and compare options.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- arnonsang/skillstheir own version, first seen Nov 1, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- arnonsang/skills★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository23 other files it gives its agents.
- AGENTS.mdAGENTS.md
- architecture-knowledge-baseSkill
- audio-transcribeSkill
- better-uiSkill
- brainstormingSkill
- broSkill
- chatgpt-imagegenSkill
- coding-standardsSkill
- deslopifySkill
- domain-modelingSkill
- frontend-designSkill
- gemini-ttsSkill
- goalSkill
- readbackSkill
- rephraseSkill
- reply-broSkill
- setup-goalSkill
- skill-cleanerSkill
- strunk-writing-qualitySkill
- technical-writingSkill
- tech-specSkill
- tool-installSkill
- type-breakdownSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
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
- Distinctive: line 17
Use the context already provided.
- Distinctive: line 57
Create four hypothetical voices when the material supports them.
- Distinctive: line 72
Use arguments from the supplied discussion first.
- Distinctive: line 82
Use a compact table. Combine it with the voices when that avoids repetition.
- Distinctive: line 87
Check the premises, the step from premise to conclusion, and hidden assumptions.
- Distinctive: line 91
Keep these distinctions clear:
- Distinctive: line 103
Test universal propositions against counterexamples and unclear definitions.
- Distinctive: line 104
Do not turn a metaphor into a logical law.
- Distinctive: line 123
Use scores only when requested or when they help explain a choice.
- Distinctive: line 145
Write plainly. Keep tables compact.
- Distinctive: line 147
Use sentence case and straight quotes.
≈ “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 room
Show the competing arguments, including tempting ones that fail. Explain what holds up and what that means for the question. Choose the voices from the topic, not a fixed list of professions or personality types.
Use the context already provided. State assumptions and proceed unless a missing fact prevents useful or safe analysis.
1. Find the actual question
Separate bundled decisions. Distinguish choosing an action from checking a claim. State the goal, constraints, and consequences of doing nothing where relevant.
Locate the disagreement. It may concern facts, predictions, values, interests, or acceptable risk. Different priorities are not automatically reasoning errors.
Separate supplied facts, verified evidence, assumptions, and unknowns. Check claims that could change the answer when sources are available. Cite the evidence you use. Never present supplied context as independently verified.
2. Choose a map that fits
For a genuine two-sided question, use position and reasoning quality as the axes:
| Position A | Position B | |
| Strongest available case | The best-supported argument for A | The best-supported argument for B |
| Weak case worth examining | A tempting argument for A that fails or lacks support | A tempting argument for B that fails or lacks support |
Name A and B after the actual positions. Judge arguments before placing them. The rows describe particular arguments, not people's intelligence, honesty, or permanent character.
The strongest available case may still be weak. Do not assume equal support on both sides or invent a weak argument to fill a cell. Label illustrative examples as hypothetical. Leave cells empty when necessary.
This matrix is a useful tool, not a rule that every debate must obey. When there are more than two positions, separate decisions, or compatible choices, use an option table or decision tree. Keep the argument audit. Include doing nothing, staged approaches, or selective choices when relevant. Do not assume the middle position is correct.
3. Build the room
Create four hypothetical voices when the material supports them. Use the matrix cells when they fit. Otherwise, choose voices with different positions, concerns, or assumptions. Use fewer rather than repeat an argument or invent a caricature.
Give each voice a short label that belongs to this topic. For each, show:
- What they support and what matters to them.
- Their central argument and the evidence or assumption it depends on.
- The strongest objection they need to answer.
- What evidence or changed circumstances would justify reconsidering, and any condition they regard as unacceptable.
For a disagreement about values, identify the priority at stake. Do not demand that a factual finding settle a value judgment.
Use arguments from the supplied discussion first. Distinguish sourced arguments, your reconstruction, and invented examples. Do not fabricate quotes or attribute hypothetical arguments to real people or groups. A hypothetical deal-breaker is not an established constraint. Agreement among the voices is not evidence.
Make weak arguments recognizable, not ridiculous. Explain why they might appeal to someone. Show the original weakness before offering a repaired version.
4. Test the arguments
Use a compact table. Combine it with the voices when that avoids repetition.
| Argument | Evidence or assumption | What holds or fails | What would resolve or repair it? |
Check the premises, the step from premise to conclusion, and hidden assumptions. Address the strongest objection, not an easier substitute. Explain the exact failure in plain language. Naming a fallacy is not enough.
Keep these distinctions clear:
- A contradicted claim differs from one that lacks evidence.
- A conclusion can be true even when the argument for it fails.
- A conclusion can follow from premises that have not been established.
- A value disagreement is not automatically a factual or logical mistake.
For a weak argument, identify what to discard, what narrower claim survives, and what evidence or change to the argument could repair it. Do not assume every argument can be repaired. For a stronger argument, state its limits and strongest counterevidence. Apply the same checks to the option you favor.
Test universal propositions against counterexamples and unclear definitions. Do not turn a metaphor into a logical law. Confidence, polished language, and stated willingness to reconsider do not establish correctness. Judge the claim without guessing the speaker's motives.
5. Check the options separately
A bad argument for A does not make A a bad option or establish B. A persuasive case can still propose something that violates a constraint.
Compare options against the actual goal and priorities. Choose criteria from the topic rather than reuse a fixed checklist. Distinguish stated priorities from ones you assumed. Explain consequences, who bears them, and uncertainties that could change the comparison.
Separate options that work now, need named changes, or violate an established constraint. Do not count planned safeguards as existing ones. When dismissing an option, state the specific reason and check whether a different priority or an overlooked benefit changes the judgment.
Use scores only when requested or when they help explain a choice. Define the criteria and scale. Keep argument quality separate from option suitability. Mark unknowns rather than invent precision. Do not average scores by default or let a total compensate for violating a hard constraint.
6. State what survives
End with the arguments to keep, qualify, or discard and the decisive reasons. State any unresolved disagreement. Unequal evidence does not require a balanced verdict, and agreement does not need to be manufactured.
For a practical decision, recommend a next step under the stated priorities. Give the strongest remaining objection and any tempting alternative to avoid. Name observable conditions that would justify reconsidering. When uncertainty blocks commitment, propose the smallest useful check or reversible trial, with a stop condition where relevant. More automation or risk is not inherently better.
For a proposition, explain which parts hold, need qualification, or fail. Offer a corrected formulation when useful. Do not invent an action decision.
Writing
Write plainly. Keep tables compact. Skip fictional dialogue, biographies, and repeated summaries. Explain failures without sneering at the people making them. Use sentence case and straight quotes. Avoid em dashes, decorative language, and generic conclusions.
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.

