Skill Guide: Turn Repeated Work Into Reusable Skills

AI picks your Skill based on one sentence you write

The AI reads the label, not the instructions

When AI created your in the previous chapter, it generated a description line in the . That line is the . Before you trust it, you need to understand what it does and how to evaluate it.

When you start a session, the AI does not read the full text of every you have installed. It reads only the name and description of each one. Think of it like reading the spines of books on a shelf rather than opening every book. This staged loading, called , keeps the AI's working memory from filling up with instructions it does not need yet. When you say something like 'Can you recap yesterday's call with the Meridian team?', the AI scans those short descriptions and recognizes that your meeting-recap matches. Only then does it open and read the full instructions.

A stylized teaching image showing a request being routed by a Skill description before the full Skill opens. — The description is the label that decides whether the full opens.

Weak descriptions cause real problems

If your description is vague, two things go wrong. The fires on conversations where it should not, applying the wrong procedure to the wrong task and producing confusing output. Or it fails to fire when you need it, and your carefully written instructions sit unused. Both waste your time.

Vague descriptions vs specific descriptions

Weak description	Why it misfires	Strong description
Helps with meeting follow-ups.	Too vague. Would fire on casual scheduling messages, calendar questions, and agenda planning, on top of actual recaps.	Use when the user drops a call transcript or mentions 'call recap,' 'meeting summary,' or 'action items from the call.' Produces a structured summary with decisions, owners, and a draft follow-up email.
Writing assistant.	Fires on every writing task. The AI cannot tell if you want an email, an article, or a proposal.	Use when the user asks to draft a client follow-up email after a call or meeting. Matches the user's voice using samples in references/voice-samples/.
Handles reports.	Which reports? Weekly status? Financial? The AI guesses.	Use when the user says 'weekly report,' 'status update,' or 'team summary.' Pulls highlights from the current week and formats them into the team's standard report template.
Client work helper.	Fires on everything client-related. Too broad to be useful.	Use when the user prepares for a client call and mentions 'call prep,' 'meeting prep,' or a specific client name. Produces a one-page brief with open threads, prior decisions, and discussion goals.

Three rules for strong triggers

Name the input shape

'When the user pastes a transcript' is far more reliable than 'when the user asks about meetings.' The input shape (a transcript, a draft, a folder of files, a set of notes) gives the AI a concrete input type to match against.

Name the output

'Produces a decision table with owners and deadlines' tells the AI what kind of work this does. Without this, the AI might activate the Skill but produce the wrong kind of output because it does not know what success looks like from the description alone.

List the phrases your future self will say

Think about how you will naturally ask for this task. 'Recap the call,' 'summarize the meeting,' 'what were the action items,' 'follow-up email from the call.' Put those phrases in the description. The AI matches against them. A is the explicit fallback when you want to force one to fire.

A stylized teaching image showing input, output, phrases, and skip case pieces forming one Skill trigger description. — A strong description is assembled from the input shape, the output, likely user phrases, and a nearby skip case.

A stylized teaching image showing run cases, skip cases, a boundary, and a near miss for Skill trigger testing. — testing works only when you test the near misses that should not open the .

descriptions tuned to four tasks you already repeat

Mini-project: stress-test and improve your description

Your turn

Test whether this Skill should fire

You'll stress-test a Skill description by simulating trigger decisions, analyzing near misses, and tightening the boundary.

Why this exercise matters

The description is the . Testing it with should-run and should-skip examples catches vague wording before the interrupts the wrong task or misses the right one.

You’ll leave with

A run-or-skip verdict for each example request with trigger word analysis
Near-miss analysis showing the smallest change that would flip each verdict
A revised description that fixes any misfires, plus edge cases for future testing

Use the prompt in order

1
Paste the description and examples
Provide both run and skip cases so the assistant tests the boundary around the instead of only confirming the happy path.
2
Check each decision
Review the words that caused each run-or-skip choice because those are the clues the description gives the AI at time.
3
Revise and retest
Ask for a tighter description when any case misfires so the becomes easier to invoke deliberately and easier to keep quiet.

Prompt details

Each detail will be inferred, or you will be asked to clarify in the chat.

3/3 details

3 details will be inferred, or you will be asked to clarify in the chat

Starter prompt text

Open the full text if you want to check what will be copied.

Show starter prompt

You are a Skill trigger evaluator. Your job is to stress-test a Skill
description by simulating how an AI assistant would decide whether to
activate the Skill for each request.

**Skill description to test:**
Infer from what you know about me or ask if it is unclear

**Requests where the Skill should run:**
Infer from what you know about me or ask if it is unclear

**Similar requests where the Skill should stay quiet:**
Infer from what you know about me or ask if it is unclear

**How to evaluate each request:**

1. Read the Skill description as if you are an AI assistant deciding
   whether to load this Skill for the request.
2. For each request, report:
   - **Verdict**: run or skip
   - **Trigger words**: which words in the description and request
     caused the match or non-match
   - **Confidence**: how obvious is the decision? Would a different
     phrasing of the request flip the verdict?
   - **Near-miss analysis**: what is the smallest change to the request
     that would flip the verdict? This reveals the boundary.
3. For any misfire (wrong verdict), propose:
   - The specific words in the description that caused the problem
   - A revised description that fixes the misfire without breaking
     the correct verdicts
   - A new edge-case request to test the revision against

**After all cases are evaluated:**

- Summarize the description's boundary: what it reliably catches,
  what it reliably skips, and where the boundary is fuzzy
- Propose a final revised description if any misfires occurred
- Suggest 2-3 additional edge cases worth testing in the future

What the answer should give you

You should receive a small table with each request marked run or skip, the trigger words that drove the decision, and revised description wording for any case that behaved incorrectly.

I reviewed the description AI generated for my .
The description names the input shape.
The description names the output.
I tested the description against should-fire and should-not-fire scenarios.
I asked AI to revise any misfires and verified the improvement.

References

2 sources

1
Agent Skills
OpenAI · 2026 · Codex Developer Documentation
Codex starts with each Skill's name, description, and file path, then loads SKILL.md only when it decides to use that Skill. Plugins are the distribution unit for reusable Skills and apps.
Checked May 10, 2026. Since Codex picks Skills based on the description alone, a vague or misleading description means a well-written Skill may never fire.
View source
2
Agent Skills Overview
Anthropic · 2026 · Claude Platform Documentation
Claude loads Skill metadata first, requires name and description frontmatter, and says the description should include both what the Skill does and when Claude should use it.
Checked May 10, 2026. The description should say both what the Skill does and when Claude should use it. Testing with examples that should trigger and examples that should not is the way to verify this.
View source