# Quick Fix > Small code task where the user ALREADY NAMED ≤3 files: bug fix, UI tweak, add a button/column/filter, small refactor. Scan only what they gave you, implement, verify. Triggers on fix, chỉnh, sửa, thêm, bỏ, update, 'small change', 'chỉnh lại', 'sửa giúp', 'thêm cho tôi', 'bỏ cái này', 'update lại', a pasted error with a file path, or 1-3 file paths plus a short instruction. Boundary: no files named, >3 files, spans multiple packages/repos, or unknown root cause → escalate to a full scan-and-plan workflow instead. File count decides, not how small it feels. - Skill: `acevinh/quick-fix` (Agent Skill) - Install (CLI): `npx skillmds@latest add acevinh/quick-fix` - Raw SKILL.md: https://api.skillmd.com/api/skills/acevinh/quick-fix/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: acevinh (https://skillmd.com/u/acevinh) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/acevinh/quick-fix --- # 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 `, `pnpm test `). - **No verify target given:** run `` 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 - — ## Verification → → [If retried: iteration chain] Final: ✅ ## Risk (if any) ## Test note ``` 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.