---
name: ticket-format
description: >
  Create consistently formatted tickets for development work. Used by the PM agent
  and during Phase 5/6. Ensures every ticket has acceptance criteria, estimates,
  and testing strategy. Invoked when creating or reviewing tickets.
---

# Ticket Format Skill

Every ticket in this project follows this standard format. No exceptions.

## Template

```markdown
## [ID] — [Title]

**Type:** Feature | Bug | Chore | Spike
**Priority:** P0 (Critical) | P1 (High) | P2 (Medium) | P3 (Low)
**Complexity:** S (< 1hr) | M (1-4hr) | L (4-8hr) | XL (> 8hr, consider splitting)
**Estimated Tokens:** [number] (budget line: 2x this)
**Depends On:** [ticket IDs or "none"]
**Blocks:** [ticket IDs or "none"]
**Assigned Role:** [agent from roster]
**Files Owned:** [list of files this ticket modifies — for conflict prevention]
**Phase:** [which workflow phase]

### Description
[What needs to be done and why. Include enough context that an agent with no
prior knowledge of this project can understand the task after reading the spec.]

### Acceptance Criteria
- [ ] [Specific, testable criterion — phrased as "Given X, when Y, then Z"]
- [ ] [Another criterion]
- [ ] [Tests written and passing]
- [ ] [Lint and type checks pass]
- [ ] [Documentation updated]

### Testing Strategy
- **Unit tests:** [what to test]
- **Integration tests:** [what to test, if applicable]
- **Manual verification:** [steps, if applicable]

### Definition of Done
- [ ] Code written and linted
- [ ] Type checks pass
- [ ] Tests written and passing
- [ ] Code reviewed by `code-reviewer` agent
- [ ] Documentation updated
- [ ] Ticket status updated in PM tool

### Notes
[Any additional context, links to research docs, design decisions, gotchas]
```

## ID Convention

`[PROJECT]-[PHASE]-[SEQ]`

Examples:
- `RSS-P6-001` — RSS Feed project, Phase 6, ticket 1
- `BEADS-P2-003` — Beads project, Phase 2, ticket 3

## Sizing Guidelines

| Size | Scope | Token Estimate | Notes |
|------|-------|---------------|-------|
| S | Single function, small fix, config change | < 5K tokens | Should be completable in one turn |
| M | Single module, new endpoint, component | 5K–20K tokens | Standard dev ticket |
| L | Multi-file feature, complex logic | 20K–50K tokens | May benefit from subagent |
| XL | Cross-cutting concern, large refactor | 50K+ tokens | Consider splitting into M tickets |

**If a ticket is XL, split it.** Large tickets have higher failure rates and waste tokens on retries.

## Rules

- Every ticket must have at least 2 acceptance criteria
- "Files Owned" must be populated to prevent merge conflicts between agents
- The "Depends On" field must be accurate — missed dependencies cause cascading failures
- Token estimates must include the 2x budget multiplier
- Bug tickets must include reproduction steps in the Description
- Spike tickets (research/investigation) have a timebox, not a deliverable