From devflow
Executes an approved implementation plan, following TDD workflow by default. Implements code changes unit by unit with mandatory pause points for developer review. Use this after plan-issue once the plan has been approved.
npx claudepluginhub joshuarweaver/cascade-code-general-misc-4 --plugin codingthefuturewithai-claude-code-primitivesThis skill is limited to using the following tools:
I'll execute the approved implementation plan for $ARGUMENTS.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
I'll execute the approved implementation plan for $ARGUMENTS.
Prerequisites:
.devflow/plans/$ARGUMENTS.md/devflow:build:plan-issue $ARGUMENTS if plan doesn't existUse the build-ops skill to load backend configuration from devflow-config.md.
See skills/build-ops/SKILL.md.
Read the approved plan at .devflow/plans/$ARGUMENTS.md. If it doesn't exist, stop and tell the user to run /devflow:build:plan-issue $ARGUMENTS first.
Extract from the plan: issue summary, implementation steps, files to modify, testing strategy, commit strategy, and the number of logical units.
Parse flags from $ARGUMENTS:
--auto → run all units continuously without pausingTDD mode: If the plan includes a TDD workflow, follow it. If the plan doesn't specify, TDD is the default for code changes.
Create a branch from the current base branch. If not a git repository, initialize one first.
Branch naming: Follow the project's CLAUDE.md or .claude/rules/ if they specify a branch naming convention. If no convention is specified, default to:
feature/[ISSUE-KEY]-[slug]bugfix/[ISSUE-KEY]-[slug]task/[ISSUE-KEY]-[slug]Use the build-ops skill to transition issue $ARGUMENTS to "In Progress".
See skills/build-ops/SKILL.md.
These apply throughout implementation. No exceptions without explicit developer approval.
TDD by default. For each unit: write failing tests first, then implement to make them pass, then refactor if needed. Detect and follow the repo's existing test framework and patterns exactly. Do not introduce a different test framework or testing strategy without explicit developer approval. If the approved plan specifies a non-TDD approach, follow the plan.
Follow existing patterns. Discover and follow the repo's conventions for imports, error handling, logging, module structure, and code organization. Do not deviate without asking.
Pause after every commit (unless --auto). After each committed unit, present a summary of what changed and offer these options:
Wait for the developer's response before proceeding.
Lint and format modified files using the project's configured formatter/linter. Only files you modified. Never touch untouched files. If no formatter is configured, don't impose one.
Update documentation affected by your changes — code comments, READMEs, API docs, whatever is relevant.
Dependency management. Before adding a new dependency, check if something already in the project covers the need. Verify compatibility with existing dependencies. Prefer well-maintained packages with compatible licenses.
Follow the plan. The plan already includes all research and technical decisions. If you encounter something not covered in the plan, use the "Auto Re-plan" section below — don't make new technical decisions on your own.
Code health awareness. As you work, assess structural quality of code you're touching. Small improvements directly related to your changes — include them. Larger structural opportunities — note them in the plan file under ## Refactoring Opportunities for the PR phase. Do not expand scope for larger refactoring.
Bug fix discipline. If this is a bug fix, read references/bug-fix-implementation.md for guidance. Reproduce the bug before writing the fix. Fix the root cause, not the symptom. Check for the same pattern elsewhere. Regression test is mandatory.
For each logical unit in the approved plan's commit strategy:
If you discover that the plan requires significant revision — an assumption was wrong, a dependency doesn't work as expected, tests reveal a fundamental issue — stop and tell the user:
"The current plan needs revision. Please run
/devflow:build:plan-issue $ARGUMENTSto update the plan."
Do not continue implementing a plan that no longer fits.
After all units are complete (or the developer stops early):
/devflow:build:complete-issue $ARGUMENTS
This will review code health and security, create a PR/MR, and update the issue status.
DO NOT CONTINUE — the developer must run complete-issue to finalize.