You installed another agent skill because the last output missed the mark. Now the agent has more instructions, but its work is not clearly better. It may be less consistent, harder to steer, or oddly generic.

The missing ingredient is usually not another skill. It is curation: deciding which skills deserve access to the agent, which need to be adapted to your business, and which should be removed before their assumptions collide.

A skill installs someone else’s operating decisions

An agent skill is not just a capability switch. In practice, it is a package of instructions and, sometimes, scripts, resources, tool rules, or examples. It can encode which tools to use, which shortcuts are acceptable, what good work looks like, when approval is required, and when the job is considered complete. Installing one therefore imports someone else’s decisions about the job.

That is useful when the job is narrow and the assumptions match yours. A mechanical transformation with an unambiguous result travels well. A skill that renames files according to a fixed convention is easier to evaluate than one that promises to create a compelling product strategy.

The risk increases as the skill takes responsibility for judgment. Brand voice, design taste, customer segmentation, prioritization, risk tolerance, and approval boundaries are local. A skill can run exactly as designed and still produce the wrong result for your company.

Before approving a skill, inspect it as you would inspect a new operating procedure. Ask:

• What exact job is this skill supposed to perform?
• Which tools, files, systems, or data can it use?
• Where does it make a judgment instead of following a mechanical rule?
• What business rules, stylistic preferences, and definitions of quality are embedded in it?
• Which actions require human approval?
• What condition tells the agent that the work is finished?
• Which existing skill already claims part of the same job?

If you cannot answer those questions, the skill is still a candidate. Installation only proves that the files are present. It does not prove that the skill improves the work.

Why a crowded skill library can produce weaker work

Skill overload is not simply a storage problem. Your inactive archive can be large without affecting a task. The important distinction is between everything you own and the active, discoverable set the agent must interpret while deciding how to work.

Codex and Claude Code place limits on how much of a skill catalog the model can see. As the catalog grows, some skill descriptions may be trimmed from the discovery context. A skill can therefore remain installed while becoming less likely to be considered for the job that needs it.

Visibility is only one failure mode. Overlapping skills can also disagree about tools, sequence, tone, quality, or completion. The model must resolve those conflicts during execution. The result may be a compromise that satisfies none of the original intentions: competent-looking work with its sharp decisions averaged away.

Failure mode	What you notice	Curation response
Discovery crowding	A relevant installed skill is ignored, or a similarly named skill is selected instead.	Reduce the active set, narrow the descriptions, and verify what the agent can actually see.
Instruction collision	The output mixes incompatible workflows, tones, tools, or definitions of done.	Choose one authoritative skill for the job or merge the required rules into a maintained local version.
Imported taste	The result is technically sound but consistently wrong for your brand, product, or customers.	Fork the useful mechanics and replace the subjective criteria with your own.
Boundary drift	The agent takes actions, uses systems, or skips approvals that do not fit your operating model.	Make permissions and approval points explicit before the skill can be approved.
Duplicate coverage	Several skills claim the same job, and invocation becomes unpredictable.	Keep one default, scope any exception narrowly, and remove the duplicate from active discovery.

Do not turn twenty-five skills into a universal maximum merely because conflict becomes visible in a library of that size. The practical limit depends on the platform, description length, overlap between jobs, and how skills are exposed to the model. Treat the number as a warning that accumulation has a cost, not as a governance policy.

You can inspect the real problem directly. Start a representative session and ask the agent to enumerate the skills available for the job, explain which one it would select, and identify any conflicting instructions. This is not a complete evaluation, but it reveals whether your intended skill is visible and distinguishable before you spend time debugging its execution.

Use one real job as the admission test

A skill should earn admission with the work you actually need, not with a polished demonstration chosen to flatter it. The most useful starting point is a one-job test: hold the task conditions steady, compare the result with and without the skill, and make an explicit decision.

1. Name one job narrowly. Use a real recurring task, such as turning an approved product brief into release notes, rather than a broad goal such as improving product communication.
2. Write the acceptance criteria before running the skill. Include required content, forbidden behavior, approval points, and the evidence a reviewer will use to judge the result.
3. Capture a baseline. Run the job with the same model, inputs, available tools, and relevant context, but without the candidate skill.
4. Inspect the candidate. Mark every embedded tool choice, shortcut, subjective preference, business rule, approval boundary, and completion condition that could alter the result.
5. Run the same job with the skill enabled. Preserve the output and note any human intervention needed to finish it.
6. Rerun the comparison. Look for repeatability rather than rewarding one unusually good output. If the behavior changes, record how and where.
7. Compare the evidence and decide: keep the skill, fork it for local use, or delete it from the active library.

Evaluate the dimensions that matter for that job. Those may include factual correctness, required coverage, compliance with business rules, unauthorized actions, consistency, reviewer effort, and the amount of editing needed before use. Define pass and veto conditions in advance. Otherwise, a fluent result can persuade you to overlook a failure that would have disqualified it at the start.

The decision rules should stay simple:

• Keep it when the skill creates a meaningful, repeatable improvement without introducing a more important failure.
• Fork it when the workflow mechanics are valuable but its taste, terminology, business rules, tools, or approval model do not match yours.
• Delete it from the active set when it adds no clear value, increases correction work, behaves unpredictably, or duplicates a better-owned skill.

One job is an admission test, not proof that the skill is universally good. Scope the approval to the job you evaluated. If another team wants to apply it to a different workflow, that is a new claim and should receive its own test.

Keep a nine-line test record

A lightweight record prevents the decision from dissolving into “this felt better.” A nine-line record is enough to make the result reviewable later:

1. Skill name and version
2. Accountable owner
3. Job being tested
4. Baseline artifact or saved output
5. Acceptance criteria and veto conditions
6. Model, inputs, tools, and relevant configuration
7. Observed result and correction work
8. Keep, fork, or delete decision with rationale
9. Trigger for the next review

Store the record beside the skill, not in a disconnected project document. The next person inspecting the folder should be able to see what the skill is authorized to do, why it exists, and which evidence justified keeping it.

Turn the collection into a governed skill portfolio

The scalable unit is not the individual install. It is the portfolio: the set of skills made available to a role, workflow, or agent, along with ownership and evidence. This is where product leadership matters. You are deciding which operating assumptions can enter the system and who must maintain them when the business changes.

Separate the inventory from the active working set. The inventory can preserve experiments, vendor packages, local forks, and deprecated versions. The active set should contain only the skills that are approved and relevant to the agent’s current responsibility. A support agent, product discovery agent, and engineering agent do not need to inspect the same universal catalog.

Give every skill a lifecycle state:

• Candidate: installed in a test environment but unavailable to routine production work.
• Approved: evaluated for a named job, assigned an owner, and exposed only where that job occurs.
• Deprecated: removed from active discovery while its history and test evidence are retained for traceability.

An approved skill should also have a selection contract. Its name and description must tell the agent what job it owns, when it should be invoked, when it should not be invoked, and which neighboring skill owns an easily confused task. Vague descriptions such as “helps with product work” force the model to guess. A description such as “converts an approved product brief into customer-facing release notes; does not create positioning or approve claims” gives the agent a usable boundary.

Assign one accountable owner even when many teams use the skill. That owner does not need to write every instruction, but someone must resolve conflicts, approve local forks, and rerun the test when a dependency changes. A skill with no owner is an unmaintained policy embedded in automation.

Review should be triggered by change, not merely by the calendar. Retest when the underlying model changes, a required tool is replaced, a business rule moves, the skill gains broader permissions, a new skill overlaps its job, or users report a recurring output regression. The prior test demonstrated behavior under prior conditions. It cannot approve a materially different system by inheritance.

Most importantly, do not respond to weak output by immediately installing another skill. First inspect which skills were visible, which were invoked, and which instructions conflicted. Adding a new instruction package to repair an unexplained failure can deepen the same overload that caused it.

Key takeaways

• An installed skill is an imported set of operating decisions, not proof of improved capability.
• The relevant constraint is the active, discoverable working set, not the total number of folders in your inventory.
• Test a skill on one real job against a controlled baseline before approving it.
• Keep it when it improves the job, fork it when the mechanics are useful but the judgment is wrong, and remove it when it adds no defensible value.
• Record the evidence, owner, scope, and review trigger beside the skill.
• When output degrades, inspect visibility and instruction conflicts before adding another skill.

Choose one recurring workflow this week and list every skill that can influence it. Run the one-job test on the least understood candidate first. By the end, it should have an owner and evidence-backed scope, a local fork with corrected assumptions, or no place in the active set.

References

• Nate Jones’s Substack – Twenty-five skills in, your agent is averaging out their conflicts and handing you duller work than it did at five.

---