Conciseness

The body is dense with non-obvious operational knowledge Claude does not already have — "Exit code 137 is an arm64e/arm64 mismatch, not a build failure", "each pack's defaultSuiteFile applies hidden filters that can produce zero results", "a process substitution discards the script's exit status" — and contains no tutorial filler or explanation of basics. Not 5: at ~280 lines there are trimmable passages — the essayistic multi-sentence comments inside bash blocks ("The metadata the selection prompt needs, collected here rather than in a block of its own: FOUND_DBS is gone by the next Bash call..."), and the 12-item "Rationalizations to Reject" list could be condensed to the distinct rules. Not 3: nearly every sentence is skill-specific and load-bearing, which is well above "some unnecessary explanation".

Actionability

Fully executable, copy-paste-ready guidance: the dependency-guard block with exact install commands ("gh extension install github/gh-codeql", "brew install --cask codeql"), the database-discovery loop with the exit-status-preserving idiom, concrete script invocations ("{baseDir}/scripts/check_db_quality.py", "{baseDir}/scripts/verify_query_suite.py"), exact artifact paths ($OUTPUT_DIR/raw/results.sarif), and a condition→action decision table. Not 4: the common case is covered end to end with real commands, specific exit codes, and named artifacts, not just "minor gaps".

Workflow Clarity

Clear sequence with explicit validation and feedback loops: "execute the full pipeline: build database → create data extensions → run analysis", quality gates ("Run {baseDir}/scripts/check_db_quality.py after the build", "confirm {baseDir}/scripts/verify_query_suite.py exited zero"), error recovery ("A database build has four fallback methods", arm64e workaround reference, "Every method failing... come back as statuses — no-method-succeeded and built-below-threshold"), a zero-findings investigation loop ("Zero findings needs investigation, not celebration"), and a terminal "Success Criteria" checklist. This matches the anchor-5 example's validate→fix→retry shape at every stage. Not 4: checkpoints are explicit and named, not merely present.

Progressive Disclosure

Structure and signaling are good — a Reference Index table with one-line content descriptions per file, a Workflow Selection table, and all cited references/*.md and scripts/* files exist and are one level deep. Not 4 (verified against the actual bundle): the three load-bearing workflow files the whole skill routes through — workflows/build-database.md, workflows/create-data-extensions.md, workflows/run-analysis.md — are absent; the workflows/ directory does not exist anywhere in the bundle, so every execution path dead-ends at a dangling reference. Additionally, the "Each Bash call is a fresh shell" failure-mode catalogue and the Database Discovery implementation are inlined in SKILL.md where the rubric expects detail to be split out. Not 2: the SKILL.md is a genuine overview with clearly signaled, one-level-deep references for everything that does exist.

Specificity

Quotes: "Scans a codebase for security vulnerabilities using CodeQL's interprocedural data flow and taint tracking analysis", "Supports 'run all' (security-and-quality + security-experimental) and 'important only' (high-precision) scan modes, and creates data extension models for project-specific sources and sinks", "Covers Python, JavaScript/TypeScript, Go, Java/Kotlin, C/C++, C#, Ruby, and Swift". Multiple specific concrete actions (scan, build databases, two named scan modes, data extension modeling) with comprehensive language coverage; third-person voice throughout ("Scans", "Covers", "Supports"). Not 4: the anchor-4 case has "minor gaps in coverage", and here actions, modes, languages, and outputs are all enumerated with no gaps.

Completeness

Quotes: the full "what" — "Scans a codebase for security vulnerabilities using CodeQL's interprocedural data flow and taint tracking analysis ... creates data extension models" — and an explicit, enumerated "when": "Triggers on 'run codeql', 'codeql scan', 'build codeql database', 'SAST scan', 'taint analysis', 'dataflow analysis', or 'find vulnerabilities in this repo'". Both what and when are explicit with concrete trigger phrases. Not 4: the when-clause is not merely present but itemized, matching the anchor-5 example's structure exactly.

Trigger Term Quality

Quotes: "run codeql", "codeql scan", "build codeql database", "SAST scan", "taint analysis", "dataflow analysis", "find vulnerabilities in this repo". Seven natural, varied phrases covering tool-name, action, and technique synonyms. Not 5: very common generic phrasings a user would naturally say without naming the tool — "static analysis" (the skill's own output directory is named static_analysis_codeql), "security scan", or "security audit" — are absent, which is the anchor-4 condition of "good keyword coverage; a few natural terms missing". Not 3: the listed terms are natural and include multiple synonyms, not merely "some relevant keywords".

Distinctiveness Conflict Risk

Quotes: "For fast single-file pattern matching, or when no build is available for a compiled language, use the semgrep skill; to parse SARIF that already exists rather than produce it, use the sarif-parsing skill". This actively de-conflicts against the two nearest neighboring skills by stating when to route elsewhere — stronger than the anchor-5 example, which only establishes a niche. Not 4: the overlap risk with semgrep/sarif skills is not left implicit; it is explicitly resolved.