feat: ban work-tracking coordinates in names and comments

[daniellam258]

Upstreamed from a consuming repo, re-expressed generically per CONTRIBUTING.

What the skills get wrong today

rules-naming.md demands self-descriptive names and rules-doc-comments.md already bans naming a tracked issue or PR from source. Neither closes the gap an agent actually falls into: an acceptance-criterion number, a review-round tag, or a workstream code is not "a tracked issue", so nothing in the rules stops ac4, [ATTSMOKE-7.1], or a ticket slug from being written into an identifier, a file name, a directory, a stack, or a test name. In the consuming repo this had accumulated across 213 files — roughly 800 bracket labels on test names, ~250 // REQ: traceability lines, plus ticket slugs baked into binary and suite file names.

The convention existed only as a default inside one agent harness's built-in prompt. Unwritten, it drifted; and because the rules covered comments but never names, the harness's own agents produced the violations while believing they complied.

What this changes

rules-naming.md gains "Names are never work-tracking coordinates." A ticket ID, an acceptance-criterion number, a review-round or finding label, or a requirement/workstream code with no in-repo definition must not appear in an identifier, file, directory, binary, module, stack, or test name. Such a name records where the work was tracked, not what the thing is — the reader of the code has no guaranteed access to the tracker, and the reference rots the day the ticket closes. The binary that proves chain anchoring is chain-anchor-proof, not proj424-proof.

rules-doc-comments.md extends its existing bullet to name acceptance-criterion numbers and requirement/workstream labels explicitly, rather than leaving them to be inferred from "tracked issue".

The load-bearing part

Both files now carry the same test: a label is canonical only if the repository itself defines it; a delivery report merely quoting it does not count.

Without that sentence the rule is unusable, because the honest objection to it is immediate — an ADR number is also a code, and it is fine. The difference is not format but resolvability: a decision record or a docs/… path can be opened by anyone holding a clone, whereas a requirement label that appears nowhere except as a quotation inside a dated evidence report cannot be resolved by anyone, including the team that wrote it. Applying that test in the consuming repo reversed an earlier carve-out that had permitted these labels in test names for "requirement traceability" — the labels turned out to have no defining document at all.

Citing an in-repo canonical artifact stays fine inside a comment, but never as a substitute for a self-descriptive name.

Escape hatch

A name that is already deployed, signed, or measured — a wire tag, a name baked into an artifact's measurement — does not get an exemption on principle. It routes to the existing compatibility-aware rename rule directly below the new section, so it is scheduled work rather than a permanent blessing.

Checks

bash scripts/skill-lint.sh
skill-lint: OK (frontmatter, size, references, citations, paths, eval.json across skills/)

skills/agent-instructions/SKILL.md bumped 0.2.0 → 0.2.1 per house style.

Genericity: the diff names no product, repo, team, or tracker; examples use proj424-proof / chain-anchor-proof.

Note for the reviewer

skill-sync-audit-and-ci-facts (opened alongside this) also bumps agent-instructions 0.2.0 → 0.2.1. The two branches are independent, so whichever merges second needs its version taken to 0.2.2 on rebase — taking either side of that line as-is would ship two changes under one version.