to-tickets

Files (1)

• SKILL.md

SKILL.md (first lines)

# To Tickets

Create **tracer-bullet tickets** with two scheduling relations:

- A **blocking edge** means the blocked ticket cannot start or integrate until
  the blocker is complete.
- A **conflict edge** means two otherwise unblocked tickets should not have
  active writers concurrently because they materially overlap in files,
  contracts, artifacts, or integration assumptions.

Read the configured issue tracker and triage-label vocabulary. If either
configuration is unavailable, follow
[setup-omskills](../setup-omskills/SKILL.md) and its scoped authorization gate
before continuing, including in headless runs. Respect read-only roles and
return unresolved prerequisites to the responsible caller.

## Process

### 1. Gather source context

Use the plan, spec, or conversation already in context. If the user provides a
path, issue number, or URL, read its complete body and comments before drafting
tickets.

### 2. Inspect the repository when needed

If the repository's current implementation has not already been inspected in
this context, inspect the affected area. Use terms from the project domain
glossary in ticket titles and bodies, and preserve applicable ADR decisions.

### 3. Draft vertical slices

Each tracer-bullet Ticket must:

- deliver one behavior through every layer that behavior affects;
- be independently demonstrable or verifiable after completion;
- fit one fresh agent context with room to understand, implement, and verify it;
  and
- identify its category role as `bug` or `enhancement` from the accepted source.

Keep every requirement durable in the Ticket or explicitly incorporated tracker
artifacts; planning and audit conversations carry no hidden requirements. Do not
split cohesive work just to manufacture parallelism or invent serial
dependencies.

Decide what can safely run in parallel to save time. Use the actual
dependencies, conflicts, shared resources, and delivery needs to make that
planning decision. Record it with each Ticket's blocking and conflict relations
so dispatch can follow the plan rather than reconstruct it.

#### Wide-refactor exception

Use **expand–contract** instead of vertical slices when one mechanical change,
such as renaming a column or retyping a shared symbol, has a whole-codebase
blast radius and no partial vertical slice can keep CI passing:

1. **Expand:** add the new form beside the old form without breaking current
   callers.
2. **Migrate:** move callers in batches sized by blast radius, such as one
   package or directory per ticket. Each migration ticket is blocked by
   expansion, and the old form remains available so each batch can pass CI
   independently.
3. **Contract:** remove the old form only after every migration ticket is
   complete; block contraction on all migration tickets.

If no migration batch can pass CI independently, retain this sequence on an
integration branch and block a final integrate-and-verify ticket on all batches.
In that case, the requirement to leave CI passing applies to the final ticket
rather than each batch.

### 4. Obtain breakdown approval

Present a numbered draft. For each ticket, include:

- **Title:** one line naming the delivered behavior;
- **Blocked by:** every ticket that must complete first, or none;
- **Conflicts with:** every conflicting ticket and its shared surface, or none;
- **Execution:** the concurrency decisions and required order not already
  expressed by those relations; and
- **What it delivers:** the end-to-end behavior that becomes demonstrable or
  verifiable.

Before requesting approval, identify Mission topology whenever the breakdown
selects multiple Tickets; record their dependency, conflict, integration, and
shared-resource needs. Record maintainer availability independently when the
source resolves it; otherwise leave that dimension for the adaptive Delivery
mode gate rather than inferring absence from Mission topology.

Show the planned execution, blockers, conflicts, and shared resources outside
Git. Distinguish priority from required sequence or phase barriers, and record
any capacity assumptions for dispatch to check at execution time. Preserve the
user's established ordering constraints without treating list order as an
execution dependency.

Every implementation Ticket in a multi-Ticket Mission, including integration
Tickets, requires an exclusive worktree and branch established by its technical
owner before implementation. Read
[the worktree policy](../orchestrate/WORKTREES.md) when planning candidate
locations and cleanup. Before reading relative links, run
`cd '<loaded-skill-directory>' && pwd -P` with this loaded file's directory to
obtain the physical base, then resolve links against that printed directory.
Resolve the source symlink before applying `..`; read linked files even when
their skills are absent from the discovery list. For planning, use that shared
policy without invoking the coordinator.

Declare every delivery boundary in the approved breakdown:

- Parallel members deliver verified, committed, pushed branch artifacts, not
  implicit shared-target merges or group completion.
- Each parallel group includes a preplanned ordinary integration Ticket blocked
  by every member. Identify every predecessor, intended base/target and
  combination requirements. Require durable tracker evidence of each produced
  artifact's repository, remote branch and exact full commit SHA before
  integration starts; exact outputs are recorded at predecessor delivery, not
  guessed during planning. The integration Ticket combines those verified inputs
  in its own candidate, reviews and verifies the complete combined state, and
  records input-to-result commits before dependent work advances.
- Non-member Tickets and individually selected Tickets state their integration
  target and direct-push or pull-request delivery method explicitly. A pull

From luizomf/omskills, MIT.

More from luizomf/omskills