Before adding another agent skill that covers an existing workflow, check whether the team’s required behavior survives with both installed. A finished report is an incomplete acceptance test: another perfectly legitimate skill may produce a different kind of report and omit the details your team relies on.
This guide concerns instruction packages containing SKILL.md, not employees’ AI abilities. The practical decision is whether two packages should remain available for the same work, have their scope separated, or be consolidated under an accountable owner. The method below is an editorial proposal with a fictional example. We have not run these packages in an assistant.
Start with what the team must receive
Our earlier skill activation guide separates availability, loading and execution. Here the question starts after installation: does a useful skill retain its distinctive requirements when another useful skill competes for the same request?
Write those requirements outside either package before comparing them. Otherwise, the selected package can end up defining its own passing grade. Distinguish requirements of the business task from preferences for one particular template. A different heading is usually less consequential than losing a source identifier or taking an unauthorized action.
For a small team, this can be a short acceptance record beside the skill. A larger organization can use the same record in its controlled workflow documentation. Give each requirement an owner and an observable check. Record which ones are shared by both packages, unique to one, or contradictory. A contradiction needs a decision by the workflow owner; asking the model to combine incompatible instructions does not resolve it.
The Agent Skills specification defines a package with metadata, instructions and optional resources. That common format is useful for distributing procedures. It does not establish that two procedures describe the same business contract.
Research finds a gap between finishing and preserving requirements
Yan and colleagues’ One Skill Too Many, submitted on 8 October 2026 and revised on 13 October, studies similar, benign skills installed together. The authors distinguish substitution, where another skill is used instead, from interference, where the intended skill is used but its behavior changes. Their experiments find that task completion can conceal lost requirements unique to the intended skill.
The full experiment used Claude Code 2.1.283 with Sonnet 4.6, Haiku 4.5 and Opus 5; a smaller Codex check covered different models and fewer pairs. Cases were constructed around skill requirements, and evaluation combined scripts with model judgments. The researchers increased the skill-listing budget to prevent description truncation. Most conditions ran once, with a subset repeated. These are important limits on applying the findings to an ordinary installation.
We inspected the methods and limitations, not just the abstract. This preprint is evidence for including requirement checks in an evaluation; it is not a current failure-rate estimate for your product, nor an independent test by Skills for Business.
Separate name resolution from overlapping purposes
Two questions need separate answers. Which package does a particular command select? And, when several packages could handle a natural request, which procedure is appropriate?
Current Claude Code documentation says that, among enterprise, personal and project skills sharing a directory or file name, enterprise takes precedence over personal, and personal over project. Plugin skills use namespaced commands and can coexist with those skills. These are documented Claude Code rules, not a universal property of Markdown packages.
OpenAI’s Codex documentation says that skills sharing the same name are not merged and both can appear in selectors. Do not transfer a precedence assumption from one product to another.
There is even a documentation discrepancy worth handling explicitly. The Agent Skills client implementation guide recommends deterministic resolution and describes project-over-user precedence as a universal convention. That description does not match the Claude Code rule above. For an operational decision, consult the target product’s current documentation and observe the actual package selected where the surface exposes it.
A practitioner explainer from Skill Check highlights the practical symptom: editing the wrong copy can leave behavior unchanged. It also describes plugin namespaces as preventing conflicts. Read that narrowly as avoiding a command-name collision; our recommendation is to check overlapping purposes even when commands have distinct names.
A fictional receivables brief with two reasonable workflows
Imagine a finance operations team with an invoice-exceptions skill. Its weekly review brief must retain overdue invoices, disputed invoices and invoices with missing due dates. Every retained item must carry its source identifier. The assistant prepares a draft only; contacting customers requires a separate decision.
An employee also enables a finance-digest package that summarizes overdue balances. It may be useful for a different report. Neither package needs to be malicious for a request such as “prepare this week’s receivables review brief” to expose a mismatch.
Use these invented records as a proposed fixture, with an explicitly supplied review date:
| Record | Supplied condition | Required treatment in this team’s brief |
|---|---|---|
| INV-41 | Due date is missing | Include as unresolved; do not classify as overdue |
| INV-42 | Disputed, with a due date after the review date | Include as disputed, without calling it overdue |
| INV-43 | Due date is before the review date; no dispute recorded | Include as overdue |
An overdue-only digest might correctly retain INV-43 for its own purpose. For this team’s review, omitting INV-41 and INV-42 fails the agreed contract. A fluent summary, correct arithmetic or attractive layout would not repair that omission.
Freeze four acceptance checks before running the comparison: all three required identifiers appear; the supplied states remain distinct; no missing date is invented; and no customer message or ledger update is attempted. Check attempted actions using the available trace, rather than inferring them from the final text. Where an action is technically prohibited, enforce that boundary in the environment as well as stating it in the task.
This fixture tests workflow selection and retained requirements. It is not an accounting policy, a product benchmark or a record of actual customer invoices.
Compare the combination, then choose a remedy
Keep the request, fictional inputs, product configuration and starting state fixed. Use fresh sessions so a previously loaded package does not carry into another condition. Record exact package revisions and installation scopes, including any personal or plugin copy that the team’s repository does not control.
Our proposed comparison is deliberately small:
| Available packages | Question the condition answers |
|---|---|
| Team skill alone | Can the intended workflow satisfy the agreed checks? |
| Digest alone | What does the alternative procedure preserve or omit? |
| Both, as employees normally have them | Does the actual combination retain the team’s contract? |
| Both, with supported explicit selection of the team package | Does resolving selection change the result? |
Explicit selection must identify the intended copy through the target product’s supported mechanism. Repeating an ambiguous short name is not evidence that the ambiguity was removed. If the surface cannot expose which copy loaded, record that limitation.
Keep separate fields for selected-package evidence, completed deliverable, each acceptance check and attempted actions. Repeat important conditions to determine whether an apparent difference persists. This proposed comparison can reveal a local problem; a handful of runs cannot estimate a general reliability rate.
Choose the remedy from the observed defect. If the wrong copy wins name resolution, remove or rename the unintended copy through the supported installation process. If different names still attract the same requests, narrow their descriptions around distinct business purposes and retest neighboring requests. If both packages are meant to govern one procedure, reconcile their requirements into one maintained workflow instead of leaving the choice implicit.
Do not consolidate packages merely because their titles sound similar. One may serve a different team or intentionally produce a different artifact. Preserve that use case with a clear selection boundary. Conversely, keep mandatory acceptance requirements in the review process even after consolidation, so a later revision cannot silently redefine success.
For the next proposed skill installation, list the existing package that covers adjacent work and identify one requirement the new package could cause the team to lose. Run the intended combination against that requirement before routine use. Keep the installation decision and evidence with the skill update comparison, so future maintainers can see why both packages remain—or why one was removed.