Design Skills as Reusable Procedures Without Bloated Context
Core Idea
Agent skills can serve two different roles. A procedure is a skill the human deliberately invokes to make the agent follow a particular workflow. An ability is a skill the model can invoke for itself when it decides the capability is relevant.
Both forms can be useful, but they create different control and context costs. Procedure-oriented design keeps the human in charge of sequencing. Ability-oriented design gives the model more autonomy, but each available ability can expose descriptive text to the context window. A large catalogue of abilities can therefore consume context before useful work begins.
How It Works
An ability might contain coding standards that the agent loads when it is about to write a particular kind of code. The model notices the situation, retrieves the ability, and applies the rules.
A procedure is intentionally started by the user. Examples include:
- Interview the user adversarially before planning.
- Turn a clarified idea into a product requirements document.
- Convert the requirements document into individual implementation issues.
- Review a change using a defined checklist.
Procedure skills can be chained by the human. The human decides when planning is sufficiently clear, when requirements should be formalized, and when implementation should begin.
The context problem appears when many skills advertise themselves to the model. If one hundred skills each leak a description into context, the agent must carry all one hundred descriptions even when only one is relevant. Some skill systems allow model invocation to be disabled. In that mode, the description is not exposed for automatic selection, and the user invokes the procedure directly.
Skills also make human procedures reusable. An engineer who has planned the same type of project many times can encode that planning approach once, distribute it to a team, and improve it collaboratively. This resembles extracting duplicated code into a shared function: repeated working knowledge becomes a maintained capability rather than an informal habit.
Why It Matters
Context is not free. Excess instructions and skill descriptions consume context before the actual task begins. A large tool or skill collection can feel sophisticated while making it harder to observe what the baseline agent can already do.
Procedure-oriented skills also preserve human judgment. The human knows the available procedures and chooses which one applies. This keeps strategic decisions with the person who understands the mission and prevents the model from silently selecting a workflow that may not fit.
At a team level, reusable procedures raise the floor. Planning, review, and task decomposition can become consistent across engineers. The skill can be refined when the team discovers a better question, a missing check, or a recurring failure.
Practical Application
Use a blank-slate rebuild to improve a bloated agent setup:
- Remove the accumulated skills, plugins, servers, and large instruction files from the active
setup.
- Observe the agent in its basic mode. Identify what it already does well and where it actually
fails.
- Reintroduce only capabilities that solve an observed problem. Do not reinstall a tool merely
because it was previously present.
- Prefer user-invoked procedures for strategic workflows. Keep the human responsible for deciding
when to brainstorm, clarify, plan, create requirements, split tasks, or review.
- Use automatic abilities selectively. They are most defensible when the agent needs a narrow rule
at the moment of implementation, such as a coding convention.
- Install skills in a form that can be edited. Experiment with their wording and behavior instead
of treating them as fixed products.
- Maintain shared procedures as team assets. Let engineers contribute improvements when a procedure
misses an edge case or creates unnecessary work.
A practical sequence might be: invoke an adversarial interview, produce a requirements document from the resolved decisions, convert that document into scoped issues, and then assign selected issues to implementation agents.
Trade-Offs and Limitations
Procedure-first design requires the human to know which procedure to invoke. It trades automatic convenience for explicit control. A model-directed skill system may be appropriate when automatic selection is valuable and context cost is acceptable.
Ability skills are not inherently bad. A narrow ability can provide the agent with a standard exactly when it is needed. The failure mode is indiscriminate accumulation: too many descriptions, overlapping instructions, and no clear evidence that the additions improve results.
Skills are also difficult to write well. A longer skill is not necessarily better. A very short instruction can be highly effective when it changes the interaction pattern in a precise way. The quality test is whether the skill reliably produces a useful procedure, not how much text it contains.
Key Takeaway
Encode repeated engineering work as reusable skills, but control context aggressively. Start from a clean baseline, add only proven value, and use human-invoked procedures for strategic workflows.