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
- Resolve the target skill or prompt chain. If the user names a path, stay on
that path and its directly linked resources.
- Read repo instructions first: nearest
AGENTS.md, plugin manifests, and the
target SKILL.md frontmatter/body.
- 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.
- Audit the contract before editing. Use Audit Checklist
and Reference Patterns as lenses.
- 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.
- 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:
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.
1---2name: skill-review3description: Use when reviewing Codex, Qoder, or repo-local skills and their prompt chains for trigger quality, workflow clarity, progressive disclosure, duplicated instructions, template ownership, output readability, validation gaps, or whether a skill should be edited.4---56# Skill Review78Review a skill as an execution contract, not as prose. Trace how an agent would9enter, load, delegate, produce artifacts, and verify results; then report the10smallest changes that would improve that chain.1112## Review Workflow13141. Resolve the target skill or prompt chain. If the user names a path, stay on15 that path and its directly linked resources.162. Read repo instructions first: nearest `AGENTS.md`, plugin manifests, and the17 target `SKILL.md` frontmatter/body.183. Trace the chain from entrypoint to references, templates, scripts, detectors,19 tests, generated artifacts, and validation commands. Build an ownership map:20 what file owns workflow, output structure, runtime rules, style, and tests.214. Audit the contract before editing. Use [Audit Checklist](references/audit-checklist.md)22 and [Reference Patterns](references/reference-patterns.md) as lenses.235. If the user asked for changes, patch only the smallest owning files. Keep24 generated helpers, smoke scripts, and local experiments outside `SKILL.md`25 unless they are durable resources the skill must use.266. Validate with the lightest real gate available: skill validator, repo tests,27 plugin validation, or a bounded agent smoke. State any gate that could not be28 run.2930Use subagents only as an evaluation surface or for independent broad research.31The lead agent owns the review, final calibration, and file edits. Pass raw32artifacts and task-local scope to subagents; do not pass the intended answer.3334## Review Lenses3536- [Audit Checklist](references/audit-checklist.md): trigger contract, progressive37 disclosure, workflow/delegation, template ownership, readability, evidence.38- [Reference Patterns](references/reference-patterns.md): reusable design lenses39 such as Trigger/Protocol split, Gate Function, and Output Contract Slots.40- [Fast Inspection Commands](references/inspection-commands.md): starting `rg`,41 `wc`, and `git diff --check` probes adapted to the repo.4243## Finding Severity4445- **P0**: The skill points to missing, empty, contradictory, or invalid resources;46 an agent can follow the instructions and fail.47- **P1**: The skill works but wastes context, duplicates ownership, hides key48 constraints, or produces unreadable output.49- **P2**: Style, naming, wording, or organization issues that reduce scanability50 without breaking the workflow.5152## Report Shape5354Lead with findings, ordered by severity. Keep each finding concrete:5556```text57P1 - <short title>58File: <path>:<line>59Why it matters: <execution or output risk>60Evidence: <quoted phrase, command result, or linked resource>61Fix: <smallest owning-file change>62Validation: <command or smoke that should prove it>63```6465After findings, add open questions only when they block a safe change. If the66user asked for edits, include changed files and validation results after the67findings. Default to the user's language.
tuyv