skill-work-slicing

Slice the spec vertically so each ticket is a complete path through every layer it touches, then declare which slices block others. File them as children under a parent epic so contributors can claim unblocked work independently.

A vertical slice is a narrow but complete path through all layers of a feature, such as schema, API, UI, and tests, that is demoable on its own. It contrasts with horizontal slices like 'add the database columns', which cannot be verified alone.

Do not slice when decisions are still open, since unresolved work produces tickets that get reopened; pressure-test the plan first. Also skip slicing when the work fits a single session or when you need immediate parallel execution rather than tracker state.

When bd is write-blocked by pending Dolt schema migrations, the Skill emits complete, ready-to-run bd create and bd dep add commands in dependency order and records them in a roadmap note. It states plainly that nothing was filed rather than pretending otherwise.

Slicing is wrong if any slice cannot be verified on its own, if the blocking graph contains a cycle, or if one plan produces more than about ten slices. In those cases stop and recut rather than filing tickets that bury the real work.