메뉴
Execute a Bug Fix pipeline: environment check, diagnosis, fix, test, regression check, documentation, commit & PR, code review, test verification, review verdict, merge, and retrospective. Invoke with /pipeline-bugfix followed by the bug report.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Execute pipeline stages by reading the state file and spawning agents. Reads .pipeline-state/<branch>.json, finds the next pending stage, spawns an agent to execute it, updates the state file, and repeats. Run /pipeline-next first to create the state file.
Shared pipeline stage procedures used by pipeline-feature, pipeline-bugfix, and pipeline-refactor skills. Not invoked directly — referenced by pipeline-specific skills as reusable building blocks for environment setup, testing, security scanning, documentation, commit/PR, code review, merge, and retrospective stages.
Drain open GitHub issues into the current milestone and process them all. Checks for open issues, adds them to the ROADMAP milestone, then runs pipeline-run --milestone --all to process everything.
Pick the next task (or group of related tasks) from ROADMAP.md and set up a pipeline state file. Reads the roadmap, filters by milestone/priority, groups related small features into batches, checks what's already done, and creates .pipeline-state/<branch>.json from the template. Run /pipeline-run after this to execute the stages.
Ship existing changes through quality gates to a merged PR. Starts from uncommitted/committed changes in your working tree and runs test → review → security → docs → commit → PR → code review → merge → retrospective. Use when you've been coding interactively and want to formalize and ship.
Fast iteration loop for initial-development work: branch → implement → build → push → live-verify → merge. No subagent reviews, no CHANGELOG, no roadmap coupling. Optimized for rapid PR cycles where the USER is the reviewer (manual verification via browser/CLI) and browser-extension reload/reconnect is an explicit handoff step. Use this INSTEAD OF /pipeline-ship when there's no CI, no formal review, and the goal is shipping many small PRs per day.
| name | pipeline-bugfix |
| description | Execute a Bug Fix pipeline: environment check, diagnosis, fix, test, regression check, documentation, commit & PR, code review, test verification, review verdict, merge, and retrospective. Invoke with /pipeline-bugfix followed by the bug report. |
Run a complete bug fix cycle with diagnosis, targeted fix, regression checking, and quality gates.
Usage: /pipeline-bugfix <bug report / description>
CRITICAL: You MUST execute ALL 13 stages. Do NOT stop after Commit & PR (Stage 8). Stages 9-13 (Code Review, Test Verification, Review Verdict, Merge PR, Retrospective) are mandatory.
fix/<short-slug> (e.g., fix/login-timeout).pipeline-state/<branch-name>.json from templates/bugfix-state.json. If it already exists, this is a resume.main)Follow the Environment Check procedure from pipeline-shared.
Gate: ENV_OK required.
On ENV_FAILED: Retry once. If retry fails → STOP PIPELINE.
Follow the Conflict Check procedure from pipeline-shared.
Gate: MERGE_CLEAN required.
On MERGE_CONFLICTS_FOUND → STOP PIPELINE.
Investigate the codebase, identify the root cause, and propose a fix.
SCOPE_EXPANDED: found X violations across Y files (spec described N)
This stage always passes (informational). The diagnosis output will be referenced by Fix and Regression Check.
Apply the fix based on the diagnosis from Stage 3.
If the branch already has commits from a previous attempt, build on that work — do NOT redo what's already done.
Stage passes if fix completes without errors. Proceed to testing.
Follow the Test Execution procedure from pipeline-shared.
Gate: TESTS_PASSED required.
On TESTS_FAILED: Go back and fix the failing code, then re-run tests (attempt 2 of 2). If tests still fail → STOP PIPELINE.
Verify the fix doesn't introduce regressions and actually addresses the root cause.
Root cause verification: Cross-reference the Diagnosis stage output (Stage 3) against the fix. Verify the root cause identified was actually addressed, not just a symptom. Flag if the fix diverged from the diagnosis.
Regression check: Verify no related functionality is broken
Edge case review: Confirm edge cases are handled
REGRESSION_PASSED — no regressions foundREGRESSION_FAILED — followed by detailsOn REGRESSION_FAILED (attempt 1): Fix the issues, then re-check.
On REGRESSION_FAILED (attempt 2): Rewind to Stage 3 (Diagnosis). The original diagnosis may have been incomplete. Re-investigate with the regression context. Then re-fix from Stage 4 onward. Maximum 1 rewind. If second pass also fails → STOP PIPELINE.
Follow the Documentation procedure from pipeline-shared.
Gate: DOCS_UPDATED (always passes).
Follow the Commit & PR procedure from pipeline-shared.
Use conventional commit format: fix: <description>
Gate: PR_CREATED, PR_EXISTS, or PR_SKIPPED.
After this stage completes, you MUST continue to Stage 9. The pipeline is NOT done.
These stages run as subagents to ensure they execute with fresh context. This prevents context compression from losing the review instructions.
Use the Agent tool to spawn a subagent with this prompt:
You are reviewing PR #
<pr_number>for a bug fix. The project directory is<project_path>. The PR targets<pr_target_branch>.Step 1 — Code Review: Run
git diff <pr_target_branch>...HEAD. Read changed files. Check fordocs/PULL_REQUEST_CHECKLIST.mdand use it if found. Review for: correctness, security, testing gaps (bug fix MUST have regression test), code quality, documentation (CHANGELOG updated for fix), performance. Flag auto-reject triggers.Step 2 — Test Verification: Run the project test suite. Report pass/fail.
Step 3 — Review Verdict: Synthesize findings. Decide: APPROVE, REQUEST_CHANGES, or COMMENT.
Step 4 — MANDATORY: Post review to GitHub PR. Run:
gh pr review <pr_number> --comment --body "<formatted review with checklist, findings, and verdict>"If REQUEST_CHANGES, use--request-changesinstead. If project haspr/feedback/, save there too.Step 5 — Output exactly one of: APPROVE, REQUEST_CHANGES, or COMMENT.
APPROVE → proceed to Stage 12REQUEST_CHANGES → fix issues, re-commit, re-push, re-run subagent. Second failure → STOP PIPELINE.Use the Agent tool to spawn a subagent:
Approve and merge PR #
<pr_number>in<project_path>.
gh pr merge <pr_number> --squash --delete-branchDo NOT rungh pr review --approve— GitHub blocks self-approval.- Output PR_MERGED or MERGE_FAILED.
PR_MERGED → proceed to Stage 13MERGE_FAILED → retry once. Still failing → STOP PIPELINE.Use the Agent tool to spawn a subagent:
You are writing a retrospective for a completed bug fix pipeline. Task:
<task description>. Project:<project_path>. PR #<pr_number>. Rungit log --oneline <pr_target_branch>..HEAD. Evaluate: quality (1-5), what went well, lessons learned, improvements, IDEA:/TOOL: lines.You MUST post the retrospective to these two places. This is not optional.
gh pr comment <pr_number> --body "## Pipeline Retrospective\n\n**Quality**: X/5\n\n### What Went Well\n- ...\n\n### Lessons Learned\n- ...\n\n### Suggested Improvements\n- IDEA: ..."- Append to
.pipeline-log.md(create if needed, ensure in .gitignore).Output RETRO_COMPLETE when both posts are done.
The pipeline is now complete.
ENV_FAILED after retryMERGE_CONFLICTS_FOUNDTESTS_FAILED after retry (Stage 5 or 10)REGRESSION_FAILED after retry + rewindMERGE_FAILED after retry| Stage | Can Rewind To | Max Rewinds | Trigger |
|---|---|---|---|
| Stage 6 (Regression Check) | Stage 3 (Diagnosis) | 1 | REGRESSION_FAILED after retry |