Content
93%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 lean, highly actionable instruction-only skill: every step names the concrete MCP tool and its purpose, with genuine checkpoints and an appropriate inline/deferred content split. The only weakness is the absence of explicit error-recovery guidance and an only-implicit verification ordering in the label-updating triage loop.
Suggestions
Add one line of error-recovery guidance to the read workflow (e.g., on empty search results: retry with broader terms or report the inbox empty rather than treating it as failure).
Make the triage loop's verification ordering explicit, e.g., "Clear the `unread` label only after the message's full content was fetched and triaged".
Name the list operations in step 2 (`list_messages` / `list_threads`) as concretely as the search tools, so every tool family in the workflow is identified.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every line is operational: tool names ("list_inboxes", "get_thread", "update_message"), pagination rules, field preferences, label mechanics, and security boundaries. No padding or explanation of concepts Claude already knows; even the one motivational sentence ("A triage loop that never updates labels will re-process the same mail forever") earns its place as a failure-mode warning. Not 4 because no section could be trimmed without losing guidance. | 5 / 5 |
Actionability | Names the exact MCP tool for each situation ("Resolve the inbox with `list_inboxes`", "Fetch a single hit with `get_message`, or the whole conversation with `get_thread`", "Use `get_attachment` only when attachment content is required") and specifies fields ("Prefer `extracted_text` or `extracted_html`... fall back to `text` or `html`") and output format (inbox, sender, subject, timestamp, message ID, thread ID). Per the instruction-only scoring note, absence of code is not penalized; the guidance is fully executable against the MCP server. Not 4 because the named tools and fields leave no meaningful execution gap. | 5 / 5 |
Workflow Clarity | The six-step read workflow is clearly sequenced with real checkpoints ("Follow pagination until the requested range is covered", fetch full content "before summarizing body content") and a conditional fallback (extraction unavailable → `text`/`html`). Falls short of anchor 5 because there is no explicit error-recovery feedback loop (e.g., what to do on empty or failed search results), and the batch triage loop's verify-before-marking ordering is only implicit ("clearing `unread` after processing"). Not 3 because the sequence is coherent and most checkpoints are present and explicit. | 4 / 5 |
Progressive Disclosure | Under 50 lines with well-organized sections and no local bundle files needed; the full threat model is deferred exactly one level with a clearly signaled path ("The full matrix and threat model live in the `agent-email-patterns` skill (`references/threat-model.md`)"), while only this skill's three-row contract is inlined. Not 4 because nothing inlined belongs in a separate file and the single cross-reference is explicit and shallow. | 5 / 5 |
Total | 19 / 20 Passed |