acevinh Quick Fix
Why this skill exists
Most day-to-day tasks are small: fix a bug, tweak UI, add a filter, rename something. For these, a full project scan wastes tokens and time. The user already knows which files matter — they just need you to read those files, understand the local context, do the work, and verify.
Even for quick fixes, the workflow should demonstrate disciplined AI usage: brief reasoning about approach, and iterative verification until the change is proven correct.
Expected input from the user
The user will provide some combination of:
| Input | Required? | Example |
|---|---|---|
| What to do | Yes | "thêm nút Copy URL cạnh ô filter" |
| File path(s) | Yes (at least 1) | src/components/UserTable/FilterRow.tsx |
| Reference | Optional | "same as the copy button on the settings tab", a screenshot, or a design image |
| Verify target | Optional | a URL like http://localhost:3000/users/51, or "type-check", or "run tests" |
| Extra context | Optional | "the export view has no status column" |
If the user gives you a file path and an instruction but nothing else, that's enough — proceed.
Workflow
Step 1 — Read & Assess (scoped)
Read ONLY the files the user provided. Do not glob or grep across the project. If the user gave a reference ("similar to X"), also read X.
While reading, note:
- Imports and dependencies used in the file
- Naming conventions, patterns, component structure
- The specific area where the change needs to happen
- Which rules from the repo's own docs (
CLAUDE.md,CONVENTIONS.md,CONTRIBUTING.md) apply to this change — read them, don't recall them
If you need one more file to understand context (a shared type, a parent component, a utility), read it — but stop there. Two hops max from the seed files.
Step 2 — Brief Approach & Reasoning
Before editing, state in 2-3 sentences:
- What you're about to do
- Why this approach ("following the same pattern as the copy button in
SettingsTab") - Risk if any ("this touches a shared component — other views might be affected")
This doesn't need to be a full plan — just enough that the human can see your reasoning and redirect before you code. For truly trivial changes (typo fix, import reorder), a single sentence is enough.
Step 3 — Implement
Make the change. Follow the patterns already in the file:
- Same import style
- Same naming convention
- Same state management approach
- Same component structure
Keep the diff minimal. Change only what the user asked for. No drive-by refactors, no "while I'm here" cleanup.
If the user gave a reference, copy its pattern closely. The existing codebase answer is almost always the right one.
Step 4 — Verify-Debug Loop
Pick the right verification based on what changed, then iterate if needed:
- UI change + URL provided: drive a browser to the view and check the result. Screenshot if helpful.
- Logic/backend change: run the repo's type-check or the relevant tests (
npm test <path>,pnpm test <path>). - No verify target given: run
<your typecheck command>at minimum. If that's not possible, say so. - Design image provided: compare the rendered result against the image. A passing type-check alone is not proof that UI matches design.
If verification fails: diagnose → fix → re-verify. Log each attempt:
Verify 1: ❌ type-check failed — missing import for CopyButton
→ Fix: added import at line 12
Verify 2: ✅ type-check passes, screenshot matches
Never claim done on a failing check.
Output format
## Approach
<1-2 sentences: what you did and why this approach>
## Changes
- <file:line> — <what changed>
## Verification
<command run> → <result> → <evidence (real output / screenshot path)>
[If retried: iteration chain]
Final: ✅
## Risk (if any)
<anything the human should be aware of>
## Test note
<the one line handed to whoever tests this>
If something couldn't be verified, say so explicitly.
Guardrails
- Leave a test note. Any change to behaviour gets one line: area · what changed · the risk it creates. If the repo keeps a testing inbox/ledger file, append it there and follow that file's format; otherwise put the line in your reply. A pure refactor with no behaviour change doesn't need one — say that instead.
- Stay in scope. If you find yourself reading more than 4-5 files, this task is too big for quick-fix — tell the user and switch to a full scan-and-plan workflow.
- Don't add error handling, comments, or abstractions the user didn't ask for.
- Don't ask alignment questions when the user already gave clear inputs. Just do the work.
- Follow existing patterns in the file. If you're inventing something new when a pattern exists right there in the file, stop.
- Cite the repo's own rule docs when a rule applies to the change — quote the section you actually read, never a remembered one.
Language
- Skill instructions: English (so Claude processes them efficiently).
- User-facing responses: match the user's language. If they write Vietnamese, respond in Vietnamese.