Enforce v13 project attachment unconditionally in /ticket-create workflow

Friction Source

Surfaced 2026-05-13 by @tobiu after a swarm-coordination audit:

"while we are working on v13, ever newly created ticket should get assigned to https://github.com/orgs/neomjs/projects/12 => better overview for us, and worth a quick win ticket to enhance /ticket-create."

Empirical anchor (same session): I filed two tickets via gh issue create directly — #11306 (key shorthand cleanup) and #11307 (merge-conflict-safe lane audit) — both bypassing v13 project attachment until @tobiu surfaced the gap. Manual retro-fix via gh project item-add 12 --owner neomjs --url <url> worked but proves the discipline isn't mechanically enforced.

The Substrate Audit (V-B-A 2026-05-13)

.agents/skills/ticket-create/references/ticket-create-workflow.md §4 line 78 ALREADY documents the discipline:

"Release tracking is NOT via labels. Use the create_issue tool's projects parameter to atomically attach the new ticket to a ProjectV2 board. ... Per #11233, the release:v* label family is deprecated — use projects: [{projectNumber: 12}] for v13 release tracking."

But two gaps prevent mechanical enforcement:

1. Conditional language — "for v13 release tracking" implies only release-blocking tickets. Operator's framing is unconditional during v13 cycle: every new ticket → v13 board for visibility, regardless of whether it's release-blocking.
2. gh issue create bypass route — projects: [...] is the MCP create_issue parameter; agents using gh issue create directly (faster for ad-hoc filing) skip the discipline silently. The skill is silent on the bypass.

The Fix

Tighten .agents/skills/ticket-create/references/ticket-create-workflow.md §4:

- - **Release tracking is NOT via labels.** Use the `create_issue` tool's `projects` parameter to atomically attach the new ticket to a ProjectV2 board. Labels are categorization primitives (`bug`, `architecture`); ProjectV2 memberships are first-class release-tracking primitives. Per [#11233](https://github.com/neomjs/neo/issues/11233), the `release:v*` label family is deprecated — use `projects: [{projectNumber: 12}]` for v13 release tracking.
+ - **Project attachment is MANDATORY on every ticket during the v13 release cycle.** Visibility primitive: every new ticket goes onto Project 12 ([Neo v13 Release board](https://github.com/orgs/neomjs/projects/12)) so the swarm + operator have a single overview. ProjectV2 memberships supersede the deprecated `release:v*` label family per [#11233](https://github.com/neomjs/neo/issues/11233).
+   - **`create_issue` MCP tool path:** pass `projects: [{projectNumber: 12}]` atomically with the create.
+   - **`gh issue create` CLI bypass path:** ALWAYS follow with `gh project item-add 12 --owner neomjs --url <new-issue-url>` immediately. Treat the two-step as inseparable.
+   - **Project anchor** is currently `12` (v13). When v14 release work begins, update the project number in this section AND the corresponding `create_issue` MCP tool default. Sunset condition: once v13 release ships, this rule needs disposition review (`keep` with updated project number, OR `compress-to-trigger` if mid-release ambiguity arises).

Also worth: add a pre-create check to ticket-create-workflow.md §1 (Gate 0):

<h3 class="neo-h3" data-record-id="5">1d. Project Attachment Pre-Flight (during release cycle)</h3>

Before draft, confirm the target project number is current (cite the project number in your Pre-Flight reasoning statement, e.g., *"Will attach to Project 12 per §4."*). Prevents stale-project-number drift across release cycles.

Acceptance Criteria

• (AC1) ticket-create-workflow.md §4 Release-tracking bullet rewritten to mandate every ticket (not just "for v13 release tracking") gets v13 project attachment during the v13 cycle
• (AC2) Both attachment paths documented: create_issue MCP projects: parameter + gh issue create + gh project item-add two-step
• (AC3) Sunset condition + post-v13 disposition review noted inline (project anchor 12 → future v14)
• (AC4) Pre-flight 1d Project Attachment Pre-Flight section added to Gate 0 sweeps
• (AC5) Bypass anti-pattern row added to ticket-create-workflow.md's existing anti-pattern table (or §10 if there's one): "Using gh issue create without follow-up gh project item-add"

Out of Scope

• Mechanical CI gate that audits new issues for v13 project membership (separate ticket if needed; this is skill-discipline-level fix)
• Auto-add via GitHub webhook on issue-open (architectural — different substrate)
• Backfilling pre-existing v13 tickets that weren't attached — separate sweep if operator wants

Avoided Traps

• Hardcode "Project 12" without sunset condition — locks the skill to v13; needs explicit update path for v14
• Add a new MCP tool just for project attachment — create_issue already supports projects: and gh project item-add works for the CLI path; no new substrate needed
• Skill addition without Pre-Flight integration — the Gate 0 sweeps are where the discipline fires reflexively, not in §4 (which is reference)
• Substrate accretion bypass — this PR is small net-expansion to skill substrate. Per pull-request-workflow.md §1.1, compress-to-trigger default doesn't strictly apply (the rule has high per-turn frequency: every ticket creation). keep is justified.

Related

• Origin friction: @tobiu observation 2026-05-13
• Empirical anchor: #11306 + #11307 filed without project attachment same session (now retro-fixed)
• Existing substrate (the gap): .agents/skills/ticket-create/references/ticket-create-workflow.md §4
• Project anchor: Project 12 — Neo v13 Release
• Deprecation reference: #11233 (release:v* label retirement)