Six routing claims in the workflow-ci-contract skill description that do not match what it ships

[ptr727]

The description: frontmatter of .agents/skills/workflow-ci-contract/SKILL.md is what routes an agent to this skill, and six of its claims do not match what the skill ships or what its sibling owns. Found by a whole-unit canonical pass on PR #1203's fix branch, and deferred out of it, which corrected only the one stale framing clause a reviewer had raised.

A reader routed by frontmatter never sees the skill body, so a claim the body scopes correctly is still wrong here.

The walkthroughs are neither part of the methodology nor shipped

the 5A/5B/5C test methodology with its per-type walkthroughs

Two errors. WORKFLOW.md section 5 is the test methodology and section 6 is a separate "Per-Project-Type Test Walkthroughs", so the walkthroughs are not part of 5A/5B/5C. And the skill ships neither them nor the per-type 5A addenda: references/test-methodology.md says the walkthroughs "are WORKFLOW.md section 6" and that the addenda are to be read "in WORKFLOW.md 5A rather than from this list". A reader holding only the description expects content the skill deliberately does not carry.

The trigger surface misses paths the skill's own rules govern

Use this whenever writing or editing anything under .github/workflows/, adding or dropping a release target, auditing a repo's workflows, or reasoning about why a publish did or did not fire

Composite actions are governed and absent from that list. D1.3 has a rule that applies only inside one, "inputs.smoke != 'true' in a composite action, whose inputs are strings", and this repository carries nine actions under .github/actions/. Editing one fires nothing.

version.json is governed too, by D3.2's three-literal rule, by D3.3, and by 5A's sweep, and appears in no trigger here. The sibling operational-vs-release-workflow description does claim "bumping version.json", so that edit routes to the skill that does not carry D3.2.

The advertised split with the sibling skill is not clean

reasoning about why a publish did or did not fire

is a trigger here, while two sentences later the same description says

the operational-vs-release-workflow skill keeps the git half (branching, promotion, publish policy), so branch choice questions go there

The skill body backs the claim in detail ("A human merge never auto-publishes", D4.1). The sibling's own description claims the same question, "reasoning about why a merge did or didn't trigger a publish", and also claims "adding or dropping a release target" in wording shared verbatim with this trigger list. Nothing tells a reader which of the two to load.

The precedence claim is unscoped

WORKFLOW.md keeps authority, and GOVERNANCE.md wins where the two overlap.

True of exactly one GOVERNANCE.md section. "Workflow YAML Conventions" says "This section and WORKFLOW.md keep the full rules, this section winning where the two overlap." The other section this skill's body names, "Release Model", points the other way: "See WORKFLOW.md for the full CI/CD contract". Generalized to the whole file the sentence asserts a precedence GOVERNANCE.md does not state, and paired with "WORKFLOW.md keeps authority" it is unresolvable from the frontmatter alone. The body has the scoping the description dropped.

The stated reason is narrower than its conclusion

because SHA pinning, the ruleset-bound aggregator name, smoke gating on uploads, and retention-days are each easy to break in a one-line diff that no smoke build exercises, since workflow-only changes are deliberately not smoke-built

D1.4's exemption covers a PR changing only .github/workflows/**, so a PR touching a workflow alongside target paths is smoke-built. Three of the four items are unexercised for a different reason: smoke uploads nothing (D1.3), so retention-days and the upload gating are never executed by any smoke run at all, and the ruleset-bound aggregator name is bound by a ruleset context: that no build touches. A reader following the stated reason concludes a mixed PR's smoke build covered them.

The seam is narrowed to one of its four destinations

the seam contract for release assets

WORKFLOW.md "Output Seam by Destination" covers a package-registry push, an image push, and a filesystem on a host the project owns, none of which contribute a release-asset-*, and each carries obligations the skill does cover (expect_release_assets: false, D4.6, D5.6). The phrasing tells a reader adding a PyPI-only, Docker-only or static-site target that the seam material here is about release assets they will never produce.

Scope note

A seventh finding, that the description asserted the D1-D9 guarantees are "stated as the failure mode each prevents", was the one corrected on the fix branch, because a reviewer raised it against WORKFLOW.md and the same stale framing sat here. The replacement states no framing at all rather than substituting "the output a conforming pipeline produces", since D9, D6.2 and D5.5 are not outputs. That underlying overclaim still stands in WORKFLOW.md section 4's preamble and in references/d-guarantees.md, and is tracked in #1206 and #1205.

Changing this file means regenerating .github/skills/ and .claude-plugin/ with scripts/build_dist.py. Related to #1200, #1204, #1205, #1206.

[ptr727]

A second whole-unit pass over the same unit, at its post-fix text, adds one finding to the six above.

A contract requirement is stated as an accomplished fact.

because SHA pinning, the ruleset-bound aggregator name, smoke gating on uploads, and retention-days are each easy to break in a one-line diff that no smoke build exercises, since workflow-only changes are deliberately not smoke-built

"are deliberately not smoke-built" is D1.4, a MUST a repository can fail, rather than a property every fleet repository already has. D1.1 names the failing shape directly: a paths filter "written the other way round, as a negation of the paths that must not build ... satisfies D1.4 and violates this item", which does mark a workflow-only or docs-only change. Auditing a repository's workflows is one of this skill's own triggers, so stating the requirement as a fact invites an auditor to assume it rather than check it. The fix is a word, "must not be" rather than "are".

The same pass also confirmed, against the current text, the composite-action trigger gap and the publish-policy split already described above, and it re-derived the composite-action case with a detail worth recording here: scripts/docker_lint.py scopes actionlint to .github/workflows/*.yml and *.yaml only, so the skill's own "run actionlint locally before pushing" remedy reads zero bytes of a hook action. An ungated upload-artifact added to .github/actions/<hook>/action.yml therefore violates D1.3 on every smoke pull request with no trigger fired and no linter reading the file. That matches the separately recorded finding in [actionlint does not cover composite actions].

Not a finding against this unit, recorded as an observation: the description is 1099 characters, over the 1024-character cap some skill consumers enforce, where truncation would drop the trailing "WORKFLOW.md keeps authority, and GOVERNANCE.md wins where the two overlap." Five other fleet skills are longer, repo-worktree at 1379, so it is fleet-wide practice rather than something this unit introduced. Worth its own decision if any consumer actually truncates.