Skill

devflow:build:complete-issue

Reviews code health and security, creates a PR/MR, and transitions the issue to done. This is the final step in the DevFlow build workflow. Use this after implementing changes to create a pull request or merge request and close the issue.

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:

BashReadWriteEditGrepGlobTaskAskUserQuestionmcp__atlassian__getJiraIssuemcp__atlassian__getAccessibleAtlassianResourcesmcp__atlassian__transitionJiraIssuemcp__atlassian__getTransitionsForJiraIssuemcp__atlassian__editJiraIssuemcp__atlassian__updateConfluencePagemcp__atlassian__getConfluencePagemcp__gitlab__get_issuemcp__gitlab__update_issuemcp__gitlab__create_merge_requestmcp__rag-memory-primary__search_documentsmcp__rag-memory-primary__update_documentmcp__google-drive__download_filemcp__google-drive__update_file

Preview

I'll review the code, create a PR/MR, and update the issue to Done.

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 19, 2026

Actions

View Source View Plugin View on GitHub View README

Complete Work

I'll review the code, create a PR/MR, and update the issue to Done.

Issue: $ARGUMENTS

Progress:
- [ ] Step 0: Load backend configuration
- [ ] Step 1: Fetch issue details
- [ ] Step 2: Analyze changes
- [ ] Steps 2a+2b: Code health + security review (parallel)
- [ ] Step 2c: Deviation review (if project manifest exists)
- [ ] Step 2d: Capture decisions (if significant deviations)
- [ ] Step 2.5: Push branch
- [ ] Step 3: Create PR/MR
- [ ] Step 4: Update issue status

Step 0: Load Backend Configuration

Use the build-ops skill to load backend configuration from devflow-config.md.

The build-ops skill handles config loading and parameter validation for both issue tracking and VCS backends. See skills/build-ops/SKILL.md.

Step 1: Fetch Issue Details

Use the build-ops skill to fetch issue $ARGUMENTS from the configured issue tracker.

The build-ops skill handles all backend-specific fetch operations and enforces parameter validation. See skills/build-ops/SKILL.md.

Issue: [key/number] - [summary/title]

Step 2: Analyze Changes for PR/MR

git diff --name-only [base-branch]...HEAD
git log --oneline [base-branch]...HEAD

[Read key changed files to understand implementation]

Changes Summary:

[What was implemented/fixed]
[Key files modified]
[How it addresses issue requirements]

Steps 2a + 2b: Code Reviews (Run in Parallel)

Run Steps 2a and 2b concurrently. Both are independent — same inputs (base branch and changed files), no dependencies between them. Use two Task tool calls simultaneously.

Step 2a: Code Health Review

Use the code-health-reviewer agent (via Task tool) to review changed files for structural quality concerns — files that are too long, poor modularity, duplication, complexity.

Pass it the base branch name and the list of changed files from Step 2.

Also check .devflow/plans/$ARGUMENTS.md for any ## Refactoring Opportunities notes left during implementation and include those for context.

Present findings to the developer. For each issue the agent identified:

If it's something that can be fixed now (localized refactoring) — recommend fixing it before the PR. The best time to improve code you just touched is right now.
If it's a larger cross-module effort — recommend deferring to a follow-up.

The developer decides what to fix now, what to defer, and what to skip entirely.

If fixes are approved: Make the changes, run validation again to confirm nothing broke, and commit them.

If no issues found or developer skips all: Proceed.

Any deferred items will be included in the PR description as suggested follow-ups.

Step 2b: Security Review (Mandatory)

Use the security-reviewer agent (via Task tool) to scan changed files for security vulnerabilities.

Pass it the base branch name and the list of changed files from Step 2.

Present findings to the developer. For each issue the agent identified:

If it can be fixed in place — recommend fixing it now. Don't ship known vulnerabilities.
If it requires broader changes beyond this issue's scope — recommend deferring, but make sure the developer understands the risk.

The developer decides what to fix now, what to defer, and what to accept.

If fixes are approved: Make the changes, run validation again, and commit them.

If critical/high severity issues remain unaddressed: Warn clearly before proceeding to PR creation, but respect the developer's decision.

Any deferred security items will be noted in the PR description.

Step 2c: Deviation Review (If Project Manifest Exists)

Check for project manifest: Read .devflow/project.md.

If no project manifest exists → skip to Step 3. Not all projects use upstream PM skills.
If project manifest exists → proceed with deviation review.

Compare plan vs implementation using the deviation-reviewer agent:

Use the deviation-reviewer agent (via Task tool) to compare the implementation plan against actual changes. Pass it:

Plan file path: .devflow/plans/[ISSUE-KEY].md
Issue key: The issue being completed
Base branch: For computing the diff

The agent reads the plan, analyzes the git diff, and returns a structured deviation report classifying each deviation by type (Technology, Architecture, Scope, Approach) with potential artifact routing.

If no plan file exists: The agent still reviews the changes for significant architectural or requirement deviations worth capturing.

Present the agent's deviation report to the developer:

"I noticed these differences between what was planned and what was built:"

[Deviation description] — Is this significant?

[Deviation description] — Is this significant?

Developer responds for each: Significant / Not significant / Dismiss all

If "Dismiss all" or no significant deviations → skip to Step 3.

Step 2d: Capture Decisions (If Significant Deviations Found)

For each deviation the developer marked as significant, propose where to route the update:

Deviation Type	Proposed Routing
Feature works differently than issue described	Update tracker issue
Architecture decision changed	New ADR (stored alongside architecture doc)
Pattern or component changed significantly	Architecture doc update
Requirement changed or scope shifted	PRD update (only during active initiative)

For each item:

"[Description]. I recommend updating [artifact]. Confirm? (Yes / Skip)"

Route confirmed updates to the correct artifact using the project manifest to find locations. Use the appropriate backend tools.

If no project manifest artifacts are found for a proposed routing (e.g., no architecture doc stored), note it and move on: "No architecture doc found in project manifest. Consider recording this decision elsewhere."

After processing all items, proceed to Step 2.5.

Step 2.5: Push Branch

All reviews are complete and any approved fixes are committed. Now push the branch.

git push -u origin HEAD

If push fails:

If remote already has the branch: git push (without -u) — ask developer to confirm
If branch is behind remote: Do NOT force push. Present the situation to the developer and stop. The developer must decide how to proceed.
Any other failure: Show the error and ask the developer before retrying.

✅ Branch pushed — the code is clean and ready for review.

Step 3: Create Pull Request / Merge Request

Use the build-ops skill to create a PR/MR in the configured VCS backend with:

Issue reference: $ARGUMENTS
Issue summary from Step 1
Changes summary from Step 2
Any deferred code health or security items from Steps 2a/2b — include as a "Suggested Follow-ups" section in the PR/MR description

The build-ops skill handles all backend-specific PR/MR creation (GitHub PRs via gh pr create, GitLab MRs via MCP) and enforces parameter validation. See skills/build-ops/SKILL.md.

✅ PR/MR: [URL]

Step 4: Update Issue Status

Use the build-ops skill to transition issue $ARGUMENTS to "Done" / close it.

The build-ops skill handles all backend-specific close/transition logic (Jira transitions to "Done", GitLab close, GitHub close with PR reference) and enforces parameter validation. See skills/build-ops/SKILL.md.

Note for GitHub: If VCS is also GitHub, the issue may auto-close when PR is merged (due to "Fixes #[number]" in PR body).

✅ Issue status updated

✅ Complete

Summary:

✅ Code reviewed (health + security)
✅ [PR/MR] created: [URL]
✅ Issue: [Status updated]

Next Steps:

Review the [PR/MR] or request teammate reviews
Address any review comments — push additional commits to the same branch
Merge when approved
After [PR/MR] is merged, run /devflow:build:post-merge
- This will assess your local state, explain what needs syncing, and guide you through each step with your approval

Work complete! Remember to run /devflow:build:post-merge after your PR/MR is merged.