Content
78%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 orchestration skill: the body stays a lean router that sequences phases, states boundaries, and delegates all heavy machinery to clearly signaled, verified reference files. Weakest points are minor redundancy in the enforcement language and a couple of underspecified items (the cost line, post-grounding verification) whose definitions live in references the body never points to for them.
Suggestions
Trim the repeated enforcement phrasing ("The read is required", and Phase 0's three-sentence restatement) — a single mandatory-read marker per phase conveys the same constraint in fewer tokens.
Either define the cost line inline in Boundary 7 or point to the reference that defines it, so "Show the user the cost line before dispatching" is actionable without guessing its contents.
State the merge/synthesis checkpoint for Phase 2's output (what must be true before continuing to post-ideation-workflow.md) in the body, so the workflow's validation spine is visible without opening the reference.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is a lean ~70-line orchestration overview that explains nothing Claude already knows, but it repeats itself in places: "The read is required" appears after already-imperative read instructions, and Phase 0 spends three sentences ("Both reads this phase names are required, even when the subject, mode, and format look clear. Those two references define... Nothing here is resolved before reading them.") restating the same enforcement. This fits anchor 4 ("Efficient; minor instances of over-explanation that could be trimmed") rather than anchor 5's every-token-earns-its-place, and is clearly above anchor 3's "some unnecessary explanation". | 4 / 5 |
Actionability | Most guidance is executable: exact paths (`<repo-root>/.compound-engineering/config.yaml`, `/tmp/compound-engineering-<uid>`), a concrete command (`git rev-parse --show-toplevel`), unambiguous precedence rules for output format and config layers, and an 8-hex run-id convention. A few items stay abstract — Boundary 7's "Show the user the cost line before dispatching" never says what the cost line contains, and "Generate many, critique all" gets criteria only by delegation to references — so anchor 4 ("mostly executable guidance; concrete code or commands with minor gaps") fits better than anchor 5. | 4 / 5 |
Workflow Clarity | Phases are explicitly sequenced (0 Resume/Scope, 1 Grounding, 1.5 Decomposition, 2 Divergent Ideation) with per-phase required reads, explicit failure handling ("Warn and proceed when grounding fails", "stop with an error naming docs_root"), and a defined Done state. It sits between anchor 4 and anchor 5: validation exists for config and grounding, but later-phase checkpoints (merge/synthesis verification, artifact validation) are delegated to reference files rather than stated, leaving minor gaps — anchor 4. | 4 / 5 |
Progressive Disclosure | The body is exactly a clear overview: each phase names its one reference with what it defines (e.g., "Read `references/output-mode.md` whenever a format is resolved... It defines each step of the decision"), and every cited file (output-mode, scope-gates, grounding, decomposition, divergent-ideation, post-ideation-workflow, universal-ideation) exists in references/. Referenced content is one level deep, well-signaled, and the split is appropriate — matching anchor 5, with the linear hand-off ("continue with references/post-ideation-workflow.md, which it names as the next required read") being sequential navigation rather than buried nesting. | 5 / 5 |
Total | 17 / 20 Passed |