git:20260813.14437ae to git:20260906.89d2d35

10 added, 0 removed. Audit A to A.

---

name: skill-work-slicing

disable-model-invocation: true

description: "Break a plan or spec into vertical slices that each declare what blocks them — use when work is agreed but not yet cut into fileable pieces"

---

# Work Slicing

Turn a plan, spec, or the conversation so far into a set of tickets. Each one is

a **vertical slice** — a narrow but complete path through every layer — and each

declares the tickets that block it.

This is the step between "we know what we are building" and "someone can pick up

a piece of it". It does not decide anything: if decisions are still open, run

`skill-pressure-test` first.

+ Before slicing, map unresolved decision records and their dependencies. Each

+ record names its question, required evidence, owner, resolution, and unblocked

+ implementation. A dependency cycle withholds ready status until it is recut.

+ Invalidated decisions reopen affected work rather than leaving stale completion.

Adapted from `to-tickets` in

[mattpocock/skills](https://github.com/mattpocock/skills) (MIT), retargeted at

this repo's trackers.

## When To Use

- A plan or spec exists and needs cutting into fileable work.

- A tracking epic is too big to claim and needs children.

- Several people or sessions will work in parallel and need boundaries.

## When Not To Use

- Decisions are still open. Slicing unresolved work produces tickets that get

reopened. Use `skill-pressure-test`.

- The work fits one session. File one ticket, or none.

- You want parallel *execution* across agents right now, with worktrees and

waves. That is `/octo:parallel`, which decomposes into work packages it then

runs. This produces tracker state for humans and future sessions.

## Inputs

The plan, spec, or conversation. Optionally a parent epic id to hang the slices

under.

## Workflow

### 1. Slice vertically

Each slice cuts a narrow but complete path through every layer it touches —

schema, API, UI, tests. It is **not a horizontal** slice of one layer.

- A completed slice is demoable or verifiable on its own.

- Each is sized to fit one fresh context window.

- "Add the database columns" is horizontal and untestable alone. "Store and

display the user's timezone, end to end" is vertical.

The first slice through a new area is the tracer bullet: thin, complete, and

proves the path exists before anything is built out along it.

### 2. Declare what blocks what

For every slice, name the slices that must close first. Only real ordering

constraints — not preference, not tidiness. Two slices that merely touch the same

file are not blocked on each other; two where one cannot be verified until the

other exists are.

Cycles mean the slicing is wrong, not that the tracker needs a workaround. Recut.

### 3. File them

This repo has two trackers and they are not interchangeable:

- **`bd` (beads) is the system of record** for work. `bd create --parent=<id>`

makes a child; `bd dep add <issue> <depends-on>` makes a blocking edge;

`bd ready` lists what is takeable — open, unblocked, and not in progress.

- **GitHub issues** are the public surface, via `gh`. Use them when the work is

externally visible or a contributor needs to see it.

Put the detail in the ticket body, not in the parent. The parent indexes; the

ticket holds.

+ Use the tracker's atomic claim operation and read ownership back before editing a

+ slice. If the tracker cannot claim atomically, use one integrator and do not treat

+ an assignee read followed by a write as a lock. Never overwrite another owner's

+ claim.

### 4. When bd will not accept writes

`bd` is periodically **write-blocked** by pending Dolt schema migrations, and the

repository rule is explicit: **do not run the migration** unless you are the

single designated migrator, because migrating a second clone forks the schema

irrecoverably.

When writes are blocked, do not pretend the work was filed and do not silently

drop it. Instead:

1. Emit the **ready-to-run `bd create` and `bd dep add` commands**, complete and

in dependency order, so they can be run unmodified once writes return.

2. Write them into the plan or a roadmap note under `docs/roadmaps/`, which is

the practice this repo already follows.

3. Say plainly, in the output, that nothing was filed and why.

## Provider Or Data Priority

1. The plan or spec as written.

2. The repository, to check whether a slice is already partly built.

3. The user, for sizing and priority. Do not invent priorities.

## Stop Or Checkpoint Rules

- Stop and recut if any slice cannot be verified on its own.

- Stop if the blocking graph has a cycle.

- Stop before filing if more than about ten slices come out of one plan — that

usually means the plan is really several, and filing them all buries the first.

- Confirm the slice list with the user before filing anything. Filing is visible

to others and awkward to undo.

## Output Contract

1. **Slice list** — title, one-line scope, and what it blocks on.

2. **Order** — which slices are takeable now, and which wait.

3. **Filed or not filed** — ids and links if filed; if not, the exact commands

and the reason they were not run.

4. **Left unsliced** — anything in the plan too vague to cut, stated as such

rather than forced into a ticket.

## Verification

- Every slice is demoable or verifiable alone.

- No slice is a single layer's worth of work.

- The blocking graph is acyclic and every edge is a real constraint.

- If bd was unavailable, the emitted commands run unmodified — check the parent

ids and the dependency order.