Conciseness

The body is mostly efficient (tool calls, YAML, tables, no concept explanations Claude already knows), but key rules are repeated three or more times: 'existing pipelines only' (Steps 1, Performance Notes, Troubleshooting), 'cloneCodebase: true' (Step 6, Performance Notes, Troubleshooting), '/create-secret' prompting (Steps 4, Performance Notes, Troubleshooting), and 'before build steps' (Steps 3, 6, Performance Notes). The Performance Notes section largely restates rules already stated in the step instructions. Not a 2 because nothing is padded filler or background explanation; not a 4+ because the redundancy pattern is systematic rather than minor.

Actionability

Fully executable, copy-paste-ready guidance: exact MCP calls with parameter blocks (harness_get/harness_update), complete YAML step configs for each scanner category, a precise table of per-scanner auth field names, the exact secret reference format ('<+secrets.getValue("project.<secret_identifier>")>'), and a concrete output summary template. This matches the score-5 anchor covering the common cases.

Workflow Clarity

The 8-step sequence is clearly ordered with several checkpoints (verify pipeline exists, stop if no codebase connector, ask user for insertion point, confirm secrets exist before generating YAML) plus a Troubleshooting section for error recovery and 'Run the pipeline to verify' in next steps. Not a 5 because there is no explicit post-update validation (e.g., re-fetch the pipeline to confirm the YAML was applied correctly) — a minor validation gap matching anchor 4; anchor 3 would require checkpoints to be missing or only implicit, which they are not.

Progressive Disclosure

The ~275-line body is a single monolithic file with no bundle files or references; content that naturally belongs in separate files — the per-scanner YAML templates, the scanner auth table, and the Troubleshooting section — is fully inlined in SKILL.md. Sections are well-labeled and navigation within the file is fine, but the structure matches 'content that should be separate is inline' (anchor 3) rather than anchor 4's 'most content is appropriately placed' with clearly signaled external references.

Specificity

Multiple concrete actions are stated ('Add secret detection scanning steps to existing Harness pipelines', 'Detects exposed credentials, API keys, tokens, and sensitive data') with comprehensive coverage including the full scanner list and an explicit scope constraint ('Only works with existing pipelines that have a codebase connector configured'). Third person voice is maintained throughout. Not below 5 because no capability area is left vague.

Completeness

Explicitly answers both 'what' (adds secret detection scanning steps to Harness pipelines using STO, detecting credentials/API keys/tokens) and 'when' ('Use when asked to add secret scanning, detect exposed secrets, find leaked API keys...') with concrete trigger phrases. This matches the score-5 anchor exactly; score 4 would require the 'when' clause to be less explicit.

Trigger Term Quality

Natural user phrasings are comprehensively covered with synonyms: 'add secret scanning, detect exposed secrets, find leaked API keys, configure secret detection, or scan code for credentials' plus an explicit trigger-phrase list ('add secret scan, find leaked credentials, add Gitleaks, secret scanning pipeline'). Falls short of neither anchor 4 (only 'a few natural terms missing' — none are missing here) nor below.

Distinctiveness Conflict Risk

The secret-scanning niche is clear, but the broad scanner roster ('Semgrep, Snyk, SonarQube, Checkmarx, Fossa, Aqua Trivy, and Wiz') and mentions of 'unified SAST/SCA/secret detection' create overlap risk with sibling Harness security-scan skills (e.g., a user asking to 'add Semgrep scanning' for SAST could trigger this). This is 'mostly distinct; minor overlap risk with closely related skills' rather than the minimal-conflict anchor 5.