cc-thinking-skills: 28 Agent Skills for Structured Reasoning in Coding Agents

What problem cc-thinking-skills solves, and for whom

Coding agents are good at executing a stated procedure and bad at choosing one. Ask Claude Code or Cursor to "decide whether to rewrite this module" and you get whatever frame the model defaults to, applied silently. cc-thinking-skills addresses that by turning named reasoning procedures into files the agent can load on demand. The README describes it as "a public catalog of Agent Skills" for decisions, diagnosis, systems, risk, strategy and innovation, with the instruction to "use a skill when its mechanism fits the task." That framing matters: the catalog does not claim to make an agent smarter, it claims to make the choice of method explicit and reviewable.

The intended user is someone already running an Agent Skills-compatible tool who wants the reasoning step to be named rather than implicit. A staff engineer asking for a pre-mortem on a launch plan, a reviewer asking for a steel-man of the opposing design, or a debugging session where you want causes ranked before anyone touches code. The 28 skills are grouped into route and compose, diagnose and understand, decide and evaluate, create and improve, and manage risk and execution. If your workflow never asks an agent to reason about a decision, only to write code, the catalog has little to offer you.

How the router and leaf skills actually work

Every skill is a directory under skills/ named thinking-{something}, and the README says the 28 active skill IDs "match the directories under skills/". The mechanism is therefore file-based: the agent reads a skill definition and follows the procedure it contains. There is no runtime, no daemon and no model of its own.

The interesting design decision is the split between routing and leaves. thinking-model-router is the entry point when the right frame is unclear. According to the README, the router "can return NONE, one skill, or up to three complementary skills." That NONE option is the part worth noticing. A router that can decline to route is a different proposition from one that always picks something, and it is the difference between a catalog and a forced-choice generator. thinking-model-combination handles the other case: sequencing distinct models when one leaves a blind spot.

The leaves are concrete procedures, not slogans. thinking-scientific-method ranks causes and tests the cheapest discriminator. thinking-kepner-tregoe compares IS/IS-NOT defects and must/want options. thinking-theory-of-constraints finds the binding throughput constraint. thinking-reversibility separates easy-to-undo choices from costly commitments. Each of those names a specific comparison or ordering step, which is what makes them invocable: you can tell an agent to use one, and you can check afterwards whether it did.

Installing cc-thinking-skills and running a first skill

The README gives three installation paths. The Skills CLI is the shortest. It installs the catalog into the current project:

npx skills add tjboudreaux/cc-thinking-skills

Adding --all skips the prompts, which is what you want in a scripted setup:

npx skills add tjboudreaux/cc-thinking-skills --all

If you use Claude Code's plugin system instead, the README lists two slash commands, first to register the marketplace and then to install from it:

/plugin marketplace add tjboudreaux/cc-thinking-skills
/plugin install thinking-skills@thinking-skills-marketplace

The third path is a clone plus a copy. The README shows copying the skill directories into .agents/skills/ under your project, and notes that Claude Code can also load the same directories from ~/.claude/skills/ or .claude/skills/:

git clone https://github.com/tjboudreaux/cc-thinking-skills.git
mkdir -p /path/to/project/.agents/skills
cp -R cc-thinking-skills/skills/* /path/to/project/.agents/skills/

With the skills in place, the README's usage examples are plain-language invocations rather than commands. Start with the router when you do not know which frame fits:

Use thinking-model-router to choose the right framework for this problem.

When the match is obvious, call the leaf directly. The README gives four examples in one block: thinking-scientific-method to localize a bug, thinking-reversibility to classify an architecture decision, thinking-pre-mortem to stress-test a launch plan, and thinking-theory-of-constraints to find the binding bottleneck. One caveat from the README: the Claude Code plugin uses thinking-skills:thinking-model-router as the exact router ID, so the plugin form is namespaced while the copied-directory form is not.

The evidence section is the most unusual part of this repository

Most skill catalogs of this kind ship a claim and no numbers. This one ships an audit that undercuts its own headline. The README's evidence section reports 28 active skills, all manual-only, with "no automatic-retain verdict". It states that portfolio-v1 ran with "zero model calls and an unmeasured result". The only row with a number is a provisional thinking-scientific-method result at +4.0 percentage points, which the README itself notes is "below the +5-point utility margin and has evidence gaps", adding: "Treat it as directional evidence, not an accuracy claim."

Read that as a design statement rather than a marketing one. The catalog is asking you to evaluate it structurally, not statistically. That is also why the README points at analysis/AUDIT.md before anyone makes performance claims, and why it says the catalog audit is "decision-ready" rather than conclusive.

The practical consequence is that you cannot justify adopting this on measured outcomes, because the repository does not provide them. What you can justify is the structural argument: 28 named procedures, a router that may return NONE, and a validation script you can run yourself. The honest reading is that the audit is the reason to trust the repository's other claims, not the reason to expect a benchmark improvement.

Validation and evaluation commands you can run locally

The repository ships its own checks, and they are the fastest way to see whether a checkout is intact. Structural validation of the skill definitions is a single Node script:

node scripts/validate-skills.js

The local structural gate runs through the eval harness with an environment variable set:

EVAL_RUN=local node evals/run-structural.js

Routing evaluation is a separate script, and the README says it requires the authenticated droid CLI:

EVAL_RUN=local node evals/run-routing.js

That authentication requirement is a real constraint. If you do not have the droid CLI available and authenticated, you can run the structural checks but not the routing evaluation, which is the one that would tell you whether the router picks sensible frames. The README directs contributors to evals/README.md and CONTRIBUTING.md before changing the catalog, and study artifacts live under evals/studies/. It also notes that external datasets follow their license limits, which is worth checking before you reuse anything from those studies.

Where cc-thinking-skills is the wrong tool

The catalog is manual-only, and the README says so plainly in its evidence section. Nothing here fires automatically. If you expected skills to be selected for you, you will be disappointed: the agent uses a skill when you or your tooling tell it to, or when the router is invoked first. Teams that want invisible, always-on reasoning scaffolding are not the audience.

The second limitation is coverage. The 28 skills cover reasoning frames, not domain knowledge. thinking-red-team is described as reviewing "authorized attack paths with reproducible findings", which is a procedural constraint, not a security scanner. thinking-probabilistic forecasts with base rates and ranges, but the skill cannot supply your base rates. Every one of these is a procedure the agent applies to information you or the agent already have.

The third is the evidence gap already described. If your adoption decision requires a measured effect size, this repository does not currently give you one, and the README does not pretend otherwise. Finally, the catalog is JavaScript tooling around Markdown skill definitions. If your agent tool does not read Agent Skills directories, installing these files accomplishes nothing.

How this differs from a single prompt or a general reasoning framework

The obvious alternative is not another skill catalog but the thing most people already do: paste a reasoning instruction into the prompt, or keep a personal notes file of frameworks. That approach is free and requires no installation. The difference is addressability. A prompt instruction is ephemeral and unnamed, so you cannot ask whether it was followed. A skill directory has an ID like thinking-pre-mortem or thinking-theory-of-constraints, which means you can reference it in a review, diff it, validate it with node scripts/validate-skills.js, and route to it by name.

The second alternative is a general reasoning framework applied wholesale, such as always using first principles. The catalog's own structure argues against that: it separates thinking-first-principles ("separate physics from convention") from thinking-via-negativa (remove harmful or nonessential elements first) and thinking-effectuation (act from available means under uncertainty). Those three produce different, sometimes opposing advice on the same problem. A single always-on framework cannot make that distinction, and the router's ability to return NONE or up to three complementary skills is the catalog's answer to it. Whether the router picks well is exactly what the authenticated routing evaluation is meant to measure, and that measurement is not in the repository yet.

Maintenance, licence and what a fork costs you

The repository is not archived and the last push was on 2026-08-07, roughly five weeks before this writing. The only release listed is v1.0.0 from 2026-08-04, so the project is at a first tagged version rather than deep into a release cadence. There is no homepage, and the README does not document a deprecation or rollback path for skills you have already copied into .agents/skills/ or ~/.claude/skills/; removing a skill means deleting its directory yourself.

The licence is MIT, which permits reuse and modification with the licence and copyright notice retained. That is a permissive arrangement, and it is the reason copying skill directories into your own project is straightforward. Two caveats sit outside the licence itself: the README says external datasets under evals/studies/ follow their own license limits, so the MIT grant on the code does not automatically extend to third-party data in the repository; and the README's contribution section points to CONTRIBUTING.md before you change the catalog, which is the file to read if you intend to maintain a fork rather than consume one. None of this is legal advice; check the LICENSE file and the individual dataset terms for your own situation.

Editorial conclusion

Adopt cc-thinking-skills if you want a named, inspectable reasoning frame that a coding agent can be told to follow, and you are comfortable that the project's own audit reports zero model calls for portfolio-v1 and a provisional +4.0-point row below its +5-point utility margin. Do not adopt it expecting measured accuracy gains; the audit explicitly says to treat that row as directional evidence. Before wiring it into a team workflow, run node scripts/validate-skills.js and EVAL_RUN=local node evals/run-structural.js against your checkout, then read analysis/AUDIT.md and analysis/evidence.json to see what the numbers actually cover.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tjboudreaux/cc-thinking-skills on GitHub