Content
75%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, highly actionable process skill: concrete commands, verbatim templates, hard line caps, and explicit validation checkpoints, with detail correctly pushed into three one-level-deep reference files. Weaknesses are limited: some duplicated guidance across sections, one unspecified validation command, and a body that is somewhat long for an overview.
Suggestions
Deduplicate the repeated guidance: merge the "FEATURE subtype and Activation Path" section into Workflow step 3 (or vice versa), state the "ba-ref: ... only if the BA exists" rule once, and drop the closing Keywords section since the frontmatter description already carries the triggers.
Specify the validation command instead of alluding to it: replace "run the forbidden-terms grep" with the actual grep invocation against the forbidden-terms list in references/tech-agnostic-rules.md (e.g., a ready-to-run grep -E pattern over the produced feature files).
Tighten progressive disclosure by moving the recurring canonical-spec pointers into a single early "Canonical specs" note rather than repeating "skills/project-conventions/SKILL.md#canonical-specs" in five places, and confirm the external paths (templates/, tools/, sibling skills) resolve from where this skill is installed.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and prescriptive with zero explanation of concepts Claude already knows, but some content is duplicated: "subtype: user-facing | library" guidance appears in both Workflow step 3 and the "FEATURE subtype and Activation Path" section, the "ba-ref: ... For IMP/FIX, only if the BA exists" rule appears twice, and the closing Keywords section largely duplicates the frontmatter description. Not 5 because these repeated tokens do not each earn their place; not 3 because there is no padded or unnecessary explanation. | 4 / 5 |
Actionability | Concrete, mostly executable guidance throughout: exact commands ("python3 tools/github-integration/flow.py create-issue --item <ID>"), a copy-paste YAML frontmatter block, exact filename patterns ("FEAT-{ee}-{ff}-{slug}.md"), verbatim dialogue templates, and a full hypothesis-statement example. Not 5 because "run the forbidden-terms grep" never specifies the actual grep command, and several pointed-to paths ("templates/", "skills/project-conventions/...") are not resolvable within this bundle; not 3 because the guidance is far beyond high-level hints. | 4 / 5 |
Workflow Clarity | A clear ordered pipeline exists: Pre-Phase 0 branch check, Phase 0 triage with a fallback question, a binding 4-step sync chain, a numbered 5-phase workflow with a validation spot-check checklist ("Success Criteria stay tech-free", "Every FEATURE has at least one Activation Path entry"), a /consistency-check run, and a mandatory Handoff Ritual. Not 5 because the top-level sequence requires hopping between sections (Start Scenarios appears after Method catalog, and backlog-ownership rules arrive after the Handoff Ritual) and there is no explicit error-recovery loop for failed validation; not 3 because checkpoints are explicit, ordered, and present. | 4 / 5 |
Progressive Disclosure | The skill's own bundle references ("references/handoff-snippets.md", "references/tech-agnostic-rules.md", "references/status-promotion-prompt.md") are real files, clearly signaled, and one level deep — the SKILL.md keeps summaries while full text lives in references. Not 5 because the body is 314 lines (long for an overview) and repeatedly leans on external paths ("skills/project-conventions/SKILL.md#canonical-specs", "templates/EPIC-TEMPLATE.md") that are not part of this bundle; not 3 because structure is good and the split that does exist is appropriate and well-signaled. | 4 / 5 |
Total | 16 / 20 Passed |