Content
71%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 content is exceptionally actionable — exact commands, formats, regexes, and ID schemas throughout — and the lifecycle and init workflows are clearly sequenced. Its two real weaknesses are significant internal duplication (writing-style rules and the three-layer model each appear twice) and an underused references/ bundle where half the files are never linked from the body.
Suggestions
Collapse the duplicated '### 4. Writing style (canonical home)' and '## Writing style for every artifact' sections into one canonical section (the body itself declares 'Phase skills do not restate them; they link back'), and merge the duplicated three-layer model tables in section 7 and the 'Three-layer documentation model' section.
Add one line per orphaned bundle file (e.g., under Git Workflow: 'Branch protection rules: see references/branch-protection.md'; similar pointers for graph-invariants.md and team-workflow.md) so the full bundle is discoverable from SKILL.md.
Add an explicit remediation step for the cap and consistency checks (e.g., 'if wc -l exceeds the cap, split the artifact or add the Reasoned exception block, then re-run the check') to close the validate -> fix -> retry loop the wc -l and /consistency-check checkpoints imply.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is 655 lines with real duplication: the writing-style rules appear twice in near-verbatim form ('### 4. Writing style (canonical home)' with the full AI-vocabulary list, then again under '## Writing style for every artifact' repeating the same em-dash, vocabulary, filler, and parallelism rules), and the three-layer model table appears twice ('### 7. Three-layer model boundaries' and '## Three-layer documentation model' with the same Wayfinder/Rule sets/Backlog/Detail artifacts rows and much of the same rationale). This matches anchor 3 (mostly efficient but includes some unnecessary explanation or could be tightened). Not 4 because whole duplicated sections are more than minor trimmable instances; not 2 because the bulk is genuinely novel project-specific binding rules (caps, ID schemas, status vocabulary), not explanations of concepts Claude already knows. | 3 / 5 |
Actionability | Guidance is fully concrete and copy-paste ready: the exact scaffold command 'mkdir -p _devprocess/{analysis/sources,requirements/{epics,features,fixes,improvements,handoff},architecture,rules,implementation/plans,context}', the binding column order '| ID | Type | Title | Status | Phase | Prio | Refs | Source | Commit | Claim | Last change | Notes |', the anchored regex '^## Activation Path\s*$', the tag command 'python3 tools/github-integration/flow.py tag-phase --item <ID> --phase <phase>', and ID patterns with worked examples like 'IMP-04-02-01'. This matches anchor 5 for an instruction-only skill (fully executable guidance; specific examples cover the common cases). Not 4 because there are no missing key details in the main flows — every convention comes with a format, example, or tool pointer. | 5 / 5 |
Workflow Clarity | The '## Feature Lifecycle' section gives an explicit 8-step sequence (BACKLOG ROW -> CLAIM -> FEATURE-SPEC -> PLAN -> IMPLEMENTATION -> SPEC UPDATE -> WAYFINDER UPDATE -> BACKLOG UPDATE) with ordering constraints like 'Status-changing actions update the backlog row BEFORE the artifact body', and '## Initializing a Project' is an executable runbook. Validation checkpoints exist but are declarative rather than procedural: 'Skills measure with `wc -l` against the cap before handoff' and '/consistency-check flags the artifact as over-cap'. This matches anchor 4 (clear sequence with most checkpoints present; minor validation gaps). Not 5 because there is no explicit validate -> fix -> retry loop telling the agent what to do when the wc -l check or consistency-check fails (the fix path lives only implicitly in other skills); not 3 because checkpoints are stated for the risky steps, not absent. | 4 / 5 |
Progressive Disclosure | Three of the six bundle files are well-signaled at one level deep ('Read `references/codebase-awareness.md` for the complete rules', 'Read `references/directory-structure.md` for the full reference', 'Read `references/naming-conventions.md` for the full reference'), but the other three — `references/branch-protection.md`, `references/graph-invariants.md`, `references/team-workflow.md` — are never referenced anywhere in the body, leaving roughly half the bundle undiscoverable; meanwhile the duplicated canonical-specs and writing-style sections are exactly the 'content that should be separate is inline' pattern. This matches anchor 3 (some structure but could be better organized; references present but not clearly signaled). Not 4 because unreferenced bundle files plus a fully duplicated spec section are more than minor organization gaps; not 2 because the three signaled references are clear, one level deep, and the body has strong section structure. | 3 / 5 |
Total | 15 / 20 Passed |