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.