Content
88%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-engineered operational skill document: exact commands, explicit validation and idempotency guarantees, and well-branching error handling for the gh pre-flight. The main improvements are removing the duplicated [github]/project-number explanations between the activation flow and the settings-format section, and turning the reference pointer into a clearly signaled link.
Suggestions
Deduplicate the [github] field semantics: activation step 4 and the 'Settings file format' section both explain project_number/status_field/project_owner and repeat the identical 'the issue itself still syncs, only the project Status field stays untouched' sentence — state the field semantics once and cross-reference from the flow.
Merge the 'Hand-off' section into the intro or the confirmation step, since it restates scope boundaries already declared at the top ('does not run any phase skill... does not invoke flow.py').
Signal the reference more clearly as a link to the bundled file (e.g. 'See [references/anchor-format.md](references/anchor-format.md)') instead of a bare repo-relative code path, so the pointer is unambiguous from the SKILL.md location.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and operational with no concept explanations Claude already knows, but contains real duplication: 'the issue itself still syncs, only the project Status field stays untouched' appears verbatim in both activation step 4 and the settings-format section, the [github] field semantics are explained twice, and the 'Hand-off' section restates the intro's scope boundaries ('does not invoke any phase skill... does not start any handoff ritual'). This fits the level-4 anchor (efficient with minor trimming opportunities) rather than level 5. | 4 / 5 |
Actionability | Guidance is copy-paste executable throughout: exact commands ('gh project view <N> --owner <owner> --format json', 'python3 tools/dia-setup/anchor.py write --mode <mode> --files <selected list>', 'gh auth refresh -s project'), a concrete template path with named placeholders ({{mode}}, {{anchor_files}}, source_branch), a full example config.toml, and specific AskUserQuestion option structures. Error-recovery branches for the gh pre-flight (missing scope vs wrong number vs other owner) cover the realistic failure cases, matching the level-5 anchor. | 5 / 5 |
Workflow Clarity | Two flows are cleanly separated by a single routing check ('does .dia/config.toml already exist?'), each with numbered, sequenced steps, and the skill has an explicit post-write validation loop ('the skill calls python3 tools/dia-setup/anchor.py verify and reports the result... surface the missing files to the user and offer a refresh') plus a documented idempotency guarantee. Destructive-adjacent operations (anchor block rewrite, deactivation removing blocks) are covered by verify and remove semantics, so the missing-validation cap does not apply — this matches the level-5 anchor with explicit checkpoints and feedback loops. | 5 / 5 |
Progressive Disclosure | The split is appropriate: the body holds the setup workflow while anchor-block format and idempotency internals live in references/anchor-format.md (verified to exist, one level deep, well sectioned, no nested references). However, the pointer is given as a bare code path ('skills/dia-setup/references/anchor-format.md') rather than a clearly signaled markdown link to the bundled reference, and the settings-format TOML example arguably duplicates content that could be consolidated. This fits the level-4 anchor (good structure, references mostly clear, minor organization gaps) more than level 5. | 4 / 5 |
Total | 18 / 20 Passed |