rolling-wave-engineering

Relentlessly pressure-test an existing plan or design artifact until every material branch is resolved, explicitly deferred, or ruled out. Use when the user wants to be grilled on a plan, design doc, PRD, ADR, rollout plan, migration runbook, or similar decision document; when they say "grill me"; or when Codex should interrogate a source-of-truth artifact, inspect code and adjacent docs before asking, auto-answer evidence-backed questions, ask only about conflicts or low-confidence recommendations, edit the original file in place, preserve the artifact's existing format, and keep conclusions, blockers, readiness, and deferred work synchronized in the document.

Shape or update a rolling-wave engineering project before slice preparation. Use when the user wants to start a rolling-wave project, define the finish line, clarify success criteria, create or update docs/rolling-wave/{project}/project.md, sketch a broad roadmap, or interrogate project-level direction without implementation details.

Review changed code for YAGNI, removable over-complexity, reuse, code quality, and efficiency, then apply worthwhile simplifications. Use when the user asks to simplify, clean up, tighten, de-hack recent changes, identify logic that can be dropped, or review whether added safeguards and edge-case handling are actually needed.

Complete a reviewed rolling-wave slice after user review. Use when the user says a slice is done, wants to mark an in-review slice done, capture implementation and review learnings, update docs/rolling-wave/{project}/project.md potential risks and review notes, output a roadmap progress checklist of completed and remaining slices, and prepare later slices to inherit what was learned.

Produce a short executive summary for the current rolling-wave project. Use when the user wants a concise status update, investor/team-friendly summary, leadership summary, project progress snapshot, or TL;DR of completed slices, the current slice plan, and upcoming slices.

Implement a ready rolling-wave slice without locking it down with tests yet. Use when the user explicitly wants to code the current docs/rolling-wave/{project}/slices/NNN-slug.md slice, mark it in progress, execute the prepared parallel work chunks with one implementation subagent per agent-fit chunk where available, pause or hand off chunks marked human-fit when appropriate, record implementation notes, defer test-writing to implement-tests, and preserve the original slice contract for review.

Add or update tests for the current rolling-wave slice after exploratory implementation. Use when the user wants to lock down the newly added slice logic with focused tests before review, using the slice contract, implementation notes, changed files, and deferred test notes while keeping test scope limited to this slice.

Prepare the next rolling-wave slice for implementation. Use when the user wants to continue a rolling-wave project, select the next slice, apply completed-slice learnings, grill slice-level decisions, decompose the slice into parallel implementation chunks where appropriate, identify whether the slice or chunks are better suited for agent, human, either, or hybrid work, write or update docs/rolling-wave/{project}/slices/NNN-slug.md, and mark exactly one slice ready before implementation.

Review a rolling-wave slice implementation against its original slice contract after implementation and focused tests. Use when the user wants to check an in-progress or in-review slice, optionally use zero to three review subagents based on risk and review scope, verify behavior and acceptance criteria, capture review notes and potential risks, and keep the slice in review until it is valid.

Shared support references for the rolling-wave engineering skill set. Use only when a rolling-wave workflow skill explicitly points here, or when maintaining the shape-project, prepare-next-slice, implement-slice, review-slice, and complete-slice skills.

Review local git changes before opening a PR or merging. First review all local tracked and untracked files; if none exist, review the current branch against a requested base branch or the Git Town parent branch. Use zero to three review subagents only when risk, diff size, language specificity, or uncertainty justifies the token cost, then report high-confidence bugs, regressions, risky assumptions, and missing tests. Use when the user asks for code review, local review, branch sanity check, pre-PR review, or review of work-in-progress changes.

Systematically find root causes and fix bugs. Use when debugging errors, investigating test failures, reproducing bugs from issue trackers (GitHub, Linear, Jira), or when stuck on a problem after failed fix attempts. Also use when the user says 'debug this', 'why is this failing', 'fix this bug', 'trace this error', or pastes stack traces, error messages, or issue references.

Draft a pull request description from the current branch diff plus rolling-wave project context. Use when the user wants PR body text, changes, potential risks, or reviewer notes for a branch, especially after completing a rolling-wave slice. Defaults to the Git Town parent branch when no base branch is named.