From 7bcddd4d2adde44157aaeef3212bd59281390c79 Mon Sep 17 00:00:00 2001 From: Amolith Date: Sat, 11 Jul 2026 10:19:24 -0600 Subject: [PATCH] skills: rename looping --- .agents/skills/feature-loop/SKILL.md | 69 +++++++++++++++++++ .../SKILL.md.license | 0 .agents/skills/loop-through-slices/SKILL.md | 37 ---------- 3 files changed, 69 insertions(+), 37 deletions(-) create mode 100644 .agents/skills/feature-loop/SKILL.md rename .agents/skills/{loop-through-slices => feature-loop}/SKILL.md.license (100%) delete mode 100644 .agents/skills/loop-through-slices/SKILL.md diff --git a/.agents/skills/feature-loop/SKILL.md b/.agents/skills/feature-loop/SKILL.md new file mode 100644 index 0000000000000000000000000000000000000000..5f565b7a954c9a233d0f53b55ff1d87baac2508d --- /dev/null +++ b/.agents/skills/feature-loop/SKILL.md @@ -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. diff --git a/.agents/skills/loop-through-slices/SKILL.md.license b/.agents/skills/feature-loop/SKILL.md.license similarity index 100% rename from .agents/skills/loop-through-slices/SKILL.md.license rename to .agents/skills/feature-loop/SKILL.md.license diff --git a/.agents/skills/loop-through-slices/SKILL.md b/.agents/skills/loop-through-slices/SKILL.md deleted file mode 100644 index d3a3f5306fed544c94f123a7e76cd384c58e4213..0000000000000000000000000000000000000000 --- a/.agents/skills/loop-through-slices/SKILL.md +++ /dev/null @@ -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.