For anyone handing a plan to agents or a team
Slice DeskBreak a plan into tracer-bullet tickets: narrow paths through every layer, each with what blocks it. The page checks the graph free.
Paste a plan or spec. Your browser numbers its requirements (R1, R2 ...), sets aside what is out of scope or still open, and spots a wide refactor or a spec written by layer. Paste or edit tickets in the local ticket template and it checks them as a dependency graph: cycles named, unknown blockers, the frontier, parallel waves, the critical path, redundant edges, one-layer tickets, missing criteria and requirement coverage. Then the slice writes the tickets, and the revise run reworks them on your feedback.
The plan or spec free
The page's reading free
Requirements, numbered by the page
What else the spec says
The tickets and their graph free
Paste or edit tickets in the local ticket template - one "# 01: Title" heading each, then What to build, Blocked by, Status, an optional Covers line with the requirement ids, and the acceptance criteria as checkboxes. The slice result's handoff fills this box. Every keystroke re-checks the graph here, free.
What the graph check found
The graph
The tickets as the page reads them
The graph as a Mermaid flowchart
The tickets metered
Pricing as soon as the session is ready...
Sign inThe reply could not be read. Here it is as it came back:
Caveats
Caveats
The page's check of this reply
Saved breakdowns
How it works - and what it cannot see
The page reads the spec as written: each bullet, numbered item and table row is a requirement, and so is every sentence with must, shall, should or needs to - except under headings such as Background or Notes, which are context, and Out of scope or Open questions, which are set aside. Tickets are read from the local ticket template, a heading per ticket; "Blocked by" becomes the graph's edges, by number or by title. A slice is called horizontal only when its title and What to build name a single layer - the database, the API, the UI or the tests - and nobody in it can do anything: a conservative check, so a miss is likelier than a false alarm.
It cannot see your codebase - the prefactors it would suggest, the real blast radius of a refactor, the glossary your team uses - or whether a criterion is testable. That is what the slice and the revise run write from the spec, and what the skill's three questions ask you. Every reply goes back through the same graph check, so a cycle, an unknown blocker, a one-layer ticket or an uncovered requirement is flagged rather than trusted.