mcpbeat Sign in

Dev Fix Agent Skill

Unified developer workflow for fixing bugs. Analyzes issue-tracker context, cross-checks docs/code, proposes a solution, implements the fix, verifies locally, and delivers a PR/MR.

2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
536
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/HoangNguyen0403/agent-skills-standard --skill dev-fix

The instruction itself

19 sections, as written by the author

Dev Fix Skill

> [!IMPORTANT]

> Unified developer workflow for fixing bugs. Analyzes issue-tracker context, cross-checks docs/code, proposes a solution, implements the fix, verifies locally, and delivers a PR/MR.

Optional args: slug=<feature>, ticket=<id/url>, mode=interactive|autonomous|channel, channel=<id>, auto_continue=true|false, profile=business|hybrid|technical.

Instructions

When the user asks to perform this workflow, execute the following steps:

Dev-Fix — Bug Remediation

Goal: Take a bug ticket from root-cause analysis through a locally-verified PR/MR, enforcing a strict Propose -> Approve -> Verify cycle.

Input

/dev-fix <issue-url-or-key>

Workflow

Step 0: Environment Prep (Turbo)

// turbo

  • Sync Registry: git pull origin main in the standard repo.

Step 1: Research & Discovery (Implementation Plan Phase)

> [!TIP]

> Sub-Agent Delegation: If your platform supports sub-agents, delegate ticket extraction to specialist-jira-analyst and context lookup to specialist-codebase-scout. If sub-agents are NOT supported, execute these steps yourself.

  • Analyze Ticket: Use installed Jira/GitHub/GitLab/ADO MCP first; otherwise use exported ticket text. Extract Reproduce steps, Expected Result, and Actual Result.
  • Cross-Check Context: Use knowledge-base MCP when configured; otherwise use local code search. Locate relevant code.
  • Create Implementation Plan:
  • Use the Implementation Plan Template below.
  • Initialize project-local docs/prd/prd-plan-[slug].md.
  • Goal: Clear description of the root cause.
  • Proposed Changes: Exact files and logic to be modified.
  • Verification Plan: Detail which QE skill will be used to verify the fix _locally_ before PR.
  • Do not propose code changes until repro steps, expected result, and root cause hypothesis are explicit.
  • HARD STOP: Request user approval for the implementation plan.
  • Readiness Gate: Run implementation-readiness; code only after READY or approved PARTIAL.

Step 2: Implementation (TDD Phase)

> [!TIP]

> Sub-Agent Delegation: For the actual fix, delegate the TDD loop to specialist-tdd-implementer. If sub-agents are NOT supported, execute the TDD loop yourself using the TDD skill matched in AGENTS.md.

  • Worktree Branching: Create a new worktree for the fix using git worktree add ../<ticket-key> -b fix/<ticket-key> and cd into it.
  • Task Tracking:
  • Use the Task Template below.
  • Initialize project-local docs/srs/srs-task-list.md.
  • Code: Implement the fix using common-tdd or the @specialist-tdd-implementer sub-agent. Follow common-best-practices and service-specific AGENTS.md rules.
  • Delete any pre-test implementation spike before starting the TDD loop.

Step 3: Local Verification (Enterprise Standard)

Do NOT rely on "it builds" — verify the fix against the issue reproduction steps.

  • Launch Dev Server: Run the local dev environment for the service.
  • Execute QE Audit:
  • Web: Load quality-engineering-playwright-cli. Run the reproduction steps. Capture "After" snapshots.
  • Mobile: Load quality-engineering-appium-mcp. Run the reproduction steps on an emulator.
  • Final Verdict: Compare results against the issue Expected Result. If any sub-3px regressions exist, fix them now.
  • No success claim without fresh local evidence in docs/srs/srs-walkthrough.md.

Step 4: Deliver PR

  • Commit: Generate a commit message using caveman-commit.
  • PR/MR Details: Draft provider-appropriate PR/MR notes and link the source issue.
  • Walkthrough:
  • Use the Walkthrough Template below.
  • Create project-local docs/srs/srs-walkthrough.md with evidence of the local verification.

Runtime Contract

  • Use for bug tickets that need root-cause remediation and a PR/MR.
  • Required inputs: issue URL/key or exported ticket text with reproduce steps.
  • Return BLOCKED only when repro steps, expected result, or root-cause hypothesis cannot be established.

Handoff Payload

  • slug, operator_profile (carried, not re-inferred), implementation plan path, task list path, walkthrough path, PR/MR link, outcome report, next workflow.

Blocking Questions

  • Ask max 3 at a time with a recommended default and 2-3 options.

Artifact Templates

Implementation Plan Template

# Implementation Plan: [Name]

## Goal

## Proposed Changes

## Task Slices

| Slice   | Scope   | Verification   |
| ------- | ------- | -------------- |
| [slice] | [scope] | [verification] |

## Risks

## Verification Plan

## Next Workflow
implementation-readiness

Task Template

# Task: [Name]

## Scope

## Checklist

- [ ] [task]

## Decisions

## Evidence

## Next Workflow
verify-work

Walkthrough Template

# Walkthrough: [Name]

## Scope

## Acceptance Criteria

## Evidence

| Check   | Result              | Evidence   |
| ------- | ------------------- | ---------- |
| [check] | [PASS/FAIL/BLOCKED] | [evidence] |

## Risks

## Outcome Report
feature_status: implemented | partially_implemented | blocked
requirement_trace: BRD-OBJ-* -> REQ-* -> AC-* -> SRS-* -> evidence
completed_evidence: []; missing_evidence: []; decision_needed: []; recommended_next_workflow: verify-bug | verify-work

## Next Workflow
verify-bug | verify-work

Cost Report

Call get_session_cost(workflow="dev-fix") before final handoff.

Anti-Patterns

  • No Blind Implementation: Never write code before the implementation plan is approved.
  • No Orphan Sessions: Always close browser/appium sessions used during verification.
  • No skipping local verify: "I checked it manually" is not enough. Provide snapshots/logs in the project-local docs/srs/srs-walkthrough.md.

Other skills for the same job

different authors, same section of the catalogue
GitHub Project Management
by ComeOnOliver
×3

Comprehensive GitHub project management with swarm-coordinated issue tracking, project board automation, and sprint planning

14k tokens
Folder Structure Blueprint Generator
by github
vendor ×1

Comprehensive technology-agnostic prompt for analyzing and documenting project folder structures. Auto-detects project types (.NET, Java, React, Angular, Python, Node.js, Flutter), generates detailed blueprints with visualization options, naming conventions, file placement patterns, and extension templates for maintaining consistent code organization across diverse technology stacks.

3k tokens
Sequential Thinking
by mrgoonie
×1

Use when complex problems require systematic step-by-step reasoning with ability to revise thoughts, branch into alternative approaches, or dynamically adjust scope. Ideal for multi-stage analysis, design planning, problem decomposition, or tasks with initially unclear scope.

4k tokens
Openserv Multi Agent Workflows
by internet-court
×1

Multi-agent workflow examples to work together on the OpenServ Platform. Covers agent discovery, multi-agent workspaces, task dependencies, and workflow orchestration using the Platform Client. Read reference.md for the full API reference. Read openserv-agent-sdk and openserv-client for building and running agents.

24k tokens
API Patterns
by lingxling
×1

API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.

5k tokens scripts
Github Workflow Automation
by lingxling
×1

Patterns for automating GitHub workflows with AI assistance, inspired by [Gemini CLI](https://github.com/google-gemini/gemini-cli) and modern DevOps practices.

5k tokens
Domain Identification Grouping
by christophacham
×1

Groups existing components into logical business domains to plan service-based architecture. Use when asking "which components belong together?", "group these into services", "organize by domain", "component-to-domain mapping", or planning service extraction from an existing codebase. Do NOT use for identifying new domains from scratch (use domain-analysis) or analyzing coupling (use coupling-analysis).

10k tokens
API Patterns
by ComeOnOliver
×1

API design principles and decision-making. REST vs GraphQL vs tRPC selection, response formats, versioning, pagination.

8k tokens scripts

How to use it

Copy the folder

Take hoangnguyen0403/dev-fix from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.