Conciseness

The body is lean and almost every token carries repo-specific information Claude cannot know (registry layout, id allocation, tag protocol). Minor over-explanation keeps it below anchor 5: the CVE contrast paragraph ('Unlike a CVE (which describes something that was once broken)') and the trailing 'good test' heuristic partly restate the point already made in 'When NOT to use this convention'. Not 3 because none of it is generic background knowledge.

Actionability

Guidance is fully executable for an instruction-only skill: copy-paste-ready commands ('grep -rn GRIDA-SEC-<id> .' and the test-discovery grep with '--include=*test*'), a deterministic id-allocation rule ('find the highest existing GRIDA-SEC-NNN, use NNN+1'), and a prescribed four-section SECURITY.md entry shape with example tag formats ('// GRIDA-SEC-NNN: rule 2 — fail closed'). Not 4 because no key detail is left for the reader to fill in.

Workflow Clarity

Both multi-step processes are explicitly sequenced with validation checkpoints and a real feedback loop: the pre-commit review requires re-reading each SECURITY.md entry, walking each numbered enforcement step against the diff, verifying tags survive renames, and gating on 'If you cannot satisfy steps 1–4, do not commit. Either revert the change, or explicitly amend the SECURITY.md entry'. This matches the anchor 5 pattern of sequence + explicit validation + error-recovery path.

Progressive Disclosure

Sections are well-organized (meaning, working with tagged code, mandatory review, adding a new id, exclusions) and the body is appropriately self-contained for a convention skill with no bundle files. Below 5 because at ~95 lines the 'Adding a new id' procedure and the exclusions section are each substantial enough to live in a reference file, and the deep relative link ('../../../supabase/AGENTS.md#rpc-role-contract') is navigation a reader must resolve unaided. Not 3 because structure and signaling are otherwise clear and one level deep.

Specificity

The description lists multiple concrete actions — 'explains the contract, mandates a security review before committing changes to any tagged file, and shows how to register a new id' — with comprehensive coverage, which fits the anchor 5 example. Reduced by 1 per the judging guideline because it uses second-person voice ('Triggers when you encounter... when modifying files under any tagged path') instead of third person.

Completeness

Both questions are answered explicitly: 'what' is stated concretely (contract explanation, mandated pre-commit security review, id registration) and 'when' is given twice with concrete trigger phrases ('Triggers when you encounter a GRIDA-SEC tag in source/docs, when modifying files under any tagged path, or when adding a new prevented-vulnerability record'). This matches the anchor 5 example structure of what + 'Use when...' verbatim.

Trigger Term Quality

Natural trigger terms are comprehensively covered for the niche: 'GRIDA-SEC tag in source/docs', 'security boundaries', 'prevented-vulnerability record', '/SECURITY.md', and the closing 'Use whenever "GRIDA-SEC" appears in context' — a user touching this convention would say exactly these phrases. Not below 5 because no common synonyms within the domain are missing; the marker itself is the vocabulary.

Distinctiveness Conflict Risk

The trigger is a unique repo-specific marker ('GRIDA-SEC-<id>', '/SECURITY.md') rather than generic security language, giving it a clear niche with essentially zero overlap risk with other skills. Not 4 because no closely related skill could plausibly claim these triggers.