Content
50%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 genuinely useful router with concrete commands and real validation instincts in the diagnostics section, undermined by heavy redundancy — the trigger-to-target map appears four times in three formats — and overlapping route triggers with no tie-break rule. Consolidating the routing into a single table plus a short examples section would cut the file by more than half without losing information.
Suggestions
Collapse 'Routing Logic', 'Decision Tree', and 'Example Invocations' into one routing table (trigger | target | invoke path) and keep a handful of example invocations only for ambiguous cases — this alone removes ~200 duplicated lines.
Resolve the overlapping triggers: state explicitly when build-fixer (automation) is preferred over xcode-debugging (manual diagnosis) and build-performance over build-optimizer, so the decision tree has a deterministic winner.
Fix section ordering (16 appears before 15) and unify the invoke-path formats ('skills/xcode-debugging.md' vs 'See axiom-shipping (skills/...)' vs '`axiom-fix-build`') into one consistent convention.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The routing information is repeated three times in near-identical form: the 16 'Routing Logic' sections, the 16-item 'Decision Tree', and the ~40-entry 'Example Invocations' list restate the same trigger→target mappings, with the 'When to Use' list adding a fourth pass. That is well over a hundred lines of redundant routing that could be one table, matching the 'noticeably verbose; several padded sections' anchor rather than the severely padded level-1 case, since the anti-rationalization and when-not-to-use sections do add unique value. | 2 / 5 |
Actionability | The diagnostics section gives concrete, executable commands ("pgrep -lx xcodebuild; echo \"pgrep exit=$?\"", "\"$AXBUILD\" xcodebuild -scheme \"$SCHEME\" -destination \"$DESTINATION\" build", "\"$AXBUILD\" swift test --package-path \"$PACKAGE\"\") with explicit rules for resolving AXBUILD's path, and each routing entry names a concrete invoke target. Minor gaps remain: cross-package pointers like "See axiom-shipping (skills/testflight-triage.md)" are navigational hints rather than invocable commands, and the truncated-marker guidance never names the actual marker string. | 4 / 5 |
Workflow Clarity | The decision tree provides a numbered 16-step routing sequence, and the diagnostics-capture procedure has real checkpoints (pgrep exit-code interpretation, inspecting 'omissions' and artifacts rather than rebuilding, truncation-marker checks, the saved-log fallback). But overlapping trigger sets across sections 1, 6, and 8 (e.g. 'BUILD FAILED' appears under both xcode-debugging and build-fixer; slow-build triggers under both build-performance and build-optimizer) plus out-of-order section numbering (16 appears before 15) leave ambiguity about which path wins, and no tie-break guidance is given — placing this between the 'sequence present, checkpoints missing' and 'clear sequence, most checkpoints' anchors. | 3 / 5 |
Progressive Disclosure | No bundle files (references/, scripts/, assets/) ship with this skill, and the routing targets (skills/xcode-debugging.md, axiom-shipping, axiom-performance) are external sibling skills, so detail is indeed deferred one level deep. Structure is decent with per-section headers, but the same routing map is inlined three times instead of being split or consolidated, some invoke paths are formatted three different ways, and section ordering is disorganized — matching the 'some structure, could be better organized' anchor. | 3 / 5 |
Total | 12 / 20 Passed |