self-consistency-reasoner
Skill146 starsChanged 7 months agoMITView on GitHub
Internal reasoning technique invoked by systematic-debugging and verification-before-completion for high-stakes multi-step inference. Generates N independent reasoning paths and takes majority vote to surface confident-but-wrong single-chain failures. DO NOT invoke independently — this skill is embedded in the skills that need it.
In this repository23 other files it gives its agents.
- brainstormingSkill
- claude-md-creatorSkill
- context-managementSkill
- deliberationSkill
- dependency-managementSkill
- dispatching-parallel-agentsSkill
- error-recoverySkill
- executing-plansSkill
- finishing-a-development-branchSkill
- frontend-designSkill
- performance-investigationSkill
- premise-checkSkill
- receiving-code-reviewSkill
- refactoringSkill
- requesting-code-reviewSkill
- subagent-driven-developmentSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- token-efficiencySkill
- using-git-worktreesSkill
- using-superpowersSkill
- verification-before-completionSkill
- writing-plansSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
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 19
Disagreement is strong evidence: If your own paths diverge, the problem is genuinely ambiguous to you.
- Distinctive: line 48
Default: 5 paths. The paper suggests 5–10 independent samples to capture most of the gain.
- Distinctive: line 58
Use a different starting point or framing
- Distinctive: line 84
Do not show all paths to the user.
≈ “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
Self-Consistency Reasoner
A structured reasoning technique adapted from Self-Consistency (Wang et al., ICLR 2023).
Core idea: Complex problems often have multiple valid paths to the correct answer, while incorrect reasoning tends to scatter across different wrong answers. Reaching the answer by several deliberately different routes and comparing the endpoints exposes a single chain that committed early to a wrong assumption.
What this is not. The paper samples N separate decodes from the same prompt and votes over them; their independence is what makes agreement track accuracy. Paths you write one after another in a single response are not independent — each one can see the ones before it, and all of them share your blind spots. So read the result asymmetrically:
- Disagreement is strong evidence. If your own paths diverge, the problem is genuinely ambiguous to you. Stop and gather evidence.
- Agreement is weak evidence. It means no route you thought of contradicts the answer — not that the answer is right. It never replaces the test or command that proves it.
When This Fires
This skill is invoked internally by:
- systematic-debugging — during root cause hypothesis generation (Phase 3)
- verification-before-completion — during evidence evaluation
It fires when:
- The reasoning requires 3+ non-trivial steps
- A single reasoning chain could make a wrong assumption or logical error
- The answer has a fixed answer set (a root cause, yes/no, a specific conclusion)
- Being wrong has real cost (wrong diagnosis wastes edits; false "done" wastes review cycles)
How Many Paths to Generate
Scale paths to difficulty:
| Problem Type | Paths |
| Binary verification (does this evidence prove the claim?) | 3 paths |
| Root cause diagnosis with 2-3 candidates | 5 paths |
| Complex multi-factor diagnosis or high-stakes verification | 7 paths |
Default: 5 paths. The paper suggests 5–10 independent samples to capture most of the gain; in a single response, extra paths add little once the genuinely different starting points are used up — stop there rather than padding.
The Process
Step 1: Generate N Independent Reasoning Paths
Produce each path independently — don't let earlier paths contaminate later ones. Vary your approach deliberately:
- Use a different starting point or framing
- Work forward from given info in one path, backward from the goal in another
- Decompose the problem differently across paths
- For debugging: start from different points in the call stack, assume different failure modes
- For verification: evaluate the evidence from different angles (what would prove it true? what would prove it false?)
Each path tries to reach the answer — not a different candidate — and must end with a clearly parsed final answer. Asking each path for a different hypothesis manufactures disagreement and makes the vote meaningless.
Diversity of route is the whole point. Paths that all use the same approach just give you one answer repeated — that's not self-consistency, it's greedy decoding in disguise.
Step 2: Aggregate via Majority Vote
Group answers that mean the same thing (two phrasings of one root cause are one answer), then count. The most frequent answer wins.
Agreement = (paths agreeing with the majority answer) / (total paths). It is a count, not a calibrated probability.
Step 3: Act on Results
- Unanimous: Proceed — and still prove it with the test or command; agreement alone is not evidence.
- Majority (more than half, not all): Proceed with the majority answer, but name the minority answer and test it next if the majority fails.
- No majority (half or fewer): STOP. Do not proceed. Report the top 2 competing conclusions and the assumption that splits them. Gather more evidence or ask the user.
Output Format
Do not show all paths to the user. The process is internal. Surface only the aggregated result:
**[Diagnosis/Verdict]**: [the majority-vote answer]
**Agreement**: [X/N paths] — unanimous | majority | no majority
[Only if not unanimous]: Brief note on the minority conclusion and the key divergence point.What the Research Supports — and What It Does Not
- Majority vote is enough — the paper found an unweighted vote about as accurate as probability-weighted aggregation, and you have no token probabilities anyway.
- Agreement tracks accuracy for independent samples — "low consistency" signals the model does not know. That calibration is measured on separate decodes; for paths in one response, trust the disagreement signal and treat agreement as weak.
- Diverse reasoning routes matter — the paper attributes the gain to diversity, and more independent samples kept helping up to 40. It does not claim that a few diverse paths beat many similar ones.
- Needs a fixed answer set — a root cause or a yes/no verdict qualifies once equivalent phrasings are grouped. Open-ended design questions do not; use
deliberationfor those.
Related Skills
systematic-debugging— invokes SC during root cause hypothesis testingverification-before-completion— invokes SC during evidence evaluation
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.

