Content
73%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 an unusually rigorous operational skill: a sequenced workflow with explicit preflight/closure checklists, validation via real evaluation results, exact commands, and a clean one-level routing table to six real reference files. Its main cost is redundancy — the same preflight and closure rules are restated across Workflow, Operating rules, preflight sections, and self-check — plus inline rule detail that belongs in the existing references.
Suggestions
Collapse the repeated preflight/closure rules into their single canonical sections: state each rule once in 'Required preflight' / 'Required closure preflight' and have the Workflow, Operating rules, and Minimum self-check reference them by name instead of restating them.
Push the 'Model-oriented repair heuristic' and the repo-mapping bullets from 'Operating rules' down into `references/value-triage.md` and `references/worktree-repair.md`, keeping the body to the workflow, routing table, and quick commands.
Add concrete request bodies for the two mutation commands (`PATCH /api/attributions/:issueId` and `POST /api/evaluations`) to the Quick commands block so every operation is copy-paste ready.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Individual lines are dense and operational, but the same rules are restated up to four times: the closure sweep appears in Workflow steps 10-11 ("Before changing an attribution to `resolved`, run a closure preflight..."), three Operating rules bullets, the entire "Required closure preflight" section, and two Minimum self-check bullets — likewise for the standard preflight. This matches the score-3 anchor (mostly efficient but could be tightened) rather than score-4, because the redundancy is systematic across sections, not just minor over-explanation; it stays above score-2 since nothing explains concepts Claude already knows and every line is operational. | 3 / 5 |
Actionability | The Quick commands block gives concrete, copy-paste-ready curl/gh/wt invocations (e.g. `curl -s 'http://127.0.0.1:5174/api/attributions?category=tool&resolutionStatus=todo&limit=50'`, `wt switch --create feature/attribution-<slug>`), and field names (`resolutionStatus`, `owner`, `notes`, `externalUrl`) are exact. It falls short of the score-5 anchor because two key mutations have no example payload — the `PATCH /api/attributions/:issueId` update and `POST /api/evaluations` appear only as bare commands with no body shape — leaving minor gaps against fully executable coverage. | 4 / 5 |
Workflow Clarity | The 12-step Workflow has an explicit sequence with ordered preflight checklists ("Required preflight", "Required closure preflight" with steps 1-5 and 1-5), explicit validation checkpoints ("run a post-PR evaluation and use the result... to decide whether to continue iterating or mark the issue closed", "Do not change `resolutionStatus` until you have read at least one related run's `result` and `trace`"), feedback loops for review comments, and a final self-check checklist. This matches the score-5 anchor — and despite involving batch operations over many issues, the batch/validation cap does not apply because validation and feedback loops are explicit throughout. | 5 / 5 |
Progressive Disclosure | The Routing table is a well-signaled, one-level-deep index to six real reference files (all six paths in the table exist in `references/`), and the body is structured into scannable sections. It falls short of the score-5 anchor because substantial detail that could live one level down is inlined instead — the ~25-bullet "Operating rules" list and the multi-paragraph "Model-oriented repair heuristic" duplicate concerns already covered by `value-triage.md`, `worktree-repair.md`, and `iteration-loop.md`, keeping the body longer than a true overview. | 4 / 5 |
Total | 16 / 20 Passed |