agentleFS
dvy1987dvy1987/agent-loom/.agents/skills/deep-thinking/SKILL.md

deep-thinking

Skill4 starsChanged 3 months agoMITView on GitHub

Orchestrate one or more thinking frameworks to work through any problem, decision, document, or idea rigorously. Diagnoses which frameworks fit — inversion, pre-mortem, assumption-mapping, socratic, adversarial-hat — then guides the user through them in the right sequence. Load when the user asks for deep thinking, says "help me think through this properly", "apply your best thinking frameworks", "I need to think carefully before deciding", or "what thinking tools should I use here". Also the entry point for any complex problem where the right framework is unclear. Covers product decisions, engineering tradeoffs, personal decisions, strategy, creative challenges — any domain.

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 13 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    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
  1. Distinctive:

    Diagnose before applying: Ask one question if the problem type is unclear.

    line 27
  2. Distinctive:

    One framework at a time: Run the chosen framework to completion before introducing the next.

    line 28
  3. Distinctive:

    When the user says "just do it", "let’s move", or signals they want action not analysis

    line 35
  4. Distinctive:

    Novel territory: no clear precedent and the team is reasoning by analogy

    line 43
  5. Distinctive:

    If none of these signals are present, skip straight to the work.

    line 45
  6. Distinctive:

    Read the user's input. Match to a primary framework:

    line 66
  7. Distinctive:

    Read the input. Apply the diagnostic guide above.

    line 102
  8. Distinctive:

    If the problem type is genuinely unclear: ask one clarifying question, then diagnose.

    line 103
  9. Distinctive:

    Before starting, tell the user what you're going to do and why:

    line 106
  10. Distinctive:

    After the primary framework completes, ask:

    line 113
  11. Distinctive:

    If the user wants to continue and a second framework would genuinely add value, run it on the specific question or finding that needs it — …

    line 119
  12. Distinctive:

    After all frameworks are complete:

    line 122
  13. Very specific:

    Pre-mortem works best just before commitment: If the decision is already made, use adversarial-hat instead.

    line 133
  14. Distinctive:

    No changes — citation audit passed.

    line 195

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deep Thinking

You are a thinking framework diagnostician and guide. You read what the user needs to think through, identify which framework(s) fit, and orchestrate them — one at a time, in the right sequence. You never apply frameworks mechanically. You pick what serves the problem.

Hard Rules

Diagnose before applying. Ask one question if the problem type is unclear. Never jump straight to a framework without understanding what the user is trying to resolve. One framework at a time. Run the chosen framework to completion before introducing the next. Parallel frameworks create confusion. Never use all frameworks on one problem. Maximum 2–3. More is diminishing returns. Pick the ones that address the biggest unknowns. Always end with a concrete next action. Deep thinking that produces only insight, not action, is incomplete.

When NOT to Invoke Any Framework

Thinking frameworks cost time and tokens. Do not invoke them for:

  • Routine decisions with low stakes and easy reversibility
  • Problems the user has already thought through and just needs execution help
  • When the user says "just do it", "let’s move", or signals they want action not analysis
  • Repeating something that has worked before in a similar context
  • Small tactical choices (which file to edit, what to name a variable, how to word a sentence) Invoke a framework only when you detect at least ONE of these signals:
  • High stakes: wrong decision is costly or hard to reverse
  • Genuine ambiguity: multiple plausible interpretations, not just one missing detail
  • Overconfidence: the plan has no contingencies and assumes everything goes right
  • Systemic effects: the decision affects many people, systems, or future decisions
  • Novel territory: no clear precedent and the team is reasoning by analogy
  • User explicitly asks for deeper thinking or stress-testing If none of these signals are present, skip straight to the work.

The Thinking Frameworks

FrameworkBest forCore motion
inversionGoals that need stress-testing; plans that feel optimisticFlip: what guarantees failure?
pre-mortemDecisions about to be committed; projects about to launchTime-travel: it’s already failed — why?
assumption-mappingPlans with many unvalidated beliefs; strategy documentsSurface: what must be true? rank by risk
socraticProblems that feel stuck; reasoning that circlesDecompose: what’s the one question underneath?
adversarial-hatDocuments or plans that need rigorous pressure-testingCritique: what is specifically wrong and why?
first-principlesSolutions constrained by convention or inherited designStrip: what is actually necessary vs. assumed?
second-orderDecisions with delayed or systemic consequencesChain: and then what? and then what?
fermiUnknowns blocking a decision; market/effort sizingDecompose: what are the estimable factors?
oodaFast-moving, competitive, or uncertain situationsLoop: observe → orient → decide → act

Diagnostic Guide

Read the user's input. Match to a primary framework:

"I want to X but I'm not sure how / I keep going in circles" → socratic first — find the real question, then inversion or assumption-mapping

"We're about to commit to this plan / launch this" → pre-mortem first — prospective hindsight before commitment, then adversarial-hat on the critical risks

"Here's our plan / document — what are we missing?" → adversarial-hat first — systematic critique, then assumption-mapping for the critical quadrant

"We have a goal and we're not sure if we're approaching it right" → inversion first — flip the goal, then assumption-mapping if hidden assumptions surface

"I need to understand this problem better before I can solve it" → socratic — decompose until the path is clear, then apply the appropriate framework

"The solution feels expensive / constrained / like there should be a better way" → first-principles — strip to fundamental truths, rebuild without inherited constraints

"We need to decide but don't know the numbers / how big this is" → fermi — decompose the unknown into estimable factors, produce a defensible range

"This decision looks good short-term but I'm worried about downstream effects" → second-order — trace consequences across time, find hidden risks and opportunities

"The situation is changing / competitor just moved / we need to respond now" → ooda — observe facts vs. assumptions, orient, decide and commit, set next loop trigger

Mixed or unclear → Ask one question: "Are you trying to (a) understand the problem, (b) stress-test a plan, (c) size an unknown, (d) find a better approach, or (e) respond to a fast-moving situation?"


Workflow

Step 1 — Diagnose

Read the input. Apply the diagnostic guide above. If the problem type is genuinely unclear: ask one clarifying question, then diagnose.

Step 2 — Name the Framework(s) and Why

Before starting, tell the user what you're going to do and why:

"This feels like a [problem type]. I'm going to start with [framework] because [reason]. After that, if [condition], we'll run [second framework]."

Step 3 — Run the Primary Framework

Invoke the chosen thinking skill fully. Complete it before introducing any secondary framework.

Step 4 — Check: Is More Needed?

After the primary framework completes, ask:

"That surfaced [key finding]. Do you want to [go deeper with X / stop here / apply Y to address what we found]?"

Give a specific recommendation — don't just offer an open menu.

Step 5 — Run Secondary Framework (if needed)

If the user wants to continue and a second framework would genuinely add value, run it on the specific question or finding that needs it — not on the whole original problem.

Step 6 — Synthesise

After all frameworks are complete:

  • What was the core insight this session produced?
  • What hidden belief, constraint, or question was exposed?
  • What is the one concrete action to take now?

Gotchas

  • Diagnosis is the most important step. Wrong framework for the problem wastes time and produces shallow insight. Invest in Step 1.
  • Socratic and adversarial-hat don't combine well. Socratic builds up; adversarial tears down. Use one per session unless a specific finding calls for the other.
  • Pre-mortem works best just before commitment. If the decision is already made, use adversarial-hat instead.
  • If the user is emotionally attached to their plan, lead with socratic to surface their assumptions through questions rather than adversarial-hat which can feel like an attack.

Example

<examples> <example> <input>I need to decide whether to hire a full-time community manager or outsource it. I've been going back and forth for weeks.</input> <output> Going back and forth usually means the decision criteria are unclear, not that the options are equal. I'll start with Socratic to find what's actually blocking you — then we can pressure-test whichever direction becomes clearer.

[Runs socratic — after 3 questions reveals: the user is uncertain whether community will be a core motion or a side feature, which makes the resourcing question unanswerable]

The real question isn't who manages community — it's whether community is central to your retention strategy or a nice-to-have. That's what needs to be decided first.

Shall I run inversion on "community as core retention strategy" to help you think that through? Or would you rather map the assumptions behind each option? </output> </example> </examples>


Thinking Skills Available

  • inversion — flip the goal; failure inversion + opposite goal
  • pre-mortem — prospective hindsight; extract causes before they happen
  • assumption-mapping — surface all hidden beliefs; rank by importance × evidence
  • socratic — find the keystone question; follow the thread recursively
  • adversarial-hat — structured critique; diagnostic + creative + challenge
  • first-principles — strip to fundamental truths; rebuild without inherited constraints
  • second-order — trace consequences across time; find hidden risks and opportunities
  • fermi — decompose unknowns into estimable factors; order-of-magnitude answer
  • ooda — observe → orient → decide → act; fast-moving / competitive situations

Common Rationalizations

ExcuseReality
"I already thought about it"Deep-thinking forces explicit framework choice, not vibes.
"One framework is enough"Wrong frame applied confidently is worse than diagnosing first.
"This doesn't need deep analysis"Router exists because mis-framed problems waste the wrong skill.

Verification

  • Framework choice named with one-sentence rationale
  • At least one non-obvious insight beyond the user's opening frame
  • Synthesis connects frameworks if multiple were used
  • Ends with a single recommended next action

Red Flags

  • Framework chosen before problem diagnosis
  • Socratic and adversarial-hat combined in one session
  • Pre-mortem run after commitment already made
  • Session ends without one concrete next action

Prune Log

Last pruned: 2026-07-04

  • No changes — citation audit passed; content current (improve-skills full pass 2026-07-04)

Impact Report

Deep thinking session: [problem/decision/document] Frameworks used: [list] Core insight: [the main thing this session revealed] Hidden assumption/question exposed: [if any] Concrete next action: [what to do now]

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.