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.
Scanned 8/31/2026
Install to Claude Code
npx -y skills add QoderAI/better-harness --skill skill-review --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Skill Review?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/qoderai-skill-review)More formats (shields.io, HTML) on the badges page.
---
name: skill-review
description: 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.
---
# 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.
2. Read repo instructions first: nearest `AGENTS.md`, plugin manifests, and the
target `SKILL.md` frontmatter/body.
3. 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.
4. Audit the contract before editing. Use [Audit Checklist](references/audit-checklist.md)
and [Reference Patterns](references/reference-patterns.md) as lenses.
5. 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.
6. 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](references/audit-checklist.md): trigger contract, progressive
disclosure, workflow/delegation, template ownership, readability, evidence.
- [Reference Patterns](references/reference-patterns.md): reusable design lenses
such as Trigger/Protocol split, Gate Function, and Output Contract Slots.
- [Fast Inspection Commands](references/inspection-commands.md): 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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!