[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWZ1BKNTGF0T4HWRST9AV9":3,"skill-same:01M6KWZ1BKNTGF0T4HWRST9AV9":94},{"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":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":37,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6KWZ1BKNTGF0T4HWRST9AV9","code-reviewer",null,"Reviews a diff across six dimensions — correctness, design, readability, performance, testing, security — plus the repo's documented standards, code smells, and what the diff could delete, and returns findings classified BLOCKING \u002F SUGGESTION \u002F NITPICK. Runs in a forked context so the diff reading stays out of the main conversation. Use when the user asks for a code review, feedback on changes, or a pre-PR check of the working diff.","dougborg\u002Fharness-kit","dougborg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1261222?v=4","01M6KWS4PB51EYD4ZDJJSGNGB2","Doug Borg","01M6KWS4T8ZZW6SX5QZS9B5BN2",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-reviewer\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,45,46,47,48],"code","code reviewer","reviewer","repo","nitpick","for","kit","reviews","main","conversation","standards","diff","use","code review","feedback","harness","pr","performance","design","testing","2026-11-10 10:12:30",false,"---\nname: code-reviewer\ndescription: >-\n  Reviews a diff across six dimensions — correctness, design, readability,\n  performance, testing, security — plus the repo's documented standards, code\n  smells, and what the diff could delete, and returns findings classified\n  BLOCKING \u002F SUGGESTION \u002F NITPICK. Runs in a forked context so the diff\n  reading stays out of the main conversation. Use when the user asks for a\n  code review, feedback on changes, or a pre-PR check of the working diff.\ncontext: fork\nagent: harness-kit:code-reviewer\nbackground: false\neffort: high\nallowed-tools: Read, Grep, Glob, Bash(git diff*), Bash(git log*)\n---\n\n# Code Reviewer\n\nThis is the **standards pass**: the six dimensions, the repo's documented\nstandards, the smell baseline, and the complexity lens. Checking the diff\nagainst its spec (the issues a PR closes) is a separate pass that needs its\nown context, so the review-pr skill runs both in parallel and reports them\nside by side.\n\nReport findings; leave the edits to whoever acts on the review. Skip anything\na linter, type checker, or automated reviewer already flags, and add context\nrather than noise.\n\n## 1. Gather the change\n\nThis skill runs forked, with no conversation history, so take everything from\ngit and the files themselves rather than from \"the change we just discussed\".\n\n```bash\ngit diff \u003Cbase>...HEAD --stat   # the branch against its base, e.g. main...HEAD\ngit diff \u003Cbase>...HEAD\ngit log \u003Cbase>..HEAD --oneline\ngit diff -- path\u002Fto\u002Ffile.js     # one file\n```\n\nReview the whole branch by default; use the range or paths the prompt names\nwhen it names one. Done when you have\nread every changed file and can say what the change does and why.\n\n## 2. Review it\n\nApply each dimension; [dimensions.md](dimensions.md) holds the questions, red\nflags, and example feedback for each.\n\n- **Correctness**: logic, semantic correctness, type safety. Correctness\n  comes first: a type error, logic bug, or data race blocks approval.\n- **Design**: architecture, interfaces, patterns. Design decisions propagate,\n  so a poor one blocks downstream work.\n- **Readability**: naming, clarity, documentation.\n- **Performance**: efficiency, algorithms, resource usage.\n- **Testing**: coverage, edge cases, test quality.\n- **Security**: injection, auth, secrets. Any vulnerability (injection, auth\n  bypass, secret exposure) is BLOCKING.\n\n**Documented standards.** Cite the repo's written standards (`CLAUDE.md`,\n`AGENTS.md`, `CONTRIBUTING.md`, `CODING_STANDARDS.md`, path-scoped rule\nfiles) by file and rule. A documented standard is the strongest evidence a\nfinding can have.\n\n**Smells.** Flag Fowler code smells as judgement calls (SUGGESTION or\nNITPICK), and let a documented standard that endorses the pattern override\nthem: mysterious name, duplicated code, feature envy, data clumps, primitive\nobsession, repeated switches, shotgun surgery, divergent change, speculative\ngenerality, message chains, middle man, refused bequest. Name the smell and\nquote the hunk; skip a hunk already reported under Complexity.\n\n**Complexity lens.** Report what the diff could delete, one line each,\nnumbered `C1.`, `C2.`, ... so they don't collide with other findings and the\nuser can say \"fix 2 and C3\". Tag each:\n\n- `delete:` dead or speculative; nothing replaces it.\n- `reuse:` duplicates a helper already in the repo; name its path.\n- `stdlib:` hand-rolls what the standard library ships; name the function.\n- `native:` does what the platform already does; name the feature.\n- `yagni:` one implementation, config nobody sets, a single-caller layer.\n- `shrink:` the same logic in fewer lines; show the shorter form.\n\nEnd with `net: -N lines possible` or \"Lean already.\" Leave alone what the\nminimal-change skill always keeps: trust-boundary validation, data-loss error\nhandling, security, accessibility, hardware calibration, explicit\nrequirements, and the one runnable check that non-trivial logic keeps.\n\n```text\nC1. src\u002Frepo.py:88 — yagni: AbstractRepository has one implementation. Inline it until a second exists.\nC2. src\u002Fdates.ts:4 — native: moment.js imported for one format call. Intl.DateTimeFormat, no dependency.\nnet: -40 lines possible\n```\n\nSome changes need more depth: read [special-cases.md](special-cases.md) for a\nlarge PR, a design that touches several systems, a refactor or migration of\nlegacy code, or a new or changed third-party dependency.\n\nDone when every changed file has been weighed against all six dimensions, the\ndocumented standards, the smells, and the complexity lens.\n\n## 3. Classify and report\n\nClassify each finding:\n\n- **BLOCKING**: cannot merge without fixing (correctness, security, design\n  that breaks contracts).\n- **SUGGESTION**: worth addressing; improves quality (minor design, a\n  performance optimization).\n- **NITPICK**: nice to have (naming, a formatting edge case).\n\nReport in the code-reviewer agent's output format, which the review-pr skill\nparses: `## Review Summary`, then `### BLOCKING`, `### SUGGESTIONS`,\n`### NITPICKS`, `### Complexity` (ending on its `net:` line), and\n`### What Looks Good`. Open the summary with a verdict: \"Approved\", \"Request\nchanges\", or \"Comment\". Suggestions stay optional when the code is otherwise\nsolid.\n\nDone when every finding carries a severity and a `file:line`, and the summary\nopens with the verdict.\n\n## Related\n\n- `\u002Freview-pr`: the full PR review lifecycle, running this standards pass and\n  the spec pass side by side.\n- The `code-reviewer` agent: the forked context this skill runs in\n  (harness-kit plugin, or project `.claude\u002Fagents\u002Fcode-reviewer.md`). If it is\n  unavailable, apply the review inline in this context.\n- `CLAUDE.md`: project-specific review standards.\n","# Code Reviewer\n\nThis is the **standards pass**: the six dimensions, the repo's documented\nstandards, the smell baseline, and the complexity lens. Checking the diff\nagainst its spec (the issues a PR closes) is a separate pass that needs its\nown context, so the review-pr skill runs both in parallel and reports them\nside by side.\n\nReport findings; leave the edits to whoever acts on the review. Skip anything\na linter, type checker, or automated reviewer already flags, and add context\nrather than noise.\n\n## 1. Gather the change\n\nThis skill runs forked, with no conversation history, so take everything from\ngit and the files themselves rather than from \"the change we just discussed\".\n\n```bash\ngit diff \u003Cbase>...HEAD --stat   # the branch against its base, e.g. main...HEAD\ngit diff \u003Cbase>...HEAD\ngit log \u003Cbase>..HEAD --oneline\ngit diff -- path\u002Fto\u002Ffile.js     # one file\n```\n\nReview the whole branch by default; use the range or paths the prompt names\nwhen it names one. Done when you have\nread every changed file and can say what the change does and why.\n\n## 2. Review it\n\nApply each dimension; [dimensions.md](dimensions.md) holds the questions, red\nflags, and example feedback for each.\n\n- **Correctness**: logic, semantic correctness, type safety. Correctness\n  comes first: a type error, logic bug, or data race blocks approval.\n- **Design**: architecture, interfaces, patterns. Design decisions propagate,\n  so a poor one blocks downstream work.\n- **Readability**: naming, clarity, documentation.\n- **Performance**: efficiency, algorithms, resource usage.\n- **Testing**: coverage, edge cases, test quality.\n- **Security**: injection, auth, secrets. Any vulnerability (injection, auth\n  bypass, secret exposure) is BLOCKING.\n\n**Documented standards.** Cite the repo's written standards (`CLAUDE.md`,\n`AGENTS.md`, `CONTRIBUTING.md`, `CODING_STANDARDS.md`, path-scoped rule\nfiles) by file and rule. A documented standard is the strongest evidence a\nfinding can have.\n\n**Smells.** Flag Fowler code smells as judgement calls (SUGGESTION or\nNITPICK), and let a documented standard that endorses the pattern override\nthem: mysterious name, duplicated code, feature envy, data clumps, primitive\nobsession, repeated switches, shotgun surgery, divergent change, speculative\ngenerality, message chains, middle man, refused bequest. Name the smell and\nquote the hunk; skip a hunk already reported under Complexity.\n\n**Complexity lens.** Report what the diff could delete, one line each,\nnumbered `C1.`, `C2.`, ... so they don't collide with other findings and the\nuser can say \"fix 2 and C3\". Tag each:\n\n- `delete:` dead or speculative; nothing replaces it.\n- `reuse:` duplicates a helper already in the repo; name its path.\n- `stdlib:` hand-rolls what the standard library ships; name the function.\n- `native:` does what the platform already does; name the feature.\n- `yagni:` one implementation, config nobody sets, a single-caller layer.\n- `shrink:` the same logic in fewer lines; show the shorter form.\n\nEnd with `net: -N lines possible` or \"Lean already.\" Leave alone what the\nminimal-change skill always keeps: trust-boundary validation, data-loss error\nhandling, security, accessibility, hardware calibration, explicit\nrequirements, and the one runnable check that non-trivial logic keeps.\n\n```text\nC1. src\u002Frepo.py:88 — yagni: AbstractRepository has one implementation. Inline it until a second exists.\nC2. src\u002Fdates.ts:4 — native: moment.js imported for one format call. Intl.DateTimeFormat, no dependency.\nnet: -40 lines possible\n```\n\nSome changes need more depth: read [special-cases.md](special-cases.md) for a\nlarge PR, a design that touches several systems, a refactor or migration of\nlegacy code, or a new or changed third-party dependency.\n\nDone when every changed file has been weighed against all six dimensions, the\ndocumented standards, the smells, and the complexity lens.\n\n## 3. Classify and report\n\nClassify each finding:\n\n- **BLOCKING**: cannot merge without fixing (correctness, security, design\n  that breaks contracts).\n- **SUGGESTION**: worth addressing; improves quality (minor design, a\n  performance optimization).\n- **NITPICK**: nice to have (naming, a formatting edge case).\n\nReport in the code-reviewer agent's output format, which the review-pr skill\nparses: `## Review Summary`, then `### BLOCKING`, `### SUGGESTIONS`,\n`### NITPICKS`, `### Complexity` (ending on its `net:` line), and\n`### What Looks Good`. Open the summary with a verdict: \"Approved\", \"Request\nchanges\", or \"Comment\". Suggestions stay optional when the code is otherwise\nsolid.\n\nDone when every finding carries a severity and a `file:line`, and the summary\nopens with the verdict.\n\n## Related\n\n- `\u002Freview-pr`: the full PR review lifecycle, running this standards pass and\n  the spec pass side by side.\n- The `code-reviewer` agent: the forked context this skill runs in\n  (harness-kit plugin, or project `.claude\u002Fagents\u002Fcode-reviewer.md`). If it is\n  unavailable, apply the review inline in this context.\n- `CLAUDE.md`: project-specific review standards.\n",{"name":5,"agent":54,"effort":55,"context":56,"background":50,"description":7,"allowed-tools":57},"harness-kit:code-reviewer","high","fork","Read, Grep, Glob, Bash(git diff*), Bash(git log*)","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fengineering\u002Fcode-reviewer",1,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit","https:\u002F\u002Fgithub.com\u002Fdougborg","http:\u002F\u002Fdougborg.org","Platforms and Infrastructure Software Engineer","2026-11-13 07:43:37",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add dougborg\u002Fharness-kit --skill code-reviewer",{"tool":72,"command":73},"bunx","bunx skills add dougborg\u002Fharness-kit --skill code-reviewer",{"tool":75,"command":76},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill code-reviewer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-reviewer\u002FSKILL.md",true,[80,86,90],{"path":81,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"agents\u002Fopenai.yaml","REFERENCE","参考文档",129,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-reviewer\u002Fagents\u002Fopenai.yaml",{"path":87,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":88,"sourceHtmlUrl":89},"dimensions.md",8623,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-reviewer\u002Fdimensions.md",{"path":91,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":92,"sourceHtmlUrl":93},"special-cases.md",3822,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fcode-reviewer\u002Fspecial-cases.md",[95,112,131,161,183,200],{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":104,"publishedAt":49},"01M6KX4J65S5FZKMSN5DQNPSZM","teach","Teach yourself a topic over several sessions, with lessons, references, and a record of what you've learned.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fteach\u002FSKILL.md",[101],{"categoryNo":102,"categoryName":103,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000039","教师与教育",[97,105,106,107,108,109,110,111],"lessons","you","with","learned","record","references","sessions",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":121,"publishedAt":49},"01M6KX4FSSG7MHF00JDT5QT0BQ","svg-logo-designer","Generate SVG logos with multiple concepts, layouts, and color variations.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fsvg-logo-designer\u002FSKILL.md",[118],{"categoryNo":119,"categoryName":120,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[122,123,124,125,126,127,107,128,129,130],"logo","designer","svg logo designer","SVG","color","concepts","write","read","generate",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":143,"publishedAt":49},"01M6KX4BD3J9MZPPSH4MENH7FP","documentation-writer","Writes and revises human-facing documentation — READMEs, contributor and setup guides, reference pages, architecture notes, CLAUDE.md, and changelog entries. Covers picking the right document type for the question being asked, structuring for skimming, writing examples that actually run, and keeping docs from going stale. Use when creating or rewriting docs, when a README has drifted from the code, or when deciding where a piece of information belongs. For SKILL.md and agent files, use \u002Fskill-writer instead.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[137,140],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":141,"categoryName":142,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[144,145,146,147,148,149,150,151,41,152,153,154,29,155,156,34,157,158,159,160],"writer","documentation writer","documentation","entries","changelog","architecture","document","files","question","README","notes","examples","pages","information","guides","type","writing",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":49},"01M6KX47ZJ4ZWHDN3MY8SYAWZZ","adhd-mode","Shapes every response for a reader with ADHD: the next action first, numbered steps, progress restated each turn, tangents held back, concrete time estimates, wins made visible. Stays on for the rest of the session until the reader says \"stop adhd mode\". On Claude Code, the harness-kit:adhd output style does the same without invoking this skill.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",[],[168,169,170,171,34,172,35,107,173,174,175,176,177,178,179,180,181,182,44,29],"adhd","mode","adhd mode","next","action","output","style","progress","time","back","stop","session","reader","first","REST",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":49},"01M6KX463Z6E18EPDW873GDHKB","wait-what","That last message didn't land: re-explain it with the missing context.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fwait-what\u002FSKILL.md",[],[190,191,192,107,193,194,195,196,197,198,199],"wait","wait what","re","it","missing","message","context","explain","land","last",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":49},"01M6KX43NE1NB0Y2HECY515730","to-questionnaire","Turn a decision you can't make alone into a questionnaire for the one person who can answer it, filled in async or together in a meeting.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fto-questionnaire\u002FSKILL.md",[],[207,208,34,209,210,211,212,106,213,193,214,215],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision"]