DEPRECATED — Sonnet 4 and Opus 4 handle structured chain-of-thought natively, including revision, branching, and scope adjustment. This skill no longer provides meaningful uplift over the base model. Retained for reference only.

"This requires approximately N steps. Here's my decomposition: ..."

• Step N of M — State the sub-goal for this step
• Show the reasoning or work
• State the intermediate conclusion
• Explicitly connect to the next step: "This means for step N+1, we need to..."

Checkpoint: Am I still on the right track?

• Do earlier conclusions still hold given what I've learned?
• Has the problem scope changed?
• Are my assumptions still valid?

Revising Step N: My earlier conclusion that [X] was wrong because [Y]. The corrected conclusion is [Z]. This affects steps [list downstream impacts].

isRevision

revisesThought

Branch Point (from Step N):

Approach A — [Label]: [Brief description and likely outcome] Approach B — [Label]: [Brief description and likely outcome]

Evaluating: [1–2 sentence comparison on key trade-off] Committing to Approach [X] because [rationale].

branchFromThought

branchId

Scope Update: Originally estimated N steps, now estimating M because [reason].

needsMoreThoughts

totalThoughts

1. Restate the original problem in your own words
2. Trace the solution path: "Steps 1→3→5 established [X], steps 4→6 established [Y]"
3. Verify against all stated constraints and requirements
4. Flag remaining uncertainties or assumptions
5. Conclude only when all constraints are satisfied

Verification: Does this solution satisfy all requirements?

• [Requirement 1]: ✓ Satisfied by [step reference]
• [Requirement 2]: ✓ Satisfied by [step reference]
• [Requirement 3]: ⚠ Partially — [explain gap and mitigation]

nextThoughtNeeded=false

• Numbered thoughts — each labeled

  Step N of M

  with a sub-goal statement, reasoning, and intermediate conclusion
• Revision markers — inline

  Revising Step N:

  blocks that name what changed, why, and which downstream steps are affected
• Branch indicators —

  Branch Point (from Step N):

  blocks listing approaches with a commitment statement and rationale
• Scope updates —

  Scope Update:

  lines when the estimated step count changes mid-analysis
• Verification block — a final checklist confirming each requirement is satisfied, with step references; flags unresolved uncertainties before concluding

• Match depth to complexity: Simple problems (single decision, clear constraints) warrant 3-5 thoughts. Moderate problems (multi-step with trade-offs) warrant 5-10. Complex problems (architecture, debugging cascading failures, formal reasoning) warrant 10 or more — do not compress artificially.
• Revisions signal quality: A thinking session that revises earlier steps is more reliable than one that proceeds linearly without self-correction. Revision is not failure; it is the methodology working as intended.
• Prefer depth over breadth: Explore fewer branches more thoroughly rather than listing many options shallowly. A branch is worth exploring only if the choice between approaches materially changes the outcome.
• Scope honesty: If the initial step estimate was wrong, update it explicitly. An accurate mid-course correction is better than forcing conclusions to fit an outdated estimate.

1. Reproduce — State the observed vs expected behavior precisely
2. Hypothesize — Generate 2–3 candidate root causes, ranked by likelihood
3. Narrow — For the top hypothesis, identify the minimal test that would confirm or refute it
4. Test — Execute the test, observe the result
5. Iterate — If refuted, move to next hypothesis. If confirmed, trace to root cause
6. Verify fix — Confirm the fix addresses the root cause without regression

1. Frame — State the decision, constraints, and evaluation criteria with weights
2. Enumerate — List viable options (aim for 3–5)
3. Evaluate — Score each option against criteria; use a decision matrix
4. Stress-test — For the top 1–2 options, probe failure modes and edge cases
5. Decide — Commit with explicit rationale and documented trade-offs
6. Record — State what would cause you to revisit this decision

1. State the claim or goal precisely
2. Identify the proof strategy (direct, contradiction, induction, construction)
3. Execute step by step, with each step justified by a named rule or lemma
4. Check each step's validity before proceeding
5. Verify the proof is complete (all cases covered, no gaps)

• No persistent state across conversations. The MCP server maintained a thought history within a session. This methodology relies on the conversation context window instead, which is equivalent within a single conversation but doesn't persist across sessions.
• No programmatic thought graph. The MCP returned structured JSON for each thought step, which could theoretically be consumed by other tools. The methodology produces natural language instead. In practice, the MCP's JSON output was rarely consumed programmatically.
• Self-discipline required. The MCP mechanically enforced step numbering and checkpoint structure. The methodology relies on Claude following the protocol. In practice, explicit instructions are as reliable as tool-call enforcement for reasoning patterns.