Chain of thought

Skill marktantongco/opencodelinux/skills/chain-of-thought

Merged opencode config + agents + accomplishments showcase — 217 skills, 17 agent profiles, 6 MCP servers, 78-server registry

Install

npx -y skills add marktantongco/opencodelinux --skill chain-of-thought

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Explicit step-by-step reasoning for complex problems including multi-step analysis, architecture decisions, and debugging. Use when showing the reasoning process is as valuable as the answer.

SKILL.md

6.0 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it

Chain-of-Thought Reasoning

Context

Activate this skill when the user presents a complex problem that benefits from explicit, step-by-step reasoning before arriving at a conclusion. This includes:

Multi-step mathematical, logical, or analytical problems
Architecture or design decisions with many moving parts
Debugging scenarios requiring causal reasoning
Any task where showing the reasoning process is as valuable as the answer
Situations where the agent might otherwise jump to a wrong conclusion by skipping steps

Do not use for simple factual lookups, greetings, or tasks where the user only wants a direct answer.

Instructions

Step 1: Restate the Problem

Paraphrase the problem in your own words to confirm understanding. Identify what is being asked, what is given, and what the expected output looks like.

Step 2: Identify and State Assumptions

List every assumption you are making before reasoning begins. Number them explicitly. If any assumption is uncertain, flag it with [ASSUMPTION — UNVERIFIED].

Step 3: Decompose into Sub-Problems

Break the problem into the smallest discrete steps possible. Each step should be independently verifiable. Assign a number to each step.

Step 4: Solve Each Step Explicitly

For every sub-problem:

State what you are calculating or reasoning about
Show the work (equations, logic, references)
State the intermediate result
Verify the result makes sense before moving on

Step 5: Cross-Check and Validate

After completing all steps, revisit the chain:

Do the intermediate results chain together correctly?
Does the final answer satisfy the original problem statement?
Run a quick sanity check (e.g., back-of-the-envelope, boundary test)

Step 6: Flag Uncertainties

After presenting the final answer, list any remaining uncertainties, caveats, or areas where assumptions could change the result. Rate confidence as High / Medium / Low for each.

Constraints

Never skip steps. Every logical jump must be explicit. If you find yourself wanting to skip, add a step explaining why.
Number every step. Use Step N: format consistently.
Assumptions come first. Never reason from hidden assumptions — state them upfront.
Show your work. Intermediate calculations, logical derivations, and references must be visible.
One conclusion per chain. If the problem branches, start a new numbered chain for each branch.
Flag, don't hide. If you are unsure about a step, mark it clearly rather than presenting it as confident.
No premature answers. The final answer appears only after Step 5 is complete.

Examples

Example 1: Technical Architecture Decision

User: "We need to choose between a monolith and microservices for our e-commerce platform with 50k daily users."

Output:

Chain-of-Thought Reasoning

Step 1: Restate the Problem
  We must choose between a monolithic architecture and microservices for an
  e-commerce platform serving approximately 50,000 daily active users. The
  decision should optimize for reliability, developer velocity, and future
  scalability.

Step 2: Assumptions
  1. [ASSUMPTION] The team size is small-to-medium (3–10 developers).
  2. [ASSUMPTION] Traffic growth is expected to be steady, not exponential.
  3. [ASSUMPTION — UNVERIFIED] The platform includes checkout, inventory,
     user accounts, and a recommendation engine.

Step 3: Decompose
  3a. Evaluate monolith against our criteria
  3b. Evaluate microservices against our criteria
  3c. Compare at current scale (50k DAU)
  3d. Compare at projected 2x scale
  3e. Consider team-structure alignment

Step 4: Solve
  4a. Monolith: simpler deployment, single database, faster initial dev...
  4b. Microservices: independent scaling per service, fault isolation...
  4c. At 50k DAU, a well-built monolith handles this comfortably...
  4d. At 100k DAU, checkout may need independent scaling...

Step 5: Cross-Check
  The monolith is the stronger fit at current scale. Microservices become
  justified when a specific service hits a scaling ceiling.

Step 6: Uncertainties
  - [Medium confidence] Assumption #1 about team size — if the team is
    larger than 15, microservices gain advantage.
  - [Low confidence] Future traffic projections are not confirmed.

Recommendation: Start with a modular monolith...

Example 2: Mathematical Problem

User: "A factory produces 400 units/day. Defect rate is 3%. Each defective unit costs $15 to rework. What is the monthly rework cost?"