[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ER2RQG9TA0PRD2F55QQGMS":3,"skill-same:01M6ER2RQG9TA0PRD2F55QQGMS":68},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":48,"commitSha":49,"skillDirectory":50,"forksCount":13,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":67},"01M6ER2RQG9TA0PRD2F55QQGMS","deep-fix",null,"Structured debugging for non-obvious bugs — reproduces, isolates root cause, verifies hypothesis before fixing, and adds regression tests. Prevents the shotgun-fix pattern where agents edit randomly until tests pass. Use when stuck on a bug, facing a cryptic error, or when a previous fix attempt failed. Manual via \u002Fdeep-fix.","cj-ways\u002Farcana","cj-ways","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F268418145?v=4","01M6ER2722FXTDPCH3119PJ5T3","01M6ER2773VFWAC3D21KGP6N7Q",0,"MIT","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fdeep-fix\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"deep fix","deep","fix","use","error","via","tests","pattern","message","when stuck","bug","debugging","edit","write","read","grep","regression","Bash","execution","file","2026-11-10 10:12:30",false,"---\nname: deep-fix\ndescription: 'Structured debugging for non-obvious bugs — reproduces, isolates root cause, verifies hypothesis before fixing, and adds regression tests. Prevents the shotgun-fix pattern where agents edit randomly until tests pass. Use when stuck on a bug, facing a cryptic error, or when a previous fix attempt failed. Manual via \u002Fdeep-fix.'\nargument-hint: \"\u003Cerror-message, file, or bug description>\"\ndisable-model-invocation: true\nallowed-tools: Bash, Read, Grep, Glob, Edit, Write, Agent, WebSearch\neffort: high\nphase: fix\nfeedback-profile: execution\ncatalog-order: 50\n---\n\n# Deep Fix — Structured Debugging\n\nA disciplined debugging workflow that prevents the most common AI agent failure mode: looping on failed fixes without understanding the root cause. Every fix must be preceded by a verified hypothesis.\n\n**Input**: $ARGUMENTS (error message, file path, bug description, or test failure)\n\n## Gotchas\n\n1. **Editing code before understanding the bug.** The #1 failure mode. If the fix attempt fails, the agent makes another guess, creating a loop of random edits. NEVER edit code until Step 3 (Hypothesize) produces a concrete, testable hypothesis.\n2. **Reading the error message without reading the stack trace.** The error message says WHAT failed. The stack trace says WHERE. Read the full trace — the root cause is usually 3-5 frames deep, not at the top.\n3. **Fixing the symptom instead of the cause.** Adding a null check to silence a TypeError is a patch, not a fix. Ask: WHY is this value null? Trace the data flow backward to the source.\n4. **Not reproducing before fixing.** If the bug can't be reproduced, the fix can't be verified. A fix without reproduction evidence is a guess.\n5. **Declaring victory without a regression test.** A fix that passes existing tests but adds no new test will break again. Every fix gets a test that would have caught the original bug.\n\n---\n\n## Step 1: Reproduce\n\nEstablish that the bug exists and is reproducible.\n\n1. **Parse the input**: Extract the error message, stack trace, failing test, or behavioral description from `$ARGUMENTS`\n2. **Reproduce the failure**:\n   - If a test fails: run it — `npm test`, `pytest`, `go test`, etc.\n   - If a runtime error: identify the trigger and execute it\n   - If a behavioral bug: identify the minimal steps to observe it\n3. **Record the reproduction**:\n   - Exact command that triggers the failure\n   - Full error output (not truncated)\n   - Environment details if relevant (Node version, OS, etc.)\n\nIf the bug **cannot be reproduced**, stop. Report: \"Could not reproduce. Here is what was tried: [list]. Possible intermittent issue — check for race conditions, timing dependencies, or environment-specific factors.\"\n\nIf the bug **is reproduced**, state: \"Reproduced. Trigger: [command]. Error: [one-line summary].\" Proceed to Step 2.\n\n---\n\n## Step 2: Isolate\n\nNarrow down exactly where the failure occurs.\n\n1. **Read the stack trace** — identify the deepest application frame (skip framework\u002Flibrary frames)\n2. **Read the source file** at the failing line and 50 lines of surrounding context\n3. **Trace the data flow**:\n   - What inputs reach the failing line?\n   - Where do those inputs come from? (function arguments, API responses, database queries, config)\n   - At what point does the data become incorrect?\n4. **Check recent changes**: `git log --oneline -10 \u003Cfile>` and `git diff HEAD~5 \u003Cfile>` — did a recent change introduce this?\n5. **Check sibling context**: Read the calling function, the module's imports, and any middleware\u002Fdecorators\n\nProduce an **isolation statement**: \"The failure occurs at `file:line` because `[variable\u002Fvalue]` is `[actual]` when it should be `[expected]`. The incorrect value originates from `[source]`.\"\n\n---\n\n## Step 3: Hypothesize\n\nForm a concrete, testable hypothesis about the root cause.\n\n**Hypothesis format**: \"The bug is caused by [specific mechanism] in [specific location]. This can be verified by [specific test].\"\n\n**Hypothesis quality check** — reject and re-investigate if:\n- The hypothesis is vague (\"something is wrong with the data\")\n- The hypothesis blames external code without evidence (\"the library must have a bug\")\n- The verification step is \"apply the fix and see if tests pass\" — that is guessing, not verifying\n\n**Common root cause patterns** (check each against the evidence):\n- Missing null\u002Fundefined check after a lookup that can return empty\n- Async operation not awaited — data used before it's available\n- Stale closure capturing an old value\n- Off-by-one in loop bounds or array indexing\n- Type coercion producing unexpected results\n- Race condition between concurrent operations\n- Config\u002Fenvironment difference between where it works and where it fails\n- Import order or circular dependency causing undefined at load time\n\n---\n\n## Step 4: Verify Hypothesis\n\nConfirm the hypothesis is correct BEFORE writing the fix.\n\n**Verification methods** (use at least one):\n- Add a temporary `console.log` \u002F `print` \u002F `fmt.Println` at the suspected point — does the output confirm the hypothesis?\n- Write a minimal failing test that isolates the exact condition the hypothesis describes\n- Use `git bisect` if the bug was introduced by a specific commit\n- Check if the same pattern exists elsewhere in the codebase — if so, does it fail there too?\n\nIf verification **confirms** the hypothesis: state \"Hypothesis confirmed: [evidence].\" Proceed to Step 5.\n\nIf verification **disproves** the hypothesis: state \"Hypothesis disproved: [evidence]. Returning to isolation.\" Go back to Step 2 with the new information.\n\n---\n\n## Step 5: Fix\n\nApply the minimal fix that addresses the root cause.\n\n**Fix principles:**\n- Fix the cause, not the symptom. If a value is null, fix WHY it's null — don't just add `?? defaultValue`\n- Minimal change. Only modify what is necessary. Do not refactor, clean up, or \"improve\" surrounding code\n- Match existing patterns. If the codebase handles similar cases with a specific pattern, use the same pattern\n- Remove temporary debug code (console.log, print statements) added during verification\n\n**After applying the fix:**\n1. Run the original reproduction command — does the error stop?\n2. Run the full test suite — does anything else break?\n3. If tests fail, the fix is wrong or incomplete. Do NOT layer another fix on top. Return to Step 3.\n\n---\n\n## Step 6: Regression Test\n\nWrite a test that would have caught the original bug.\n\n1. The test must **fail without the fix** and **pass with the fix**\n2. The test must target the **root cause**, not the surface symptom\n3. Name the test descriptively: `\"handles null response from API\"` not `\"fix bug #123\"`\n4. Follow existing test patterns — detect framework, match style (same rules as generate-tests)\n\nRun the test to confirm it passes with the fix applied.\n\n---\n\n## Step 7: Report\n\nPresent the debugging results:\n\n```\n## Deep Fix Report\n\n**Bug:** [one-line description]\n**Root cause:** [what was actually wrong and why]\n**Fix:** [what was changed, file:line references]\n**Regression test:** [test name and file]\n**Confidence:** high \u002F medium (medium if hypothesis verification was indirect)\n\n### Debug trace\n1. Reproduced: [command and error]\n2. Isolated to: [file:line, data flow]\n3. Hypothesis: [what was suspected]\n4. Verified by: [how hypothesis was confirmed]\n5. Fixed: [minimal change description]\n6. Tested: [test name, pass\u002Ffail status]\n```\n\n**If the bug could not be fixed**, report honestly:\n- What was tried\n- What was learned\n- Remaining hypotheses to investigate\n- Suggest `\u002Fdeep-review` if the issue may be architectural\n\n**If the fix revealed related issues**, mention: \"Consider running `\u002Fgenerate-tests` to cover similar patterns in the codebase.\"\n\n## Rules\n\n- NEVER edit code before completing Step 3 (Hypothesize)\n- NEVER declare a fix without reproduction evidence (Step 1) and a regression test (Step 6)\n- NEVER layer fix attempts — if a fix doesn't work, return to hypothesis, don't add another patch\n- If 3 hypotheses fail in sequence, step back and re-read the full module from scratch\n- Remove all temporary debug code before reporting\n- Match existing code style and test patterns\n","# Deep Fix — Structured Debugging\n\nA disciplined debugging workflow that prevents the most common AI agent failure mode: looping on failed fixes without understanding the root cause. Every fix must be preceded by a verified hypothesis.\n\n**Input**: $ARGUMENTS (error message, file path, bug description, or test failure)\n\n## Gotchas\n\n1. **Editing code before understanding the bug.** The #1 failure mode. If the fix attempt fails, the agent makes another guess, creating a loop of random edits. NEVER edit code until Step 3 (Hypothesize) produces a concrete, testable hypothesis.\n2. **Reading the error message without reading the stack trace.** The error message says WHAT failed. The stack trace says WHERE. Read the full trace — the root cause is usually 3-5 frames deep, not at the top.\n3. **Fixing the symptom instead of the cause.** Adding a null check to silence a TypeError is a patch, not a fix. Ask: WHY is this value null? Trace the data flow backward to the source.\n4. **Not reproducing before fixing.** If the bug can't be reproduced, the fix can't be verified. A fix without reproduction evidence is a guess.\n5. **Declaring victory without a regression test.** A fix that passes existing tests but adds no new test will break again. Every fix gets a test that would have caught the original bug.\n\n---\n\n## Step 1: Reproduce\n\nEstablish that the bug exists and is reproducible.\n\n1. **Parse the input**: Extract the error message, stack trace, failing test, or behavioral description from `$ARGUMENTS`\n2. **Reproduce the failure**:\n   - If a test fails: run it — `npm test`, `pytest`, `go test`, etc.\n   - If a runtime error: identify the trigger and execute it\n   - If a behavioral bug: identify the minimal steps to observe it\n3. **Record the reproduction**:\n   - Exact command that triggers the failure\n   - Full error output (not truncated)\n   - Environment details if relevant (Node version, OS, etc.)\n\nIf the bug **cannot be reproduced**, stop. Report: \"Could not reproduce. Here is what was tried: [list]. Possible intermittent issue — check for race conditions, timing dependencies, or environment-specific factors.\"\n\nIf the bug **is reproduced**, state: \"Reproduced. Trigger: [command]. Error: [one-line summary].\" Proceed to Step 2.\n\n---\n\n## Step 2: Isolate\n\nNarrow down exactly where the failure occurs.\n\n1. **Read the stack trace** — identify the deepest application frame (skip framework\u002Flibrary frames)\n2. **Read the source file** at the failing line and 50 lines of surrounding context\n3. **Trace the data flow**:\n   - What inputs reach the failing line?\n   - Where do those inputs come from? (function arguments, API responses, database queries, config)\n   - At what point does the data become incorrect?\n4. **Check recent changes**: `git log --oneline -10 \u003Cfile>` and `git diff HEAD~5 \u003Cfile>` — did a recent change introduce this?\n5. **Check sibling context**: Read the calling function, the module's imports, and any middleware\u002Fdecorators\n\nProduce an **isolation statement**: \"The failure occurs at `file:line` because `[variable\u002Fvalue]` is `[actual]` when it should be `[expected]`. The incorrect value originates from `[source]`.\"\n\n---\n\n## Step 3: Hypothesize\n\nForm a concrete, testable hypothesis about the root cause.\n\n**Hypothesis format**: \"The bug is caused by [specific mechanism] in [specific location]. This can be verified by [specific test].\"\n\n**Hypothesis quality check** — reject and re-investigate if:\n- The hypothesis is vague (\"something is wrong with the data\")\n- The hypothesis blames external code without evidence (\"the library must have a bug\")\n- The verification step is \"apply the fix and see if tests pass\" — that is guessing, not verifying\n\n**Common root cause patterns** (check each against the evidence):\n- Missing null\u002Fundefined check after a lookup that can return empty\n- Async operation not awaited — data used before it's available\n- Stale closure capturing an old value\n- Off-by-one in loop bounds or array indexing\n- Type coercion producing unexpected results\n- Race condition between concurrent operations\n- Config\u002Fenvironment difference between where it works and where it fails\n- Import order or circular dependency causing undefined at load time\n\n---\n\n## Step 4: Verify Hypothesis\n\nConfirm the hypothesis is correct BEFORE writing the fix.\n\n**Verification methods** (use at least one):\n- Add a temporary `console.log` \u002F `print` \u002F `fmt.Println` at the suspected point — does the output confirm the hypothesis?\n- Write a minimal failing test that isolates the exact condition the hypothesis describes\n- Use `git bisect` if the bug was introduced by a specific commit\n- Check if the same pattern exists elsewhere in the codebase — if so, does it fail there too?\n\nIf verification **confirms** the hypothesis: state \"Hypothesis confirmed: [evidence].\" Proceed to Step 5.\n\nIf verification **disproves** the hypothesis: state \"Hypothesis disproved: [evidence]. Returning to isolation.\" Go back to Step 2 with the new information.\n\n---\n\n## Step 5: Fix\n\nApply the minimal fix that addresses the root cause.\n\n**Fix principles:**\n- Fix the cause, not the symptom. If a value is null, fix WHY it's null — don't just add `?? defaultValue`\n- Minimal change. Only modify what is necessary. Do not refactor, clean up, or \"improve\" surrounding code\n- Match existing patterns. If the codebase handles similar cases with a specific pattern, use the same pattern\n- Remove temporary debug code (console.log, print statements) added during verification\n\n**After applying the fix:**\n1. Run the original reproduction command — does the error stop?\n2. Run the full test suite — does anything else break?\n3. If tests fail, the fix is wrong or incomplete. Do NOT layer another fix on top. Return to Step 3.\n\n---\n\n## Step 6: Regression Test\n\nWrite a test that would have caught the original bug.\n\n1. The test must **fail without the fix** and **pass with the fix**\n2. The test must target the **root cause**, not the surface symptom\n3. Name the test descriptively: `\"handles null response from API\"` not `\"fix bug #123\"`\n4. Follow existing test patterns — detect framework, match style (same rules as generate-tests)\n\nRun the test to confirm it passes with the fix applied.\n\n---\n\n## Step 7: Report\n\nPresent the debugging results:\n\n```\n## Deep Fix Report\n\n**Bug:** [one-line description]\n**Root cause:** [what was actually wrong and why]\n**Fix:** [what was changed, file:line references]\n**Regression test:** [test name and file]\n**Confidence:** high \u002F medium (medium if hypothesis verification was indirect)\n\n### Debug trace\n1. Reproduced: [command and error]\n2. Isolated to: [file:line, data flow]\n3. Hypothesis: [what was suspected]\n4. Verified by: [how hypothesis was confirmed]\n5. Fixed: [minimal change description]\n6. Tested: [test name, pass\u002Ffail status]\n```\n\n**If the bug could not be fixed**, report honestly:\n- What was tried\n- What was learned\n- Remaining hypotheses to investigate\n- Suggest `\u002Fdeep-review` if the issue may be architectural\n\n**If the fix revealed related issues**, mention: \"Consider running `\u002Fgenerate-tests` to cover similar patterns in the codebase.\"\n\n## Rules\n\n- NEVER edit code before completing Step 3 (Hypothesize)\n- NEVER declare a fix without reproduction evidence (Step 1) and a regression test (Step 6)\n- NEVER layer fix attempts — if a fix doesn't work, return to hypothesis, don't add another patch\n- If 3 hypotheses fail in sequence, step back and re-read the full module from scratch\n- Remove all temporary debug code before reporting\n- Match existing code style and test patterns\n",{"name":5,"phase":20,"effort":43,"description":7,"allowed-tools":44,"argument-hint":45,"catalog-order":46,"feedback-profile":36,"disable-model-invocation":47},"high","Bash, Read, Grep, Glob, Edit, Write, Agent, WebSearch","\u003Cerror-message, file, or bug description>",50,true,"main","62a5cbde2da44ccf4660521f0e3b2286f71dcbfd","skills\u002Fdeep-fix","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana","https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@cj-ways\u002Farcana","https:\u002F\u002Fgithub.com\u002Fcj-ways","2026-04-27 15:57:45",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":47},[57,60,63],{"tool":58,"command":59},"npx","npx skills add cj-ways\u002Farcana --skill deep-fix",{"tool":61,"command":62},"bunx","bunx skills add cj-ways\u002Farcana --skill deep-fix",{"tool":64,"command":65},"pnpm","pnpm dlx skills add cj-ways\u002Farcana --skill deep-fix","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fdeep-fix\u002FSKILL.md",[],[69,104,129,148,169,192],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":85,"publishedAt":38},"01M6ER4PGRFCMZ3D11YCEQ7Q9H","v0-design","Generates optimized v0.dev prompts for UI design — full pages, single components, design systems, or redesigns. Analyzes the project, adapts questions to context, researches user-specified design references, and outputs ready-to-copy prompts following Vercel's three-part framework. Manual via \u002Fv0-design.","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fv0-design\u002FSKILL.md",[75,80],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[86,87,88,89,90,91,92,93,32,31,94,95,96,97,98,99,100,101,102,103],"design","v0","v0 design","components","component","design systems","framework","ui","context","design-system","ready","ui design","references","three","project","full","feature","app",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":113,"publishedAt":38},"01M6ER4J1MAN09RA7ZVFQP5WC0","skill-scout","Scouts major skill providers for skills that match the current project — fetches catalogs, analyzes the codebase, cross-matches, and recommends with evidence. Critical assessment, not a dump of everything available. Manual via \u002Fskill-scout.","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fskill-scout\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发",[114,115,116,117,118,119,120,35,33,32,121,122,123,124,125,100,126,127,23,128],"skill scout","scout","testing","security","workflow","assessment","Providers","webfetch","ops","evidence","focus","advisory","critical","dump","utility",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":38},"01M6ER4EGNXCNN8P05RKVCQXHC","security-check","Quick security scan — hardcoded secrets, common vulnerabilities, dependency issues. Use when the user asks to check security, scan for secrets, or audit for vulnerabilities. Manual via \u002Fsecurity-check.","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fsecurity-check\u002FSKILL.md",[],[117,136,137,138,139,140,141,142,35,143,144,33,32,121,21,145,146,147,23,128],"check","security check","vulnerabilities","issues","security scan","audit","secrets","deps","common","dependency","scan","scope",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":38},"01M6ER4A08G4CPT443J7XSHDJQ","release-check","Analyzes branch diff to generate deploy checklists — env vars, migrations, new services, dependencies, schema changes, breaking changes. Works across any tech stack. Manual via \u002Frelease-check [source] [target].","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Frelease-check\u002FSKILL.md",[],[155,156,136,157,158,159,36,35,160,33,161,32,162,163,164,165,166,167,23,168],"release","release check","generate","env vars","services","stack","branch","diff","schema","migrations","dependencies","across","env","tech",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":178,"publishedAt":38},"01M6ER45AQCN9RDAXZA5A5W03C","refactor-plan","Plans and executes safe multi-file refactoring — maps dependency graph, batches changes into atomic commits, runs tests between batches. Prevents the cascading-breakage pattern where agents make sweeping changes that fail halfway. Use for renames, extractions, moves, or structural changes across multiple files. Manual via \u002Frefactor-plan.","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Frefactor-plan\u002FSKILL.md",[175],{"categoryNo":176,"categoryName":177,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000007","代码审查",[179,180,181,182,183,184,35,185,186,32,31,30,145,187,188,189,25,166,190,191],"refactor plan","refactor","plan","safe","graph","commits","refactoring","atomic commits","dependency graph","files","maps","structural","make",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":202,"publishedAt":38},"01M6ER41VW96NCAMSQF8SV31J7","quick-review","Fast single-pass code review with strong false-positive suppression. Reviews git diff for runtime errors, data corruption, security breaches, operational incidents. Use for PR reviews and quick change validation. Manual via \u002Fquick-review.","https:\u002F\u002Fgithub.com\u002Fcj-ways\u002Farcana\u002Fblob\u002Fmain\u002Fskills\u002Fquick-review\u002FSKILL.md",[198,199],{"categoryNo":176,"categoryName":177,"taxonomyType":78,"taxonomyTypeDesc":79},{"categoryNo":200,"categoryName":201,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000030","开发工程师",[203,204,205,206,207,208,209,210,211,35,33,161,32,21,162,188,100,212,213,23],"review","quick review","code review","change","pr","code","validation","worktree","false-positive","runtime","false"]