Content
60%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, highly actionable design reference with exact parameters, named APIs, and a clearly sequenced workflow with a validation phase. Its weaknesses are token efficiency — a large capabilities comment block and mobile/PQC details repeated across five or more sections — and progressive disclosure, since referenced files are absent from the bundle and reference-scope material is inlined.
Suggestions
Delete or drastically shrink the CAPABILITIES_SUMMARY / COLLABORATION_PATTERNS HTML comment block — it duplicates the Trigger Guidance, Recipes, and Collaboration sections already present in the body.
Consolidate the mobile keystore / Passkey / JWT / certificate-pinning details, which currently appear in Trigger Guidance, Recipes, Subcommand Dispatch, Output Routing, and the Anti-Pattern Checklist, into the Mobile Keys recipe row and its reference file.
Move date-stamped PQC timeline and version details (HQC selection 2025-03-11, EncryptedSharedPreferences deprecation 2025-12, IR 8547 'final pending as of June 2026') into reference/post-quantum-migration.md, keeping only status flags in the quick-reference tables.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Noticeably verbose with padded, duplicated sections: the ~35-line CAPABILITIES_SUMMARY comment block (e.g. "mobile_keystore_design: iOS Keychain (`kSecAttrAccessControl` with `.biometryCurrentSet`...)...") restates material that reappears in Trigger Guidance, Recipes, Subcommand Dispatch, Output Routing, and the Anti-Pattern Checklist, and time-stamped claims ("Selected 2025-03-11", "Officially deprecated 2025-12", "final pending as of June 2026") are scattered inline rather than confined to a deprecated section. It is above anchor 1 because the body is dense reference tables rather than explanations of concepts Claude already knows, but the repetition across sections goes beyond anchor 3's 'some unnecessary explanation'. | 2 / 5 |
Actionability | Highly concrete guidance with exact parameters throughout — "m=19 MiB, t=2, p=1", "cost factor >=12", "random 96-bit IV", "max 10 GB or `2^32` messages per DEK, `<=10`-minute TTL", and specific APIs like `kSecAttrTokenIDSecureEnclave` and `setIsStrongBoxBacked(true)` — making it mostly executable for a design skill. It falls short of anchor 5 only because no worked design-spec example or code snippet is included despite Output Requirements demanding "code examples". | 4 / 5 |
Workflow Clarity | The "THREAT -> SELECT -> DESIGN -> VERIFY -> DOCUMENT" table gives per-phase required actions, key rules, and read pointers, and VERIFY embeds a validation checkpoint ("Every design gets anti-pattern checklist") plus subcommand dispatch is unambiguous. Not anchor 5 because there is no feedback loop — no instruction to revise and re-verify a design when the anti-pattern checklist finds issues. | 4 / 5 |
Progressive Disclosure | References are clearly signaled one level deep via the Recipes "Read First" column, Output Routing "Read next" column, and a dedicated Reference Map table (reference/patterns.md, reference/password-hashing.md, reference/post-quantum-migration.md, etc.). Not anchor 5 because none of those referenced files exist in the provided bundle, and substantial reference-scope content (the 17-row Anti-Pattern Checklist, PQC timeline detail, algorithm quick reference) is inlined in SKILL.md; not anchor 3 because navigation is easy and references are well signaled. | 4 / 5 |
Total | 14 / 20 Passed |