---
name: loop-through-slices
description: Guides Blush feature work by having Oracle break features into reviewed jj-backed slices, with per-slice and aggregate feature reviews. Use when explicitly told to loop through one or more features.
user-invocable: true
---

A **feature** is the larger capability the user asked for. A **slice** is one
Oracle-scoped portion of that feature, implemented in one jj change and
verified independently.

Each slice must deliver independently verifiable and observable behaviour. In
addition to what AGENTS.md says,

## Feature loop

- Before implementing a feature, ask Oracle to break that feature into the
  smallest useful slices. Include the feature goal, completed work, relevant
  files, constraints, explicit non-goals, and the current jj stack.

- Treat Oracle's answer as the slice backlog for that feature. If a suggested
  slice still feels too broad, ask Oracle to split that slice again before
  coding.

- Implement exactly one slice at a time. Each slice gets its own jj change, its
	own verification, and its own Oracle code review before the next slice
  starts.

- After all slices for a feature are reviewed and complete, ask Oracle for an
	aggregate review across the feature's changes before calling it done or
  moving to the next feature.

- Only after the aggregate feature review is resolved should you create a new
  jj change and ask Oracle to scope the next feature.

## Slice loop

- Check `jj status`. If the working copy already contains completed or unrelated
  work, run `jj new -m "subsystem: imperative, kernel-style change description"`.

- Before starting the slice, confirm the selected Oracle-scoped slice is still
  the next smallest useful unit. If anything changed, ask Oracle to rescope
  before coding.

- Write the failing test first. Avoid ad-hoc smoke tests as a substitute for
  coverage; if manual testing finds a gap, add or improve automated tests so the
  gap stays covered. Then implement the smallest correct change using existing
  project patterns.

- Verify with `mise`, using narrower tasks while iterating and `mise run check`
  before calling the slice done. After checks pass, ask Oracle for a formal code
  review of that single slice. Validate review findings before acting on them;
  fix clear and obvious findings directly, and ask the user about validated
  findings whose solution is not obvious.

- When the slice is complete, review `jj status`, `jj diff --git`, and the
  working-copy description. Only move on to the next slice after the tests,
  check output, review, and jj history for the current slice are coherent.

## Review cadence example

For a feature Oracle splits into four slices, the cadence is:

1. Oracle scopes the feature into four slices.
2. Implement slice 1 in one jj change, verify it, and get Oracle's slice review.
3. Fix slice 1 if needed, then `jj new`.
4. Repeat for slices 2, 3, and 4.
5. Ask Oracle for an aggregate feature review covering all four slice changes.
6. Fix the feature if needed, in a new jj change when the fix is distinct.
7. Only then ask Oracle to scope the next feature.