[Vendor] [Topic] · diff
git:20260728.b7e78fc to git:20260804.99bca6f
19 added, 0 removed. Audit A to A.
---
name: "[Vendor] [Topic]"
description: >
[What this skill covers — the domain knowledge inside: entities, API
surface, workflows, gotchas. One clear statement of coverage; do not
restate the trigger conditions from when_to_use.]
when_to_use: >-
When [specific action or scenario that should trigger this skill].
Use when: [keyword 1], [keyword 2], or [phrase that triggers this skill].
---
# [Skill Title]
<!--
Structure guidance (delete this comment in real skills):
- Keep SKILL.md lean. It should carry the knowledge Claude can't infer
from the API itself: domain concepts, non-obvious constraints,
workflow shape, and gotchas.
- `description` and `when_to_use` have distinct jobs — coverage vs.
trigger conditions. Don't duplicate content between them, and never
add a `triggers:` list.
+ - `when_to_use` routes work *in*; `## Anti-triggers` routes it *out*.
+ Only add the section where a sibling skill is genuinely confusable —
+ see the guidance above that section.
- State each instruction once. No repetition for emphasis, no ALL-CAPS
warnings unless something genuinely destroys data or money.
- Skip any section below that would only hold generic filler. A skill
with three real gotchas beats one with eight boilerplate sections.
- Progressive disclosure: if SKILL.md grows past ~350 lines, move
exhaustive reference material (full field tables, complete error
catalogs, long request/response examples) into `references/*.md`
files in this skill's directory and link them from the relevant
section. SKILL.md keeps the concepts and workflows; references hold
the lookup tables.
-->
## Overview
One short paragraph: what this domain is and what an MSP does with it.
+
+ ## Anti-triggers
+
+ Where this skill gets loaded by mistake, and what to load instead. One
+ bullet per case, each naming the correct destination skill:
+
+ - **[Neighbouring concern]** — use `[vendor]-[other-skill]` instead.
+ - **[Adjacent vendor with overlapping vocabulary]** — this skill only
+ speaks the [Vendor] API.
+
+ Include this section **only** when a real routing mistake exists: a
+ sibling skill in the same plugin covering an adjacent entity, or another
+ vendor sharing this one's vocabulary. Two skills whose names alone
+ disambiguate them do not need it. A bullet that just negates the
+ `when_to_use` ("do not use for non-[Vendor] questions") is filler —
+ cut it.
## Key Concepts
The entities, relationships, and terminology Claude needs before touching
the API. Prefer a compact table for enums and status codes. If the full
field reference is long, summarize the important fields here and link the
complete table:
See [references/fields.md](references/fields.md) for the complete field reference.
## Common Workflows
### Workflow name
1. Step one
2. Step two
Include decision points and the non-obvious ordering constraints. Skip
workflows that are just "call the endpoint."
## API Patterns
The request shapes that aren't guessable — auth quirks, pagination
casing, filter syntax. Link `references/api.md` for the exhaustive
endpoint catalog if it's long.
## Gotchas
The section that earns the skill its tokens: rate-limit behavior,
case-sensitive parameters, fields that silently drop, errors whose
messages mislead. Each entry: what happens, why, what to do instead.
## Related Skills
Only if the links genuinely route the reader somewhere (e.g., a shared
auth skill). Omit otherwise.