[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KBCEJ0XRJCFW283XQKMNXT":3,"skill-same:01M6KBCEJ0XRJCFW283XQKMNXT":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":6,"updatedAt":56,"install":57,"resources":70},"01M6KBCEJ0XRJCFW283XQKMNXT","focused-fix",null,"Use when the user asks to fix, debug, or make a specific feature\u002Fmodule\u002Farea work end-to-end. Triggers: 'make X work', 'fix the Y feature', 'the Z module is broken', 'focus on [area]'. Not for quick single-bug fixes — this is for systematic deep-dive repair across all files and dependencies.","afaizalam2003\u002FMaster-claude-skill","afaizalam2003","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F222019359?v=4","01M6K8F2XNT0HKBPF00JQ78SV3","Faiz Alam","01M6K8F31EBXAPER0EG8R9HTR5",3,"MIT","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Ffocused-fix\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"fix","focused fix","deep","fixes","for","quick","make","systematic","module","triggers","end","feature","work","across","repair","focus","files","bug","use","broken","2026-11-10 10:12:30",false,"---\nname: \"focused-fix\"\ndescription: \"Use when the user asks to fix, debug, or make a specific feature\u002Fmodule\u002Farea work end-to-end. Triggers: 'make X work', 'fix the Y feature', 'the Z module is broken', 'focus on [area]'. Not for quick single-bug fixes — this is for systematic deep-dive repair across all files and dependencies.\"\n---\n\n# Focused Fix — Deep-Dive Feature Repair\n\n## When to Use\n\nActivate when the user asks to fix, debug, or make a specific feature\u002Fmodule\u002Farea work. Key triggers:\n- \"make X work\"\n- \"fix the Y feature\"\n- \"the Z module is broken\"\n- \"focus on [area]\"\n- \"this feature needs to work properly\"\n\nThis 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.\n\n```dot\ndigraph when_to_use {\n    \"User reports feature broken\" [shape=diamond];\n    \"Single bug or symptom?\" [shape=diamond];\n    \"Use systematic-debugging\" [shape=box];\n    \"Entire feature\u002Fmodule needs repair?\" [shape=diamond];\n    \"Use focused-fix\" [shape=box];\n    \"Something else\" [shape=box];\n\n    \"User reports feature broken\" -> \"Single bug or symptom?\";\n    \"Single bug or symptom?\" -> \"Use systematic-debugging\" [label=\"yes\"];\n    \"Single bug or symptom?\" -> \"Entire feature\u002Fmodule needs repair?\" [label=\"no\"];\n    \"Entire feature\u002Fmodule needs repair?\" -> \"Use focused-fix\" [label=\"yes\"];\n    \"Entire feature\u002Fmodule needs repair?\" -> \"Something else\" [label=\"no\"];\n}\n```\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT COMPLETING SCOPE → TRACE → DIAGNOSE FIRST\n```\n\nIf you haven't finished Phase 3, you cannot propose fixes. Period.\n\n**Violating the letter of these phases is violating the spirit of focused repair.**\n\n## Protocol — STRICTLY follow these 5 phases IN ORDER\n\n```dot\ndigraph phases {\n    rankdir=LR;\n    SCOPE [shape=box, label=\"Phase 1\\nSCOPE\"];\n    TRACE [shape=box, label=\"Phase 2\\nTRACE\"];\n    DIAGNOSE [shape=box, label=\"Phase 3\\nDIAGNOSE\"];\n    FIX [shape=box, label=\"Phase 4\\nFIX\"];\n    VERIFY [shape=box, label=\"Phase 5\\nVERIFY\"];\n\n    SCOPE -> TRACE -> DIAGNOSE -> FIX -> VERIFY;\n    FIX -> DIAGNOSE [label=\"fix broke\\nsomething else\"];\n    FIX -> ESCALATE [label=\"3+ fixes\\ncreate new issues\"];\n    ESCALATE [shape=doubleoctagon, label=\"STOP\\nQuestion Architecture\\nDiscuss with User\"];\n}\n```\n\n### Phase 1: SCOPE — Map the Feature Boundary\n\nBefore touching any code, understand the full scope of the feature.\n\n1. Ask the user: \"Which feature\u002Ffolder should I focus on?\" if not already clear\n2. Identify the PRIMARY folder\u002Ffiles for this feature\n3. Map EVERY file in that folder — read each one, understand its purpose\n4. Create a feature manifest:\n\n```\nFEATURE SCOPE:\n  Primary path: src\u002Ffeatures\u002Fauth\u002F\n  Entry points: [files that are imported by other parts of the app]\n  Internal files: [files only used within this feature]\n  Total files: N\n  Total lines: N\n```\n\n### Phase 2: TRACE — Map All Dependencies (Inside AND Outside)\n\nTrace every connection this feature has to the rest of the codebase.\n\n**INBOUND (what this feature imports):**\n1. For every import statement in every file in the feature folder:\n   - Trace it to its source\n   - Verify the source file exists\n   - Verify the imported entity (function, type, component) exists and is exported\n   - Check if the types\u002Fsignatures match what the feature expects\n2. Check for:\n   - Environment variables used (grep for process.env, import.meta.env, os.environ, etc.)\n   - Config files referenced\n   - Database models\u002Fschemas used\n   - API endpoints called\n   - Third-party packages imported\n\n**OUTBOUND (what imports this feature):**\n1. Search the entire codebase for imports from this feature folder\n2. For each consumer:\n   - Verify they're importing entities that actually exist\n   - Check if they're using the correct API\u002Finterface\n   - Note if any consumers are using deprecated patterns\n\nOutput format:\n```\nDEPENDENCY MAP:\n  Inbound (this feature depends on):\n    src\u002Flib\u002Fdb.ts → used in auth\u002Frepository.ts (getUserById, createUser)\n    src\u002Flib\u002Fjwt.ts → used in auth\u002Fservice.ts (signToken, verifyToken)\n    @prisma\u002Fclient → used in auth\u002Frepository.ts\n    process.env.JWT_SECRET → used in auth\u002Fservice.ts\n    process.env.DATABASE_URL → used via prisma\n\n  Outbound (depends on this feature):\n    src\u002Fapp\u002Fapi\u002Flogin\u002Froute.ts → imports { login } from auth\u002Fservice\n    src\u002Fapp\u002Fapi\u002Fregister\u002Froute.ts → imports { register } from auth\u002Fservice\n    src\u002Fmiddleware.ts → imports { verifyToken } from auth\u002Fservice\n\n  Env vars required: JWT_SECRET, DATABASE_URL\n  Config files: prisma\u002Fschema.prisma (User model)\n```\n\n### Phase 3: DIAGNOSE — Find Every Issue\n\nSystematically check for problems. Run ALL of these checks:\n\n**CODE QUALITY:**\n- [ ] Every import resolves to a real file\u002Fexport\n- [ ] No circular dependencies within the feature\n- [ ] Types are consistent across boundaries (no `any` at interfaces)\n- [ ] Error handling exists for all async operations\n- [ ] No TODO\u002FFIXME\u002FHACK comments indicating known issues\n\n**RUNTIME:**\n- [ ] All required environment variables are set (check .env)\n- [ ] Database migrations are up to date (if applicable)\n- [ ] API endpoints return expected shapes\n- [ ] No hardcoded values that should be configurable\n\n**TESTS:**\n- [ ] Run ALL tests related to this feature: find them by searching for imports from the feature folder\n- [ ] Record every failure with full error output\n- [ ] Check test coverage — are there untested code paths?\n\n**LOGS & ERRORS:**\n- [ ] Search for any log files, error reports, or Sentry-style error tracking\n- [ ] Check git log for recent changes to this feature: `git log --oneline -20 -- \u003Cfeature-path>`\n- [ ] Check if any recent commits might have broken something: `git log --oneline -5 --all -- \u003Cfiles that this feature depends on>`\n\n**CONFIGURATION:**\n- [ ] Verify all config files this feature depends on are valid\n- [ ] Check for mismatches between development and production configs\n- [ ] Verify third-party service credentials are valid (if testable)\n\n**ROOT-CAUSE CONFIRMATION:**\nFor each CRITICAL issue found, confirm root cause before adding it to the fix list:\n- State clearly: \"I think X is the root cause because Y\"\n- Trace the data\u002Fcontrol flow backward to verify — don't trust surface-level symptoms\n- If the issue spans multiple components, add diagnostic logging at each boundary to identify which layer fails\n- **REQUIRED SUB-SKILL:** For complex bugs found during diagnosis, apply `superpowers:systematic-debugging` Phase 1 (Root Cause Investigation) to confirm before proceeding\n\n**RISK LABELING:**\nAssign each issue a risk label:\n\n| Risk | Criteria |\n|---|---|\n| HIGH | Public API surface \u002F breaking interface contract \u002F DB schema \u002F auth or security logic \u002F widely imported module (>3 callers) \u002F git hotspot |\n| MED | Internal module with tests \u002F shared utility \u002F config with runtime impact \u002F internal callers of changed functions |\n| LOW | Leaf module \u002F isolated file \u002F test-only change \u002F single-purpose helper with no callers |\n\nOutput format:\n```\nDIAGNOSIS REPORT:\n  Issues found: N\n\n  CRITICAL:\n    1. [HIGH] [file:line] — description of issue. Root cause: [confirmed explanation]\n    2. [HIGH] [file:line] — description of issue. Root cause: [confirmed explanation]\n\n  WARNINGS:\n    1. [MED] [file:line] — description of issue\n    2. [LOW] [file:line] — description of issue\n\n  TESTS:\n    Ran: N tests\n    Passed: N\n    Failed: N\n    [list each failure with one-line summary]\n```\n\n### Phase 4: FIX — Repair Everything Systematically\n\nFix issues in this EXACT order:\n\n1. **DEPENDENCIES FIRST** — fix broken imports, missing packages, wrong versions\n2. **TYPES SECOND** — fix type mismatches at feature boundaries\n3. **LOGIC THIRD** — fix actual business logic bugs\n4. **TESTS FOURTH** — fix or create tests for each fix\n5. **INTEGRATION LAST** — verify the feature works end-to-end with its consumers\n\nRules:\n- Fix ONE issue at a time\n- After each fix, run the related test to confirm it works\n- If a fix breaks something else, STOP and re-evaluate (go back to DIAGNOSE)\n- Keep a running log of every change made\n- Never change code outside the feature folder without explicitly stating why\n- Fix HIGH-risk issues before MED, MED before LOW\n\n**ESCALATION RULE — 3-Strike Architecture Check:**\nIf 3+ fixes in this phase create NEW issues (not pre-existing ones), STOP immediately.\n\nThis pattern indicates an architectural problem, not a bug collection:\n- Each fix reveals new shared state \u002F coupling \u002F problem in a different place\n- Fixes require \"massive refactoring\" to implement\n- Each fix creates new symptoms elsewhere\n\n**Action:** Stop fixing. Tell the user: \"3+ fixes have cascaded into new issues. This suggests the feature's architecture may need rethinking, not patching. Here's what I've found: [summary]. Should we continue fixing symptoms or discuss restructuring?\"\n\nDo NOT attempt fix #4 without this discussion.\n\nOutput after each fix:\n```\nFIX #1:\n  File: auth\u002Fservice.ts:45\n  Issue: signToken called with wrong argument order\n  Change: swapped (expiresIn, payload) to (payload, expiresIn)\n  Test: auth.test.ts → PASSES\n```\n\n### Phase 5: VERIFY — Confirm Everything Works\n\nAfter all fixes are applied:\n\n1. Run ALL tests in the feature folder — every single one must pass\n2. Run ALL tests in files that IMPORT from this feature — must pass\n3. Run the full test suite if available — check for regressions\n4. If the feature has a UI, describe how to manually verify it\n5. Summarize all changes made\n\nFinal output:\n```\nFOCUSED FIX COMPLETE:\n  Feature: auth\n  Files changed: 4\n  Total fixes: 7\n  Tests: 23\u002F23 passing\n  Regressions: 0\n\n  Changes:\n    1. auth\u002Fservice.ts — fixed token signing argument order\n    2. auth\u002Frepository.ts — added null check for user lookup\n    3. auth\u002Fmiddleware.ts — fixed async error handling\n    4. auth\u002Ftypes.ts — aligned UserResponse type with actual DB schema\n\n  Consumers verified:\n    - src\u002Fapp\u002Fapi\u002Flogin\u002Froute.ts ✅\n    - src\u002Fapp\u002Fapi\u002Fregister\u002Froute.ts ✅\n    - src\u002Fmiddleware.ts ✅\n```\n\n## Red Flags — STOP and Return to Current Phase\n\nIf you catch yourself thinking any of these, you are skipping phases:\n\n- \"I can see the bug, let me just fix it\" → STOP. You haven't traced dependencies yet.\n- \"Scoping is overkill, it's obviously just this file\" → STOP. That's always wrong for feature-level fixes.\n- \"I'll map dependencies after I fix the obvious stuff\" → STOP. You'll miss root causes.\n- \"The user said fix X, so I only need to look at X\" → STOP. Features have dependencies.\n- \"Tests are passing so I'm done\" → STOP. Did you run consumer tests too?\n- \"I don't need to check env vars for this\" → STOP. Config issues masquerade as code bugs.\n- \"One more fix should do it\" (after 2+ cascading failures) → STOP. Escalate.\n- \"I'll skip the diagnosis report, the fixes are obvious\" → STOP. Write it down.\n\n**ALL of these mean: Return to the phase you're supposed to be in.**\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|---|---|\n| \"The feature is small, I don't need all 5 phases\" | Small features have dependencies too. Phases 1-2 take minutes for small features — do them. |\n| \"I already know this codebase\" | Knowledge decays. Trace the actual imports, don't rely on memory. |\n| \"The user wants speed, not process\" | Skipping phases causes rework. Systematic is faster than thrashing. |\n| \"Only one file is broken\" | If only one file were broken, the user would say \"fix this bug\", not \"make the feature work.\" |\n| \"I fixed the tests, so it works\" | Tests can pass while consumers are broken. Verify Phase 5 fully. |\n| \"The dependency map is too big to trace\" | Then the feature is too big to fix without tracing. That's exactly why you need it. |\n| \"Root cause is obvious, I don't need to confirm\" | \"Obvious\" root causes are wrong 40% of the time. Confirm with evidence. |\n| \"3 cascading failures is normal for a big fix\" | 3 cascading failures means you're patching symptoms of an architectural problem. |\n\n## Anti-Patterns — NEVER do these\n\n| Anti-Pattern | Why It's Wrong |\n|---|---|\n| Starting to fix code before mapping all dependencies | You'll miss root causes and create whack-a-mole fixes |\n| Fixing only the file the user mentioned | Related files likely have issues too |\n| Ignoring environment variables and configuration | Many \"code bugs\" are actually config issues |\n| Skipping the test run phase | You can't verify fixes without running tests |\n| Making changes outside the feature folder without explaining why | Unexpected side effects confuse the user |\n| Fixing symptoms in consumer files instead of root cause in feature | Band-aids that break when the next consumer appears |\n| Declaring \"done\" without running verification tests | Untested fixes are unverified fixes |\n| Changing the public API without updating all consumers | Breaks everything that depends on the feature |\n\n## Related Skills\n\n- **`superpowers:systematic-debugging`** — Use within Phase 3 for root-cause tracing of individual complex bugs\n- **`superpowers:verification-before-completion`** — Use within Phase 5 before claiming the feature is fixed\n- **`scope`** — If you need to understand blast radius before starting, run scope first then focused-fix\n\n## Quick Reference\n\n| Phase | Key Action | Output |\n|---|---|---|\n| SCOPE | Read every file, map entry points | Feature manifest |\n| TRACE | Map inbound + outbound dependencies | Dependency map |\n| DIAGNOSE | Check code, runtime, tests, logs, config | Diagnosis report |\n| FIX | Fix in order: deps → types → logic → tests → integration | Fix log per issue |\n| VERIFY | Run all tests, check consumers, summarize | Completion report |\n","# Focused Fix — Deep-Dive Feature Repair\n\n## When to Use\n\nActivate when the user asks to fix, debug, or make a specific feature\u002Fmodule\u002Farea work. Key triggers:\n- \"make X work\"\n- \"fix the Y feature\"\n- \"the Z module is broken\"\n- \"focus on [area]\"\n- \"this feature needs to work properly\"\n\nThis 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.\n\n```dot\ndigraph when_to_use {\n    \"User reports feature broken\" [shape=diamond];\n    \"Single bug or symptom?\" [shape=diamond];\n    \"Use systematic-debugging\" [shape=box];\n    \"Entire feature\u002Fmodule needs repair?\" [shape=diamond];\n    \"Use focused-fix\" [shape=box];\n    \"Something else\" [shape=box];\n\n    \"User reports feature broken\" -> \"Single bug or symptom?\";\n    \"Single bug or symptom?\" -> \"Use systematic-debugging\" [label=\"yes\"];\n    \"Single bug or symptom?\" -> \"Entire feature\u002Fmodule needs repair?\" [label=\"no\"];\n    \"Entire feature\u002Fmodule needs repair?\" -> \"Use focused-fix\" [label=\"yes\"];\n    \"Entire feature\u002Fmodule needs repair?\" -> \"Something else\" [label=\"no\"];\n}\n```\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT COMPLETING SCOPE → TRACE → DIAGNOSE FIRST\n```\n\nIf you haven't finished Phase 3, you cannot propose fixes. Period.\n\n**Violating the letter of these phases is violating the spirit of focused repair.**\n\n## Protocol — STRICTLY follow these 5 phases IN ORDER\n\n```dot\ndigraph phases {\n    rankdir=LR;\n    SCOPE [shape=box, label=\"Phase 1\\nSCOPE\"];\n    TRACE [shape=box, label=\"Phase 2\\nTRACE\"];\n    DIAGNOSE [shape=box, label=\"Phase 3\\nDIAGNOSE\"];\n    FIX [shape=box, label=\"Phase 4\\nFIX\"];\n    VERIFY [shape=box, label=\"Phase 5\\nVERIFY\"];\n\n    SCOPE -> TRACE -> DIAGNOSE -> FIX -> VERIFY;\n    FIX -> DIAGNOSE [label=\"fix broke\\nsomething else\"];\n    FIX -> ESCALATE [label=\"3+ fixes\\ncreate new issues\"];\n    ESCALATE [shape=doubleoctagon, label=\"STOP\\nQuestion Architecture\\nDiscuss with User\"];\n}\n```\n\n### Phase 1: SCOPE — Map the Feature Boundary\n\nBefore touching any code, understand the full scope of the feature.\n\n1. Ask the user: \"Which feature\u002Ffolder should I focus on?\" if not already clear\n2. Identify the PRIMARY folder\u002Ffiles for this feature\n3. Map EVERY file in that folder — read each one, understand its purpose\n4. Create a feature manifest:\n\n```\nFEATURE SCOPE:\n  Primary path: src\u002Ffeatures\u002Fauth\u002F\n  Entry points: [files that are imported by other parts of the app]\n  Internal files: [files only used within this feature]\n  Total files: N\n  Total lines: N\n```\n\n### Phase 2: TRACE — Map All Dependencies (Inside AND Outside)\n\nTrace every connection this feature has to the rest of the codebase.\n\n**INBOUND (what this feature imports):**\n1. For every import statement in every file in the feature folder:\n   - Trace it to its source\n   - Verify the source file exists\n   - Verify the imported entity (function, type, component) exists and is exported\n   - Check if the types\u002Fsignatures match what the feature expects\n2. Check for:\n   - Environment variables used (grep for process.env, import.meta.env, os.environ, etc.)\n   - Config files referenced\n   - Database models\u002Fschemas used\n   - API endpoints called\n   - Third-party packages imported\n\n**OUTBOUND (what imports this feature):**\n1. Search the entire codebase for imports from this feature folder\n2. For each consumer:\n   - Verify they're importing entities that actually exist\n   - Check if they're using the correct API\u002Finterface\n   - Note if any consumers are using deprecated patterns\n\nOutput format:\n```\nDEPENDENCY MAP:\n  Inbound (this feature depends on):\n    src\u002Flib\u002Fdb.ts → used in auth\u002Frepository.ts (getUserById, createUser)\n    src\u002Flib\u002Fjwt.ts → used in auth\u002Fservice.ts (signToken, verifyToken)\n    @prisma\u002Fclient → used in auth\u002Frepository.ts\n    process.env.JWT_SECRET → used in auth\u002Fservice.ts\n    process.env.DATABASE_URL → used via prisma\n\n  Outbound (depends on this feature):\n    src\u002Fapp\u002Fapi\u002Flogin\u002Froute.ts → imports { login } from auth\u002Fservice\n    src\u002Fapp\u002Fapi\u002Fregister\u002Froute.ts → imports { register } from auth\u002Fservice\n    src\u002Fmiddleware.ts → imports { verifyToken } from auth\u002Fservice\n\n  Env vars required: JWT_SECRET, DATABASE_URL\n  Config files: prisma\u002Fschema.prisma (User model)\n```\n\n### Phase 3: DIAGNOSE — Find Every Issue\n\nSystematically check for problems. Run ALL of these checks:\n\n**CODE QUALITY:**\n- [ ] Every import resolves to a real file\u002Fexport\n- [ ] No circular dependencies within the feature\n- [ ] Types are consistent across boundaries (no `any` at interfaces)\n- [ ] Error handling exists for all async operations\n- [ ] No TODO\u002FFIXME\u002FHACK comments indicating known issues\n\n**RUNTIME:**\n- [ ] All required environment variables are set (check .env)\n- [ ] Database migrations are up to date (if applicable)\n- [ ] API endpoints return expected shapes\n- [ ] No hardcoded values that should be configurable\n\n**TESTS:**\n- [ ] Run ALL tests related to this feature: find them by searching for imports from the feature folder\n- [ ] Record every failure with full error output\n- [ ] Check test coverage — are there untested code paths?\n\n**LOGS & ERRORS:**\n- [ ] Search for any log files, error reports, or Sentry-style error tracking\n- [ ] Check git log for recent changes to this feature: `git log --oneline -20 -- \u003Cfeature-path>`\n- [ ] Check if any recent commits might have broken something: `git log --oneline -5 --all -- \u003Cfiles that this feature depends on>`\n\n**CONFIGURATION:**\n- [ ] Verify all config files this feature depends on are valid\n- [ ] Check for mismatches between development and production configs\n- [ ] Verify third-party service credentials are valid (if testable)\n\n**ROOT-CAUSE CONFIRMATION:**\nFor each CRITICAL issue found, confirm root cause before adding it to the fix list:\n- State clearly: \"I think X is the root cause because Y\"\n- Trace the data\u002Fcontrol flow backward to verify — don't trust surface-level symptoms\n- If the issue spans multiple components, add diagnostic logging at each boundary to identify which layer fails\n- **REQUIRED SUB-SKILL:** For complex bugs found during diagnosis, apply `superpowers:systematic-debugging` Phase 1 (Root Cause Investigation) to confirm before proceeding\n\n**RISK LABELING:**\nAssign each issue a risk label:\n\n| Risk | Criteria |\n|---|---|\n| HIGH | Public API surface \u002F breaking interface contract \u002F DB schema \u002F auth or security logic \u002F widely imported module (>3 callers) \u002F git hotspot |\n| MED | Internal module with tests \u002F shared utility \u002F config with runtime impact \u002F internal callers of changed functions |\n| LOW | Leaf module \u002F isolated file \u002F test-only change \u002F single-purpose helper with no callers |\n\nOutput format:\n```\nDIAGNOSIS REPORT:\n  Issues found: N\n\n  CRITICAL:\n    1. [HIGH] [file:line] — description of issue. Root cause: [confirmed explanation]\n    2. [HIGH] [file:line] — description of issue. Root cause: [confirmed explanation]\n\n  WARNINGS:\n    1. [MED] [file:line] — description of issue\n    2. [LOW] [file:line] — description of issue\n\n  TESTS:\n    Ran: N tests\n    Passed: N\n    Failed: N\n    [list each failure with one-line summary]\n```\n\n### Phase 4: FIX — Repair Everything Systematically\n\nFix issues in this EXACT order:\n\n1. **DEPENDENCIES FIRST** — fix broken imports, missing packages, wrong versions\n2. **TYPES SECOND** — fix type mismatches at feature boundaries\n3. **LOGIC THIRD** — fix actual business logic bugs\n4. **TESTS FOURTH** — fix or create tests for each fix\n5. **INTEGRATION LAST** — verify the feature works end-to-end with its consumers\n\nRules:\n- Fix ONE issue at a time\n- After each fix, run the related test to confirm it works\n- If a fix breaks something else, STOP and re-evaluate (go back to DIAGNOSE)\n- Keep a running log of every change made\n- Never change code outside the feature folder without explicitly stating why\n- Fix HIGH-risk issues before MED, MED before LOW\n\n**ESCALATION RULE — 3-Strike Architecture Check:**\nIf 3+ fixes in this phase create NEW issues (not pre-existing ones), STOP immediately.\n\nThis pattern indicates an architectural problem, not a bug collection:\n- Each fix reveals new shared state \u002F coupling \u002F problem in a different place\n- Fixes require \"massive refactoring\" to implement\n- Each fix creates new symptoms elsewhere\n\n**Action:** Stop fixing. Tell the user: \"3+ fixes have cascaded into new issues. This suggests the feature's architecture may need rethinking, not patching. Here's what I've found: [summary]. Should we continue fixing symptoms or discuss restructuring?\"\n\nDo NOT attempt fix #4 without this discussion.\n\nOutput after each fix:\n```\nFIX #1:\n  File: auth\u002Fservice.ts:45\n  Issue: signToken called with wrong argument order\n  Change: swapped (expiresIn, payload) to (payload, expiresIn)\n  Test: auth.test.ts → PASSES\n```\n\n### Phase 5: VERIFY — Confirm Everything Works\n\nAfter all fixes are applied:\n\n1. Run ALL tests in the feature folder — every single one must pass\n2. Run ALL tests in files that IMPORT from this feature — must pass\n3. Run the full test suite if available — check for regressions\n4. If the feature has a UI, describe how to manually verify it\n5. Summarize all changes made\n\nFinal output:\n```\nFOCUSED FIX COMPLETE:\n  Feature: auth\n  Files changed: 4\n  Total fixes: 7\n  Tests: 23\u002F23 passing\n  Regressions: 0\n\n  Changes:\n    1. auth\u002Fservice.ts — fixed token signing argument order\n    2. auth\u002Frepository.ts — added null check for user lookup\n    3. auth\u002Fmiddleware.ts — fixed async error handling\n    4. auth\u002Ftypes.ts — aligned UserResponse type with actual DB schema\n\n  Consumers verified:\n    - src\u002Fapp\u002Fapi\u002Flogin\u002Froute.ts ✅\n    - src\u002Fapp\u002Fapi\u002Fregister\u002Froute.ts ✅\n    - src\u002Fmiddleware.ts ✅\n```\n\n## Red Flags — STOP and Return to Current Phase\n\nIf you catch yourself thinking any of these, you are skipping phases:\n\n- \"I can see the bug, let me just fix it\" → STOP. You haven't traced dependencies yet.\n- \"Scoping is overkill, it's obviously just this file\" → STOP. That's always wrong for feature-level fixes.\n- \"I'll map dependencies after I fix the obvious stuff\" → STOP. You'll miss root causes.\n- \"The user said fix X, so I only need to look at X\" → STOP. Features have dependencies.\n- \"Tests are passing so I'm done\" → STOP. Did you run consumer tests too?\n- \"I don't need to check env vars for this\" → STOP. Config issues masquerade as code bugs.\n- \"One more fix should do it\" (after 2+ cascading failures) → STOP. Escalate.\n- \"I'll skip the diagnosis report, the fixes are obvious\" → STOP. Write it down.\n\n**ALL of these mean: Return to the phase you're supposed to be in.**\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|---|---|\n| \"The feature is small, I don't need all 5 phases\" | Small features have dependencies too. Phases 1-2 take minutes for small features — do them. |\n| \"I already know this codebase\" | Knowledge decays. Trace the actual imports, don't rely on memory. |\n| \"The user wants speed, not process\" | Skipping phases causes rework. Systematic is faster than thrashing. |\n| \"Only one file is broken\" | If only one file were broken, the user would say \"fix this bug\", not \"make the feature work.\" |\n| \"I fixed the tests, so it works\" | Tests can pass while consumers are broken. Verify Phase 5 fully. |\n| \"The dependency map is too big to trace\" | Then the feature is too big to fix without tracing. That's exactly why you need it. |\n| \"Root cause is obvious, I don't need to confirm\" | \"Obvious\" root causes are wrong 40% of the time. Confirm with evidence. |\n| \"3 cascading failures is normal for a big fix\" | 3 cascading failures means you're patching symptoms of an architectural problem. |\n\n## Anti-Patterns — NEVER do these\n\n| Anti-Pattern | Why It's Wrong |\n|---|---|\n| Starting to fix code before mapping all dependencies | You'll miss root causes and create whack-a-mole fixes |\n| Fixing only the file the user mentioned | Related files likely have issues too |\n| Ignoring environment variables and configuration | Many \"code bugs\" are actually config issues |\n| Skipping the test run phase | You can't verify fixes without running tests |\n| Making changes outside the feature folder without explaining why | Unexpected side effects confuse the user |\n| Fixing symptoms in consumer files instead of root cause in feature | Band-aids that break when the next consumer appears |\n| Declaring \"done\" without running verification tests | Untested fixes are unverified fixes |\n| Changing the public API without updating all consumers | Breaks everything that depends on the feature |\n\n## Related Skills\n\n- **`superpowers:systematic-debugging`** — Use within Phase 3 for root-cause tracing of individual complex bugs\n- **`superpowers:verification-before-completion`** — Use within Phase 5 before claiming the feature is fixed\n- **`scope`** — If you need to understand blast radius before starting, run scope first then focused-fix\n\n## Quick Reference\n\n| Phase | Key Action | Output |\n|---|---|---|\n| SCOPE | Read every file, map entry points | Feature manifest |\n| TRACE | Map inbound + outbound dependencies | Dependency map |\n| DIAGNOSE | Check code, runtime, tests, logs, config | Diagnosis report |\n| FIX | Fix in order: deps → types → logic → tests → integration | Fix log per issue |\n| VERIFY | Run all tests, check consumers, summarize | Completion report |\n",{"name":5,"description":7},"main","0b48cbb0e6d5be6ff68c0f6b28bc0c65ee21c4a1","engineering\u002Ffocused-fix",2,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill","https:\u002F\u002Fgithub.com\u002Fafaizalam2003","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmdfaizalam2003\u002F","2026-04-01 04:35:43",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add afaizalam2003\u002FMaster-claude-skill --skill focused-fix",{"tool":63,"command":64},"bunx","bunx skills add afaizalam2003\u002FMaster-claude-skill --skill focused-fix",{"tool":66,"command":67},"pnpm","pnpm dlx skills add afaizalam2003\u002FMaster-claude-skill --skill focused-fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Ffocused-fix\u002FSKILL.md",true,[],[72,100,125,150,182,202],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":81,"publishedAt":44},"01M6KC4E8MYR9DBAZTAXHKYMMH","soc2-compliance","Use when the user asks to prepare for SOC 2 audits, map Trust Service Criteria, build control matrices, collect audit evidence, perform gap analysis, or assess SOC 2 Type I vs Type II readiness.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fsoc2-compliance\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务",[82,83,84,85,86,87,88,89,42,90,91,92,93,94,95,96,97,98,99,28],"compliance","soc2","soc2 compliance","audit evidence","audit","collect","soc","analysis","evidence","trust","build","map","control","type","gap","readiness","gap analysis","assess",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":44},"01M6KC461R3GKGZ1TAYHVR1MW9","risk-management-specialist","Medical device risk management specialist implementing ISO 14971 throughout product lifecycle. Provides risk analysis, risk evaluation, risk control, and post-production information analysis. Use when user mentions risk management, ISO 14971, risk analysis, FMEA, fault tree analysis, hazard identification, risk control, risk matrix, benefit-risk analysis, residual risk, risk acceptability, or post-market risk.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Frisk-management-specialist\u002FSKILL.md",[],[107,108,109,110,111,112,113,114,89,42,115,116,117,118,119,120,121,122,123,124],"risk","risk management specialist","management","risk management","risk evaluation","product","Evaluation","lifecycle","risk matrix","iso","medical","iso 14971","identification","information","post-production","tree","matrix","implementing",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":44},"01M6KC3HF5ZFSSP2NZF68PEPFB","regulatory-affairs-head","Senior Regulatory Affairs Manager for HealthTech and MedTech companies. Prepares FDA 510(k), De Novo, and PMA submission packages; analyzes regulatory pathways for new medical devices; drafts responses to FDA deficiency letters and Notified Body queries; develops CE marking technical documentation under EU MDR 2017\u002F745; coordinates multi-market approval strategies across FDA, EU, Health Canada, PMDA, and NMPA; and maintains regulatory intelligence on evolving standards. Use when users need to plan or execute FDA submissions, navigate 510(k) or PMA approval processes, achieve CE marking, prepare pre-submission meeting materials, write regulatory strategy documents, respond to agency queries, or manage compliance documentation for medical device market access.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fregulatory-affairs-head\u002FSKILL.md",[],[132,133,134,135,136,137,138,139,140,42,141,142,143,144,145,146,147,148,149,28],"regulatory affairs head","regulatory","head","documents","devices","health","plan","write","strategy","standards","queries","manage","strategies","de","users","respond","medical devices","manager",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":164,"publishedAt":44},"01M6KC34Z8M1559EY1CXYBJB1A","quality-manager-qms-iso13485","ISO 13485 Quality Management System implementation and maintenance for medical device organizations. Provides QMS design, documentation control, internal auditing, CAPA management, and certification support. Use when working with medical device quality systems, preparing for ISO 13485 audits, managing regulatory compliance documentation, setting up corrective actions, or building audit preparation programs. Useful for quality management, audit preparation, regulatory compliance, medical device documentation, and corrective action workflows.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qms-iso13485\u002FSKILL.md",[156,161],{"categoryNo":157,"categoryName":158,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":162,"categoryName":163,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000032","设计师",[165,166,149,167,168,169,170,171,172,42,173,174,175,176,177,178,179,180,28,181],"quality manager qms iso13485","quality","design","workflows","validation","actions","certification","system","maintenance","document","systems","records","ISO 13485","organizations","corrective action","internal audit","preparation",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":44},"01M6KC2FXHBHXYX2ZZ17Y3GDB4","quality-manager-qmr","Senior Quality Manager Responsible Person (QMR) for HealthTech and MedTech companies. Provides quality system governance, management review leadership, regulatory compliance oversight, and quality performance monitoring per ISO 13485 Clause 5.5.2.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qmr\u002FSKILL.md",[188],{"categoryNo":79,"categoryName":80,"taxonomyType":21,"taxonomyTypeDesc":22},[190,166,149,191,192,193,194,195,82,196,172,197,133,198,199,200,116,177,28,201],"quality manager qmr","review","policy","performance","governance","monitoring","regulatory compliance","oversight","cost","culture","leadership","person",{"skillNo":203,"name":204,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":215,"publishedAt":44},"01M6KC1VRR5JTDBNZANHPS6VR6","quality-documentation-manager","Document control system management for medical device QMS. Covers document numbering, version control, change management, and 21 CFR Part 11 compliance. Use for document control procedures, change control workflow, document numbering, version management, electronic signature compliance, or regulatory documentation review.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-documentation-manager\u002FSKILL.md",[208,211,214],{"categoryNo":209,"categoryName":210,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":212,"categoryName":213,"taxonomyType":159,"taxonomyTypeDesc":160},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":79,"categoryName":80,"taxonomyType":21,"taxonomyTypeDesc":22},[216,217,166,149,191,218,219,86,172,220,221,222,223,224,117,225,226,227,228,28],"documentation","quality documentation manager","workflow","change","change management","list","master","system management","documentation review","cfr","21 cfr part 11","change control","retention"]