Content
68%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 well-structured, mostly executable runbook: concrete CLI/API/SDK/compose examples organized in a clear numbered sequence, with useful anti-pattern and limitation tables. Its main weakness is the absence of validation checkpoints — no step confirms the proxy or toxic is in effect, and cleanup is advisory rather than a verified workflow step — plus a few minor command/comment mismatches.
Suggestions
Add validation checkpoints to the workflow: after Step 2 confirm the proxy exists (e.g., `toxiproxy-cli list` as an explicit check, not a side note), after Step 4 verify the toxic registered, and add an explicit cleanup step that verifies all toxics were removed after the test.
Fix the Step 1 install block — the 'Or natively (Linux)' heading is followed by a macOS brew command — and correct the 'Remove all toxics on this proxy' comment, which sits on a command that removes a single named toxic.
Trim the Overview's quoted tagline and consider moving the full toxic catalog and language SDK samples into a references/ file so SKILL.md stays a lean overview with one-level-deep pointers.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Largely efficient: every step is a compact command block or table with little padding ("toxiproxy-cli toxic add -t latency -a latency=500 orders-db"). Not 5: the Overview quotes Toxiproxy's tagline and restates README context Claude can fetch from the linked repo, and the 8-row toxic catalog plus two-language SDK samples are reference material inlined in the main file. | 4 / 5 |
Actionability | Mostly copy-paste ready: docker pull/run, a curl proxy-create call, toxiproxy-cli add/remove commands, Python and Node SDK snippets, and a docker-compose.yml. Not 5: minor gaps and inaccuracies — Step 1's "Or natively (Linux):" heading is followed by "brew install toxiproxy # macOS" (garbled), and the comment "Remove all toxics on this proxy" sits on a command that removes a single named toxic. | 4 / 5 |
Workflow Clarity | Steps 1–8 are clearly sequenced (install → define proxy → catalog → add toxics → directions → SDKs → compose → use cases), but no validation checkpoints exist: nothing verifies the proxy was created or the toxic took effect before proceeding. Since toxics like `down`/`reset_peer` disrupt live connections (the examples front a database on 5432) and cleanup appears only as an anti-pattern note rather than a verified step, the destructive-operation cap applies. | 3 / 5 |
Progressive Disclosure | Good structure: well-labeled sections (When to use, numbered steps, Anti-patterns, Limitations, References) with the one external reference ([tp] GitHub README) clearly signaled and only one level deep; no bundle files exist to organize. Not 5: at ~190 lines the toxic catalog, SDK samples, and use-case/anti-pattern tables could be split into reference files to keep SKILL.md a leaner overview. | 4 / 5 |
Total | 15 / 20 Passed |