Skill Review

Review a skill as an execution contract, not as prose. Trace how an agent would enter, load, delegate, produce artifacts, and verify results; then report the smallest changes that would improve that chain.

Review Workflow

1. Resolve the target skill or prompt chain. If the user names a path, stay on

that path and its directly linked resources.

1. Read repo instructions first: nearest AGENTS.md, plugin manifests, and the

target SKILL.md frontmatter/body.

1. Trace the chain from entrypoint to references, templates, scripts, detectors,

tests, generated artifacts, and validation commands. Build an ownership map: what file owns workflow, output structure, runtime rules, style, and tests.

1. Audit the contract before editing. Use Audit Checklist

and Reference Patterns as lenses.

1. If the user asked for changes, patch only the smallest owning files. Keep

generated helpers, smoke scripts, and local experiments outside SKILL.md unless they are durable resources the skill must use.

1. Validate with the lightest real gate available: skill validator, repo tests,

plugin validation, or a bounded agent smoke. State any gate that could not be run.

Use subagents only as an evaluation surface or for independent broad research. The lead agent owns the review, final calibration, and file edits. Pass raw artifacts and task-local scope to subagents; do not pass the intended answer.

Review Lenses

• Audit Checklist: trigger contract, progressive

disclosure, workflow/delegation, template ownership, readability, evidence.

• Reference Patterns: reusable design lenses

such as Trigger/Protocol split, Gate Function, and Output Contract Slots.

• Fast Inspection Commands: starting rg,

wc, and git diff --check probes adapted to the repo.

Finding Severity

• P0: The skill points to missing, empty, contradictory, or invalid resources;

an agent can follow the instructions and fail.

• P1: The skill works but wastes context, duplicates ownership, hides key

constraints, or produces unreadable output.

• P2: Style, naming, wording, or organization issues that reduce scanability

without breaking the workflow.

Report Shape

Lead with findings, ordered by severity. Keep each finding concrete:

text
P1 - <short title>
File: <path>:<line>
Why it matters: <execution or output risk>
Evidence: <quoted phrase, command result, or linked resource>
Fix: <smallest owning-file change>
Validation: <command or smoke that should prove it>

After findings, add open questions only when they block a safe change. If the user asked for edits, include changed files and validation results after the findings. Default to the user's language.