Executes tech plans via dependency-aware task batching, TDD, incremental commits, section code reviews, and PR creation. Use after planning phases.
npx claudepluginhub tmchow/tmc-marketplace --plugin iterative-engineeringThis skill uses the workspace's default tool permissions.
Read the plan critically, create tasks, and implement with TDD, code review, and continuous testing. The plan is your guide — it contains the decisions, patterns, and test scenarios that drive implementation.
Verifies tests pass on completed feature branch, presents options to merge locally, create GitHub PR, keep as-is or discard; executes choice and cleans up worktree.
Guides root cause investigation for bugs, test failures, unexpected behavior, performance issues, and build failures before proposing fixes.
Writes implementation plans from specs for multi-step tasks, mapping files and breaking into TDD bite-sized steps before coding.
Read the plan critically, create tasks, and implement with TDD, code review, and continuous testing. The plan is your guide — it contains the decisions, patterns, and test scenarios that drive implementation.
iterative:tech-planning skill completes a plandocs/plans/ for recent plan files. If no plan found, ask user for path. If no plan exists, ask the user: A) Create a tech plan first (recommended), B) I'll provide the plan path. If tech plan: invoke iterative:tech-planning skill.AskUserQuestion (Claude Code) or request_user_input (Codex): A) Execute all tasks, report when done (default), B) Pause after each plan section for feedback, C) Pause after each subtask for feedback.git rev-parse HEAD. This SHA is the section's baseline — used to scope reviews to only this section's changes.**Depends on:** and **Files:** fields, group the section's subtasks into execution batches — subtasks with no unmet dependencies form the next batch.**Files:** field exist, and does it contain tests matching the plan's **Test scenarios:**? If a feature subtask committed without tests, flag it immediately — do not continue to the next batch until resolved.git diff <section-baseline-sha>..HEAD. Pass the baseline SHA and plan context to the code-review skill. Wait for the review to complete and fixes to land before moving on. Do not run anything else in parallel with code review — it needs to see the final code. Placeholder exclusion: When the review returns findings targeting code that is an acknowledged placeholder for a later plan section, exclude those findings from severity acceptance — they will be addressed in a later section and caught by the final review. Note excluded count and reasons in the review summary (e.g., "Excluded 1 finding — placeholder for section 3").Phase 3 steps are strictly sequential. Do not parallelize them — each step depends on the output of the previous one.
git rev-parse --verify origin/main >/dev/null 2>&1 && echo main || echo master. Use this for all branch-level scoping in Phase 3./simplify is available, invoke it to review and clean up changed code. Otherwise, do a manual review of changed files (git diff --name-only $(git merge-base HEAD <base>)..HEAD) and apply behavior-preserving simplifications: flatten nesting, remove dead code, simplify expressions, collapse single-use variables. This is a single bounded pass — not a refactor. Wait for simplification to complete before proceeding — the final review must see simplified code.code-review skill with scope git diff $(git merge-base HEAD <base>)..HEAD (all branch changes including simplification).Ensure the agent has an isolated workspace before creating tasks or writing code.
First: sync with remote Pull the latest from the default branch before creating any branch or worktree.
Then: check current state
| Situation | Action |
|---|---|
| Already in a worktree | Confirm it's for this feature, then proceed |
| On default branch | Ask the user: A) Create worktree (recommended), B) Create branch, C) Continue on main (requires explicit consent) |
| On a feature branch | Ask the user: A) Continue on this branch, B) Create new worktree |
Invoke the git-worktree skill if a worktree is needed.
Task creation happens inside Phase 1, after the plan is read and clarified. This ensures the implementer understands the plan before tasks are locked in.
Use built-in task tracking for all plans. Tasks are lightweight and session-scoped.
Platform mapping: Claude Code provides task objects (TaskCreate, TaskUpdate, TaskList, TaskGet) — use these directly. Codex composes equivalent tracking from update_plan (plan steps as task state) + spawn_agent/wait/close_agent (delegation). The workflow is the same: create tasks from the plan, track status, and mark complete — only the tool names differ.
The plan's standardized subtask format (numbered, with dependencies and files) maps directly to tasks:
Depends on fields → task dependenciesFiles fields → description references in tasksShow the proposed task structure to the user for approval before creating.
**Files:** fields| Trigger | Review Level |
|---|---|
| Section review (after all subtasks in a plan section complete) | Full review via code-review skill. Skip if single-section plan — Phase 3 final review covers it |
| Trivial section (config, single-line, renaming only) | Skip review — note in progress report |
This is its own prompt — do not combine it with next-step options. Present severity acceptance whenever the review has findings at ANY severity, including Medium/Low-only reviews. Do not interpret "no Critical/High" as "clean" — clean means zero findings. Use the platform's interactive question tool — AskUserQuestion (Claude Code) or request_user_input (Codex) — for all severity acceptance prompts. Do not print options as text. Both platforms provide an automatic "Other" free-form option — do not add one manually.
Present a single prompt listing all severity levels with findings. No intermediate "choose which..." step.
Claude Code — use AskUserQuestion with multiSelect: true:
When Critical or High issues exist, pre-check the Critical+High option:
When only Medium/Low issues exist, nothing pre-checked:
Only include severity levels that have findings.
Codex — use request_user_input (single-select, build combined options):
When Critical or High issues exist:
When only Medium/Low issues exist:
Only include options where findings exist at those levels. Omit options that would duplicate another (e.g., if no Low, omit "Fix all" since it equals the line above).
Fix only the selected severities. Spawn a single subagent to apply all selected fixes — do not fix in the main thread (preserves context for subsequent review rounds and wrapup).
The subagent receives:
One subagent (not one per finding) because findings can interact — a security fix and a correctness fix in the same function need to see each other. This mirrors the simplification pattern: one bounded pass, specific scope, commits separately.
Wait for the subagent to complete before proceeding. Next-step options come AFTER fixes land, as a separate prompt (Phase 3 step 7).
By the time implementing hands off to implementation-wrapup, all code reviews are complete. Wrapup skips its own review offer and handles verification, PR, and cleanup.
If reality diverges from the plan during implementation:
Stop and ask for clarification (plain text, not structured options) when:
If a subtask fails:
| Anti-Pattern | Better Approach |
|---|---|
| Jumping to code without reading plan context | Read each subtask's referenced files and patterns first |
| Skipping clarification to start faster | Ask questions now — building the wrong thing is slower |
| Creating tasks before understanding the plan | Read and clarify the plan, then create tasks |
| Committing with failing tests | Only commit when tests pass |
| Committing feature subtask without writing tests | TDD: write tests first from plan's test scenarios, then implement |
| Skipping Phase 1 because of prior conversation context | Prior context ≠ setup complete. If no tasks exist, run Phase 1 — task creation, workspace isolation |
| Pushing through when blocked | Stop and ask for help |
| Running code review in parallel with simplification or other code changes | Code review must see final code. Simplify → wait → review. Never parallelize steps that change code with steps that review it |
| Full code review on trivial changes | Scale review to complexity — skip for config changes |
| Modifying the plan silently | Report divergence and get user agreement |
| Applying TDD rigidly to config/refactoring subtasks | TDD for feature work, verify for non-feature work |
Always present options to the user at transition points using the platform's interactive question tool — AskUserQuestion (Claude Code) or request_user_input (Codex). Never print options as text or end the turn without presenting a choice.
After simplification pass completes (Phase 3 step 4), present options:
After review (or skip), present options:
For templates and detailed guidelines, consult:
references/progress-template.md — Execution progress report format