Reasons
- A single context can legitimately map to multiple skills
- Spec-driven planning does not reason over the available skill space
Source Code Used in the Experiment
To reproduce the behavior, I used a minimal repository containing only two skills.
- lint
- planner
A single context can legitimately map to multiple skills
I wanted to create a plan, so I input "Create a plan to lint.". However, this directly triggered the /lint skill.
This happened even though the planner skill description explicitly says:
“Use when the user says things like ‘create a plan’.”
In practice, explicitly calling /planner turns out to be far more reliable.
Spec-driven planning does not reason over the available skill space
When I input /planner lint, the planner sometimes discovers skills/lint/SKILL.md and incorporates it into the plan. However, this behavior is not guaranteed.
The problem becomes more obvious with inputs like:
/planner lint src directory
In this case, the planner restricts its file exploration to the src directory.
As a result, it does not discover other skills.
The planner then reasons about how to lint in general and produces a plan that ignores the lint skill’s defined procedure entirely.
I stopped using skills implicitly
When I asked Claude to fix the planner so that it considers available skills, it actually worked.
However, I was using a get-shit-done style workflow, where the system assumes that everything belongs in .planning.
At that point, I realized the core issue:
I should not be using skills to encode project-specific behavior.
Those behaviors belong in the spec, not in skills.
Top comments (0)