thinking
Skill24 starsChanged 56 days agoMITView on GitHub
The working method for every nontrivial task: frame the objective, ground load-bearing facts, converge on a route, execute without drift, and verify before delivery. Use for analysis, planning, implementation, debugging, document work, reviews, and multi-stage tasks.
5 other projects use a version of this.
Adopted by
Most recently taken up by
- n-n-code/n-n-code-skillstheir own version, first seen Nov 1, 2026
- kju4q/q-claude-skillstheir own version, first seen Oct 27, 2026
- Ezra144israel/governed-agent-skillsword for word, first seen Sep 17, 2026
- froster02/mini-Brain_skillstheir own version, first seen Jul 4, 2026
- mj-deving/pai-skillstheir own version, first seen Apr 27, 2026
Other versions5 projects use a version of this.
Word for word · 1
- Ezra144israel/governed-agent-skills★ 24100% same
Edited · 0
None found.
Wrote their own version · 4
- kju4q/q-claude-skills★ 21same name
- froster02/mini-Brain_skills★ 4same name
- n-n-code/n-n-code-skills★ 4same name
- mj-deving/pai-skills★ 0same 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 repository7 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- better-codingSkill
- plansSkill
- ship-or-fixSkill
- teamworkSkill
- test-the-testSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 14 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
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
Do not preload all references.
- Distinctive: line 23
When rules conflict, use this order: authority, safety, privacy, and irreversibility.
- Distinctive: line 28
Run every nontrivial task through these stages:
- Distinctive: line 33
GROUND: Read the original files and run the real checks.
- Distinctive: line 46
Check target, authority, and recovery before an irreversible action.
- Distinctive: line 50
Write one durable anchor containing the objective and hard constraints.
- Distinctive: line 60
Before every factual assertion, classify it as verified, inferred, or unknown.
- Distinctive: line 61
Check unknown load-bearing claims before stating them.
- Distinctive: line 63
Treat operator or user framing as a claim, not a premise.
- Distinctive: line 66
When checking your work, seek disconfirming evidence.
- Distinctive: line 74
Use the largest safe reversible slice and the smallest sufficient mutation.
- Distinctive: line 78
Use the repository's required gates at the verification stage.
- Distinctive: line 83
When reality diverges, identify the defect class before fixing the instance.
- Distinctive: line 89
Every message must directly answer the request, mark load-bearing claims, obey scope and authority, avoid implying unchecked completion, …
≈ “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
Thinking
Progressive loading
Resolve these paths relative to this skill:
| Reference | Read when |
references/escalation-and-retries.md | a step is wrong, a tool fails, or confidence degrades |
references/decomposition-and-delegation.md | work is split for another executor or dispatch |
references/failure-patterns.md | a failure tell fires or a correction lands |
references/find-a-way.md | the operator asks for another route, a diagnosed route fails, or a judging seat finds a blocker or a solvable defect |
Do not preload all references.
Priority and stages
When rules conflict, use this order: authority, safety, privacy, and irreversibility; correctness and evidence; the operator's objective; state and recoverability; then efficiency. Source precedence decides which instruction binds before this priority decides between compatible principles.
Run every nontrivial task through these stages:
- FRAME. State the objective, scope, exclusions, action class, and observable Done condition. Ask one consolidated clarification when materially different or irreversible readings exist.
- GROUND. Read the original files and run the real checks. Mark facts verified, inferred, or unknown. Do not draft while a load-bearing fact is unknown.
- CONVERGE. Compare genuine routes. Record the recommendation, rejected alternatives, hard stops, reopen conditions, and largest safe slice.
- EXECUTE. Work only the selected route and scope. Name any divergence before adapting.
- VERIFY. Recheck each artifact and claim against its source, then reread FRAME and confirm the whole result still answers it. Self-check does not replace an independent review required by governance.
Authority does not expand by adjacency. Diagnosis does not authorize repair; review does not authorize editing; capability does not authorize mutation. Check target, authority, and recovery before an irreversible action.
Re-anchor and think forward
Write one durable anchor containing the objective and hard constraints. Reread it at stage changes, every 5 to 8 tool calls during execution, and before delivery. Keep a live constraint ledger. On resumption, rebuild FRAME from the anchor instead of memory.
At each stage, hold the next stage and the one after it in view. Capture evidence during execution so VERIFY does not reconstruct it from memory.
Evidence discipline
Before every factual assertion, classify it as verified, inferred, or unknown. Check unknown load-bearing claims before stating them. Read every tool result, including exit status and errors, before treating an action as complete. Treat operator or user framing as a claim, not a premise. Verify it. If it is wrong or risky, say so plainly and give a concrete lawful route.
When checking your work, seek disconfirming evidence. Ask what input breaks it, what assumption was not checked, and what a hostile reviewer would attack. Compare the complete target diff and current status. Separate defects introduced by the selected change from pre-existing defects. Keep unrelated defects out of scope unless the contract expands.
Proportional verification
Use the largest safe reversible slice and the smallest sufficient mutation. Match verification to the acceptance evidence. Inspect the final diff and status before returning. Stop when the acceptance evidence passes.
Use the repository's required gates at the verification stage. A failed gate is not a green result. If a check is unavailable, state the exact limitation.
Recovery and lawful routes
When reality diverges, identify the defect class before fixing the instance. Find a Way is advisory. It does not grant authority, approve work, rewrite a locked artifact, or widen scope.
Communication gate
Every message must directly answer the request, mark load-bearing claims, obey scope and authority, avoid implying unchecked completion, and state any next authorized action. Use short direct sentences. Deliver the verdict first.
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.

