review-pr

Review a pull request for hacs_waste_collection_schedule and execute only approved fixes or review actions. Use when the user asks to inspect, fix, approve, or request changes on a PR.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Quality

Content

92%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An exemplary lean orchestration skill: a tightly written 8-step workflow with verbatim agent prompts, an exact command prefix for the policy hook, and strong approval/validation checkpoints around risky GitHub operations. The only minor gap is that artifacts like the 'Phase 1 report' and 'draft review' are referenced without defining where they come from. Scoring 4.7/5.

Dimension	Reasoning	Score
Conciseness	The body is a lean 8-step numbered workflow with zero concept explanations and no padding ('Spawn the `pr-reviewer` custom agent with:...', 'Prefix every approved GitHub-mutating shell command with `WCS_GITHUB_APPROVED=1`'). Every token earns its place, matching anchor 5.	5 / 5
Actionability	Highly concrete: a verbatim agent spawn prompt, an exact environment-variable prefix, named custom agents, and an explicit no-improvise failure policy. Minor gaps remain — the provenance of the 'Phase 1 report', 'URL', and 'draft review' referenced in steps 2-3 is not specified — so it fits anchor 4 rather than the fully copy-paste-ready anchor 5.	4 / 5
Workflow Clarity	A clearly sequenced 8-step process with explicit validation checkpoints around GitHub-mutating operations: ask for the PR number when missing (step 1), an explicit approval gate with three options (step 4), re-presenting material changes before execution (step 5), a stop-if-overwrite guard (step 6), and report-exact-failure handling (step 8). This matches anchor 5; the destructive-operation cap does not apply because validation and approval gates are present.	5 / 5
Progressive Disclosure	The skill is under 50 lines, single-purpose, and self-contained with no bundle files (references/, scripts/, assets/ do not exist), organized as a clean numbered list. Per the simple-skill exception, well-organized sections alone warrant anchor 5.	5 / 5
	Total	19 / 20 Passed

Description

78%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit 'Use when' trigger clause covering natural verbs (inspect, fix, approve, request changes) and a clearly scoped niche. Its main weakness is specificity: it names only a couple of concrete actions and 'review actions' is vague. Scoring 4.15/5.

Suggestions

Enumerate the concrete review/fix actions (e.g., 'post an approving review, request changes, or apply approved fixes to the source') instead of the generic phrase 'review actions'.

Add common trigger synonyms such as 'code review', 'review this PR', or 'review pull request' to broaden natural-term coverage.

Mention the repo or project context in the 'Use when' clause so the trigger itself carries the scoping and reduces overlap with generic PR-review skills.

Dimension	Reasoning	Score
Specificity	Names a tightly scoped domain ('Review a pull request for hacs_waste_collection_schedule') and roughly two concrete actions ('execute only approved fixes or review actions'), but coverage is not comprehensive and 'review actions' is somewhat generic. It lists fewer specific actions than the anchor-4 example, so it sits at anchor 3.	3 / 5
Completeness	Explicitly answers both: what ('Review a pull request... and execute only approved fixes or review actions') and when ('Use when the user asks to inspect, fix, approve, or request changes on a PR') with concrete trigger phrases. This matches anchor 5; anchor 4's caveat that 'when' could be more explicit does not apply.	5 / 5
Trigger Term Quality	'inspect, fix, approve, or request changes on a PR' gives good natural keyword coverage with both 'pull request' and 'PR' spelled out, but common variations like 'code review', 'review this PR', or 'LGTM' are missing. Good coverage with a few natural terms missing matches anchor 4, not the comprehensive synonym coverage of anchor 5.	4 / 5
Distinctiveness Conflict Risk	The repo-specific scoping (hacs_waste_collection_schedule) gives it a clear niche, but the trigger clause itself ('inspect... a PR') is phrased generically and could overlap generic PR-review skills. Mostly distinct with minor overlap risk matches anchor 4 rather than anchor 5's minimal-conflict profile.	4 / 5
	Total	16 / 20 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: mampfes/hacs_waste_collection_schedule
Path: .agents/skills/review-pr/SKILL.md
Commit: b081073

Reviewed: 8 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.