Conciseness

The Discovery Checklist runs ~60 dense, multi-clause bullets that restate a handful of core principles many times over: instance-splitting appears as "keep each vulnerable instance addressable" (line 51), "its own candidate instance" (57), "needs its own candidate id" (63), and "separate candidate instances" (62), while "do not drop a row in favor of a louder neighboring issue" recurs at lines 82, 89, and 90. It never explains concepts Claude already knows, which keeps it above anchor 1, but the padding and redundancy are extensive.

Actionability

The body supplies exact commands with flags ("generate_rank_input.py make-diff-rank-input --repo <repo_root> --base <base> --mode revisions --head <head> --out <discovery_dir>/rank_input.jsonl"), a concrete output contract enumerating required fields per candidate, and concrete search hints ("Version", "versionCompare", "getDOM", "cloneNode", "execute/executemany/executescript"). It misses anchor 5 because commands contain unresolved placeholders (<python_command>, <plugin_dir>) and a large share of the checklist is abstract directive rather than executable guidance.

Workflow Clarity

The entry conditions are clearly branched (compact inventory, code diff, standalone repository discovery) and the Code Diff Workflow lists ordered steps, with one explicit checkpoint ("If a required input is still missing, stop and ask the user for it before continuing") and a termination criterion ("Continue reviewing until no additional distinct plausible candidates remain"). However, the dominant operational guidance is a flat 60-item rule list with no feedback loop validating emitted candidates or the ledger, which fits anchor 3 (sequence present but checkpoints missing or implicit) rather than 4.

Progressive Disclosure

External references are clearly signaled with purpose and are one level deep ("read `../../references/artifact-storage.md` and follow its storage policy", "defer to `../attack-path-analysis/references/severity-policy.md`"), and the body has clear section headers. But no bundle files ship with this skill, and the family-specific enumeration rules (SAML/SSO validators, XML parser factories, archive extraction, realm/authenticator packages, query APIs) are ~60 bullets of inlined material that belongs in per-family reference files — the anchor-3 case of content that should be separate staying inline.

Specificity

The description names its domain and one concrete action — "discover candidate security findings in a repository or code change" — but lists only a single capability rather than several specific actions, so it does not reach anchor 4. It is well above anchor 2 because the action named is concrete and scoped, not generic.

Completeness

It explicitly answers both questions: what it does ("discover candidate security findings in a repository or code change") and when to use it ("Use when Codex is already in the finding-discovery phase of a security scan or the user explicitly asks to discover candidate security findings"), plus a negative trigger ("Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans"). This matches the anchor-5 pattern of concrete what + when with explicit trigger phrases.

Trigger Term Quality

Natural trigger terms are present — "security scan", "security findings", "repository", "code change", "PR, commit, branch, patch" — giving good keyword coverage a user would actually say. It falls short of anchor 5 because common synonyms such as "vulnerabilities", "security issues", "audit", or "CVE" are missing.

Distinctiveness Conflict Risk

It carves out a clear niche — the finding-discovery phase or an explicit discovery request — and explicitly excludes the sibling full-scan triggers ("Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans"), which sharply reduces conflict risk with related scan skills. This is the anchor-5 case: distinct triggers, minimal overlap.