Creating good Skills
How to scope and write a Skill that the AI follows reliably.
A Skill is only as good as the judgment it hands off. If it's vague, the AI either ignores it or misapplies it. If it's scoped well, you can actually trust its behavior on a real ticket. Here's how to write ones that hold up.
25,000 characters on Instructions
That's where the limit actually lives. Title, description, trigger phrases, and things to avoid all get more room. Instructions get capped tighter to keep the AI reasoning through the ticket in front of it instead of running a script, and it's more than a well-scoped Skill needs anyway. If you're bumping up against it, that's rarely because the situation needs more space. More often the Skill covers more than one situation, or it's over-explained: spelling out branches and reasoning the AI would already get right if you just gave it the decision and the guardrail.
Scope one situation
A Skill should cover a single recognizable situation: "Pam Beesly is locked out of her Microsoft 365 account after repeated failed sign-in attempts," not "handle all account issues." Broad Skills force the AI to guess which part applies, and that guessing is where mistakes creep in. One "if this, but if that instead" is a normal branch, that's fine. A Skill that's collected several of them usually isn't one situation with options, it's a few different workflows crammed into one Skill. Split it.
Smaller, single-purpose Skills also run cheaper: less branching logic to evaluate per ticket, and less surface area for one wrong guess to cascade into the wrong action.
Rule of thumb
If you can't describe when a Skill applies in one sentence, split it.
Title and description: what the AI matches on
The AI picks a Skill by matching the ticket or conversation against its title, description, and trigger phrases. That's the entire mechanism, so all three need to say what the Skill is, what it does, and which situations it's for, not just name the topic.
- Weak: "Password issues."
- Better: "Reset a user's Microsoft 365 password after they're locked out following failed sign-in attempts."
The second version tells the AI exactly when to reach for the Skill, and rules out the cases where it shouldn't, like a customer who's simply forgotten their password with no lockout involved. A description that only names the topic gives the AI nothing to rule out.
Trigger phrases: match what shows up in a ticket
Trigger phrases are a separate field from title and description, a list of phrases the AI matches directly against incoming tickets. Write them the way your techs actually talk, not the way you'd summarize the situation for a manual.
If a ticket would say "Pam locked out again, 5 bad attempts on the portal," that phrasing belongs here, not "credential lockout event." You're matching against what actually shows up in a ticket, not a category label.
Add a few variants if your techs word it differently person to person. That's more useful than one phrase written to sound official.
Instructions: write the exact steps
List what the AI should actually do, in order, the same way you'd write it for a new technician.
- One action per step.
- Keep it linear.
- Start each step with a verb where you can.
- If a step needs a condition, put it in a sub-step underneath instead of folding it into the same sentence.
- Check the user and reset their password, then update the ticket if the reset was successful.
The bad version buries a decision, what happens if the reset fails, inside a sentence about something else. The good version pulls that decision out into its own sub-step, so it's something you can see instead of something buried in a clause.
Share the draft before it acts
For any step that writes something a customer or another tech will see, tell the AI to share the draft with you first: a ticket note, a time entry, a new doc it's about to publish. You read it, fix anything off, and only then does it go out.
This matters most for anything that's annoying to undo. A wrong ticket note or a published doc with the wrong customer's name on it is a cleanup job, not a typo.
Build the review step into the Skill
This only happens if the Skill's instructions ask for it. Add a step like "share the note with me before posting it" wherever the AI is about to write something durable. Nothing else is checking for it.
Things to avoid: the hard guardrails
Things to avoid is where the non-negotiables live: the things the AI should never do, regardless of how the ticket reads. Once something is in there, you don't need to repeat it in the instructions above, and you don't need to explain it either.
Skip the background paragraphs. The AI already knows what a password reset is and why MFA matters. Every sentence in a Skill competes with the actual ticket content for the AI's attention, so spend the space on decisions, parameters, and guardrails, not theory it already has.
Don't write the exact response you want the AI to give, either. "Reply with: your password has been reset and emailed to you" scripts an outcome that might not have happened. Describe the outcome you want and let the AI report what the tools actually returned, so a failed send gets reported as a failed send instead of a canned success message.
A full example: resetting Pam's password
Here's a Skill for the lockout scenario above, written the way the tips on this page would produce it.
Title: Reset Microsoft 365 password after lockout
Description: Resets a locked-out Microsoft 365 account. Use when a user or their manager reports being locked out, or a connected RMM or PSA shows repeated failed sign-in attempts on one account in a short window. Doesn't apply to a plain forgotten-password request with no lockout, route that to self-service reset instead.
Test before you trust it
Run it against a real ticket
Use a recent or live ticket that matches the Skill's trigger, and watch what the AI actually does with it, not just what it says it would do.
Check the edge of the scope
Try a ticket that's close to the trigger but shouldn't match. If the Skill fires anyway, tighten the description.
Review real chats and adjust
Read back through how the AI actually used the Skill, not just whether it fired. If it matched the right ticket but did the wrong thing, the fix is almost always a missing or ambiguous step. If it did something you didn't want, that's a Things to avoid entry. Add it and re-test.
Keep it current
A Skill that documents a procedure you've since changed is worse than no Skill. It steers the AI wrong, and it does so with the same confidence as a Skill that's actually correct. When a customer's tooling, contacts, or approval chain changes, update the Skill too.