focused-fix
by alirezarezvanifocused-fix is a Claude skill for deep feature or module repair. Use it when an area is broken end-to-end and needs scope mapping, dependency tracing, tests, logs, and a repair plan before code edits—not for quick one-line bugs.
This skill scores 70/100, which makes it an acceptable but limited listing candidate. Directory users can understand when to invoke it for systematic feature/module repair, but should expect a self-contained markdown workflow rather than a packaged skill with supporting files, examples, or installation guidance.
- Strong triggerability: the frontmatter and “When to Use” section explicitly name prompts like “make X work,” “fix the Y feature,” and “focus on [area].”
- Clear scope boundary: it distinguishes feature/module repair from quick single-bug fixes and emphasizes tracing dependencies, logs, and tests.
- Substantial SKILL.md content with multiple headings and constraints suggests more operational guidance than a minimal prompt.
- No support files, README, install command, scripts, references, or resources are present, so adoption relies entirely on the single SKILL.md.
- The skill references an alternative “systematic-debugging” workflow and contains placeholder markers, but the provided evidence does not show companion materials or concrete examples.
Overview of focused-fix skill
What focused-fix is for
focused-fix is an engineering skill for systematic feature repair. Use it when a whole feature, module, route, workflow, or integration is broken and you need the agent to trace the full boundary before changing code. It is designed for Debugging work where “fix the login flow” or “make billing exports work” is too broad for a single bug prompt but still needs a focused repair plan.
Best-fit users and situations
The focused-fix skill is most useful for developers, tech leads, and AI coding agents working inside an existing codebase. It fits tasks such as repairing a failing feature end-to-end, restoring a broken module after refactors, checking every dependency of a workflow, or making a partially implemented area production-ready. It is less useful for greenfield feature design, quick syntax errors, or isolated one-line defects.
What makes the workflow different
The core differentiator is its “scope before fixes” discipline. Instead of jumping from symptom to patch, focused-fix pushes the agent to map the feature boundary, inspect dependent files, understand tests and logs, then repair the feature as a connected system. That matters when the visible error is only one symptom of a deeper mismatch between UI, API, state, database, configuration, and tests.
Adoption cautions before install
Install focused-fix if you want slower but more complete repair behavior. Do not install it expecting a lightweight debugging shortcut. The upstream skill is concentrated in SKILL.md and does not appear to ship helper scripts, reference packs, or extra rule files, so its value comes from the protocol quality rather than tooling around it.
How to Use focused-fix skill
focused-fix install and repository check
Install the skill in a compatible Claude Skills setup with:
npx skills add alirezarezvani/claude-skills --skill focused-fix
After install, read the source at engineering/skills/focused-fix/SKILL.md first. The repository preview shows this skill is primarily self-contained, so there are no major support folders to inspect before use. If your skill runner exposes installed skill metadata, confirm the description still mentions feature/module repair and not quick single-bug debugging.
Inputs the skill needs to work well
A weak prompt is: “Fix checkout.” A useful focused-fix usage prompt names the feature boundary, the expected behavior, the observed failure, relevant commands, and files or logs already known.
Example:
Use focused-fix for Debugging the checkout flow. Expected: guest users can add an item, enter shipping, pay with Stripe test card, and see an order confirmation. Actual: payment succeeds in Stripe but no order appears in the app. Start with
apps/web/src/checkout,apps/api/src/orders,packages/payments, and the failing testcheckout.e2e.ts. Do not patch until you have mapped the full flow and identified every dependent file.
This gives the skill enough scope to avoid random edits while still keeping the repair bounded.
Suggested focused-fix workflow
Use focused-fix when the task deserves a deep pass:
- State the feature or module to repair.
- Define “working” in observable terms: tests pass, user path completes, API returns expected data, logs stop showing a known error.
- Ask the agent to map the feature boundary before editing.
- Provide test commands, reproduction steps, recent refactors, and known risky files.
- Require a short repair plan before code changes.
- After changes, ask for validation evidence: tests run, logs checked, manual path verified, or remaining gaps listed.
This workflow matches the skill’s intent: complete the investigation before committing to a fix.
Prompt pattern for stronger results
Use this pattern when calling the focused-fix skill:
Use focused-fix on [feature/module].
Goal: [what must work end-to-end].
Current failure: [symptoms, errors, logs, failing tests].
Scope hints: [directories, services, routes, configs, data models].
Constraints: [do not change public API, preserve backward compatibility, avoid migrations, etc.].
Validation: [commands or manual checks that prove the feature works].
Before editing: map the boundary and explain likely dependency points.
The constraint and validation lines are especially important. They stop the agent from “fixing” the symptom by changing behavior you actually need to preserve.
focused-fix skill FAQ
Is focused-fix only for debugging?
It is mainly a focused-fix for Debugging and repair skill, but the target is broader than a single stack trace. Use it for a broken feature area that needs dependency tracing. If you already know the exact failing line and the change is obvious, a normal coding prompt or a smaller systematic debugging skill may be faster.
How is focused-fix different from an ordinary prompt?
An ordinary prompt often optimizes for a quick patch. The focused-fix skill biases the agent toward investigation order: define scope, inspect related files, understand dependencies, then fix. That reduces the chance of partial repairs where the immediate test passes but another part of the feature remains broken.
Is focused-fix beginner-friendly?
Yes, if you can describe the broken feature and run validation commands. Beginners may benefit from its structured approach because it asks the agent to explain the feature boundary before changing code. However, you still need to review edits carefully, especially in areas involving authentication, payments, data migration, permissions, or production configuration.
When should I not use focused-fix?
Avoid focused-fix for tiny defects, formatting fixes, dependency upgrades, broad architecture redesigns, or vague requests like “improve the app.” It also performs poorly when you cannot provide a reproducible failure, expected behavior, or access to enough repository context. The skill is strongest when the problem is bounded but internally connected.
How to Improve focused-fix skill
Improve focused-fix inputs before the first run
The best way to improve focused-fix results is to provide richer boundaries. Include user journey steps, API endpoints, background jobs, database tables, feature flags, environment variables, and test names when relevant. If you know a recent merge or refactor likely caused the breakage, say so. This helps the agent inspect the right dependency graph instead of scanning the whole repository.
Watch for common failure modes
Common failure modes include scope creep, premature edits, overfitting to one failing test, and ignoring hidden dependencies such as configuration, seed data, permissions, queues, or client/server type mismatches. If the agent starts patching before mapping the feature, interrupt and restate: “Complete the scope map first; no fixes until the full path is understood.”
Iterate after the first repair
After the first output, do not stop at “tests pass.” Ask for a concise change summary, files touched, validation performed, and remaining risks. Then run your own checks and feed back any new error exactly as observed. focused-fix works best as a loop: scope, repair, validate, tighten scope, repair again only if evidence shows a remaining failure.
Add project-specific guidance
For repeated use, pair focused-fix with local repository instructions. Add notes such as preferred test commands, code ownership boundaries, logging conventions, forbidden shortcuts, and release-risk areas. For example: “Do not bypass permission checks to make the admin panel pass,” or “Use existing service methods rather than direct database writes.” This turns the general focused-fix guide into a safer repair workflow for your codebase.