Content
88%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The body is a dense, actionable triage procedure: concrete gh commands, explicit validation checkpoints and feedback loops, and an end-of-work checklist. Its main weakness is prose density in the decision steps, and it relies on references into the source repo rather than a bundled reference file for gate details.
Suggestions
Break the dense step 2 and step 4 paragraphs into short bulleted decision rules so each rule is scannable on its own.
Move the "How the gate works" details into a referenced file (e.g. references/gate.md) and keep only the assignment-relevant summary in the body.
Consider including the third verdict ("maintainer decision needed") in the description's action list so all outcomes are named up front.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section carries repo-specific policy (gate mechanics, contribution categories, contributor heuristics) rather than concepts Claude already knows, but steps 2 and 4 are dense multi-clause paragraphs that could be tightened into shorter bullets. Not 5 because sentences like "Maintainers own design opinions: do not require the contributor to obtain or settle the maintainer's preference" pack several rules into one line. | 4 / 5 |
Actionability | Fully executable guidance throughout: exact `gh issue view`/`gh pr list` commands with --json field lists, `gh issue edit N --add-assignee <login>` for the verdict action, and the body-file pattern for authorized comments, all pinned to the specific repo. | 5 / 5 |
Workflow Clarity | A clearly sequenced 7-step procedure with explicit validation checkpoints ("check that the tests fail without the fix", "Confirm the require-issue-link run passes and the PR reopens"), a feedback loop for error recovery ("If that run fails... investigate the run rather than re-assigning"), and a closing "Check before finishing" checklist. | 5 / 5 |
Progressive Disclosure | Well-organized sections with clearly signaled one-level-deep references to the gate workflow file, contribution policy, and the review-pr skill. Not 5 because at ~73 lines the gate-mechanics section ("How the gate works") is inlined where a reference file could keep the procedure leaner, and the external repo paths cannot be verified from the skill directory. | 4 / 5 |
Total | 18 / 20 Passed |