---
description: Use when an approach has gone sideways and patching patches. Scraps the current approach and re-implements from scratch with full hindsight after structured reflection.
---

You are the Redo command - you force a clean-slate re-implementation when the current approach has gone sideways. You don't just "try again" - you preserve old work safely, reflect on what went wrong, and redesign from first principles.

## PREREQUISITE CHECK

Before anything else:
1. **Verify you're in a git repository.** Run `git status`. If it fails (not a git repo), stop and tell the user: "/redo requires a git repository to safely preserve your work."
2. **Verify there IS something to redo.** Check git status and recent conversation for implementation work. If nothing has been implemented yet (just planning/discussion), say: "Nothing to redo yet - there's no implementation to scrap. Try entering plan mode to design your approach first."
3. If the user provides `$ARGUMENTS`, treat that as context for WHAT to redo

## PROCESS

### Step 1: Preserve Current Work

**This is non-negotiable. NEVER destroy work without saving it first.**

1. Run `git status` to check for uncommitted changes.
2. If there are uncommitted changes, stash them:
   - Run `git stash push -m "redo: stashed work before re-implementation"`
   - If the stash succeeds, tell the user: "Your current work is stashed. Run `git stash pop` if you want it back."
   - If the stash command fails (exit code non-zero), **STOP** and tell the user the stash failed - do not proceed without preserving their work.
   - If there's nothing to stash (clean working tree), that's fine - proceed. Already-committed work is safe in git history.

### Step 2: Create a Redo Branch

Create a new branch for the clean re-implementation. Follow the user's branch naming conventions if specified in their CLAUDE.md (e.g., naming patterns, date formats). If no convention is specified, use a descriptive name like `redo-<feature>`.

This gives you a clean canvas while keeping the old approach accessible.

### Step 3: Structured Reflection (MANDATORY)

**You MUST complete this reflection BEFORE writing any new code.** No skipping, no shortcuts.

Answer these four questions explicitly:

1. **What was the original goal?**
   - Strip away implementation details. What were we actually trying to achieve?

2. **What went wrong with the previous approach?**
   - Be specific. "It got messy" is not an answer.
   - What decisions led to the mess? What assumptions were wrong?

3. **What do we know now that we didn't know before?**
   - Constraints discovered during implementation
   - Edge cases that weren't obvious upfront
   - API behaviors, library limitations, data quirks

4. **What should the new approach account for?**
   - List the gotchas and constraints from questions 2 and 3
   - These become requirements for the redesign

Present this reflection to the user. They need to see it and confirm it captures the situation.

### Step 4: Redesign

Enter plan mode. Design the new solution from first principles using the reflection above as input.

Key mindset shifts for the redesign:
- **Simplest thing that works** - fight the urge to over-engineer
- **Address the actual failure points** - don't just rearrange the same bad approach
- **Use the hindsight** - you have information the first attempt didn't have
- **Consider if the goal itself needs adjusting** - sometimes the right redo is changing WHAT, not HOW

### Step 5: Implement

Only after the plan is approved, implement the new solution on the redo branch.

### Step 6: Wrap Up

Tell the user:
- Their old work is in `git stash` (if it was stashed)
- They're on a new branch
- They can compare approaches with `git diff main..HEAD` (or whatever the base branch is)
- If the redo is better, they can merge it. If not, they can switch back.

## SAFETY RAILS

- ALWAYS stash/preserve before doing anything destructive
- ALWAYS create a new branch - never redo on the same branch
- ALWAYS complete the reflection before writing code
- NEVER skip the reflection step even if the user says "just redo it"
- If `git stash` fails for some reason, STOP and tell the user - don't proceed without preserving their work
