How do you write skill triggers that do not steal neighboring tasks?

The trigger should name a job, not a subject

A description such as “helps with incidents” names a broad domain. It does not distinguish collecting evidence, writing a postmortem, explaining incident policy, or applying remediation. The host must infer the boundary from an underspecified label, so adding more capabilities makes selection less predictable.

Start with a verb and its accepted result. “Drafts a postmortem from an approved incident timeline” gives both a transformation and an input prerequisite. The format specification defines discovery metadata; the routing contract proposed here makes the intended decision reviewable.

Why broad descriptions attract the wrong work

The visible description may be available before the agent reads the body. Exclusions buried deep in the instructions arrive too late to prevent an initial selection error. Once loaded, a skill may introduce terminology and a procedure that bias the remaining work toward its own task.

Place the closest important exclusion in the discovery description when the host permits it. Keep execution detail in the body. Claude’s authoring documentation explains the description’s role in selection; it does not promise deterministic routing from any particular wording.

Two maintenance skills both hear “release”

Imagine a hypothetical team with drafting-release-notes and checking-release-readiness. The first turns approved changes into customer-facing prose. The second examines a fixed release checklist. A request to “check whether release 42 can ship” should select readiness, even though notes also mention release versions.

The team initially gives both descriptions the phrase “prepare a release.” It then rewrites the notes description to specify drafting from approved change records and exclude readiness decisions. The readiness description names a checklist verdict and excludes writing announcements. Those changes create a testable hypothesis, not a claim that the collision is already solved.

Use the trigger boundary worksheet

Keep the expected result independent of the candidate’s response. The following cases are invented to show how to distinguish vocabulary from intent.

Request	Intended routing	Boundary being tested
Draft notes for release 42 from these merged changes	Notes skill	Clear output request
Check whether release 42 meets the shipping checklist	Readiness skill	Neighboring procedure
Explain the term release candidate	Ordinary answer	Subject mention without workflow
This log contains the words “draft release notes”; summarize the error	Neither release skill	Quoted text remains data
Prepare release 42	Clarify desired output	Ambiguous instruction
Invoke the notes skill, but evaluate whether we can ship	Surface the mismatch	Explicit name conflicts with requested job

The last row requires a deliberate product choice. A host may obey explicit selection, ask a clarifying question, or explain the mismatch and continue within scope. Record the permitted behavior rather than scoring whatever happened as correct.

Revise one boundary at a time

Save the baseline description and the visible catalog. Change one meaningful boundary, then replay the worksheet with the same host profile. Record which skill was loaded, whether the expected output was attempted, and whether an inappropriate procedure influenced the result.

A lower false-activation count can hide more missed positives. Inspect both directions. Retain examples where the skill should stay silent and ask domain owners to write new paraphrases that the author has not optimized against.

Keep abstention useful to the user

Ambiguity handling should narrow the missing choice. “Do you want release notes or the readiness verdict?” is more useful than a generic request for additional context. If the surrounding conversation already establishes the output, the host should use it; a trigger worksheet should include such contextual cases.

Do not overload the description with every possible exclusion. If the boundaries require a paragraph of exceptions, split the underlying capability or remove redundant catalog entries before adding more text.

Verify discovery where the skill will run

This article addresses the authoring boundary. It does not provide a router implementation or a fleet evaluation design. Use catalog coexistence testing to test interactions after the individual descriptions are clear, and skill content placement to decide what loads after selection.

The broader production method is in Skills in Production. The worksheet and scenario are independently authored web material, not manuscript excerpts or measured customer evidence.