chelch5/ticket-pack-builder

Ticket Pack Builder

Use this skill to create or refine the repo-local work queue.

Modes

• bootstrap: Generate the first implementation-ready backlog during initial scaffold
• refine: Regenerate, expand, or normalize an existing backlog later

Bootstrap mode procedure

1. Read the canonical brief

Read the project brief. Identify:

• What features/capabilities need to be built
• What infrastructure/setup is required
• What the acceptance criteria are
• Which areas are blocked on unresolved decisions
• The backlog readiness signal

2. Break work into implementation waves

Organize tickets into waves based on dependency order:

| Wave | Purpose | Examples | |------|---------|---------| | Wave 0: Foundation | Repo setup, CI/CD, configuration | Project init, dependency install, CI pipeline | | Wave 1: Core | Primary functionality | Core business logic, main features | | Wave 2: Secondary | Supporting features, integrations | Secondary workflows, integrations | | Wave 3: Polish | Hardening, performance, docs | Error handling, performance, UX refinement |

3. Create individual tickets

For each piece of work, create a ticket with these fields:

• id — unique identifier (e.g., SETUP-001, CORE-001, FEAT-001)
• title — short descriptive title
• wave — which execution wave
• status — todo or blocked (all new tickets start in planning stage)
• depends_on — list of ticket IDs this depends on
• summary — one-paragraph description
• acceptance — list of specific, verifiable acceptance criteria
• decision_blockers — unresolved decisions that block this ticket (empty if none)

Optional fields for parallel execution:

• lane — which project area or ownership lane
• parallel_safe — whether this can advance in parallel when dependencies are met
• overlap_risk — low, medium, or high expected overlap with other tickets

Ticket sizing rules

• Each ticket should be completable in ONE agent session
• If a ticket requires changes to more than 5-7 files, split it
• If a ticket has more than 5 acceptance criteria, consider splitting
• Prefer many small tickets over few large ones

Handling unresolved decisions

• Do NOT fabricate implementation detail for work that depends on unresolved major choices
• Create explicit blocked tickets with decision_blockers listing what needs to be decided
• Create decision tickets for choices the team needs to make
• Create discovery tickets for research that needs to happen before implementation

4. Write ticket files

For each ticket, write a markdown file to tickets/<id>.md:

---
id: SETUP-001
title: Initialize project structure
wave: 0
status: todo
depends_on: []
---

# SETUP-001: Initialize project structure

## Summary
Set up the base repository structure with package manager, build tooling, and test framework.

## Acceptance Criteria
- [ ] Package manager configured with lock file
- [ ] Build command produces output without errors
- [ ] Test command runs (even with zero tests)
- [ ] Linter configured and passing

5. Write the manifest

Write tickets/manifest.json with structured ticket data:

{
  "version": 2,
  "project": "<project-name>",
  "active_ticket": "<first-ticket-id>",
  "tickets": [ ... ]
}

6. Generate the board

Write tickets/BOARD.md as a human-readable view organized by wave:

• Ticket ID, title, status, dependencies
• Grouped by wave
• This is a DERIVED VIEW — the manifest is the source of truth

7. Validate

• No circular dependencies in the dependency graph
• Every depends_on reference points to a real ticket
• Every ticket has at least one acceptance criterion
• No ticket is both todo and has unresolved decision_blockers (should be blocked)
• Critical path is identifiable

Refine mode

Use when expanding or normalizing an existing backlog:

1. Read the existing manifest
2. Identify gaps, unclear tickets, or new work from updated brief
3. Add/modify tickets following the same rules
4. Regenerate BOARD.md from manifest

Output contract

tickets/
├── manifest.json          # Machine-readable ticket data (source of truth)
├── BOARD.md               # Human-readable board (derived view)
├── SETUP-001.md           # Individual ticket files
├── CORE-001.md
└── ...

Rules

• Keep manifest machine-readable; keep board human-readable
• Keep status coarse: todo, ready, in_progress, blocked, review, qa, done
• Do NOT use ticket status for transient approval state (that belongs in workflow state)
• Record dependencies explicitly
• Put acceptance criteria on every ticket
• Mark parallel_safe: true only when overlap risk is genuinely low

Failure handling

• Brief too vague: Cannot decompose "build the app" into tickets. Request specific features first.
• Ticket too large: Split into sub-tickets. Use -a, -b suffixes if needed.
• Circular dependencies: Refactor to break cycle — extract shared prerequisite as separate ticket.
• No clear acceptance criteria: Do not create ticket. Flag as needing clarification.

References

• This is step 5 of the scaffold-kickoff flow — continue to ../project-skill-bootstrap/SKILL.md
• Shape Up "Map the Scopes": https://basecamp.com/shapeup