Content
92%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.
A tight, well-structured router body: zero padding, an explicit stage sequence with a real review-feedback loop, and clean one-level skill references. The only meaningful gap is that a few routing boundaries rest on undefined judgment terms rather than concrete criteria or examples.
Suggestions
Define or give a one-line example for the borderline gating terms — 'multiple meaningful implementation units', 'a missing decision that materially changes scope, behavior, or safety' — so the routing decision is mechanical rather than judgmental.
Add a brief tie-breaking rule for when a task is both a bug fix and a small feature, since steps 2 and 3 (TDD vs systematic-debugging) can both claim the same request.
Give one concrete example of 'valid findings' vs. dismissible findings in step 5 to make the review-fix feedback loop's exit condition unambiguous.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line is directive and earns its place — no concept is explained that Claude doesn't already know; the only near-explanatory line ('Mentioning a skill or paraphrasing it is not equivalent to loading it') is a real behavioral correction, not padding. The 25-line body matches the lean anchor and cannot be a 4 because there are no over-explanatory passages to trim. | 5 / 5 |
Actionability | Guidance is concrete and executable for an instruction-only router: each numbered rule names the exact skill to load and its trigger condition ('Load `finishing-a-development-branch` only when the user explicitly asks to integrate, push, or create a pull request'), and the routing contract gives checkable rules ('Never push, merge, open a pull request, or delete a worktree without explicit authorization'). It falls short of the fully-executable 5 anchor because several gating conditions remain judgment calls — 'when the task spans multiple meaningful implementation units', 'a missing decision that materially changes scope, behavior, or safety', 'If it returns valid findings' — with no worked example or tie-breaking rule for borderline cases. | 4 / 5 |
Workflow Clarity | The six numbered stages give an explicit sequence with load conditions, step 4 places verification before any completion claim, and step 5 contains a genuine feedback loop ('If it returns valid findings, load `receiving-code-review`, address them, and return to verification'). This matches the top anchor's explicit-validation-plus-error-recovery-loop pattern; it is not a 4 because no checkpoint in the routed sequence is implicit. | 5 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), and the named skills (`writing-plans`, `systematic-debugging`, etc.) are installed stage skills this router dispatches to, not nested bundle references — so there is exactly one level of indirection, clearly signaled under 'Required stage loading'. Per the simple-skill guidance, a well-organized 25-line skill with no need for external files scores 5 on section organization alone; the two headers plus numbered list make navigation trivial. | 5 / 5 |
Total | 19 / 20 Passed |