[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-b2940664-9ddd-44e3-8390-b430ef07489d":3,"$ft4kV23lbk13RI3Wyg8_TV8qyZuCuIaj7UjncJ718bHo":43},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":34},"b2940664-9ddd-44e3-8390-b430ef07489d","focused-fix","使用时，当用户要求修复、调试或使特定功能\u002F模块\u002F区域工作端到端。触发条件：'让X工作'、'修复Y功能'、'Z模块损坏'、'关注[区域]'。不适用于快速单个错误修复——这是针对所有文件和依赖项的系统化深度修复。","cat_life_career","mod_other","alirezarezvani,other","---\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","","imported","https:\u002F\u002Fgithub.com\u002Falirezarezvani\u002Fclaude-skills","user_system_seed","SkillOPIC",true,156,1711,"2026-05-16 13:53:58",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"其他","other","mdi-page-next-outline","其他类型Skill",5,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":32,"skillCount":33,"createdAt":26},"职场发展","career","mdi-briefcase-outline","面试准备、简历优化、职业规划",4,575,[35],{"id":36,"skillId":4,"version":37,"fileName":38,"fileSize":39,"filePath":40,"fileHash":41,"manifest":42,"createdAt":19},"59f5a1b7-5a83-4498-b750-5e3840aaf154","1.0.0","focused-fix.zip",5771,"uploads\u002Fskills\u002Fb2940664-9ddd-44e3-8390-b430ef07489d\u002Ffocused-fix.zip","9f72ff379467394a27c8112dc3ccf83b73fe2b165da8c8d6e00147d9ae08752d","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":13778}]",{"code":44,"message":45,"data":46},200,"success",{"items":47,"stats":48,"page":51},[],{"averageRating":49,"totalRatings":49,"ratingCounts":50},0,[49,49,49,49,49],{"limit":52,"offset":49,"hasMore":53,"nextOffset":52,"ratedOnly":16},15,false]