Skill

devflow:build:implement-issue

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.

Install

npx claudepluginhub joshuarweaver/cascade-code-general-misc-4 --plugin codingthefuturewithai-claude-code-primitives

Tool Access

This skill is limited to using the following tools:

ReadWriteEditBashGrepGlobTodoWritemcp__atlassian__getAccessibleAtlassianResourcesmcp__atlassian__getJiraIssuemcp__atlassian__getTransitionsForJiraIssuemcp__atlassian__transitionJiraIssuemcp__gitlab__get_issuemcp__gitlab__update_issue

Preview

I'll execute the approved implementation plan for $ARGUMENTS.

Supporting Assets

references/bug-fix-implementation.md

SKILL.md

Similar Skills

using-git-worktrees

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.

superpowers

168.3k

subagent-driven-development

3 files

Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.

superpowers

168.3k

dispatching-parallel-agents

Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.

superpowers

168.3k

Stats

Parent Repo Stars0

Parent Repo Forks0

Last CommitFeb 17, 2026

Actions

View Source View Plugin View on GitHub View README

Implement Work

I'll execute the approved implementation plan for $ARGUMENTS.

Prerequisites:

Approved plan at .devflow/plans/$ARGUMENTS.md
Run /devflow:build:plan-issue $ARGUMENTS if plan doesn't exist

Step 0: Load Plan & Configuration

Use 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 pausing
No flag → pause after each commit for developer review

TDD mode: If the plan includes a TDD workflow, follow it. If the plan doesn't specify, TDD is the default for code changes.

Step 1: Create Git Branch

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 → feature/[ISSUE-KEY]-[slug]
Bug → bugfix/[ISSUE-KEY]-[slug]
Other → task/[ISSUE-KEY]-[slug]

Step 2: Update Issue Status

Use the build-ops skill to transition issue $ARGUMENTS to "In Progress". See skills/build-ops/SKILL.md.

Non-Negotiable Constraints

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:

Continue → proceed to next unit
Review [file] → show a specific file
Revise [instructions] → make changes to this unit
Stop → halt implementation (all committed work is preserved)

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.

Implementation Loop

For each logical unit in the approved plan's commit strategy:

Implement the unit following the plan's approach and the constraints above.
Validate — run tests, verify behavior matches expectations.
Update documentation as needed.
Commit with a message referencing $ARGUMENTS, following the plan's commit strategy.
Present a unit summary — what was implemented, files changed, test results, progress (Unit X of Y).
Pause for review (unless --auto) — present options and wait for the developer's response.

Auto Re-plan

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 $ARGUMENTS to update the plan."

Do not continue implementing a plan that no longer fits.

Implementation Summary

After all units are complete (or the developer stops early):

Progress: [X] of [Y] units completed
Files modified (compared with plan's expectations)
Test results
Deviations from the approved plan (if any)
Refactoring opportunities noted (if any)

Next Step

/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.