@@ -0,0 +1,69 @@
+---
+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.
@@ -1,37 +0,0 @@
----
-name: loop-through-slices
-description: Guides the vertical-slice development loop for cooked-mcp. Use when explicitly told to loop through one or multiple slices.
-user-invocable: true
----
-
-Each unit of work must deliver independently verifiable and observable
-behaviour. In addition to what AGENTS.md says,
-
-- Check `jj status`. If the working copy already contains completed or
- unrelated work, run `jj new -m "area: imperative, kernel-style change
- description"`.
-
-- For design or behaviour questions, consult the oracle before implementation
- and adjust the spec or plan based on the answer. Include the slice goal,
- already-completed behaviour, relevant specs/files, explicit in-scope and
- out-of-scope ACIDs, and ask for spec adjustments, target ACIDs, tests to add,
- and implementation pitfalls.
-
-- 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, get a formal code review
- for meaningful behaviour changes. 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. Push relevant acai specs/refs and update completed
- ACID statuses without comments: `acai set-status @payload.json --product
- lipu-kute --impl main --json`. The payload is a JSON object keyed by full
- ACID, e.g. `{"notes.ENCRYPT.1": {"status": "completed"}}`. Only move on to
- the next slice after the tests, check, review, and acai state for the current
- slice are coherent.