Spec Tasks To Github

Spec Tasks To GitHub

When to use

• spec/tasks.md exists and user wants GitHub issues that trace to task lines or IDs.
• Planning a swarm milestone after SDD approval.

Preconditions

• User confirms spec/tasks.md is the approved source for scope.
• Issue labels exist or you document one-time gh label create commands.

Workflow

1. Parse spec/tasks.md for - [ ] / - [x] items and any task IDs or requirement references.
2. Group into minimal set of issues (prefer one issue per mergeable unit, not one per checkbox micro-step).
3. Infer DAG:
   • Tasks that only depend on earlier sections → earlier issues block later ones (blocked-by:<N>).
   • Independent sections → parallel label.
4. Draft one issue body per issue using this template (copy to clipboard or file for gh issue create --body-file):

## Spec trace
- spec/tasks.md: <!-- quote the task line or ID -->

## Acceptance criteria
- [ ] ...

## Branch
`feat/issue-<N>-short-slug` (fill N after issue is created)

## Dependencies
- Labels: <!-- parallel | sequential -->
- blocked-by: <!-- issue numbers, or none -->

## Review / verify
- [ ] pr-reviewer
- [ ] replication-verifier (if applicable)
- [ ] artifact-coherence-auditor (if paper/replication alignment)

5. Ordering: Create blocking issues first so you can reference their numbers in blocked-by: on dependent issues.
6. Handoff: Tell the user to run github-swarm-orchestration for execution, or continue in the same session following that skill's phases.

Guardrails

• Do not change product scope: export what the spec says; flag ambiguities instead of inventing tasks.
• Keep issue bodies self-contained for workers who lack chat context.

Output

• Numbered list of proposed issue titles + labels + dependency notes
• Ready-to-paste issue bodies (or paths to temp files) for gh issue create