Content
81%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 highly actionable with a well-sequenced, heavily validated workflow and properly structured one-level-deep references to real bundle files. Its main weakness is token efficiency: identity/suppression rule blocks are repeated nearly verbatim across the Skill Contract and Procedure sections, and dense protocol prose is inlined rather than referenced.
Suggestions
Deduplicate the identity and suppression rules: state the 'never persist raw locators' list and the decline/stop-contact reason codes once (e.g., in the Skill Contract) and reference them from Steps 1, 3, and 5 instead of repeating them.
Move the multi-paragraph consent/identity protocol (the runtime-resolution prose and the pre-procedure decline handling) into a dedicated reference file, keeping the procedure steps as concise pointers.
Trim the example output section — the abridged example duplicates the template structure already available in references/templates.md.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly efficient domain-specific guidance, but noticeably repeated rule blocks pad the body: "Never derive the path from a raw handle" / "Never persist a raw handle, name, profile URL, email, phone, postal address, provider ID, or credential" appears in both the Skill Contract and Step 1, and the suppression reason codes (user-request/unsubscribe/complaint/withdrawal) are stated three times. It is above the 2 anchor because the content is non-obvious project protocol rather than concepts Claude already knows, but below 4 because whole paragraphs could be deduplicated. | 3 / 5 |
Actionability | Fully executable guidance: the consent-runtime bash block is copy-paste ready with explicit failure messages and exit codes, the 5-step procedure each links to a verified fill-in template anchor in references/templates.md, the cadence is concretely specified ("Day 0 / 3-4 / 7-8 / 14, then archive at Day 21"), and a worked example is provided. Matches the 5 anchor 'Fully executable; copy-paste ready code or commands'. | 5 / 5 |
Workflow Clarity | Clear five-step sequence with explicit validation checkpoints for the risky external-side-effect operation: the "Do not send or schedule anything until all of these are true" gate, fail-closed rules ("'Unknown' or missing eligibility fails closed"), live suppression check immediately before dispatch, and NEEDS_INPUT recovery handoffs — matching the 5 anchor with feedback loops and error-recovery paths. Not below 5 because validation is pervasive and explicit. | 5 / 5 |
Progressive Disclosure | Good structure: Quick Start, Skill Contract, Data Sources, a five-step procedure whose bulk detail correctly lives in one-level-deep, well-signaled references ([references/templates.md](references/templates.md), [references/cold-copy-rules.md](references/cold-copy-rules.md)) with real per-step anchors, plus a clear Reference Materials index. Not a 5 because dense protocol prose (the multi-paragraph consent/identity rules) is inlined in the body where a reference file would keep the overview leaner. | 4 / 5 |
Total | 17 / 20 Passed |