home / skills / duc01226 / easyplatform / fix-fast

fix-fast skill

/.claude/skills/fix-fast

This skill helps identify and fix small defects quickly in C# projects by validating evidence, proposing fixes, and guiding safe code changes.

npx playbooks add skill duc01226/easyplatform --skill fix-fast

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.6 KB
---
name: fix-fast
description: "[Fix & Debug] ⚡ Analyze and fix small issues [FAST]"
argument-hint: [issues]
infer: true
---

Analyze the skills catalog and activate the skills that are needed for the task during the process.

## ⚠️ Anti-Hallucination Reminder

**Before modifying ANY code:** Verify assumptions with actual code evidence. Search for usages, read implementations, trace dependencies. If confidence < 90% on any change, investigate first or ask user. See `.claude/skills/shared/anti-hallucination-protocol.md` for full protocol.

## Mission
**Think hard** to analyze and fix these issues:
<issues>$ARGUMENTS</issues>

## Workflow
1. If the user provides a screenshots or videos, use `ai-multimodal` skill to describe as detailed as possible the issue, make sure developers can predict the root causes easily based on the description.
2. Use `debugger` subagent to find the root cause of the issues and report back to main agent.
3. Activate `debug` skills and `problem-solving` skills to tackle the issues.
4. Start implementing the fix based the reports and solutions.
5. Use `tester` agent to test the fix and make sure it works, then report back to main agent.
6. If there are issues or failed tests, repeat from step 2.
7. After finishing, respond back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.

## IMPORTANT Task Planning Notes

- Always plan and break many small todo tasks
- Always add a final review todo task to review the works done at the end to find any fix or enhancement needed

Overview

This skill speeds up diagnosis and repair of small code defects in C# projects by combining targeted analysis, automated debugging, and rapid test-driven fixes. It focuses on fast, evidence-driven changes with a clear audit trail so developers can trust every modification. The goal is minimal, safe edits that restore functionality or remove obvious bugs without large refactors.

How this skill works

The skill inspects the codebase to locate failing code paths, reproduces issues with lightweight tests, and traces dependencies to identify root causes. It applies small, well-scoped fixes, runs automated tests, and iterates until passing. Throughout the process it verifies assumptions against actual code usage and test evidence before changing any code.

When to use it

  • A single failing unit or integration test points to a narrow area of code
  • Runtime exceptions or crashes with clear stack traces in C# projects
  • Small feature regressions introduced by recent commits
  • Minor performance hotspots where localized fixes are possible
  • When you need a quick, low-risk patch to unblock development

Best practices

  • Verify every assumption against code and tests before making changes
  • Break the work into small, reviewable tasks and include a final review task
  • Make minimal, behavior-preserving edits and include unit tests for regressions
  • Document the cause, change, and test evidence in the commit message
  • Run the full test suite after the local fix before submitting changes

Example use cases

  • Fixing a null reference exception in a controller or service method
  • Correcting an off-by-one error that breaks a calculation or loop
  • Restoring a failing unit test by fixing a wrong assertion or mock setup
  • Adjusting a LINQ query that returned incorrect results after a model change
  • Resolving a serialization or deserialization mismatch causing runtime errors

FAQ

How do you avoid introducing new bugs during a quick fix?

I keep changes minimal, add or update small focused tests that reproduce the issue, run the full test suite, and document the exact reasons and code evidence for the change.

What if the root cause is unclear?

I gather more evidence by tracing call sites, logging relevant state, and creating small reproducible tests. If confidence is under 90%, I pause and request additional information before modifying code.