Conciseness

Mostly efficient — the validation-classes table, phases, and output rules are dense and non-obvious — but there is noticeable padding: the "Why This Exists" narrative, the historical pre-v0.37.5.0 bug story ("One brain saw 6,981 of these on a single doctor run"), and a body-level "Trigger words" section that duplicates the frontmatter triggers. Not 4 because several sections could be trimmed without losing actionable content; not 2 because almost nothing explains concepts Claude already knows — the detail is tool-specific and unfamiliar.

Actionability

Fully executable throughout: copy-paste-ready commands for every phase ("gbrain frontmatter audit --json", "gbrain frontmatter validate <path> --fix", "gbrain frontmatter install-hook"), explicit exit-code semantics ("Exit code 0 = clean; 1 = errors found"), a concrete correct/broken YAML example set, and realistic sample outputs covering the common cases. Not 4 because there are no gaps — commands, flags, and expected outputs are all specified.

Workflow Clarity

Clear sequence with explicit validation checkpoints and feedback loops for destructive/batch operations: audit first ("Always run `gbrain frontmatter audit --json` first; never assume a brain is clean"), `--dry-run` preview ("Use this before applying fixes in batch"), `.bak` backups before every mutation, count-and-confirm before `--fix`, and exit-code validation for CI. The destructive-operation cap at 3 does not apply because verification steps are explicitly present. Not 4 because checkpoints are explicit and the anti-patterns section documents error-recovery behavior for every failure path.

Progressive Disclosure

The single-file body has good header structure, but reference-style material is inlined that belongs in a separate file — the ~60-line "Prevention — Writing Valid Frontmatter" section (canonical YAML forms, quoting rules, the LLM-trap JS snippet) and the full JSON envelope example read like a reference doc, and there are no bundle files at all (no references/, scripts/, or assets/). It matches anchor 3 ('content that should be separate is inline'); not 4 because the long inline reference material is exactly what the level-4/5 anchors expect split out, and not 2 because the section structure and navigation within the file are clear.

Specificity

The description names the domain ("YAML frontmatter on brain pages") and multiple concrete actions ("Validate and auto-repair"), and enumerates comprehensive concrete failure modes: "missing closing ---, nested quotes, slug mismatches, null bytes, empty frontmatter, YAML parse failures". It clearly matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage', not the level below where coverage has minor gaps.

Completeness

The 'what' is clear and concrete ("Validate and auto-repair YAML frontmatter... Wraps the `gbrain frontmatter` CLI"), but there is no 'Use when...' clause or equivalent explicit trigger guidance in the description, which caps completeness at 3 per the judging guidelines. It is not 2 because the 'what' is fully explicit, and not 4 because 'when' is entirely absent from the description field rather than weakly stated.

Trigger Term Quality

Good natural-keyword coverage: "frontmatter", "YAML", "validate", "auto-repair", "brain pages" are phrases a user would plausibly say. It is not 5 because common variations users would naturally say — "check frontmatter", "frontmatter audit", "brain lint" — appear only in the separate `triggers` frontmatter field, not in the description itself; it is above 3 because the terms present are relevant and domain-natural rather than generic.

Distinctiveness Conflict Risk

Clear niche with distinct triggers: "YAML frontmatter on brain pages" scoped via "Wraps the `gbrain frontmatter` CLI for agent-driven workflows" — highly unlikely to trigger for an unrelated skill. Not the level below (4) because there is no meaningful overlap risk; the tool name and page-type vocabulary are unique to this domain.