Write a skill description that matches the task

Choose a job with a recognizable start and finish. “Review a proposed repository change” is easier to identify than “improve engineering quality.” List the phrases you would naturally use when asking for that job.

The description should identify the purpose and the situations that call for the procedure. Avoid loading it with every related keyword; an overly broad description makes neighboring tasks hard to distinguish.

A procedure can be selected correctly and still lack what it needs. State the inputs in the body and explain what to do when an input is missing. For example, a review needs the requested behavior as well as the code change.

---
name: focused-change-review
description: Review a supplied repository diff against a stated requirement. Use when the user asks for actionable findings on a specific patch or change.
---

If the requirement or diff is missing, identify the missing input before concluding the review.

Positive case: “Review this patch against the empty-state requirement.” Neighboring case: “Explain how the empty-state component works.” The first asks for a review; the second asks for an explanation. Evaluate whether the resulting behavior respects that distinction.

Also try a request that says “review this” without supplying a change. A useful result asks for or locates the necessary context rather than inventing a patch. Record the actual behavior so you can compare a revision fairly.

If the wrong requests select the procedure, narrow the description. If the correct task produces the wrong output, revise the instructions or output contract. Keep these changes separate so you know which one helped.

• Open the evaluation worksheet

Primary source: Skill invocation and descriptions. Source checked September 10, 2026.