using-exloomlisted

# Using exloom exloom produces **evidence**, not discipline. The model already plans, tests, and self-reviews without being told. What a team of many developers lacks is evidence that transfers between people: something the next person can read to know what was intended, whether the tests actually exercise the change, and who reviewed it at which commit. exloom produces four artifacts and gates them once, at push. | Artifact | Produced by | Answers | |---|---|---| | Spec | `brainstorming` | what we decided to build, what we rejected, and what "done" means — as numbered criteria | | Plan | `planning-for-handoff` | what to do, in what order, verifiable by someone else | | Proof receipt | `scripts/prove-change-is-tested.sh` | do the tests actually fail without this change | | Review checklist + receipts | `/review-init` → `/review-complete` | who reviewed, at which commit, with what verdict | Nothing here instructs you how to think about code. If a skill would only tell you to be careful, it was removed. ## Quick start — a feature, start to finish This is the sequence. The table below is for looking up a single step; this is what you actually do. | # | Step | What you run | What it produces | |---|---|---|---| | 1 | Decide what to build | `exloom:brainstorming` | a spec — problem, approach, numbered requirements, one criterion each | | 2 | Turn it into a plan | `exloom:planning-for-handoff` | a plan — exact files, tasks, each citing the criteria it serves | | 3 | Get on a