---
name: paradigm-shift
description: Close one development Phase and open the next when the project's direction shifts — or, the first time, to graduate out of Phase 0. Squashes the chapter into one commit, archives the history, ratifies the organization the phase produced, and sets the next Phase's goal. Triggers on "paradigm shift", "close this phase", or graduating from Phase 0.
---

Close the current Phase and open the next. This is a deliberate boundary, not a routine increment — and it is **user-invoked only**: never start it autonomously; `go-next` suggests it, the user runs it. Challenge whether it's earned before running it.

1. **Earn it.** Confirm the direction has genuinely shifted, or — the first time — that Phase 0's gate is met: `docs/mission.md` is formalized with evidence. If the case is thin, say so and stop.
2. **Record what closed.** Summarize what the Phase produced and update `docs/` so it reads as the present truth.
3. **Set the next goal.** Decide what the next Phase pursues and write it down (e.g. in `docs/roadmap.md`).
4. **Reorganize.** Adopt any structure the project has now earned (e.g. milestones, a Project).
5. **Run the git ceremony** — on the user's explicit go, and in this order. **Archive before you squash**: capture the Phase's commit-message journey — how the work unfolded, not the diffs git already keeps — into `archive/` and commit it. *Then* commit the reorg and squash the Phase's commits into one on `main`. The squash is a one-way door; the archive is what survives it. Then open the next Phase.

If the shift changes *how* you work, not just *what* you're working on, that is a constitutional amendment — open a pull request against [`CLAUDE.md`](../../../CLAUDE.md) as part of the reorg.