Content
70%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 well-engineered, highly actionable audit workflow: clear phase sequencing, explicit verify-before-report validation, concrete fix guidance, and thoughtful false-positive and overflow handling. The main weaknesses are redundancy (duplicated exclusions, scope statements, and near-identical invocation examples) and a fully monolithic single-file layout with no progressive disclosure of the detailed anti-pattern reference material.
Suggestions
Remove duplication: state the exclusion globs and SwiftUI scope boundary once (the 'Files to Exclude' and top 'Scope' sections), and cut the 'Invocation Examples' section to 2 representative examples or drop it — the description already carries the triggers.
Move the 8 detailed anti-pattern specifications (Pattern/Search/Issue/Fix/Note) into a references/ file (e.g. references/anti-patterns.md), keeping one-line summaries in SKILL.md with clearly signaled links, to reduce the inline token load.
Tighten the 'Search' entries into runnable grep patterns where possible (e.g. a concrete regex for structs with collection stored properties) so every detection step is copy-paste executable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and directive — Pattern/Search/Issue/Fix per anti-pattern with no explanation of basics Claude already knows — but contains avoidable repetition: exclusion paths appear in both 'Files to Exclude' and Phase 1 Step 1; the SwiftUI scope note is stated twice (top 'Scope' and bottom 'Scope' section); and the five Invocation Examples are near-identical padding. Mostly efficient but could be tightened → anchor 3, not 4 due to these redundant sections. | 3 / 5 |
Actionability | Concrete grep patterns, exact exclusion globs, specific fixes per issue ('borrowing'/'consuming', 'isKnownUniquelyReferenced', '@_specialize(where T == ConcreteType)', 'reserveCapacity'), and a complete output template make this mostly executable guidance. Not 5 because several 'Search' entries are heuristics requiring judgment ('structs with >5 stored properties', 'alternating small/large fields') rather than runnable patterns. | 4 / 5 |
Workflow Clarity | Five clearly sequenced phases with explicit validation: grep matches must be verified via Read before reporting, Phase 3 findings require evidence from the Phase 1 hotspot map, and a False Positives section plus output limits handle error/overflow cases. The audit is read-only, so the destructive-operation cap does not apply; the verify-before-report loop matches the anchor 5 pattern. | 5 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/ directories) and the body contains no external references — all ~290 lines are inline. Section headers give good structure, but content that could plausibly live in separate files (the 8 detailed anti-pattern specs, the invocation examples) is inlined, matching anchor 3 (some structure, content that should be separate is inline) rather than 4. | 3 / 5 |
Total | 15 / 20 Passed |