[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71NEZ21BJ79P0Y6YAV4P3GV":3,"skill-same:01M71NEZ21BJ79P0Y6YAV4P3GV":86},{"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":27,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":13,"repositoryHtmlUrl":57,"repositoryHomepageUrl":6,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M71NEZ21BJ79P0Y6YAV4P3GV","arch-code-review",null,"Architecture-first merge-decision review. Use only on explicit request to review whether a diff\u002FPR\u002Fbranch can be merged. Infers the minimum closed loop this change must complete, inspects the diff against authoritative docs, gathers validation evidence, and decides mergeability. Not for ordinary coding, debugging, refactoring, or casual code reading.","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\u002Farch-code-review\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"review","arch code review","arch","code","code review","debugging","pr","file","loop","decision","branch","use","diff","only","evidence","architecture","complete","URL","can","for","2026-11-10 10:56:23",false,"---\nname: arch-code-review\ndescription: Architecture-first merge-decision review. Use only on explicit request to review whether a diff\u002FPR\u002Fbranch can be merged. Infers the minimum closed loop this change must complete, inspects the diff against authoritative docs, gathers validation evidence, and decides mergeability. Not for ordinary coding, debugging, refactoring, or casual code reading.\nargument-hint: \"\u003Coptional PR URL, diff, file path, base branch, or review focus>\"\n---\n\n# \u002Farch-code-review\n\nAn architecture-first **merge decision**. Decide whether this change completes its minimum mergeable loop. Do not list every nit.\n\nDefault output language: English. Prefer prose over Markdown tables.\n\n## When to use\n\nOnly for explicit review requests — \"review this PR\", \"can this be merged?\", \"architecture review of this diff\", \"review before merge\". Not for ordinary coding, debugging, refactoring, or casual \"look at this code\".\n\n## Mindset\n\nJudge every finding against the **minimum closed loop**: the smallest end-to-end behavior, boundary, data flow, or lifecycle this change must complete to be mergeable. State that loop at the top of the report, then report only **principal contradictions** that affect it. A correct-but-unimportant detail is noise; a small issue becomes reportable only when it reveals systemic risk or breaks the loop.\n\nTwo authorities:\n\n- **Documentation > implementation.** Read the relevant docs first (README, `docs\u002F`, `ARCHITECTURE.md`, `CONTEXT.md`, ADRs, module docs). If docs say X and code does Y, the implementation deviates. You may flag suspected-stale docs, but do not invert the judgment without user confirmation.\n- **Facts > claims.** Findings rest on code, diff, and validation output — not comments, TODOs, or PR descriptions. A finding with no code\u002Fvalidation fact is a follow-up observation at most.\n\n## Inputs\n\nIf the user gives a PR URL, diff, file, zip, doc, reference implementation, or base branch, use it. Otherwise review the current repo diff: full branch diff vs `main`\u002F`master`, falling back to staged + working tree diff. If no diff is obtainable, ask.\n\nNo review config file. Honor only parameters in the current request (output language, base branch, depth, reference implementation, whether to evaluate tests).\n\n## How to review\n\n1. **Gather facts.** Read the diff, changed files, and nearby dependency\u002Fboundary code. Find and read the docs that govern the changed area. Track any doc\u002Fcode conflict.\n2. **State the minimum closed loop.** Infer it from the diff, docs, directory structure, changed tests, public APIs, and execution paths. Say explicitly: *\"This review's minimum closed loop is X.\"*\n3. **Inspect through the lens that matters for this change** — do not mechanically cover all of them:\n   - data structure, ownership, and flow\n   - lifecycle and destruction\n   - performance\n   - abstraction boundary\n   - tests (only when in scope — see below)\n4. **Gather validation evidence.** Detect project type and run the cheap checks first (lint, typecheck, related tests), broadening to full tests if useful. Validation is evidence, not a replacement for reading the code.\n\n**Stop instead of forcing a review** when the loop cannot be inferred, multiple unrelated loops exist and the user did not pick one (list the candidates and ask which is primary), required comparison material is inaccessible, the repo\u002Fdiff cannot be read, docs and the stated goal fundamentally conflict with no basis to choose, or there are not enough facts. Output *\"Cannot complete formal review\"* and state what is missing. Do not invent findings.\n\n## Severity\n\n- **blocker** — must fix before merge. Breaks a core boundary or data flow, leaves lifecycle\u002Fownership unprovable, makes the core flow wrong or non-executable, violates authoritative docs, or masks truth in tests\u002Fvalidation. Any blocker ⇒ not mergeable.\n- **high** — strongly recommended; several can make the change practically unmergeable.\n- **medium** — can merge if the loop is otherwise intact; should be scheduled.\n- **low** — usually omit; include only when it reveals systemic risk or affects the loop.\n\n## Validation and tests\n\nGrade validation failures by **impact on the minimum closed loop**, not mechanically. A failure that breaks compilability, the core path, data truthfulness, lifecycle safety, or validation credibility is blocker\u002Fhigh. A lint\u002Fformat failure that does not touch the loop is medium or follow-up. Passing validation is evidence, not proof of mergeability.\n\nDo not penalize missing tests by default — tests are often written after the loop stabilizes. Evaluate the test suite only when the user asks for it, the loop *is* a test\u002Fvalidation loop, the tests changed substantially, or test scaffolding distorts the loop. Otherwise note the test dimension as \"not evaluated this round\". Temporary markers (`FOR TEST`, fixtures, debug helpers) are not automatically issues.\n\n## Merge gate\n\nMergeable only when there is no blocker and the principal contradictions around the minimum closed loop are resolved. State the gate result and the reasoning (blockers, severity mix, validation facts). Judgment decides — a clean surface never makes code mergeable on its own.\n\n## Output\n\nA focused report that lets a maintainer make the call. Suggested shape — adapt to the change, but always state the loop and the gate:\n\n```markdown\n# Architecture Code Review\n\n## 1. Minimum closed loop\n[the inferred loop and why; or \"Cannot complete formal review\" + what's missing]\n\n## 2. Merge decision\n[Mergeable \u002F Not mergeable \u002F Needs user decision, with reasoning]\n\n## 3. Findings\n[Each: Severity · affected area · code\u002Fvalidation facts · why it breaks the loop · repair direction.\nLead with blockers and highs. Give a strategic repair direction, not a full patch unless asked.]\n\n## 4. Validation evidence\n[commands run + results + how failures affect the loop; or why not run]\n\n## 5. Doc\u002Fcode conflicts\n[docs vs implementation; or None]\n\n## 6. Follow-ups\n[few restrained notes — current non-blockers that may become principal contradictions later; no gate impact]\n```\n\nNo generic praise section. If a key design is valid and matters for the gate, say it briefly in the decision. Be direct and evidence-based — no flattery, no insults.\n\nIf blockers are numerous, do not enumerate every one: call the change broadly unmergeable, detail the representative blockers, and summarize the rest by category.\n","# \u002Farch-code-review\n\nAn architecture-first **merge decision**. Decide whether this change completes its minimum mergeable loop. Do not list every nit.\n\nDefault output language: English. Prefer prose over Markdown tables.\n\n## When to use\n\nOnly for explicit review requests — \"review this PR\", \"can this be merged?\", \"architecture review of this diff\", \"review before merge\". Not for ordinary coding, debugging, refactoring, or casual \"look at this code\".\n\n## Mindset\n\nJudge every finding against the **minimum closed loop**: the smallest end-to-end behavior, boundary, data flow, or lifecycle this change must complete to be mergeable. State that loop at the top of the report, then report only **principal contradictions** that affect it. A correct-but-unimportant detail is noise; a small issue becomes reportable only when it reveals systemic risk or breaks the loop.\n\nTwo authorities:\n\n- **Documentation > implementation.** Read the relevant docs first (README, `docs\u002F`, `ARCHITECTURE.md`, `CONTEXT.md`, ADRs, module docs). If docs say X and code does Y, the implementation deviates. You may flag suspected-stale docs, but do not invert the judgment without user confirmation.\n- **Facts > claims.** Findings rest on code, diff, and validation output — not comments, TODOs, or PR descriptions. A finding with no code\u002Fvalidation fact is a follow-up observation at most.\n\n## Inputs\n\nIf the user gives a PR URL, diff, file, zip, doc, reference implementation, or base branch, use it. Otherwise review the current repo diff: full branch diff vs `main`\u002F`master`, falling back to staged + working tree diff. If no diff is obtainable, ask.\n\nNo review config file. Honor only parameters in the current request (output language, base branch, depth, reference implementation, whether to evaluate tests).\n\n## How to review\n\n1. **Gather facts.** Read the diff, changed files, and nearby dependency\u002Fboundary code. Find and read the docs that govern the changed area. Track any doc\u002Fcode conflict.\n2. **State the minimum closed loop.** Infer it from the diff, docs, directory structure, changed tests, public APIs, and execution paths. Say explicitly: *\"This review's minimum closed loop is X.\"*\n3. **Inspect through the lens that matters for this change** — do not mechanically cover all of them:\n   - data structure, ownership, and flow\n   - lifecycle and destruction\n   - performance\n   - abstraction boundary\n   - tests (only when in scope — see below)\n4. **Gather validation evidence.** Detect project type and run the cheap checks first (lint, typecheck, related tests), broadening to full tests if useful. Validation is evidence, not a replacement for reading the code.\n\n**Stop instead of forcing a review** when the loop cannot be inferred, multiple unrelated loops exist and the user did not pick one (list the candidates and ask which is primary), required comparison material is inaccessible, the repo\u002Fdiff cannot be read, docs and the stated goal fundamentally conflict with no basis to choose, or there are not enough facts. Output *\"Cannot complete formal review\"* and state what is missing. Do not invent findings.\n\n## Severity\n\n- **blocker** — must fix before merge. Breaks a core boundary or data flow, leaves lifecycle\u002Fownership unprovable, makes the core flow wrong or non-executable, violates authoritative docs, or masks truth in tests\u002Fvalidation. Any blocker ⇒ not mergeable.\n- **high** — strongly recommended; several can make the change practically unmergeable.\n- **medium** — can merge if the loop is otherwise intact; should be scheduled.\n- **low** — usually omit; include only when it reveals systemic risk or affects the loop.\n\n## Validation and tests\n\nGrade validation failures by **impact on the minimum closed loop**, not mechanically. A failure that breaks compilability, the core path, data truthfulness, lifecycle safety, or validation credibility is blocker\u002Fhigh. A lint\u002Fformat failure that does not touch the loop is medium or follow-up. Passing validation is evidence, not proof of mergeability.\n\nDo not penalize missing tests by default — tests are often written after the loop stabilizes. Evaluate the test suite only when the user asks for it, the loop *is* a test\u002Fvalidation loop, the tests changed substantially, or test scaffolding distorts the loop. Otherwise note the test dimension as \"not evaluated this round\". Temporary markers (`FOR TEST`, fixtures, debug helpers) are not automatically issues.\n\n## Merge gate\n\nMergeable only when there is no blocker and the principal contradictions around the minimum closed loop are resolved. State the gate result and the reasoning (blockers, severity mix, validation facts). Judgment decides — a clean surface never makes code mergeable on its own.\n\n## Output\n\nA focused report that lets a maintainer make the call. Suggested shape — adapt to the change, but always state the loop and the gate:\n\n```markdown\n# Architecture Code Review\n\n## 1. Minimum closed loop\n[the inferred loop and why; or \"Cannot complete formal review\" + what's missing]\n\n## 2. Merge decision\n[Mergeable \u002F Not mergeable \u002F Needs user decision, with reasoning]\n\n## 3. Findings\n[Each: Severity · affected area · code\u002Fvalidation facts · why it breaks the loop · repair direction.\nLead with blockers and highs. Give a strategic repair direction, not a full patch unless asked.]\n\n## 4. Validation evidence\n[commands run + results + how failures affect the loop; or why not run]\n\n## 5. Doc\u002Fcode conflicts\n[docs vs implementation; or None]\n\n## 6. Follow-ups\n[few restrained notes — current non-blockers that may become principal contradictions later; no gate impact]\n```\n\nNo generic praise section. If a key design is valid and matters for the gate, say it briefly in the decision. Be direct and evidence-based — no flattery, no insults.\n\nIf blockers are numerous, do not enumerate every one: call the change broadly unmergeable, detail the representative blockers, and summarize the rest by category.\n",{"name":5,"description":7,"argument-hint":53},"\u003Coptional PR URL, diff, file path, base branch, or review focus>","main","f48fc8bda161a30c80be9ca1189279414dde1f3a","skills\u002Farch-code-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":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add SikongJueluo\u002Fskills --skill arch-code-review",{"tool":68,"command":69},"bunx","bunx skills add SikongJueluo\u002Fskills --skill arch-code-review",{"tool":71,"command":72},"pnpm","pnpm dlx skills add SikongJueluo\u002Fskills --skill arch-code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Farch-code-review\u002FSKILL.md",true,[76,82],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"evals\u002Fevals.json","REFERENCE","参考文档",4181,"https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Farch-code-review\u002Fevals\u002Fevals.json",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"evals\u002Ftrigger-set.json",1991,"https:\u002F\u002Fgithub.com\u002FSikongJueluo\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Farch-code-review\u002Fevals\u002Ftrigger-set.json",[87,111,127,145,171,191],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":48},"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",[],[89,94,95,39,96,97,98,99,100,101,102,47,103,104,105,106,107,108,109,110],"implementation","task","when","learn","user","before building","project work","project","co","development","courses","standalone","work","with","technology","general","design",{"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":120,"publishedAt":48},"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",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000039","教师与教育",[121,122,123,102,97,103,124,125,110,126],"teach me","me","teach","maintain","change","true",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":48},"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",[],[122,107,28,134,135,136,137,138,139,140,31,126,141,142,38,143,144],"review with me","it","language","present","bookmark","curate","human","commits","scope","attention","natural language",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":155,"publishedAt":48},"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",[151,152],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":153,"categoryName":154,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[156,157,158,159,160,161,162,163,45,96,164,39,110,165,166,167,168,47,169,170],"refactor","ui","refactor ui","implementing","artifact","From Scratch","conversion","visual","Existing","improve","screen","scratch","deck","direction","feedback",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":48},"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",[],[178,179,180,181,39,41,182,183,47,141,184,40,185,186,96,31,187,188,189,190],"jj describe","jj","describe","as","labels","jujutsu","planning","cohesive","show","git log","apply","Bash","conventional commits",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":195,"categories":196,"keywords":197,"publishedAt":48},"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",[],[198,179,199,200,201,202,183,203,125,126,204,205],"jj desc","write","self-contained","commit","why","concise","self","id"]