Conciseness

The body is dense with high-value, non-obvious API details ("Verification `source.type` is PascalCase (`Docker`) — generation uses lowercase (`docker`)", "`verify_attestation` is snake_case (not `verifyAttestation)"), but several rules are repeated across sections: the "do not execute the pipeline" rule appears in Interaction model #10, the phase table note, the summary section, and Performance Notes; the external cd-containerized-step-group.md path is cited four times; and "only works with existing pipelines" is stated three times.

Actionability

Guidance is fully executable: a copy-paste-ready SlsaVerification YAML block with concrete values, an exact generation-to-verification field mapping table ("`source.spec.repo` → `source.spec.image_path`"), a parameterized harness_update call, insertion rules with identifier conventions, and a complete summary template. Common cases (keyless, keybased, policy-only, CD) each have concrete examples.

Workflow Clarity

The wizard is clearly sequenced as a phase table (0–10 plus 3b) with a progress breadcrumb, and validation checkpoints are explicit: "Fetch before configure — `harness_get` before placement/source questions", "Confirm before write", and "Stop after update". Error-recovery feedback loops are present in Troubleshooting (validation errors → "retry with nested `cosign` wrapper", `DUPLICATE_IDENTIFIER` → rename, `CONNECTOR_NOT_FOUND` → verify connector).

Progressive Disclosure

The body is a well-structured overview with clearly signaled one-level-deep references (`references/interactive-wizard-flow.md` and `references/slsa-verification-step.md` both exist and hold the bulk detail), but the repeatedly cited `skills/security/generate-slsa/references/cd-containerized-step-group.md` is not part of this bundle, and the inline phase table partially duplicates the wizard-flow reference. Anchor 4 fits: good structure with minor organization gaps.

Specificity

Multiple concrete actions are stated: "Add an SLSA Verification (SlsaVerification) step", "verify SLSA provenance attestations", "optionally enforce OPA policy sets on provenance data", "append a Deploy stage via Phase 3b", plus explicit stage and artifact-type coverage ("Docker, ECR, GCR, GAR, ACR, HAR, and Local"). No vague filler; anchor 5 fits and anchor 4's 'minor gaps' does not.

Completeness

Both questions are answered explicitly: 'what' — "Add an SLSA Verification (SlsaVerification) step to an existing Harness pipeline to verify SLSA provenance attestations and optionally enforce OPA policy sets", and 'when' — "Use when asked to verify SLSA, enforce SLSA policies, add SLSA verification step, validate SLSA attestation, or gate deploy on SLSA provenance" followed by an explicit Trigger phrases list. This matches the anchor-5 example pattern exactly.

Trigger Term Quality

Natural user phrasings are comprehensively covered with synonyms and variations: "enforce SLSA, SLSA verification, verify SLSA, SLSA policy enforcement, SlsaVerification, verify SLSA attestation, add SLSA verify step", plus "validate SLSA attestation" and "gate deploy on SLSA provenance" in the Use-when clause. A user needing this skill would naturally say these.

Distinctiveness Conflict Risk

The niche is clear and distinct: SLSA verification/enforcement on existing Harness pipelines, separated from the sibling generation skill by verification-only triggers ("verify SLSA", "SlsaVerification", "gate deploy on SLSA provenance") and the scope constraint "Only works with existing pipelines". Overlap risk with /generate-slsa or /create-policy triggers is minimal.