[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X1QHE686Y2DB4TPJ2S7E7C":3,"skill-same:01M6X1QHE686Y2DB4TPJ2S7E7C":83},{"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":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":14,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6X1QHE686Y2DB4TPJ2S7E7C","code-review",null,"Structured code review with a checklist covering correctness, clarity, tests, security, performance, and style. Use when reviewing a PR, diff, or set of code changes before merging — including phrases like \"review this\", \"check my changes\", or \"is this ready to merge\".","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,5,45,46,47],"review","code review","code","when","changes","v1","correctness","with","style","tests","ready","diff","use","check","work","SET","pr","merge","performance","2026-11-10 10:12:30",false,"---\nname: code-review\ndescription: |\n  Structured code review with a checklist covering correctness, clarity, tests, security, performance, and style. Use when reviewing a PR, diff, or set of code changes before merging — including phrases like \"review this\", \"check my changes\", or \"is this ready to merge\".\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-code-review\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: engineering\n    layer: 3\n---\n\n# Code Review\n\n## Intro\n\nCode review is a structured pass over a diff against a fixed\nchecklist, then a categorized response: must-fix, should-fix, nit.\nThe goal is to surface real defects with specific line references,\nnot to rewrite the author's code.\n\n## Overview\n\n### The review checklist\n\nRead the diff or changed files, then evaluate each change against:\n\n- **Correctness** — Does the code do what it claims? Are edge\n  cases handled?\n- **Clarity** — Are names descriptive? Is the logic easy to\n  follow on a single read?\n- **Tests** — Are new behaviors tested? Do existing tests still\n  hold?\n- **Security** — Hardcoded secrets, SQL injection, unsafe input\n  handling, missing authz?\n- **Performance** — Unnecessary allocations, N+1 queries,\n  accidental O(n^2) loops?\n- **Style** — Consistent with the project's existing conventions\n  (not your personal preferences)?\n\n### Categorize findings\n\nSort each finding into one bucket and label it explicitly:\n\n- **Must fix** — bugs, security issues, broken tests, contract\n  violations\n- **Should fix** — unclear naming, missing tests for non-trivial\n  paths, code smells\n- **Nit** — style preferences, minor suggestions, taste calls\n\nAlways include specific line references and concrete suggestions.\nAcknowledge what was done well — review is not adversarial.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Burying must-fix items after style comments.** When a security issue or correctness bug appears three paragraphs into a review, the author may miss it. Lead with must-fix items; put nits at the end.\n- **Vague comments without line references or concrete suggestions.** \"This looks weird\" is not actionable. Every finding needs a specific line reference and a concrete suggestion — what is the problem and what would fix it.\n- **Stamp-of-approval review.** Skimming the diff and approving to move it along defeats the purpose of review and gives the team false confidence. If you cannot read the changed lines, say so and ask to review in a smaller chunk.\n- **Reviewing huge diffs in one pass.** Large diffs cause reviewer fatigue and cause real issues to be missed. Either push back on PR scope or break the review into sessions (security first, then logic, then style).\n- **Missing the escalation trigger.** Line-by-line comments on a diff that has fundamental design issues waste both sides' time. When the design is wrong, stop the line review and raise the design concern first.\n- **Rewriting in review.** Proposing complete rewrites of code that works demotivates authors and overreaches the reviewer's role. Propose the improvement once; the author owns the code.\n- **No acknowledgment of what was done well.** All-negative reviews are adversarial over time and reduce the quality of future work. Code review should also surface what was done right.\n\n## Full reference\n\n### Example output shape\n\n> **Must fix:** `parse_input()` on line 42 doesn't handle empty\n> strings — this will panic.\n>\n> **Should fix:** The variable `x` on line 15 could be renamed to\n> `retry_count` for clarity.\n>\n> **Nit:** Consider extracting lines 30-45 into a helper function.\n>\n> Overall: Good separation of concerns. The error handling pattern\n> is clean.\n\n### Anti-patterns\n\n- **Rewriting in review** — propose, don't dictate. The author\n  owns the code.\n- **Bikeshedding** — if it's a nit, label it a nit and move on.\n- **Stamp-of-approval review** — skimming and approving without\n  reading the changed lines defeats the purpose.\n- **Vague comments** — \"this looks weird\" is not actionable. Say\n  what's weird and what would fix it.\n- **Reviewing in one pass when the diff is huge** — split the\n  review across sessions or push back on PR scope.\n\n### When to escalate\n\nIf the diff has fundamental design issues, stop the line-by-line\nreview and discuss the design first. Line comments on a diff that\nshould never have been written waste both sides' time.\n","# Code Review\n\n## Intro\n\nCode review is a structured pass over a diff against a fixed\nchecklist, then a categorized response: must-fix, should-fix, nit.\nThe goal is to surface real defects with specific line references,\nnot to rewrite the author's code.\n\n## Overview\n\n### The review checklist\n\nRead the diff or changed files, then evaluate each change against:\n\n- **Correctness** — Does the code do what it claims? Are edge\n  cases handled?\n- **Clarity** — Are names descriptive? Is the logic easy to\n  follow on a single read?\n- **Tests** — Are new behaviors tested? Do existing tests still\n  hold?\n- **Security** — Hardcoded secrets, SQL injection, unsafe input\n  handling, missing authz?\n- **Performance** — Unnecessary allocations, N+1 queries,\n  accidental O(n^2) loops?\n- **Style** — Consistent with the project's existing conventions\n  (not your personal preferences)?\n\n### Categorize findings\n\nSort each finding into one bucket and label it explicitly:\n\n- **Must fix** — bugs, security issues, broken tests, contract\n  violations\n- **Should fix** — unclear naming, missing tests for non-trivial\n  paths, code smells\n- **Nit** — style preferences, minor suggestions, taste calls\n\nAlways include specific line references and concrete suggestions.\nAcknowledge what was done well — review is not adversarial.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Burying must-fix items after style comments.** When a security issue or correctness bug appears three paragraphs into a review, the author may miss it. Lead with must-fix items; put nits at the end.\n- **Vague comments without line references or concrete suggestions.** \"This looks weird\" is not actionable. Every finding needs a specific line reference and a concrete suggestion — what is the problem and what would fix it.\n- **Stamp-of-approval review.** Skimming the diff and approving to move it along defeats the purpose of review and gives the team false confidence. If you cannot read the changed lines, say so and ask to review in a smaller chunk.\n- **Reviewing huge diffs in one pass.** Large diffs cause reviewer fatigue and cause real issues to be missed. Either push back on PR scope or break the review into sessions (security first, then logic, then style).\n- **Missing the escalation trigger.** Line-by-line comments on a diff that has fundamental design issues waste both sides' time. When the design is wrong, stop the line review and raise the design concern first.\n- **Rewriting in review.** Proposing complete rewrites of code that works demotivates authors and overreaches the reviewer's role. Propose the improvement once; the author owns the code.\n- **No acknowledgment of what was done well.** All-negative reviews are adversarial over time and reduce the quality of future work. Code review should also surface what was done right.\n\n## Full reference\n\n### Example output shape\n\n> **Must fix:** `parse_input()` on line 42 doesn't handle empty\n> strings — this will panic.\n>\n> **Should fix:** The variable `x` on line 15 could be renamed to\n> `retry_count` for clarity.\n>\n> **Nit:** Consider extracting lines 30-45 into a helper function.\n>\n> Overall: Good separation of concerns. The error handling pattern\n> is clean.\n\n### Anti-patterns\n\n- **Rewriting in review** — propose, don't dictate. The author\n  owns the code.\n- **Bikeshedding** — if it's a nit, label it a nit and move on.\n- **Stamp-of-approval review** — skimming and approving without\n  reading the changed lines defeats the purpose.\n- **Vague comments** — \"this looks weird\" is not actionable. Say\n  what's weird and what would fix it.\n- **Reviewing in one pass when the diff is huge** — split the\n  review across sessions or push back on PR scope.\n\n### When to escalate\n\nIf the diff has fundamental design issues, stop the line-by-line\nreview and discuss the design first. Line comments on a diff that\nshould never have been written waste both sides' time.\n",{"name":5,"metadata":53,"description":61},{"processkit":54},{"id":55,"layer":56,"created":57,"version":58,"category":59,"apiVersion":60},"SKILL-code-review",3,1775433600000,"1.1.0","engineering","processkit.projectious.work\u002Fv1","Structured code review with a checklist covering correctness, clarity, tests, security, performance, and style. Use when reviewing a PR, diff, or set of code changes before merging — including phrases like \"review this\", \"check my changes\", or \"is this ready to merge\".\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-review","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-11 23:24:18",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add projectious-work\u002Fprocesskit --skill code-review",{"tool":75,"command":76},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill code-review",{"tool":78,"command":79},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.23.0\u002Fcontext\u002Fskills\u002Fengineering\u002Fcode-review\u002FSKILL.md",true,[],[84,108,128,149,166,184],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":93,"publishedAt":48},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[90],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[94,95,96,97,98,99,43,100,101,102,86,103,104,105,34,106,107],"management","skill management","create","update","package","alpha","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":115,"publishedAt":48},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[114],{"categoryNo":91,"categoryName":92,"taxonomyType":21,"taxonomyTypeDesc":22},[94,116,117,118,119,120,99,43,121,122,101,123,124,125,103,126,127],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":48},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[94,135,136,96,97,137,99,43,138,139,140,141,103,142,143,144,145,146,147,148],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":48},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[94,102,156,96,99,157,158,121,159,138,101,160,161,103,162,163,143,164,34,165],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":48},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[173,174,175,176,99,177,178,179,43,180,181,182,183],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":48},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[94,191,192,96,97,137,99,157,43,100,138,193,101,140,103,163,143,144,33,107],"capability","capability management","queries"]