I came to Claude Code Skills through translation evaluation, which is a very good way to become suspicious of vague instructions.
When you compare model outputs for long enough, you stop asking only, “Does it sound fluent?” You start asking smaller questions. What context was actually used? Which instruction changed the result? Did the model improve, or did it just become more confident?
That is also how I now look at AI coding assistants.
The current excitement around Claude Code Skills, Codex configuration, multi-agent workflows, and local model setups is real. GitHub Trending is full of skill packs, agent wrappers, review bridges, and “make my coding agent better” projects. But I think the useful question is not “What is the best Claude Code skill in 2026?”
The useful question is:
What belongs in a Skill, what belongs in the harness around the agent, and what should remain a human decision?
A Skill Is A Workflow Package, Not Just A Prompt
Anthropic’s Claude Code documentation describes Skills as reusable instruction packages. A skill is built around a SKILL.md file, and Claude Code can load it when relevant or when invoked directly.
The part I care about most is context loading.
According to the Claude Code Skills documentation, unlike CLAUDE.md, a skill body loads only when the skill is used. That matters because long procedural instructions stop being a permanent tax on every session.
A small project skill might look like this:
.claude/
skills/
summarize-changes/
SKILL.md
references/
risk-checklist.md
scripts/
validate.sh
This is just an example layout. The official docs describe SKILL.md as required, with supporting files such as references, examples, templates, and scripts as optional.
A conservative SKILL.md could be:
---
description: "Summarize uncommitted changes and flag risks. Use when reviewing a local diff before committing."
allowed-tools: Read Grep
---
## Instructions
Read the current change context.
Return:
1. What changed
2. What could break
3. The smallest useful verification step
4. What you are not confident about
Do not rewrite the implementation unless asked.
I would keep the first version boring. A skill that does one thing reliably is more valuable than a skill that tries to become a tiny operating system.
What The Caveman Idea Gets Right, And Wrong
One reason caveman attracted attention is obvious: the repo’s own GitHub Trending description claims it cuts token usage by making Claude Code “talk like caveman.” That is a funny hook. It is not, by itself, a verified benchmark.
So I would treat the idea as a hypothesis to test.
The useful part is not “remove grammar everywhere.” The useful part is instruction compression. Many agent prompts contain politeness, repeated framing, and explanatory padding that does not change behavior.
For a narrow workflow, this kind of instruction can be enough:
Goal: find likely cause of failing test.
Do:
- read error
- inspect related files
- propose one fix
- run smallest test
Do not:
- refactor
- rename
- touch unrelated files
Output:
- cause
- patch summary
- test result
This is not elegant prose. It is not supposed to be.
But I would not use compressed “caveman” prompting for everything. A translation evaluator learns this quickly: shorter text is not automatically clearer text. If compression removes constraints, examples, or edge cases, the model may spend more tokens recovering the missing context.
The practical rule is simple: compress wording, not requirements.
Skills Need A Harness Around Them
A skill helps with repeatable behavior. It does not solve scope control by itself.
For coding agents, the harness around the model matters just as much as the prompt. By harness, I mean the configuration layer that decides:
- which instructions load
- which tools are allowed
- which agent handles which part of the task
- which checks run before or after actions
- which outputs require review
This is where Claude Code subagents and hooks become relevant.
The Claude Code subagents documentation describes built-in and custom subagents for separating exploration, planning, and implementation. That is useful because research can pollute the main thread. If an agent spends 20 minutes scanning a codebase, I do not always want all of that exploration living in the same context as the final edit.
Hooks are the other side of the harness. The Claude Code hooks documentation shows hooks as event-based configuration, such as PreToolUse, where a hook can inspect a tool call before it proceeds. I would start with simple hooks only: blocking destructive shell patterns, requiring a small verification command, or enforcing local project conventions.
Hooks are not decoration. They are automation with consequences.
That's a setup I would actually try.
If I were configuring a fresh AI coding workflow, I would not install a large skill bundle immediately.
Instead, I would start with four layers.
First, a repo-orientation skill.
It should answer: where is the code, how is it tested, what commands matter, and what areas are sensitive. This belongs in a skill because it is repeated and local.
Second, a verification skill.
For a frontend app, that might mean lint, typecheck, and one smoke test. For my own language-tooling experiments, it might mean running a tiny fixture set before trusting a script change.
Third, a read-only exploration subagent.
Use this for file discovery and risk mapping. The point is not to make the agent more dramatic. The point is to keep exploration separate from editing.
Fourth, a review gate for risky changes.
Not every change needs another agent. But auth, data loss, migrations, concurrency, and generated-code rewrites deserve a second pass.
Where Codex Fits
Codex can be useful as a second lane, especially for review and delegation.
The official openai/codex-plugin-cc repository says it lets Claude Code users call Codex from inside Claude Code for reviews or delegated tasks. Its README lists commands such as /codex:review, /codex:adversarial-review, /codex:rescue, /codex:status, and /codex:result.
That makes the pattern concrete: Claude can stay in the main implementation flow, while Codex runs a bounded review or background investigation.
For configuration, I would keep the article-level example tied to documented Codex config keys rather than pretending one model choice is universal. OpenAI’s Codex configuration reference documents model and model_reasoning_effort in config.toml.
A project-level example can look like this:
# .codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "high"
The exact model should match what your account, organization, and current Codex release support. The important point is not the sample model string. It is that model and reasoning-effort defaults belong in configuration, not scattered through prompts.
I would also avoid turning review gates into infinite loops. The Codex plugin README warns that its review gate can create long-running Claude/Codex loops and drain usage limits quickly. That warning is worth taking seriously.
What About Local Models?
Local models are attractive for cost control, but I would give them low-risk work first.
OpenAI’s Codex config reference includes oss_provider with lmstudio and ollama as supported values for local-provider selection when running with --oss. That tells me local-model workflows are a real configuration path, not just a fantasy.
Still, I would not put a small local model in charge of production edits on day one.
I would start with tasks like:
- summarizing logs
- grouping similar errors
- drafting grep queries
- compressing long command output
- ranking files by likely relevance
Then a stronger coding model can handle the actual patch, or a human can review before anything writes to the repository.
Local deployment should not mean “remove judgment.” It should mean “move cheap, low-risk language work out of the expensive lane.”
My Current Rule
I don't trust a skill because of its cleverness. I trust it when it makes the workflow easier to inspect.
A good Claude Code Skill should make one repeated procedure smaller, clearer, and easier to trigger.
A good Codex configuration should make review and delegation more explicit.
A good harness should make the agent less likely to wander outside the task.
That is the part of this ecosystem I find promising. Not the idea that AI coding assistants will magically write everything. More the possibility that the boring parts of engineering can become programmable without making the risky parts invisible.
Top comments (0)