← ClaudeAtlas

ticketlisted

Associate every PDS task with a GitHub issue. Orchestrator finds or creates the ticket, posts plan and acceptance criteria as a checkbox list, updates it as work progresses. Use at Phase 1 of every swarm.
rmzi/portable-dev-system · ★ 24 · AI & Automation · score 53
Install: claude install-skill rmzi/portable-dev-system
# /ticket — GitHub Issue Enforcement Every swarm must be tethered to a GitHub issue. The ticket is the durable record: plan, acceptance criteria, progress, and final PR link. The orchestrator owns this — workers, validators, reviewers, scout, and shepherd reference the ticket but do not manage it. ## Why - **Traceability.** Every change maps to a ticket, PR, and closed criterion checklist — not just a commit. - **Handoff across swarms.** A resumed swarm reads the ticket body to recover plan + criteria even if `.claude/swarm/` was cleared. - **Human visibility.** Progress is visible outside the terminal. Acceptance criteria flip from `[ ]` to `[x]` as the validator confirms them. - **PR hygiene.** PRs link back with `Closes #<num>` so merging closes the ticket automatically. ## Protocol ### 1. Find or create — at Phase 1 of every swarm After `/pds:grill` produces a plan + acceptance criteria, the orchestrator searches for an existing ticket: ```bash # Search open and recently-closed issues for title/body keywords from the task gh issue list --state all --limit 20 --search "<task keywords>" --json number,title,state,body ``` Rules: - If exactly one open issue matches the task's intent, **reuse it** — append to the body (don't overwrite). - If zero matches, **create one** using the 7-section evolving-body template (`skills/ticket/templates/issue-body.md` — see `docs/adr/0009-evolving-body-issue-and-slim-pr-format.md` for why this shape, not a new one invented per-skill):