A skill that undertriggers never activates when you need it. A skill that false-positives activates on prompts it has no business handling. Both look like "inconsistent behavior" in the first five minutes of debugging. The test that separates them takes ten minutes and a spreadsheet. AEM has built this diagnostic from production work across 30+ commissioned Claude Code skills.
TL;DR: Undertriggering and false-positives are opposite Claude Code skill description failures. Undertriggers have descriptions too passive or too narrow to fire reliably. False-positives have descriptions too broad or missing explicit exclusions. A 10+10 prompt test — 10 should-trigger, 10 should-not — tells you which problem you have before you touch the description.
What does an undertriggering Claude Code skill look like in practice?
An undertriggering Claude Code skill has one reliable tell: manual invocation works, automatic activation does not. Type /code-review and the skill runs correctly. Type "let's review this PR" and Claude handles it from scratch, generating a generic response without the skill.
This is the more common failure mode. Community testing across 650 activation trials found passive description styles ("This skill helps with code review tasks") achieve 77% activation on matched prompts (Claude Code activation research, 2025). Directive, imperative descriptions ("Review this code for security vulnerabilities and code quality") reach 100%. The content is identical. The grammatical construction is the only variable.
The second undertrigger cause: accurate but too narrow scope. A skill for reviewing React components with a description that mentions only "React components" misses "check my hooks" or "audit this context setup" — even though hooks and context are exactly what the skill covers. Anthropic's skill authoring best practices recommend front-loading trigger keywords in the first 50 characters of the description field, since Claude uses only that window when scanning across a library of 40 or more installed skills (Anthropic, skill authoring best practices, 2025).
Signs you have an undertrigger:
- Manual
/skill-nameinvocations work reliably - Natural-language requests that match the skill's domain get handled without the skill activating
- You have developed a habit of prepending the slash command to every relevant request as a workaround
For the specific fix, see How Do I Write Trigger Phrases That Make My Skill Activate Reliably.
What does a false-positive skill look like in practice?
A false-positive skill interrupts other work. You are asking about database schema migration and your content review skill activates. You are debugging a Python error and your documentation generator takes over. Your architecture review skill fires during standup notes. That is not a feature.
False-positive descriptions share three patterns:
Keyword traps. A description containing general terms ("This skill handles code improvement") matches nearly any coding conversation. There is no scope boundary in the description, so Claude has no basis for excluding adjacent topics. A Microsoft Research analysis of 1,470 MCP servers found 775 tool naming collisions, with "search" appearing across 32 distinct servers. Generic descriptions generate interference at scale (Microsoft Research, MCP tool-space interference, 2025).
Missing negative triggers. A description for a Python formatter that says nothing about "not for JavaScript" activates on JavaScript files too. Negative triggers are not optional defensive boilerplate. They are the specification. A description without them is an incomplete spec.
Overreaching trigger language. "Use this skill whenever you need to improve any file" reads as a directive covering everything. In projects with 4 or more installed skills, this pattern monopolizes 25-35% of session invocations on prompts the skill author never intended (AEM production observation across 30+ commissioned skills, 2025-2026).
False-positives are less common than undertriggers but more disruptive. An undertrigger makes you type an extra command. A false-positive breaks workflows you did not know were affected.
How do you design a test that separates them?
The 10+10 prompt test is the standard diagnostic: write 10 prompts that should activate the skill and 10 that should not, run each in a fresh Claude Code session, and count activations. The split between true positives and false positives tells you exactly which description problem you are solving before you change a single word.
- 10 prompts that should activate the skill
- 10 prompts that should not activate the skill
Run each in a fresh Claude Code session with no prior context. Count activations.
| Result | Diagnosis |
|---|---|
| Under 8/10 true positives | Undertrigger |
| Over 2/10 false positives | False-positive |
| Both | Complete description rewrite required |
The second list is where most skill authors fail. Engineers test positive cases carefully and write no negative test prompts at all. False-positives hide entirely in the "should not trigger" group.
"The failure mode isn't that the model is bad at the task — it's that the task wasn't specified tightly enough. Almost every production failure traces back to an ambiguous instruction." — Simon Willison, creator of Datasette and llm CLI (2024)
One practical shortcut: review your skill's recent activation history in session logs. Any activation that surprised you is a false-positive. Any session where you invoked the skill manually when it should have auto-triggered is an undertrigger. Skills with several weeks of production use surface both problems clearly.
For a broader diagnostic framework covering description, instruction, and reference loading layers, see How Do You Diagnose Whether a Skill Failure Is a Description Problem, Instruction Problem, or Reference Loading Problem.
What does the fix look like for each failure mode?
Undertrigger fixes rewrite passive descriptions as imperative commands and widen the trigger vocabulary to cover adjacent natural-language phrasings. False-positive fixes add a bounded inclusion scope and explicit negative triggers naming what the skill does not handle. Both are specification problems, and both have a targeted rewrite pattern that resolves them without touching the skill's instruction logic.
Undertrigger fix: change construction, widen trigger vocabulary
Before: "This skill helps with code review tasks when requested." After: "Review code for security vulnerabilities, logic errors, and quality issues. Activate on: code review, audit requests, PR review, 'check my code,' 'look at this file' phrases."
Three changes happen here: the construction shifts from passive to imperative, explicit trigger phrases cover natural-language variations, and the scope broadens to include adjacent phrases the author expects users to type.
False-positive fix: add scope constraints and negative triggers
Before: "Review and improve code files." After: "Review Python files for style, type errors, and test coverage. NOT for: JavaScript, TypeScript, CSS, YAML, configuration files, or documentation. Activate only when the file under discussion ends in .py."
The negative trigger list reads as defensive. It is not. It is a specification. Claude uses it to narrow activation. Without explicit exclusions, the description stretches to fill adjacent cases. In large tool environments, interference is measurable: Microsoft Research found large tool spaces lower agent performance by up to 85% on some models, with skill-selection accuracy degrading as tool count grows (Microsoft Research, MCP tool-space interference, 2025).
Every production-grade Claude Code skill we have built includes an explicit inclusion scope and an explicit exclusion list. Single-domain skills without negative triggers develop false-positive behavior in nearly every multi-skill project.
What are the limits of this diagnostic?
The 10+10 test catches systematic description failures. It does not catch context drift: a skill can pass all tests in a fresh session, then misfire in session minute 40 once unrelated context accumulates. Research confirms the mechanism: accuracy drops over 30% when relevant instructions sit in mid-context positions (Liu et al., Stanford NLP, TACL 2024).
Context-dependent activation is harder to test and harder to fix. The description is technically accurate, but accumulated context changes how Claude interprets activation intent. This pattern appears in roughly 1 in 8 production skills we have diagnosed at AEM. The fix is restructuring the trigger to reference the current file type or explicit task marker rather than relying on intent matching against general language.
For deterministic single-domain skills, the 10+10 test covers the risk. For skills that activate in varied linguistic contexts — audit skills, research skills, content review skills — add a third test battery: 5 prompts with heavy unrelated context already loaded in session before running them.
Related: My Skill Produces Great Output But Never Activates Automatically.
Frequently asked questions
Most undertrigger and false-positive problems trace back to two description errors: passive construction and missing scope constraints. The 10+10 test diagnoses which problem you have, and the rewrite patterns above fix it. The questions below address edge cases that appear after the initial fix is applied.
My skill passes the 10+10 test but still undertriggers in real sessions. Why?
Context contamination. A previous exchange primed Claude's attention toward a different domain, and the skill's description does not override strong existing context. Test in fresh sessions. If the problem persists, add an explicit trigger phrase that references the task type directly rather than relying on Claude to infer intent from natural language alone.
Can a skill be both an undertrigger and a false-positive at the same time?
Yes. A description written for one narrow use case but phrased too broadly undertriggers on intended prompts while false-positiving on adjacent ones. The 10+10 test surfaces both simultaneously: a low true positive rate combined with a high false positive rate means the description needs a complete rewrite, not a targeted tweak.
How many negative trigger phrases do I need?
In production work, 3-5 specific exclusions cover most false-positive cases. The goal is to exclude the most likely adjacent activations, not to write an exhaustive list. More than 6-7 negative triggers starts to crowd out positive trigger coverage within the 1,024-character description limit.
Do I need negative triggers in every skill?
Add negative triggers to any skill operating in a domain where other installed skills also operate. A single skill in a project with no peers can skip them. In any project with 5 or more skills, negative triggers are the mechanism that prevents cross-skill interference from scaling into cascading false-positives.
What's the fastest way to check whether a new skill will false-positive against existing skills?
Before installing, list the domains your existing skills cover. Read the new skill's description and ask: "Does this scope overlap with any existing skill?" If it does, add explicit exclusions before installing. Post-installation debugging costs significantly more time than pre-installation description review.
Last updated: 2026-04-20