Content
67%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 delivers a concrete, largely copy-paste-ready workflow for connecting to ClassLink via the Membrane CLI, with good state-based checkpoints for connection readiness and errors. Its weaknesses are moderate padding (background and marketing prose), placeholder-only action examples, and broken step numbering ('Step 2' / '1b' references with no matching sections).
Suggestions
Fix the dangling step references: 'skip to **Step 2**' and '#### 1b' point to numbering that doesn't exist — either number the sections (1, 1b, 2...) or replace with descriptive section links.
Trim the background and marketing prose (the 'what is ClassLink' sentences, 'so you can focus on the integration logic', 'This is the fastest way to get a connection') to save tokens.
Add one concrete end-to-end example with a real ClassLink action (e.g., a OneRoster users query with actual --intent and --input values) instead of only CONNECTION_ID / QUERY placeholders.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient, command-first content, but contains unnecessary explanation and padding: a two-sentence background on what ClassLink is ('ClassLink is a single sign-on platform used primarily by K-12 schools. It provides students and teachers with easy access...'), marketing-flavored prose ('Membrane handles authentication and credentials refresh automatically — so you can focus on the integration logic rather than auth plumbing'), and internal mechanics like 'The URL is normalized to a domain and matched against known apps.' This matches anchor 3 — mostly efficient but could be tightened — rather than anchor 4, since the padding spans several sections. | 3 / 5 |
Actionability | Concrete, copy-paste-ready commands cover the whole flow: npm install, membrane login with headless completion, connection ensure with a real URL, polling with --wait, action list/run with a JSON --input example, and a proxy flags table. It fits anchor 4 ('mostly executable; concrete code or commands with minor gaps') rather than anchor 5 because the action examples remain placeholders — no concrete ClassLink/OneRoster action or intent example is shown. | 4 / 5 |
Workflow Clarity | The sequence install → login → connect → poll to READY → handle client actions → discover → run → proxy fallback is clear, with real checkpoints (poll states, the error field on CONFIGURATION_ERROR/SETUP_FAILED, re-poll after user action). It matches anchor 4 rather than 5 because step numbering is broken — 'skip to **Step 2**' points to a section that doesn't exist and '#### 1b' has no '1a' — leaving a navigation gap in the workflow. | 4 / 5 |
Progressive Disclosure | The single-file body (~140 lines) is well-organized into clear sections (install, authentication, connecting, searching, running, proxy, best practices) with no nested or dangling file references — no bundle files exist or are needed at this size. It fits anchor 4 ('good structure; most content appropriately placed; minor organization gaps') rather than 5 because the detailed clientAction state handling could be externalized to a reference file to slim the overview. | 4 / 5 |
Total | 15 / 20 Passed |