Content
57%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 practical, actionable incident runbook with real API calls and an executable diagnostic script, but it mixes instructional prose into code and lacks explicit validation gates on its destructive batch operations. No bundle files are provided, so all content is inline despite being long enough to benefit from splitting.
Suggestions
Add explicit validation checkpoints to the account-health cascade — e.g. re-test account vitals and confirm SMTP/IMAP are 'ok' before resuming accounts or reactivating campaigns — to lift workflow_clarity above the batch/destructive cap of 3.
Move the long TypeScript triage/mitigation blocks into scripts/ files and keep SKILL.md as an overview that links to them, improving progressive disclosure and conciseness.
Convert the instructional console.log recovery steps into either real executable code or concise markdown numbered lists, removing the prose-embedded-in-code padding.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is dense and domain-specific without re-explaining concepts Claude knows, but embeds prose recovery steps as console.log strings (e.g. 'Step 1: Pause broken accounts', numbered 'Recovery Steps' printed rather than executed) that could be tightened into markdown or real code; not a 2 because it is mostly efficient. | 3 / 5 |
Actionability | Provides concrete executable API calls (client.accounts.pause, campaigns.list, webhooks resume) and a fully runnable bash diagnostic with curl/jq; falls short of 5 because the TypeScript depends on an un-bundled './src/instantly/client' and several recovery actions are emitted as instructional console.log text rather than executable code. | 4 / 5 |
Workflow Clarity | Each incident has a clear Triage -> Mitigation -> Recovery sequence with a severity/response-time table, but the destructive batch cascade (pause all broken accounts, then resume and reactivate campaigns) lacks explicit validation checkpoints before resuming; per the batch/destructive cap this cannot exceed 3, and the warmup section's 'Re-test inbox rates before re-enabling' is the only true validate-before-proceed gate. | 3 / 5 |
Progressive Disclosure | Sections are well-organized by incident type, but the entire runbook is a single ~290-line inline file with no bundle files in references/scripts/assets, and the lone cross-skill pointer ('see `instantly-data-handling`') is an unsignaled backtick mention rather than a clear link; content that could live in scripts/ is inlined. | 3 / 5 |
Total | 13 / 20 Passed |