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.
An excellent orchestrator-style body: concrete URL conventions, dispatch tables, verbatim scripts, and a clearly sequenced Step 0 -> Setup -> Docs-lookup flow with strong grounding rules. Its weaknesses are inlined runbook detail (the styling-depth and workplace paragraphs duplicate design-matching.md/custom-ui.md content) that hurts token efficiency, and validation checkpoints that exist only for the design-matching path.
Suggestions
Move the four composite-slot traps and the region checklist out of the styling-depth paragraph into design-matching.md, keeping in SKILL.md only the routing rule and a one-line summary of the core failure mode — the paragraph currently duplicates the referenced runbook.
Trim the workplace/Liquid Glass paragraph to the routing decision (flat message row + glassy header => components job) and delegate the archetype details and factory.styles mechanism to design-matching.md.
Add an explicit validation checkpoint to the plain docs-lookup/integrate flow (e.g., confirm the fetched page matches the SDK version the project pins before applying its code, mirroring the 'read the version the project actually pins' escalation rule).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient and contains no boilerplate explanations of concepts Claude already knows, but the ~450-word styling-depth paragraph ("A reference design is a checklist of regions (header, composer buttons, where the timestamp + read receipts sit...)" plus the four numbered traps) and the workplace/Liquid Glass paragraph inline runbook-level detail that duplicates the referenced design-matching.md and custom-ui.md. Not 2: everything inlined is curated non-obvious knowledge, not padding; not 4: several mega-paragraphs restate content already delegated to referenced files and could be tightened to routing rules. | 3 / 5 |
Actionability | Fully executable instruction-only guidance: the exact URL convention with a concrete example ("take the page URL, drop the trailing /, add .md"), a live index table with exact URLs, "Fetch at most 3 pages per request", a verbatim citation format ("Source: [Title](https://getstream.io/...)") and "Never answer SDK specifics from training data", named escalation files ("read ViewFactory.swift (every slot) + DefaultViewFactory.swift"), and even verbatim clarifying questions. Not 4: even the ambiguity-handling paths are copy-paste ready. | 5 / 5 |
Workflow Clarity | Clear ordered sequence: "Step 0: Classify the request (always first)" -> Setup for integrate/new app -> "Step 1: Docs lookup (every request ends here)" with numbered application steps, plus an explicit iterate loop for design work ("The match is not done until you build, run, seed data that triggers every region, compare region-by-region ... and iterate"). Not 5: validation/feedback checkpoints are only spelled out for the design-matching path — the plain docs-lookup and integrate flows have grounding rules but no verify step; not 3: the sequence is explicit and well-dispatched by mode. | 4 / 5 |
Progressive Disclosure | One-level-deep references, each well signaled with its purpose: "RULES.md - non-negotiable rules + iOS pitfalls. Read before writing any code", the setup.md numbered flow, and a closing "What this skill no longer carries" section that enumerates every runbook. Not 5: heavy runbook detail is inlined in SKILL.md instead of living solely in the referenced files, two references point outside the skill directory ("../stream/sendbird-data-migration.md", "../stream/ai-backend-contract.md"), and none of the referenced files (RULES.md, docs-map.md, setup.md, push.md, ai-integration.md, design-matching.md, custom-ui.md, sendbird-migration.md) are present in this skill bundle to verify they resolve. Not 3: references are clearly signaled, single-level, and purpose-stated. | 4 / 5 |
Total | 16 / 20 Passed |