---
name: measure-twice
description: Forces an incremental, chunked workflow for complex tasks to allow for human auditing and verification at every step.
---
# Measure-Twice Workflow Instructions
Whenever this skill is active or invoked via `/measure-twice`, you MUST follow this strict incremental protocol:
### 1. The Planning Phase
- **Do not edit any files yet.**
- Before breaking down the work, **interview the user relentlessly** about every aspect of the plan:
- Walk down each branch of the design tree, resolving dependencies between decisions one at a time.
- For each open question, **provide your recommended answer** rather than leaving the choice open-ended.
- If a question can be answered by exploring the codebase, **explore the codebase instead of asking**.
- Keep drilling until you and the user have reached a shared understanding with no unresolved branches.
- Once all design questions are settled, analyze the request and break it down into the smallest possible logical "chunks" (e.g., "Step 1: Update Type definitions", "Step 2: Refactor API route", etc.).
- Present this list to the user and **wait for approval** or modification.
### 2. The Execution Phase (One Chunk at a Time)
- Perform **ONLY ONE** chunk from the approved list.
- After finishing the chunk, run `git diff` (or the internal diff tool) to show the user exactly what changed.
- Run relevant tests or linting for that specific chunk.
### 3. The Verification Gate
- After displaying the `/diff`, you MUST present exactly three numbered options for the user.
- **DO NOT** offer an "automatic yes" or "always accept" option; this skill requires manual audit for every chunk.
- **The required options are:**
1. **Yes, proceed to next chunk.**
2. **No, undo this chunk and stop.**
3. **I have questions about this chunk.** (Use this to discuss logic or suggest a tweak before proceeding).
- If the user selects **Option 3**, enter "Discussion Mode." Do not move to the next chunk until the user's questions are resolved and they eventually select Option 1.
### 4. Completion
- Once all chunks are finished, run a full project build/test to ensure no regressions.
- **Review gate (before committing):** run `/code-review` on the accumulated working-tree diff as a final sanity check. This is review-only — present the findings to the user; **do not** auto-fix or commit based on them.
- If `/code-review` surfaces issues, treat each like an Option 3 discussion: resolve with the user before finishing.
- If the user wants a deeper, senior-engineer audit, note that `paranoid-review` is the right tool — but it runs against an **open PR**, so it belongs *after* the PR is opened, not here.
- Provide a final summary of all changes.
> **Note:** If a chunk fails or the user identifies an issue, fix it immediately within that chunk before moving forward.
