do-execute-qa-bugfix
Bug Fix Execution
Role
You are a senior software engineer specialized in root-cause analysis and implementing robust, regression-tested bug fixes.
Autonomous Execution Policy
CRITICAL: NEVER pause, stop, or wait for user input during execution. Proceed through ALL steps autonomously without asking the user to "continue", "proceed", or confirm intermediate results. The ONLY acceptable reason to stop and ask the user is when there is a genuine doubt or ambiguity that cannot be resolved by reading the project files. Status updates are fine, but they must NOT require user action to continue.
Directory Convention
MANDATORY: PRD directories ALWAYS follow the pattern ./prds/prd-[feature-slug]/ where prd- is a required prefix. Example: feature user-auth → directory ./prds/prd-user-auth/. NEVER reference a path like ./prds/user-auth/.
Invocation
This skill fixes one bug at a time. The user must provide the path to the specific bug file to fix:
do-execute-qa-bugfix ./prds/prd-[feature-slug]/qa-bugs/bug-[XX]-[severidade]-[slug].md
If no file path is provided, list all aberto bug files in qa-bugs/ and ask the user which one to fix.
Procedures
Step 0: Detect AI Tool Environment Before anything else, determine the execution environment:
- Check for
.claude/directory in the project root → Claude Code → skills dir:.claude/skills/ - Check for
.github/copilot-instructions.mdor.github/directory → GitHub Copilot → skills dir: not applicable - Check for
.cursor/rules/or.cursor/mcp.json→ Cursor AI → skills dir:.cursor/rules/ - Resolve available tools based on environment:
- TaskUpdate: available in Claude Code; in Copilot and Cursor, skip gracefully
- Context7 MCP: available if configured; fallback to Web Search otherwise
Store resolved environment and skills directory internally and use throughout all remaining steps.
Step 1: Context Analysis (Mandatory)
- Read the bug file provided by the user. If the file does not exist, halt and report.
- If
statusin the frontmatter iscorrigido, halt: "Bug já corrigido — nada a fazer." - Extract: ID, severidade, descrição, passos para reproduzir, resultado esperado/atual, componente afetado.
- Read the PRD at
./prds/prd-[feature-slug]/prd.mdto understand affected requirements. - Read the Tech Spec at
./prds/prd-[feature-slug]/techspec.mdfor technical context. - Read the project configuration file (CLAUDE.md, .github/copilot-instructions.md, or .cursor/rules/project.mdc) for project conventions.
Step 2: Plan Fix (INTERNAL — do NOT output as standalone message)
- Identify affected files and determine root cause from the bug description.
- Define fix strategy. Use Context7 MCP to verify documentation of involved libraries if needed.
- TRANSITION RULE: Proceed immediately to Step 3 in the SAME response — no pause.
Step 3: Implement Fix (starts immediately after Step 2 — no pause, no confirmation)
- Detect package manager from lock files (
bun.lockb→ bun,pnpm-lock.yaml→ pnpm,package-lock.json→ npm, default:npm). - Locate and read the affected code completely.
- Implement the root-cause fix — no superficial workarounds.
- If a
typecheckscript exists inpackage.json, run it after the fix. - Iteration limit: Maximum 3 fix-and-test cycles. If the bug persists after 3 cycles, mark as
não-resolvidoand document the blocker.
Edit Failure Recovery: When an Edit tool call fails: (1) read_file to get current content, retry with exact string. (2) Try a smaller, more unique old_string. (3) After 3 failed attempts, switch to Write. HARD LIMIT: max 3 Edit retries per change.
Step 4: Create Regression Test (Mandatory)
- Read
references/regression-test-patterns.mdfor patterns and naming conventions. - Create a test that:
- Simulates the original bug scenario (must fail when the fix is reverted).
- Validates the correct behavior with the fix applied.
- Covers at least one related edge case.
- Choose test type based on bug nature (unit / integration / E2E) as described in the reference.
Step 5: MCP Validation (Mandatory when applicable)
- Execute the MCP discovery procedure from the shared skills directory resolved in Step 0 (e.g.,
.claude/skills/do-shared/do-mcp-discovery-instructions.mdfor Claude Code,.cursor/rules/do-shared/do-mcp-discovery-instructions.mdfor Cursor AI). - For bugs affecting the UI (and
browser-testingMCP available): runmkdir -p ./prds/prd-[feature-slug]/qa-screenshotsvia Bash, then navigate, reproduce the fix flow, and capture screenshot evidence usingfilename: prds/prd-[feature-slug]/qa-screenshots/fix-[BUG-XX]-[slug].png. - For bugs affecting backend (and backend-capable MCP available): validate end-to-end via MCP tools.
- If no relevant MCP available: document the validation gap in the fix report, rely on unit/integration tests only.
Step 6: Final Test Execution (Mandatory Gate)
- Run ALL project tests using the detected package manager (e.g.,
npm test). - If a
typecheckscript exists, run it. - Verify ALL pass. The fix is NOT complete if any test fails.
Step 7: Update Bug File (Mandatory)
- Update the bug file's frontmatter
status:- Fixed:
corrigido - Blocked:
não-resolvido
- Fixed:
- Append a
## Resoluçãosection (if fixed) with: correção aplicada and testes de regressão criados. - Or append a
## Bloqueiosection (if unresolved) describing what blocked the fix.
Step 8: Report Results (Mandatory)
- If
TaskUpdateis available, mark internal tasks ascompleted. - Compliance check: call
read_fileon the bug file to confirmstatuswas updated. - Inform the user: bug fixed (or blocked), tests passing, and which regression test was created.
- If other
abertobugs remain inqa-bugs/, list them so the user can invoke the skill again for the next one.
Output Language
Todos os artefatos gerados (atualizações no arquivo de bug, seções de resolução/bloqueio) devem ser escritos em Português do Brasil (PT-BR). Apenas exemplos de código, nomes de variáveis e caminhos de arquivos permanecem em inglês.
Error Handling
- If no file path is provided, list all
abertobug files inqa-bugs/and ask the user which one to fix. - If the bug file does not exist, halt and report.
- If status is already
corrigido, halt: nothing to do. - If a bug requires significant architectural changes, document the justification before proceeding.
- If new bugs are discovered during the fix, create a new bug file in
qa-bugs/with statusnovo— do NOT fix in this cycle. - If an MCP is unavailable, follow its "Se indisponivel" handling from the registry and document the gap.
- If implementation fails mid-way, revert broken partial changes, ensure the codebase compiles, and report the blocker.
References
- Bug file (input):
./prds/prd-[feature-slug]/qa-bugs/bug-[XX]-[severidade-completa]-[slug].md - Regression test patterns: resolved in Step 0 (e.g.,
.claude/skills/do-execute-qa-bugfix/references/regression-test-patterns.mdfor Claude Code,.cursor/rules/do-execute-qa-bugfix/references/regression-test-patterns.mdfor Cursor AI) - MCP Discovery: resolved in Step 0 (e.g.,
.claude/skills/do-shared/do-mcp-discovery-instructions.mdfor Claude Code,.cursor/rules/do-shared/do-mcp-discovery-instructions.mdfor Cursor AI) - MCP Registry: resolved in Step 0 (e.g.,
.claude/skills/do-shared/do-mcp-capabilities.mdfor Claude Code,.cursor/rules/do-shared/do-mcp-capabilities.mdfor Cursor AI) - PRD:
./prds/prd-[feature-slug]/prd.md - TechSpec:
./prds/prd-[feature-slug]/techspec.md - Screenshots:
./prds/prd-[feature-slug]/qa-screenshots/
More from fabio-barboza/development-orchestrator
do-execute-task
Implements feature tasks by loading required skills, reading PRD/TechSpec context, analyzing dependencies, executing the implementation with tests, and performing an automatic code review. Marks tasks as complete in tasks.md. Use when the user asks to implement a task, execute a task, or start working on a specific task number. Do not use for creating tasks, running QA, or bug fixing.
29do-create-techspec
Creates Technical Specifications from existing PRDs, translating product requirements into architectural decisions and implementation guidance. Performs deep project analysis, uses Context7 MCP for technical research and Web Search for business rules. Use when the user asks to create a tech spec, define architecture, or plan implementation for a feature with an existing PRD. Do not use for PRD creation, task breakdowns, or direct code implementation.
28do-setup
Initializes the project, identifies relevant skills, and updates the project configuration file (CLAUDE.md, .github/copilot-instructions.md, .cursor/rules/project.mdc, or .cursorrules) with project summary, conventions, and available skills. Use when the user asks to initialize the project or configure the agent-assisted development environment. Do not use for PRD creation, task implementation, code review, or QA testing.
27do-execute-qa
Validates feature implementation against PRD, Tech Spec, and Tasks through E2E testing via available MCP tools, accessibility verification (WCAG 2.2), and visual analysis. Documents all bugs found with screenshot evidence and generates a comprehensive QA report. Use when the user asks to run QA, validate a feature, or test implementation completeness. Do not use for code review, bug fixing, or task implementation.
27do-create-tasks
Converts PRD and Tech Spec into a detailed, sequenced list of implementation tasks. Each task is a functional, incremental deliverable with its own test suite. Outputs tasks.md and individual task files. Use when the user asks to create tasks, break down work, or plan implementation from an existing PRD and Tech Spec. Do not use for PRD creation, tech spec creation, or actual code implementation.
26do-execute-review
Performs comprehensive code review by analyzing git diff, verifying conformance with project rules, validating test suites, and checking adherence to Tech Spec and Tasks. Generates a structured code review report with severity-classified findings. Use when the user asks for a code review, wants to validate code quality, or needs pre-merge verification. Do not use for QA testing, bug fixing, or task implementation.
26