Content
75%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-structured, genuinely executable research workflow with concrete tool calls, file conventions, fallback stacks, and sensible progressive disclosure to two real reference files. Its main weakness is token efficiency: the complete profile template is duplicated inline in the body even though references/templates.md already holds it, and some per-endpoint SEO detail could live entirely in the tool reference.
Suggestions
Replace the ~140-line inline profile template in Output Format with a short section skeleton (headings plus one-line descriptions), leaving the full template to references/templates.md — the body already links to it.
Compress the Phase 2 per-endpoint bullet lists (Domain Authority & Backlinks, Keyword & Traffic Intelligence, Competitive Positioning Data) into a single table or move the endpoint-by-endpoint detail into references/tool-reference.md, keeping only the metric names in the body.
Add a brief inline note on error handling for the two most common failure modes (scrape failures and MCP unavailability mid-run), or surface the Error Handling section of references/tool-reference.md with a one-line pointer where Phase 1 and Phase 2 begin.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient — tables for extraction targets, no explanations of concepts Claude already knows — but it inlines the full ~140-line profile template ('# [Competitor Name] — Competitor Profile' through '## Raw Data Sources') while also pointing to references/templates.md for the same templates, a clear duplication that could be tightened. Not a 2 because there is no padding or basic-concept explanation anywhere else. | 3 / 5 |
Actionability | Highly actionable throughout: named MCP tools with invocation notation ('firecrawl_map → competitor URL', 'backlinks_summary', 'dataforseo_labs_google_ranked_keywords'), exact save paths ('competitor-profiles/raw/<competitor-slug>/<YYYY-MM-DD>/scrapes/<page-name>.md'), per-page extraction tables, and explicit fallback procedures ('If Firecrawl is unavailable, use WebFetch... probe common page paths manually'). As an instruction-only skill, the guidance is concrete and covers the common cases. | 5 / 5 |
Workflow Clarity | A clearly sequenced multi-phase workflow (assess → select stack → save raw data → map → scrape → SEO → synthesize → output → summary) with meaningful checkpoints: persist raw data before extracting, 'never estimate' unavailable metrics, cross-reference claims in Phase 3, never overwrite prior date folders. It falls short of 5 because error-recovery loops are deferred to references/tool-reference.md rather than stated inline, and per-step validation is implicit rather than an explicit checklist. | 4 / 5 |
Progressive Disclosure | Good structure with well-signaled, verified, one-level-deep references: references/tool-reference.md (tool docs, execution order, error handling) and references/templates.md are both real files and both linked from the body at the point of need. The gap keeping it from 5 is the full profile template inlined in the Output Format section despite templates.md existing for exactly that content. | 4 / 5 |
Total | 16 / 20 Passed |