From pds
Associates PDS tasks with GitHub issues: orchestrator finds or creates ticket using gh CLI, posts plan and checkbox acceptance criteria, updates progress, stores number in .claude/swarm/ticket. Use at Phase 1 of swarms.
npx claudepluginhub rmzi/portable-dev-system --plugin pdsThis skill uses the workspace's default tool permissions.
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.
Grooms all open GitHub issues with subagents for clarity then loops implementation: branch, research, swarm code, test, commit, merge PRs until backlog cleared.
Initiates BEADS multi-agent orchestration to autonomously handle GitHub issues from creation through design review, implementation, code review, and deployment to production. Triggers on 'start issue', 'work on issue', or metaswarm mentions.
Creates PRDs, tasks, or GitHub issues/sub-issues for features, bugs, enhancements. Detects GitHub CLI or local workflow, researches context, drafts for approval before creation.
Share bugs, ideas, or general feedback.
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.
.claude/swarm/ was cleared.[ ] to [x] as the validator confirms them.Closes #<num> so merging closes the ticket automatically.After /pds:grill produces a plan + acceptance criteria, the orchestrator searches for an existing ticket:
# 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:
gh issue create --title "<task summary>" --body "$(cat <<'EOF'
## Plan
<plan summary from grill>
## Acceptance Criteria
- [ ] <criterion 1>
- [ ] <criterion 2>
- [ ] <criterion 3>
## Swarm Context
- **Tier:** <lite | med | heavy>
- **Swarm started:** <YYYY-MM-DD>
- **Artifacts:** `.claude/swarm/` (ephemeral; archived to `docs/swarm-reports/` on teardown)
EOF
)"
AskUserQuestion with the candidate issue numbers as options + "Create new" + "Other".Write the resolved issue number to .claude/swarm/ticket:
echo "<issue-number>" > .claude/swarm/ticket
If fallback was taken (see section 4), write a human-readable marker instead:
echo "none (<reason>)" > .claude/swarm/ticket
# e.g. "none (no github remote, gh unauthenticated)"
All subsequent phases read this file. The invariant is: the file always exists after Phase 1. Downstream checks distinguish a real ticket from a fallback marker by the content — if it matches ^[0-9]+$, it's an issue number; otherwise it's a fallback marker and ticket operations are skipped.
On each acceptance-criterion completion (Phase 4, when the validator confirms a criterion):
# Fetch current body, flip the matching checkbox, write back
gh issue view <num> --json body --jq '.body' \
| sed 's/- \[ \] <matching criterion text>/- [x] <matching criterion text>/' \
> /tmp/ticket-body.md
gh issue edit <num> --body-file /tmp/ticket-body.md
On phase transitions (Phase 2, 3, 4, 5, 6 start), post a short comment:
gh issue comment <num> --body "Phase: <phase-name>. <one-line summary>"
On PR creation (Phase 5), include Closes #<num> in the PR body. Not enforced by the PR gate — the gate only checks phase state + validation/review reports. Omitting Closes won't block the PR, but it will break GitHub's auto-close-on-merge and leave the ticket orphaned.
On swarm completion (Phase 6, after scout report), post a completion comment with a link to docs/swarm-reports/<YYYY-MM-DD-HHmm>/ if archived.
If any of these are true, the orchestrator warns and proceeds without a ticket, recording the reason in scout-report.md AND writing a fallback marker to .claude/swarm/ticket (see section 2):
gh CLI is not installed or not authenticatedgit remote -v shows no github.com origin)Never block work solely on ticket unavailability. A warning in the swarm report + fallback marker in .claude/swarm/ticket is sufficient.
Downstream phases (4, 5, 6) check the ticket file content: if it's numeric, run the ticket update (gh issue edit, gh issue comment); if it's a fallback marker, skip ticket operations silently.
AskUserQuestion.claude/swarm/ticketCloses #<num> in PR body; comment on ticket linking the PRThe orchestrator speaks terse to the user (see /pds:voice) — the ticket body itself is normal register, not terse. The ticket is for human and future-agent readability; full prose belongs there. Voice applies to the orchestrator's inline status narration, not to the artifacts it writes.
/pds:swarm — Phases reference this skill at 1, 2, 4, 5, 6/pds:triage — downstream skill for converting swarm findings into new tickets