thkt/slice

/slice - Break a plan into vertical-slice issues

Break a plan into independently-grabbable issues. Each issue is a tracer bullet, a thin slice cutting end-to-end through every layer (schema / API / UI / test), demoable or verifiable on its own.

Input

Take the plan source from $ARGUMENTS. For an issue reference given as a number, URL, or path, fetch the body and comments via gh issue view <N>. If empty, work from a plan already in conversation context; if none, ask what to break down via AskUserQuestion.

Distinction from related skills

| Skill | Output | Medium / timing | | ------------- | ----------------------------------------- | ------------------------------------ | | /slice (this) | Durable GitHub issues in dependency order | A queue for a human to pick up later | | /issue | One issue | File a single request |

/slice's value is decomposition and dependency-ordered publish. For one issue use /issue. A sliced issue carries no ## Plan yet; handing it straight to /build makes build auto-generate an ephemeral plan and proceed, recording a not-human-reviewed assumption. For slices where plan quality matters, generate a plan via /think and append it to the issue as a ## Plan section before handing it to /build; use /code when you already hold a structured plan.

Phase 1: Gather context

Work from the plan in conversation context. If $ARGUMENTS carries an issue reference, read its body and comments.

Phase 2: Explore the codebase (optional)

If not yet explored, understand the current state. Issue titles / descriptions follow the project glossary and respect ADRs in the area you touch. Look for prefactor opportunities that make the change easier. Spawn one Explore agent only when a cross-cutting sweep is needed; no per-slice spawns.

Phase 3: Draft vertical slices

Split the plan into tracer-bullet issues. Vertical slices (through all layers), not horizontal (one layer only).

| Rule | Content | | --------------- | -------------------------------------------------------------- | | All layers | Each slice cuts through every layer (schema / API / UI / test) | | Self-verifiable | A completed slice is demoable or verifiable on its own | | Prefactor first | If prefactoring is needed, put it in the first slice |

Coverage check

After drafting, enumerate the plan's requirement units, meaning user stories / acceptance criteria / FR-equivalents, and extract the units assigned to no slice. Weigh misses over false alarms; include doubtful units among the uncovered. Surface the uncovered units in the Phase 4 preview.

Phase 4: Quiz the user

Present the proposed breakdown as a numbered list. For each slice show the following.

| Field | Content | | ------------ | ----------------------------------------------- | | Title | Short descriptive name | | Blocked by | Which other slices must complete first (if any) | | User stories | Which user stories this slice covers (if any) |

Ask: is the granularity neither too coarse nor too fine, are the dependencies correct, should any slices be merged or split, and how to handle the uncovered units. The handling options are assigning to an existing slice, a new slice, or deliberate exclusion with a reason. Iterate until the user approves.

Phase 5: Publish the issues

After approval, confirm once more via AskUserQuestion before batch publish: "Create these N issues?". Creating N issues is outward-facing and hard to unwind, so never auto-publish without confirmation.

On approval, publish in dependency order with blockers first. Create blockers first and capture their numbers so "Blocked by" can reference real issue numbers. Use the template below and Sandbox-Compatible Create per issue. Do not attach a triage label; AFK consumer wiring is out of scope. Do not close or modify any parent issue.

Issue Template

## Parent

A reference to the parent issue (only if the source was an existing issue; otherwise omit this section).

## What to build

A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation. Avoid specific file paths or code snippets, which go stale fast. Exception: a state machine / reducer / schema / type snippet a prototype produced that encodes a decision more precisely than prose. Note it came from a prototype and trim to the decision-rich parts.

## Acceptance criteria

- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3

## Blocked by

- A reference to the blocking ticket (if any)

Or "None - can start immediately" if no blockers.

Language

Read language from ${CLAUDE_SKILL_DIR}/../../settings.json and translate the issue body into that language. Default to English if unset. Keep technical terms / code / identifiers untranslated.

Sandbox-Compatible Create

cat > /tmp/claude/slice-body.md << 'EOF'
<body>
EOF
gh issue create --title "<title>" --body-file /tmp/claude/slice-body.md
mv /tmp/claude/slice-body.md ~/.Trash/ 2>/dev/null || true

Repeat this in dependency order for multiple slices, capturing each issue number from the publish output to fill into later "Blocked by" fields.

Error Handling

| Error | Action | | ---------------------- | ------------------------------------------------ | | No plan source | Ask what to break down via AskUserQuestion | | Issue ref unresolvable | Report the ref and stop | | No git repository | Report "Not a git repo" | | gh auth failure | Report the auth error | | Publish fails midway | Report created numbers and ask whether to resume |

Display Format

Preview (Phase 4)

## Slice breakdown (N)

1. <Title>
   - Blocked by: <slices or none>
   - User stories: <ids or none>

Uncovered: <requirement units on no slice or none>

Success

List published issues in dependency order.

Created (dependency order):

- #<number> <title> (blocked by: #<n> | none)