1---
 2name: loop-through-slices
 3description: 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.
 4user-invocable: true
 5---
 6
 7A **feature** is the larger capability the user asked for. A **slice** is one
 8Oracle-scoped portion of that feature, implemented in one jj change and
 9verified independently.
10
11Each slice must deliver independently verifiable and observable behaviour. In
12addition to what AGENTS.md says,
13
14## Feature loop
15
16- Before implementing a feature, ask Oracle to break that feature into the
17  smallest useful slices. Include the feature goal, completed work, relevant
18  files, constraints, explicit non-goals, and the current jj stack.
19
20- Treat Oracle's answer as the slice backlog for that feature. If a suggested
21  slice still feels too broad, ask Oracle to split that slice again before
22  coding.
23
24- Implement exactly one slice at a time. Each slice gets its own jj change, its
25	own verification, and its own Oracle code review before the next slice
26  starts.
27
28- After all slices for a feature are reviewed and complete, ask Oracle for an
29	aggregate review across the feature's changes before calling it done or
30  moving to the next feature.
31
32- Only after the aggregate feature review is resolved should you create a new
33  jj change and ask Oracle to scope the next feature.
34
35## Slice loop
36
37- Check `jj status`. If the working copy already contains completed or unrelated
38  work, run `jj new -m "subsystem: imperative, kernel-style change description"`.
39
40- Before starting the slice, confirm the selected Oracle-scoped slice is still
41  the next smallest useful unit. If anything changed, ask Oracle to rescope
42  before coding.
43
44- Write the failing test first. Avoid ad-hoc smoke tests as a substitute for
45  coverage; if manual testing finds a gap, add or improve automated tests so the
46  gap stays covered. Then implement the smallest correct change using existing
47  project patterns.
48
49- Verify with `mise`, using narrower tasks while iterating and `mise run check`
50  before calling the slice done. After checks pass, ask Oracle for a formal code
51  review of that single slice. Validate review findings before acting on them;
52  fix clear and obvious findings directly, and ask the user about validated
53  findings whose solution is not obvious.
54
55- When the slice is complete, review `jj status`, `jj diff --git`, and the
56  working-copy description. Only move on to the next slice after the tests,
57  check output, review, and jj history for the current slice are coherent.
58
59## Review cadence example
60
61For a feature Oracle splits into four slices, the cadence is:
62
631. Oracle scopes the feature into four slices.
642. Implement slice 1 in one jj change, verify it, and get Oracle's slice review.
653. Fix slice 1 if needed, then `jj new`.
664. Repeat for slices 2, 3, and 4.
675. Ask Oracle for an aggregate feature review covering all four slice changes.
686. Fix the feature if needed, in a new jj change when the fix is distinct.
697. Only then ask Oracle to scope the next feature.