Menu
Use when the user says "fix bug", "fix
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Measure the token/cost/time efficiency of AI coding-agent work — per session, per role, per day, and per individual sub-agent — with every dollar metered by ccusage. Use when the user asks "what did this cost", cost per session/role/test case, which role/sub-agent burned the most, tool-call/skill/time breakdowns, "before vs after" cost comparisons, or wants to audit AI spend over time.
Per-role persistent memory — durable facts, preferences, decisions, and a daily log, as plain markdown. Use when the user says "remember this" or "log this", asks "what did you learn yesterday", or whenever you discover something worth keeping across sessions.
UI/E2E test automation with Playwright MCP. Use when the user asks to "test the UI", "automate browser tests", "check the page", "take a screenshot", "run Playwright", "write E2E tests", or anything about browser-based testing.
Turn a vague bug report into precise, repeatable steps with evidence and a CONFIRMED / CANNOT-REPRODUCE / PARTIAL verdict. Use when a bug is unclear or unconfirmed and needs reproduction before RCA or any fix. Reproduction and documentation only — does not fix code.
Generate AGENTS.md and .agents/ configuration files for a new project. Use when the user asks to "seed the project", "onboard this repo", "generate project config", "create AGENTS.md", or after the scout has explored the codebase.
Use when a TMS test case needs to become an automated test, or when automating a regression batch — "automate TC-NNN", "convert this case to a framework test", any flow from a manual case to green framework tests. Pluggable TMS (Zephyr/TestRail/Xray/Azure/markdown).
| name | bugfix-workflow |
| description | Use when the user says "fix bug", "fix |
| license | Apache-2.0 |
| metadata | {"authors":["Artem Rozumenko <artem_rozumenko@epam.com>"],"version":"0.1.0"} |
Core philosophy: reproduce before you fix, verify after you fix, link everything to the ticket.
gh issue … / gh pr … below are the GitHub reference. Translate to your
tracker per .agents/profile.md § Project systems (jira / gitlab-issues /
azure-boards / linear) and your code host's CLI per .agents/workflow.md
(GitLab glab, Azure DevOps az repos, Bitbucket bb, Gitea tea). If scout
hasn't recorded them, ask before assuming GitHub.
1. Read & understand the bug
2. Reproduce
3. Write a failing test
4. Root cause analysis
5. Implement the fix
6. Verify
7. Document on ticket
gh issue view <N>. Identify expected vs actual behavior, files involved,
error messages, stack traces, related issues. Post a 🔧 **Investigating**
comment on the ticket so the reporter knows work has started.
Confirm the bug exists and understand the exact conditions that trigger it.
For the full method — UI / API / logic / intermittent attempts and the
CONFIRMED / CANNOT-REPRODUCE confirmation gate — use the reproducing-issues
skill. UI bugs → Playwright MCP snapshots. API bugs → curl. Logic bugs →
minimal reproducer script.
If you cannot reproduce, stop and ask. Do not proceed to fix a bug you cannot observe. Post what you tried and request more details.
Once reproduced, post a ✅ **Reproduced** comment with steps, expected,
actual, and frequency (always / intermittent).
Capture the bug as a regression test before fixing. Run it and confirm it fails — that's the whole point. A passing test for an unfixed bug means the test doesn't exercise the bug.
Trace the bug to its exact cause — for the full method (execution-path
tracing, root-cause classification, confidence, impact/regression analysis)
use the root-cause-analysis skill. Locate the code, trace execution from
entry point to failure, classify the cause (logic / data / concurrency /
config / integration / resource), and assess blast radius — what else uses
this code, could the fix break anything else?
Post a 🔍 **Root Cause** comment with location (file:line), cause, impact,
and fix approach.
Minimal, focused. Fix the root cause — only the root cause. Don't refactor neighboring code, don't clean up unrelated style, don't expand scope. A bug fix is not the place for improvements.
The failing test from step 3 now passes. Full test suite still passes. Lint and type checks clean. If anything fails, fix it before proceeding — don't ship a fix that breaks something else.
Post a ✅ **Fixed** comment with root cause summary, what changed, regression
test name, and PR number. Commit and open the PR. The completing-a-task skill
covers the full commit → PR → notify handoff.
All the gh issue comment heredocs, reproduction patterns, test templates,
and verification commands live in
references/commands.md. Load that file when you
need the exact template text.