linear-slice

name	linear-slice
description	Decompose a plan into dependency-ordered Linear issues (tracer-bullet vertical slices) and release them into the autonomous dispatch pipeline.
user_invocable	true

/linear-slice

Turn a plan or PRD into a set of thin, vertical, independently-shippable slices, each created as a Linear issue in dependency order, then released into Deus's autonomous dispatch pipeline.

This is the missing front-end to the Linear pipeline: the webhook gates (enrichment-gate → bouncer-gate → dispatcher) describe how an issue flows through the board, but not how a good, independently-grabbable issue gets created. This skill creates them.

Creating issues is a deliberate action with real side effects. Always preview and get explicit approval before creating anything.

How the pipeline works (the contract you must honor)

The board is Backlog → Todo → Ready for Agent → Agent Working → In Review → Done. Gates fire on transitions into a state, never on issue creation:

• Backlog → Todo fires the enrichment gate, a mutating controller that writes the scope block into the issue description itself (wrapped in <!-- gate:enrichment-gate:start --> … <!-- gate:enrichment-gate:end -->).
• Todo → Ready for Agent fires the bouncer gate, which validates that scope block.
• The dispatcher then picks up Ready for Agent issues autonomously.

Consequences for this skill:

• Create issues in Backlog. A freshly created issue fires no gate, so it sits inert until moved.
• Never pre-write the enrichment scope block. It is gate-owned. Write a normal human description; the enrichment gate generates the ## Scope block on the Backlog→Todo transition.
• Never apply a Scoped label. The dispatcher matches Scoped; applying it to a non-enriched issue would make the dispatcher pick up unscoped work. The gate manages that label.
• Releasing = moving Backlog → Todo. That is how you start the pipeline on a slice.

Steps

1. Get the plan

Take the plan from one of, in priority order:

• An explicit argument (a file path, or pasted text).
• The current conversation (a plan just drafted/approved here).
• A parent Linear issue (mcp__linear__linear_getIssueById) whose body is the plan to decompose.

If no plan is identifiable, ask the user for one. Do not invent scope.

2. Decompose into tracer-bullet vertical slices

Break the plan into the smallest set of vertical slices. Each slice must:

• Cut through every layer needed to be independently demoable (a thin end-to-end thread, not a horizontal layer like "all the types" or "the whole API").
• Deliver one tangible increment of value on its own.
• Put prefactoring first — if a slice needs a seam that doesn't exist yet, make the prefactor its own earlier slice.

Use codegraph before estimating blast-radius (a skill body inherits no exploration hook, so this is on you): for each slice that touches existing code, run codegraph_impact / codegraph_callers on the symbols it changes to size the real blast-radius and surface prefactor opportunities. Do not guess from filenames. Fall back to search_code then grep only to confirm.

3. Build the dependency graph

Determine the Blocked by edges between slices (prefactors block the features that need them; a shared scaffold blocks its consumers). Keep it a DAG. The unblocked (root) slices are the ones that can start immediately.

4. Resolve Linear context

(If the plan came from a parent Linear issue in Step 1, you already used mcp__linear__linear_getIssueById to read it.)

• mcp__linear__linear_getTeams → pick the team (single team LIA in this workspace).
• mcp__linear__linear_getProjects → confirm the target project with the user. Every issue must be assigned to a project — never leave an issue floating (orchestration rule).
• mcp__linear__linear_getWorkflowStates (with teamId) → resolve the Backlog and Todo state IDs. The call returns [{id, name, type, position, …}]. Match by exact .name ("Backlog", "Todo") — never by .type: there are two type:"backlog" states ("Icebox" and "Backlog"), so a type match is ambiguous and can land issues in Icebox. Resolve IDs at runtime; never hardcode them.

5. Preview and get approval

Present, and then stop and wait for explicit approval:

• A slice table: # | Title | One-line scope | Blocked by | Effort (trivial/small/medium/large).
• The dependency graph (ASCII or mermaid).
• The target project, and which slices will be auto-released to Todo (the unblocked ones).

Do not create anything until the user approves. If they want changes, revise and re-preview.

6. Create the issues (on approval)

For each slice, mcp__linear__linear_createIssue:

• teamId, projectId (mandatory), title = [Slice N] <concise name>.

• description written with actual newlines, never \n escape sequences (MCP double-escapes them into literal \\n). Use these GENERAL sections (this is not a frontend skill — do not use design-to-dev's Wireframe/Design-Tokens/shadcn sections):

  ## Overview
  What this slice delivers and why it is independently shippable.
  
  ## Acceptance criteria
  - Observable, checkable outcomes that mean this slice is done.
  
  ## Dependencies
  Blocked by: [Slice K] <name> (and the Linear relation below). "None" if a root slice.
  
  ## Definition of Done
  - Builds/tests pass; criteria met; reviewed.
  

• Land in Backlog (set stateId to the resolved Backlog id, or leave unset — Backlog is the default). Do not write the enrichment scope block. Do not add a Scoped label. Omit priority and estimate — let the enrichment gate or the user set them; do not guess.

7. Link the dependencies

For each Blocked by edge, mcp__linear__linear_createIssueRelation (type blocks/blocked_by) between the two created issue IDs, so the board reflects the DAG.

8. Release the unblocked slices

For each root (unblocked) slice, mcp__linear__linear_updateIssue to set stateId → the resolved Todo id. This fires the enrichment gate and starts the autonomous pipeline. Leave blocked slices in Backlog. Do not auto-release subsequent waves: tell the user which slices are now blocked and on what, and let them re-approve (or manually release) each later wave. A blocked slice advancing without fresh approval would push unreviewed work into the pipeline.

9. Cap handling — never silent-partial

If mcp__linear__linear_createIssue fails with exceeded the free issue limit (Linear free-plan cap), STOP immediately. Report exactly which slices were created (with IDs) and which were not, and which relations/releases did or didn't happen. Offer to archive old issues and resume, or to resume later. Never leave a half-created graph unreported.

A gate or API failure is an error, not an approval — never proceed as if a failed step succeeded.

10. Summary

Report: created issue IDs + URLs, the dependency graph, and which slices were released to Todo (now in the pipeline) vs left in Backlog.

Notes

• Preview-first is mandatory; this skill mutates a shared system of record.
• A change to a slice's scope after creation must move that issue back per the orchestration rules (scope change → back to the relevant step so the gate re-evaluates).
• Companion to /design-to-dev (which creates issues from design wireframes); this is the general-plan analog.