菜单
Executes bug fix workflows from branch creation through pull request with root cause driven execution. Use when the user says "execute bug fix", "fix this bug", "run the bug fix workflow", or references bug documents in requirements/bugs/.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Developer-persona skill that consumes QA findings (verdict ISSUES-FOUND), reproduces failing QA tests, writes production fixes, re-validates, and adopts QA tests into *.qa.* siblings next to peer tests once re-QA passes. Use when the orchestrator branches from executing-qa with a non-PASS verdict, or when re-running addressing-qa-findings to drive the QA loop forward.
Merges the current PR, checks out main, fetches, and pulls — reducing the repetitive end-of-workflow sequence to a single slash command. Use when the user says "finalize", "merge and reset", "finalize workflow", or after QA passes.
Orchestrate full SDLC workflow chains (feature, chore, bug) end-to-end by sequencing sub-skill invocations, managing state across pause points, and isolating per-step context via Agent tool forking.
Executes adversarial QA against a feature branch by writing and running real tests (or producing a structured exploratory review when no test framework is detected). Emits a version-2 results artifact with verdict, execution results, findings, and reconciliation delta.
Centralizes git and pull-request operations into a single delegatable skill. Dispatches between GitHub (gh CLI) and Azure DevOps (az CLI) backends based on origin URL or SDLC_SCM_BACKEND env override. Use when the orchestrator or a consumer skill needs to create, view, list, merge, or diff pull requests, or perform branch/commit/push work backed by either SCM provider.
Executes chore task workflows including branch creation, implementation, and pull request creation. Use when the user says "execute chore", "implement this chore", "run the chore workflow", or references chore documents in requirements/chores/.
| name | executing-bug-fixes |
| description | Executes bug fix workflows from branch creation through pull request with root cause driven execution. Use when the user says "execute bug fix", "fix this bug", "run the bug fix workflow", or references bug documents in requirements/bugs/. |
| allowed-tools | ["Read","Write","Edit","Bash","Glob","Grep"] |
| argument-hint | <bug-id> |
Execute bug fix workflows with root cause driven execution from branch creation through pull request.
requirements/bugs/requirements/bugs/ by ID prefix (e.g., BUG-003 matches BUG-003-login-timeout-error.md). On no match, inform the user and fall back to interactive selection. On multiple matches, present options and ask the user to choose.requirements/bugs/ and prompt the user to select if multiple exist.Locate the bug document — resolve a BUG-NNN ID with:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/resolve-requirement-doc.sh" "<BUG-NNN>"
Exit codes: 0 on exactly-one match (path on stdout); 1 on zero matches; 2 on ambiguous (list candidates); 3 on malformed/missing ID.
Extract Bug ID, severity, root cause(s), and review acceptance criteria
Redeclare root causes from the bug document into the workflow context
Create the git branch. Build the name and ensure checkout with:
branch=$(bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/build-branch-name.sh" fix "<BUG-NNN>" "<2-4 word description>")
bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/ensure-branch.sh" "$branch"
build-branch-name.sh calls slugify.sh internally (bash "${CLAUDE_PLUGIN_ROOT}/scripts/slugify.sh" "<description>") — handles lowercasing, punctuation stripping, stopword removal (a, an, the, of, for, to, and, or), and the 4-token cap. Exit codes: build-branch-name.sh returns 1 on empty slug (ask for a more descriptive title) and 2 on invalid type. ensure-branch.sh returns 0 on success, 2 on missing arg, 3 on dirty working tree (stash or commit first).
Address each root cause systematically, implementing fixes and tracking with todos
Check off each acceptance criterion in the bug document with:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/check-acceptance.sh" "<bug-doc>" "<AC matcher>"
Literal substring match (not regex), fence-aware. Exit codes: 0 on checked / already checked (idempotent); 1 on criterion not found; 2 on ambiguous; 3 on missing arg.
Commit changes with:
bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/commit-work.sh" fix <category> "<description>"
The script does not stage files — run git add <paths> first. It runs git commit -m "fix(<category>): <description>" and prints the short SHA on success. Exit codes: 0 on success (SHA on stdout); 1 on commit failure (git stderr passes through); 2 on missing/invalid type arg.
Verify reproduction steps no longer trigger the bug
Run build-health verification:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/verify-build-health.sh"
See the script header for full semantics. Non-zero exit halts the fix.
Create the pull request with:
bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/create-pr.sh" fix "<BUG-NNN>" "<summary>" [--closes <issueRef>]
Multi-backend dispatcher (FEAT-033): pushes the current branch, then dispatches on backend-detect.sh output. GitHub path runs gh pr create against scripts/assets/pr-body.tmpl; Azure DevOps path runs az repos pr create against the AzDO body template. MUST include --closes #N (GitHub) or --issue-ref AB#NNN (AzDO Boards) if an issue exists — --closes auto-closes the linked GitHub issue on merge; --issue-ref is rendered into the AzDO description for cross-link visibility. Exit codes: 0 on success (PR URL on stdout) OR on graceful-skip (gh/az absent, unauthenticated, or az devops extension missing — [warn] line on stderr); 1 on push failure or backend-CLI hard failure; 2 on missing/invalid args.
Update the bug document completion section (status, date, PR link)
Note: Issue tracking (start/completion comments) is handled by the orchestrator via
managing-work-items. This skill focuses on root cause driven execution and verification.
Follow the lite-narration rules below. Load-bearing carve-outs MUST be emitted as specified; they are not narration. This skill is forked by orchestrating-workflows once per bug (bug chain step 4), so its output flows to a parent orchestrator rather than directly to the user.
Edit confirmations, git push tracking lines).->) and punctuation over Unicode alternatives in skill-authored prose. Existing Unicode em dashes in tables and reference docs are retained.The following MUST always be emitted even when they resemble narration:
fail calls -- users need the reason the skill halted. Surface script and tool stderr verbatim (e.g., resolve-requirement-doc.sh, build-branch-name.sh, ensure-branch.sh, check-acceptance.sh, commit-work.sh, create-pr.sh failures; npm test / npm run build / npm run lint failing output).build-branch-name.sh exits 1 on an empty slug, selection prompt when no bug argument is supplied and multiple bug documents exist).reviewing-requirements -- N/A for this skill (it does not consume reviewing-requirements findings); bullet retained for consistency with the canonical template.[model] step {N} ({skill}) → {tier} (...) audit-trail lines emitted by prepare-fork.sh. The Unicode → is the documented emitter format; do not rewrite to ASCII.[info], [warn], or [model] is a structured log, not narration. Emit verbatim.This skill is forked by orchestrating-workflows once per bug (bug chain step 4). Emit done | artifact=<path> | <note-of-at-most-10-words> as the final line on success, and failed | <one-sentence reason> on failure. The Found **N errors**, **N warnings**, **N info** shape is reserved for reviewing-requirements only and MUST NOT be emitted here.
artifact= points to the file(s) the bug fix actually produced. Because a bug fix typically commits to multiple files (source edits + bug-document checkmark edits) and finishes with a pull request, use the most-representative single reference: the PR URL or the fix branch name when the PR is created successfully, or the bug document path (requirements/bugs/<ID>-*.md) when no PR-identifying artifact is available. Example: done | artifact=requirements/bugs/BUG-NNN-*.md | PR #<N> created.
PR creation is this skill's responsibility. Unlike implementing-plan-phases, this skill is NOT asked to skip PR creation when orchestrated — the bug chain has no separate PR-creation step. Step 10 (Create Pull Request) runs in both orchestrated and standalone invocations. The orchestrator extracts the PR number from this subagent's output (or falls back to gh pr list --head <branch>) and uses it for downstream chain steps.
Precedence: the return contract takes precedence over the lite rules when the two conflict. The subagent MUST emit the contract shape as the final line of the response even if it reads like narration.
Copy this checklist to track progress:
Bug Fix Execution:
- [ ] Locate bug document (get Bug ID)
- [ ] Extract severity, root causes, and acceptance criteria
- [ ] Redeclare root causes as trackable work items
- [ ] Create git branch: fix/BUG-XXX-description
- [ ] Address each root cause systematically (RC-1, RC-2, ...)
- [ ] Check off each acceptance criterion in bug document (- [ ] → - [x]) as verified
- [ ] Commit with fix(category): message format
- [ ] Verify reproduction steps no longer trigger the bug
- [ ] Run tests/build verification
- [ ] Create pull request (include "Closes #N" in body if issue exists)
- [ ] Update bug document (status → Completed, date, PR link)
Important: Including Closes #N in the PR body auto-closes the linked GitHub issue when merged. Without it, the issue must be closed manually.
See references/workflow-details.md for detailed guidance on each step.
Bug fixes are organized around root causes identified in the bug document for systematic coverage and traceability.
(RC-N) acceptance criteria passRC-N is addressed and its acceptance criteria are metIf a new root cause surfaces during execution:
RC-N entry(RC-N) tagFormat: fix/BUG-XXX-{2-4-word-description}. Always assemble via bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/build-branch-name.sh" fix "<BUG-NNN>" "<description>" (see Quick Start step 4) — the script applies slugify normalization uniformly.
Examples:
fix/BUG-001-null-pointer-crashfix/BUG-002-incorrect-total-calcfix/BUG-003-missing-input-validationFormat: fix(category): brief description. Assemble via bash "${CLAUDE_PLUGIN_ROOT}/skills/managing-source-control/scripts/commit-work.sh" fix <category> "<description>" (see Quick Start step 7). Callers must git add relevant paths before invoking — the script does not auto-stage.
| Category | Use When |
|---|---|
runtime-error | Crashes, exceptions, unhandled errors |
logic-error | Incorrect calculations, wrong conditions, flawed algorithms |
ui-defect | Visual bugs, layout issues, rendering problems |
performance | Slowness, memory leaks, resource exhaustion |
security | Vulnerabilities, auth bypasses, data exposure |
regression | Previously working functionality that broke |
Examples:
fix(runtime-error): handle null user in profile lookupfix(logic-error): correct discount calculation for bulk ordersfix(ui-defect): fix modal overlay z-index stackingBefore creating the PR, verify:
(RC-N) tagged acceptance criterion is metverify-build-health.sh exits 0 (lint, format:check, test, build all pass)| Task Type | Recommended Approach |
|---|---|
| Bug already documented | Use this skill (executing-bug-fixes) |
| Bug needs documentation first | Use documenting-bugs, then this skill |
| Chore or maintenance task | Use documenting-chores -> executing-chores |
| New feature with requirements | Use documenting-features -> creating-implementation-plans -> implementing-plan-phases |
| Quick fix (no tracking needed) | Direct implementation |
After executing a bug fix, consider running /reviewing-requirements for code-review reconciliation after PR review (optional but recommended), then /executing-qa to verify the implementation against the test plan, and /finalizing-workflow to merge.