Content
77%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 overview for a high-stakes write-path skill: it leads with mandatory probes, hard destructive-write invariants with a snapshot/verify/restore loop, prompt-injection defenses for catalog content, and a clean router to twelve one-level-deep reference files that all exist. The main weakness is verbosity — several sections restate their tables narratively and could be tightened without losing any domain content.
Suggestions
Trim the narrative restatement after the authorisation table (the 'So: a user who says...' paragraph) — the table already encodes the rule and the paragraph adds roughly 120 tokens of repetition.
Compress the MCP-vs-local-install guardrail to a short two-branch rule plus the 'resolve against references/, never write API calls from memory' pointer; the current prose over-explains runtime variations the reader can infer.
Move the detailed CloudTrail control text (specific event names, encryption settings) from the security-considerations table row into references/catalog-safety.md, keeping only the one-line recommendation and link in the overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient and dense with non-obvious domain knowledge (the replace-vs-merge table, per-surface authentication, verify-on-the-visible-surface), but several sections could be tightened: 'The request is the authorisation' restates its table in a follow-up narrative paragraph ('So: a user who says... gets the plan first...'), the MCP-vs-local-install guardrail over-explains runtime variations, and rhetorical flourishes ('it is a failure, and it is the most common one in this domain') pad the message. It is not 2 because none of the prose explains concepts Claude already knows — it is all domain-specific earned tokens, not generic padding. | 3 / 5 |
Actionability | Concrete executable guidance is present: three copy-ready probe commands ('aws sts get-caller-identity', 'aws datazone list-domains --region <region>', 'aws glue list-form-types --region <region> --max-results 5'), a specific snapshot pattern ('/tmp/<asset>-before.json'), named verification commands ('glue get-table', 'glue get-table-versions'), and a router table pointing to real files. It is not 5 because the body is a router — the actual write-command blocks users would copy-paste live in the reference files rather than here — and not 3 because what is inline is fully executable rather than pseudocode. | 4 / 5 |
Workflow Clarity | Despite destructive and batch operations, validation is explicit and central: the numbered 'snapshot, write, verify, restore' loop with a restore-on-mismatch error-recovery step, verification 'on the surface where the damage is visible' with a concrete counter-example (list-iterable-forms masking a destroyed StorageDescriptor), a mandatory platform-detection step before anything, and a read-back-before-reporting-success rule. This clears the destructive/batch cap with feedback loops and checklists matching the anchor-5 example, so it is not 4. | 5 / 5 |
Progressive Disclosure | A router table maps twelve distinct user intents to twelve real reference files (all verified present in references/, one level deep, no nesting), each labeled with applicable platforms, while cross-cutting invariants are kept in the overview with an explicit justification for why they outrank chapters. It is not 4 because navigation is unambiguous and every reference is well-signaled with no content that clearly belongs in a separate file left inline — the overview holds only globally applicable rules. | 5 / 5 |
Total | 17 / 20 Passed |