[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NF1QZCAR0REEYG7K04EBH":3,"skill-same:01M71NF1QZCAR0REEYG7K04EBH":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":13,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71NF1QZCAR0REEYG7K04EBH","code-craft-review",null,"Independent code-quality review of a finished change. Use when asked to review a diff, files, or patch for unearned defensive code, silent fallbacks, speculative abstractions, naming, control flow, and scope, or when dispatched after implementation as the reviewer. Checks the change against the shared code-craft standard and reports actionable findings. Not an architecture review or a merge decision.","SikongJueluo\u002Fskills","SikongJueluo","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F53223107?v=4","01M71NEWK46KJB0R64SBCD990Z","01M71NEWKPCXWFQFMNTXW5ZYQN",0,"MIT","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcode-craft-review\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"review","craft","code craft review","code","reviewer","standard","architecture","patch","when","use","files","decision","actionable","for","scope","diff","architecture review","quality review","as","shared","2026-11-10 10:56:23",false,"---\nname: code-craft-review\ndescription: Independent code-quality review of a finished change. Use when asked to review a diff, files, or patch for unearned defensive code, silent fallbacks, speculative abstractions, naming, control flow, and scope, or when dispatched after implementation as the reviewer. Checks the change against the shared code-craft standard and reports actionable findings. Not an architecture review or a merge decision.\nargument-hint: \"[optional diff, revset, files, or review focus]\"\n---\n\n# \u002Fcode-craft-review\n\nReview the **code**, not the plan, the architecture, or whether the change should merge. The bar is [..\u002Fcode-craft\u002Freferences\u002Fstandards.md](..\u002Fcode-craft\u002Freferences\u002Fstandards.md), resolved from this skill's directory; read that file before judging anything. Read only the standards, not the `code-craft` procedure. If the standards file is missing, report that `code-craft` is not installed and stop.\n\n## Scope\n\nFix the target before reading code:\n\n- Use the diff, revset, files, or PR the user named.\n- Otherwise review the current working-copy diff; if that is empty, review the branch against its merge base with the default branch.\n- State the baseline and what is in scope. In a Jujutsu repo, resolve it with `jj log`\u002F`jj diff` and follow the `jujutsu` skill; do not use raw git.\n- Read every changed file in full and the adjacent code needed to judge it; do not audit the repository. If the diff is empty, say there is nothing to review and stop. If no baseline is obtainable, ask once.\n\n**Read-only.** Do not edit, format, or fix at any point unless the user explicitly asks for fixes; that request switches you to `code-craft`, whose procedure you then follow under this bar.\n\nThis is a code-quality conclusion. It is not a merge gate, not an architecture verdict, and not a system-wide validation report; for those, use `arch-code-review`.\n\n## How to review\n\n1. Read the diff and each changed file. Use the request and commit descriptions for intent, code and tests for behavior. For every new guard, default, retry, wrapper, config, compatibility branch, or abstraction, look for the fact it serves: a contract, boundary validation, a test, a confirmed failure path, or the task. For every removed guard or boundary, find what now covers the same need. Check new comments against the comment default, and treat them as claims about the code, not evidence for it.\n2. When you cannot find that fact, investigate before concluding: the definition and implementation behind the interface, the tests that pin it, the callers, the project's docs. A pattern match (`catch`, `??`, a default, a helper) is a prompt to look, not a finding.\n3. Apply the symmetric evidence rule. Asking to delete needs a contract, a test that pins the guarantee by asserting the behavior, or a simpler implementation that covers the same need. Asking to add needs a confirmed external boundary or failure path that the code currently mishandles.\n4. Report only what changes behavior or understanding. Each finding needs a location, evidence, a concrete cost, and the smallest direction. No score, no dimension checklist, no finding quota, no generic praise.\n5. Run the project's cheap checks only when a behavior-affecting judgment needs confirmation. Passing checks do not excuse code that hides failures; a failing check unrelated to the change is a note, not a finding.\n\nPrefer the smaller repair: remove the redundant guard, fix the source rather than masking it, use the established contract directly, clarify the name or data shape, or collapse a layer with no separate responsibility. Add code only for a confirmed failure path or requirement.\n\n## Output\n\nState the scope and baseline, then one of:\n\n**No code-quality changes needed.** The changed code meets the bar. Name any assumption you could not verify.\n\n**Rework needed.** Order findings by cost. For each:\n\n- `path:line` or symbol\n- **Evidence**: what the code does, and the contract, requirement, or failure path it contradicts\n- **Cost**: the concrete consequence — hidden failure, ambiguous state, a concept the reader must hold, a misleading call site\n- **Direction**: the smallest change that keeps the current need satisfied; describe it, do not rewrite the file\n\n**Evidence insufficient.** Name the exact unresolved items and what would settle them: file, doc, or runtime fact. Do not present a guess as a verdict.\n\nWhen findings and open items coexist, report both; the findings are still actionable.\n\nIf the code is fine, say so and stop.\n","# \u002Fcode-craft-review\n\nReview the **code**, not the plan, the architecture, or whether the change should merge. The bar is [..\u002Fcode-craft\u002Freferences\u002Fstandards.md](..\u002Fcode-craft\u002Freferences\u002Fstandards.md), resolved from this skill's directory; read that file before judging anything. Read only the standards, not the `code-craft` procedure. If the standards file is missing, report that `code-craft` is not installed and stop.\n\n## Scope\n\nFix the target before reading code:\n\n- Use the diff, revset, files, or PR the user named.\n- Otherwise review the current working-copy diff; if that is empty, review the branch against its merge base with the default branch.\n- State the baseline and what is in scope. In a Jujutsu repo, resolve it with `jj log`\u002F`jj diff` and follow the `jujutsu` skill; do not use raw git.\n- Read every changed file in full and the adjacent code needed to judge it; do not audit the repository. If the diff is empty, say there is nothing to review and stop. If no baseline is obtainable, ask once.\n\n**Read-only.** Do not edit, format, or fix at any point unless the user explicitly asks for fixes; that request switches you to `code-craft`, whose procedure you then follow under this bar.\n\nThis is a code-quality conclusion. It is not a merge gate, not an architecture verdict, and not a system-wide validation report; for those, use `arch-code-review`.\n\n## How to review\n\n1. Read the diff and each changed file. Use the request and commit descriptions for intent, code and tests for behavior. For every new guard, default, retry, wrapper, config, compatibility branch, or abstraction, look for the fact it serves: a contract, boundary validation, a test, a confirmed failure path, or the task. For every removed guard or boundary, find what now covers the same need. Check new comments against the comment default, and treat them as claims about the code, not evidence for it.\n2. When you cannot find that fact, investigate before concluding: the definition and implementation behind the interface, the tests that pin it, the callers, the project's docs. A pattern match (`catch`, `??`, a default, a helper) is a prompt to look, not a finding.\n3. Apply the symmetric evidence rule. Asking to delete needs a contract, a test that pins the guarantee by asserting the behavior, or a simpler implementation that covers the same need. Asking to add needs a confirmed external boundary or failure path that the code currently mishandles.\n4. Report only what changes behavior or understanding. Each finding needs a location, evidence, a concrete cost, and the smallest direction. No score, no dimension checklist, no finding quota, no generic praise.\n5. Run the project's cheap checks only when a behavior-affecting judgment needs confirmation. Passing checks do not excuse code that hides failures; a failing check unrelated to the change is a note, not a finding.\n\nPrefer the smaller repair: remove the redundant guard, fix the source rather than masking it, use the established contract directly, clarify the name or data shape, or collapse a layer with no separate responsibility. Add code only for a confirmed failure path or requirement.\n\n## Output\n\nState the scope and baseline, then one of:\n\n**No code-quality changes needed.** The changed code meets the bar. Name any assumption you could not verify.\n\n**Rework needed.** Order findings by cost. For each:\n\n- `path:line` or symbol\n- **Evidence**: what the code does, and the contract, requirement, or failure path it contradicts\n- **Cost**: the concrete consequence — hidden failure, ambiguous state, a concept the reader must hold, a misleading call site\n- **Direction**: the smallest change that keeps the current need satisfied; describe it, do not rewrite the file\n\n**Evidence insufficient.** Name the exact unresolved items and what would settle them: file, doc, or runtime fact. Do not present a guess as a verdict.\n\nWhen findings and open items coexist, report both; the findings are still actionable.\n\nIf the code is fine, say so and stop.\n",{"name":5,"description":7,"argument-hint":48},"[optional diff, revset, files, or review focus]","main","f48fc8bda161a30c80be9ca1189279414dde1f3a","skills\u002Fcode-craft-review","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills","https:\u002F\u002Fgithub.com\u002FSikongJueluo","https:\u002F\u002Fwww.swordlost.top","安得广厦千万间，大庇天下寒士俱欢颜！","2026-10-28 22:03:31",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add SikongJueluo\u002Fskills --skill code-craft-review",{"tool":63,"command":64},"bunx","bunx skills add SikongJueluo\u002Fskills --skill code-craft-review",{"tool":66,"command":67},"pnpm","pnpm dlx skills add SikongJueluo\u002Fskills --skill code-craft-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fcode-craft-review\u002FSKILL.md",true,[],[72,95,111,129,160,180],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":43},"01M71NFQMX5RNAXMZCXTCA0FFW","teaching","Teach toward a maintainable implementation when the user asks to learn before building, or says they are unfamiliar with technology required by a development task. Use for conversational co-design tied to real project work; not for general explanations, standalone tutorials, or persistent courses.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fteaching\u002FSKILL.md",[],[74,79,80,32,31,81,82,83,84,85,86,36,87,88,89,90,91,92,93,94],"implementation","task","learn","user","before building","project work","project","co","development","courses","standalone","work","with","technology","general","design",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"publishedAt":43},"01M71NFP48KR5WA41MWB59MBSZ","teach-me","Learn enough to co-design and maintain a real development change.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fteach-me\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000039","教师与教育",[105,106,107,86,81,87,108,109,94,110],"teach me","me","teach","maintain","change","true",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":43},"01M71NFM3K25R1843319SZ9JJ7","review-with-me","Curate the code worth a human's attention and present it in reviewable slices.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Freview-with-me\u002FSKILL.md",[],[106,91,23,118,119,120,121,122,123,124,26,110,125,37,126,127,128],"review with me","it","language","present","bookmark","curate","human","commits","branch","attention","natural language",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":143,"publishedAt":43},"01M71NFHBZQR70H9PATVKWDN68","refactor-ui","Improve an existing UI, screen, slide deck, or visual artifact that the user mostly accepts but finds too busy, unclear, inconsistent, ugly, plain, or over-decorated. Use when the user gives feedback on a rendered artifact and wants a bounded revision that preserves what works. Not for building from scratch, exploring an undecided visual direction, deck production or conversion, or implementing a specified design.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Frefactor-ui\u002FSKILL.md",[135,140],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":141,"categoryName":142,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000032","设计师",[144,145,146,147,148,149,150,151,152,31,153,32,94,154,155,156,157,36,158,159],"refactor","ui","refactor ui","implementing","artifact","From Scratch","conversion","visual","URL","Existing","improve","screen","scratch","deck","direction","feedback",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":43},"01M71NFDMN0VZ3JYMZBK6BJF5P","jj-describe","Write and apply concise, self-contained Conventional Commits descriptions for Jujutsu commits. Use when the user asks to describe a jj commit, and after completing a cohesive code or documentation change in a jj repository when the current non-empty commit is undescribed. Explain what changed and why without context-only planning labels such as P0 or P1.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fjj-describe\u002FSKILL.md",[],[167,168,169,41,32,170,171,172,36,125,173,38,174,175,31,26,176,177,178,179],"jj describe","jj","describe","only","labels","jujutsu","planning","cohesive","show","git log","apply","Bash","conventional commits",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":43},"01M71NFBQXB3GDS2V272956BWN","jj-desc","Write a concise, self-contained Jujutsu commit description that explains what changed and why.","https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fjj-desc\u002FSKILL.md",[],[187,168,188,189,190,191,172,192,109,110,193,194],"jj desc","write","self-contained","commit","why","concise","self","id"]