Conciseness

The body is lean and code-first: every section is either a compact command block, a payload diff, or a two-column table, and the prose adds only non-obvious domain knowledge (the D-PPE/I-PPE taxonomy, why pull_request_target + PR-head checkout is privileged). It is not 4 because nothing reads as over-explanation to trim; the CVE/date mentions ("CVE-2025-30066", "Mar 2025") are precedent citations, not date-conditional instructions.

Actionability

Guidance is fully executable: copy-paste recon greps and gh api commands, concrete PR-diff payloads per ecosystem (package.json postinstall, Makefile target, build.gradle doFirst, pom.xml plugin, Dangerfile, pre-commit repo, setup.py), and a named tool table (gato/gato-x, actionlint, zizmor, octoscan). It is not 4 because the examples are complete and cover the common cases; the <COLLAB>/<REPO> placeholders are parameters, not pseudocode.

Workflow Clarity

A clear implicit sequence runs Recon → choose D-PPE or I-PPE vector → payload → Decision gate, with a numbered recon checklist (trigger greps, fork/permission checks) and a Decision gate acting as a safety checklist (beacon-only PoC, labeled research fork, close+delete after capture). It is not 5 because there is no explicit end-to-end numbered workflow or feedback loop (e.g., verify the beacon was received before cleanup); not 3 because validation checkpoints are present via the recon gates and Decision gate.

Progressive Disclosure

The body is well-sectioned with navigable headers (Recon, Direct PPE, Indirect PPE, pull_request_target, Chains, Tools, Detection, Decision gate) and cross-skill references clearly signaled in the Chains table (cicd-secrets-exfil/SKILL.md, self-hosted-runner-abuse/SKILL.md); no bundle files exist, so inline placement is the only option. It is not 5 because at ~180 lines the per-ecosystem payload examples are candidates for one-level-deep references/ files that would keep SKILL.md a leaner overview.

Specificity

The description lists multiple concrete actions — "inject commands via attacker-controllable build files (Makefile, package.json scripts, build.gradle, Dangerfile, .pre-commit-config.yaml)", "abuse pull_request_target / fork-PR triggers", and "ride dependency / test-script execution on CI" — each with named file targets, comprehensively covering the direct and indirect PPE space. It is not 4 because there are no coverage gaps: the actions are specific and span the technique's full scope.

Completeness

The "what" is explicit and concrete (inject commands via named build files, abuse specific triggers), but the description field contains no "Use when..." clause or equivalent explicit trigger guidance — the trigger phrasing lives in metadata.when_to_use, outside the evaluated field — which caps completeness at 3 per the rubric. It is not 4 because "when" is absent entirely rather than merely imprecise.

Trigger Term Quality

Strong keyword coverage including "PPE", "pull_request_target", "fork-PR", "Makefile", "package.json scripts", "Dangerfile", ".pre-commit-config.yaml", and "CI" — terms a security researcher would naturally say. It is not 5 because natural synonyms and variations such as "CI/CD", "GitHub Actions", "workflow", or "supply chain" are absent; not 3 because the terms present are specific and abundant rather than missing common variations.

Distinctiveness Conflict Risk

"Poisoned Pipeline Execution (PPE)" names a specific attack technique with highly distinct triggers ("pull_request_target", "Dangerfile", ".pre-commit-config.yaml") that no sibling skill would plausibly claim, giving a clear niche with minimal conflict risk. It is not 4 because the named technique and unique file/trigger terms make even minor overlap with related CI/CD security skills unlikely.