Focused Fix
Systematically repair an entire feature or module end-to-end—dependencies, logs, and tests—when “make X work” is bigger than one bug.
Overview
focused-fix is an agent skill most often used in Ship (also Build integrations, Operate errors) that systematically repairs a whole feature or module across dependencies, logs, and tests.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill focused-fixWhat is this skill?
- Explicit trigger map: “make X work”, “fix the Y feature”, “Z module is broken”, “focus on [area]”
- Decision guide: single symptom → systematic-debugging; whole feature/module → focused-fix
- Deep-dive scope: trace dependencies, read logs, check tests, map the dependency graph
- End-to-end ownership of one feature area across all related files
- Contrasts with quick single-bug fixes in skill documentation
Adoption & trust: 525 installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
A named feature or module fails holistically and scattered one-off fixes have not made the user journey actually work.
Who is it for?
When an entire capability—auth, billing, sync, or an agent tool surface—needs to work reliably and you can name the area to focus on.
Skip if: Quick single-bug or single-symptom fixes; the skill directs those to systematic-debugging instead.
When should I use this skill?
User asks to fix, debug, or make a specific feature/module/area work end-to-end—triggers include “make X work”, “fix the Y feature”, “the Z module is broken”, “focus on [area]”.
What do I get? / Deliverables
The feature area is traced across its dependency graph, failures are correlated with logs and tests, and repairs are applied coherently until the end-to-end path works.
- Dependency-aware fix plan and code changes for the scoped feature
- Updated or passing tests for the repaired module path
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Focused repair is shelved under Ship because it assumes an integrated product area that must pass real flows before release, not greenfield scaffolding. Testing subphase fits full feature verification across files, test suites, and dependency graphs rather than a single hotfix.
Where it fits
Checkout E2E fails across API, UI, and webhooks—agent maps the graph and fixes until the full purchase path passes tests.
A sync module never reliably pulls third-party data; focused-fix traces jobs, credentials handling, and retries together.
A feature regressed in production across multiple services; repair is scoped to that module with log-backed hypotheses.
“Make notifications work” requires aligning queue workers, templates, and API triggers—not patching one handler.
How it compares
Use for module-scale repair instead of systematic-debugging’s single-incident loop when the whole feature is the unit of work.
Common Questions / FAQ
Who is focused-fix for?
Solo builders maintaining multi-file features who need an agent to own a broad repair pass without losing context across dependencies and tests.
When should I use focused-fix?
In Ship when E2E flows for one feature fail across services; in Build when an integrations module never worked end-to-end; in Operate when a production feature regressed across several touchpoints—not for one isolated error.
Is focused-fix safe to install?
Expect normal dev permissions in your repo when the agent runs tests and reads logs; review the Security Audits panel on this Prism page before install.
SKILL.md
READMESKILL.md - Focused Fix
# Focused Fix — Deep-Dive Feature Repair ## When to Use Activate when the user asks to fix, debug, or make a specific feature/module/area work. Key triggers: - "make X work" - "fix the Y feature" - "the Z module is broken" - "focus on [area]" - "this feature needs to work properly" This is NOT for quick single-bug fixes (use systematic-debugging for that). This is for when an entire feature or module needs systematic repair — tracing every dependency, reading logs, checking tests, mapping the full dependency graph. ```dot digraph when_to_use { "User reports feature broken" [shape=diamond]; "Single bug or symptom?" [shape=diamond]; "Use systematic-debugging" [shape=box]; "Entire feature/module needs repair?" [shape=diamond]; "Use focused-fix" [shape=box]; "Something else" [shape=box]; "User reports feature broken" -> "Single bug or symptom?"; "Single bug or symptom?" -> "Use systematic-debugging" [label="yes"]; "Single bug or symptom?" -> "Entire feature/module needs repair?" [label="no"]; "Entire feature/module needs repair?" -> "Use focused-fix" [label="yes"]; "Entire feature/module needs repair?" -> "Something else" [label="no"]; } ``` ## The Iron Law ``` NO FIXES WITHOUT COMPLETING SCOPE → TRACE → DIAGNOSE FIRST ``` If you haven't finished Phase 3, you cannot propose fixes. Period. **Violating the letter of these phases is violating the spirit of focused repair.** ## Protocol — STRICTLY follow these 5 phases IN ORDER ```dot digraph phases { rankdir=LR; SCOPE [shape=box, label="Phase 1\nSCOPE"]; TRACE [shape=box, label="Phase 2\nTRACE"]; DIAGNOSE [shape=box, label="Phase 3\nDIAGNOSE"]; FIX [shape=box, label="Phase 4\nFIX"]; VERIFY [shape=box, label="Phase 5\nVERIFY"]; SCOPE -> TRACE -> DIAGNOSE -> FIX -> VERIFY; FIX -> DIAGNOSE [label="fix broke\nsomething else"]; FIX -> ESCALATE [label="3+ fixes\ncreate new issues"]; ESCALATE [shape=doubleoctagon, label="STOP\nQuestion Architecture\nDiscuss with User"]; } ``` ### Phase 1: SCOPE — Map the Feature Boundary Before touching any code, understand the full scope of the feature. 1. Ask the user: "Which feature/folder should I focus on?" if not already clear 2. Identify the PRIMARY folder/files for this feature 3. Map EVERY file in that folder — read each one, understand its purpose 4. Create a feature manifest: ``` FEATURE SCOPE: Primary path: src/features/auth/ Entry points: [files that are imported by other parts of the app] Internal files: [files only used within this feature] Total files: N Total lines: N ``` ### Phase 2: TRACE — Map All Dependencies (Inside AND Outside) Trace every connection this feature has to the rest of the codebase. **INBOUND (what this feature imports):** 1. For every import statement in every file in the feature folder: - Trace it to its source - Verify the source file exists - Verify the imported entity (function, type, component) exists and is exported - Check if the types/signatures match what the feature expects 2. Check for: - Environment variables used (grep for process.env, import.meta.env, os.environ, etc.) - Config files referenced - Database models/schemas used - API endpoints called - Third-party packages imported **OUTBOUND (what imports this feature):** 1. Search the entire codebase for imports from this feature folder 2. For each consumer: - Verify they're importing entities that actually exist - Check if they're using the correct API/interface - Note if any consumers are using deprecated patterns Output format: ``` DEPENDENCY MAP: Inbound (this feature depen