| name | to-tickets |
| description | Split settled conversation or an implementation-ready artifact into independently deliverable tracer-bullet tickets when explicit work decomposition is useful. |
| disable-model-invocation | true |
To Tickets
Turn settled work into tracer-bullet tickets when the user explicitly wants separately tracked work units.
Load /vault before reading or publishing artifacts.
Process
1. Gather the source
Use settled conversation as the source when no artifact is supplied. When the user supplies a vault artifact, resolve it with vlt read <stem> --depth 2. Require clear scope, implementation approach, acceptance criteria, and verification regardless of source shape. Report missing information and stop when the work is not implementation-ready.
2. Confirm current boundaries
Inspect enough current code and tests to verify the proposed slices against real integration points, dependencies, and test seams. Preserve the source scope and decisions.
3. Draft tracer bullets
Each ticket:
- delivers observable end-to-end behavior
- can be implemented and verified in one fresh context
- owns explicit source acceptance criteria
- states its verification evidence
- names only genuine blockers
- leaves the repository coherent after completion
Use expand-migrate-contract only when a wide change cannot stay green as independent vertical slices.
4. Check coverage
Map every source acceptance criterion or settled requirement to one or more tickets. Merge slices that only produce scaffolding, and split slices that exceed one coherent implementation session. Resolve material ambiguity with the user before publishing.
5. Publish tickets
Create blockers first:
vlt create --type ticket --topic "<ticket title>" --tags "stage/ready-for-agent" --json
vlt update <ticket-stem> --stdin --json
When a source artifact exists, record and link it:
vlt link <ticket> <source> --type derives-from --annotation "Implements one vertical slice"
vlt link <ticket> <blocker> --type blocked-by --annotation "Requires <capability> first"
Use this body:
## Status
ready_for_agent
## What to Build
The end-to-end behavior this ticket delivers.
## Source Coverage
- Source acceptance criterion or settled requirement covered by this ticket.
## Acceptance Criteria
- [ ] Independently verifiable ticket result.
## Verification
- Check or test that proves completion.
## Blocked By
- Linked ticket title, or `None - can start immediately`.
## Out of Scope
- Adjacent behavior owned elsewhere.
## Delivery Evidence
Pending implementation.
6. Report the work graph
Report every ticket, covered spec criteria, blocking edges, and the initial frontier. A frontier ticket has ready_for_agent status and no incomplete blocker.
