{ "schemaVersion": "1.0", "item": { "slug": "code-review", "name": "Code Review", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/wpank/code-review", "canonicalUrl": "https://clawhub.ai/wpank/code-review", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/code-review", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=code-review", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "README.md", "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "slug": "code-review", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-05-01T22:23:07.987Z", "expiresAt": "2026-05-08T22:23:07.987Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=code-review", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=code-review", "contentDisposition": "attachment; filename=\"code-review-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null, "slug": "code-review" }, "scope": "item", "summary": "Item download looks usable.", "detail": "Yavira can redirect you to the upstream package for this item.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/code-review" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/code-review", "agentPageUrl": "https://openagent3.xyz/skills/code-review/agent", "manifestUrl": "https://openagent3.xyz/skills/code-review/agent.json", "briefUrl": "https://openagent3.xyz/skills/code-review/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Then review README.md for any prerequisites, environment setup, or post-install checks. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Then review README.md for any prerequisites, environment setup, or post-install checks. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Code Review Checklist", "body": "Thorough, structured approach to reviewing code. Work through each dimension systematically rather than scanning randomly." }, { "title": "OpenClaw / Moltbot / Clawbot", "body": "npx clawhub@latest install code-review" }, { "title": "Review Dimensions", "body": "DimensionFocusPrioritySecurityVulnerabilities, auth, data exposureCriticalPerformanceSpeed, memory, scalability bottlenecksHighCorrectnessLogic errors, edge cases, data integrityHighMaintainabilityReadability, structure, future-proofingMediumTestingCoverage, quality, reliability of testsMediumAccessibilityWCAG compliance, keyboard nav, screen readersMediumDocumentationComments, API docs, changelog entriesLow" }, { "title": "Security Checklist", "body": "Review every change for these vulnerabilities:\n\nSQL Injection — All queries use parameterized statements or an ORM; no string concatenation with user input\n XSS — User-provided content is escaped/sanitized before rendering; dangerouslySetInnerHTML or equivalent is justified and safe\n CSRF Protection — State-changing requests require valid CSRF tokens; SameSite cookie attributes are set\n Authentication — Every protected endpoint verifies the user is authenticated before processing\n Authorization — Resource access is scoped to the requesting user's permissions; no IDOR vulnerabilities\n Input Validation — All external input (params, headers, body, files) is validated for type, length, format, and range on the server side\n Secrets Management — No API keys, passwords, tokens, or credentials in source code; secrets come from environment variables or a vault\n Dependency Safety — New dependencies are from trusted sources, actively maintained, and free of known CVEs\n Sensitive Data — PII, tokens, and secrets are never logged, included in error messages, or returned in API responses\n Rate Limiting — Public and auth endpoints have rate limits to prevent brute-force and abuse\n File Upload Safety — Uploaded files are validated for type and size, stored outside the webroot, and served with safe Content-Type headers\n HTTP Security Headers — Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security are set" }, { "title": "Performance Checklist", "body": "N+1 Queries — Database access patterns are batched or joined; no loops issuing individual queries\n Unnecessary Re-renders — Components only re-render when their relevant state/props change; memoization is applied where measurable\n Memory Leaks — Event listeners, subscriptions, timers, and intervals are cleaned up on unmount/disposal\n Bundle Size — New dependencies are tree-shakeable; large libraries are loaded dynamically; no full-library imports for a single function\n Lazy Loading — Heavy components, routes, and below-the-fold content use lazy loading / code splitting\n Caching Strategy — Expensive computations and API responses use appropriate caching (memoization, HTTP cache headers, Redis)\n Database Indexing — Queries filter/sort on indexed columns; new queries have been checked with EXPLAIN\n Pagination — List endpoints and queries use pagination or cursor-based fetching; no unbounded SELECT *\n Async Operations — Long-running tasks are offloaded to background jobs or queues rather than blocking request threads\n Image & Asset Optimization — Images are properly sized, use modern formats (WebP/AVIF), and leverage CDN delivery" }, { "title": "Correctness Checklist", "body": "Edge Cases — Empty arrays, empty strings, zero values, negative numbers, and maximum values are handled\n Null/Undefined Handling — Nullable values are checked before access; optional chaining or guards prevent runtime errors\n Off-by-One Errors — Loop bounds, array slicing, pagination offsets, and range calculations are verified\n Race Conditions — Concurrent access to shared state uses locks, transactions, or atomic operations\n Timezone Handling — Dates are stored in UTC; display conversion happens at the presentation layer\n Unicode & Encoding — String operations handle multi-byte characters; text encoding is explicit (UTF-8)\n Integer Overflow / Precision — Arithmetic on large numbers or currency uses appropriate types (BigInt, Decimal)\n Error Propagation — Errors from async calls and external services are caught and handled; promises are never silently swallowed\n State Consistency — Multi-step mutations are transactional; partial failures leave the system in a valid state\n Boundary Validation — Values at the boundaries of valid ranges (min, max, exactly-at-limit) are tested" }, { "title": "Maintainability Checklist", "body": "Naming Clarity — Variables, functions, and classes have descriptive names that reveal intent\n Single Responsibility — Each function/class/module does one thing; changes to one concern don't ripple through unrelated code\n DRY — Duplicated logic is extracted into shared utilities; copy-pasted blocks are consolidated\n Cyclomatic Complexity — Functions have low branching complexity; deeply nested chains are refactored\n Error Handling — Errors are caught at appropriate boundaries, logged with context, and surfaced meaningfully\n Dead Code Removal — Commented-out code, unused imports, unreachable branches, and obsolete feature flags are removed\n Magic Numbers & Strings — Literal values are extracted into named constants with clear semantics\n Consistent Patterns — New code follows the conventions already established in the codebase\n Function Length — Functions are short enough to understand at a glance; long functions are decomposed\n Dependency Direction — Dependencies point inward (infrastructure to domain); core logic does not import from UI or framework layers" }, { "title": "Testing Checklist", "body": "Test Coverage — New logic paths have corresponding tests; critical paths have both happy-path and failure-case tests\n Edge Case Tests — Tests cover boundary values, empty inputs, nulls, and error conditions\n No Flaky Tests — Tests are deterministic; no reliance on timing, external services, or shared mutable state\n Test Independence — Each test sets up its own state and tears it down; test order does not affect results\n Meaningful Assertions — Tests assert on behavior and outcomes, not implementation details\n Test Readability — Tests follow Arrange-Act-Assert; test names describe the scenario and expected outcome\n Mocking Discipline — Only external boundaries (network, DB, filesystem) are mocked\n Regression Tests — Bug fixes include a test that reproduces the original bug and proves it is resolved" }, { "title": "Review Process", "body": "Work through the code in three passes. Do not try to catch everything in one read.\n\nPassFocusTimeWhat to Look ForFirstHigh-level structure2-5 minArchitecture fit, file organization, API design, overall approachSecondLine-by-line detailBulkLogic errors, security issues, performance problems, edge casesThirdEdge cases & hardening5 minFailure modes, concurrency, boundary values, missing tests" }, { "title": "First Pass (2-5 minutes)", "body": "Read the PR description and linked issue\nScan the file list — does the change scope make sense?\nCheck the overall approach — is this the right solution to the problem?\nVerify the change does not introduce architectural drift" }, { "title": "Second Pass (bulk of review time)", "body": "Read each file diff top to bottom\nCheck every function change against the checklists above\nVerify error handling at every I/O boundary\nFlag anything that makes you pause — trust your instincts" }, { "title": "Third Pass (5 minutes)", "body": "Think about what could go wrong in production\nCheck for missing tests on the code paths you flagged\nVerify rollback safety — can this change be reverted without data loss?\nConfirm documentation and changelog are updated if needed" }, { "title": "Severity Levels", "body": "Classify every comment by severity so the author knows what blocks merge.\n\nLevelLabelMeaningBlocks Merge?Critical[CRITICAL]Security vulnerability, data loss, or crash in productionYesMajor[MAJOR]Bug, logic error, or significant performance regressionYesMinor[MINOR]Improvement that would reduce future maintenance costNoNitpick[NIT]Style preference, naming suggestion, or trivial cleanupNo\n\nAlways prefix your review comment with the severity label. This removes ambiguity about what matters." }, { "title": "Principles", "body": "Be specific — Point to the exact line and explain the issue, not just \"this is wrong\"\nExplain why — State the risk or consequence, not just the rule\nSuggest a fix — Offer a concrete alternative or code snippet when possible\nAsk, don't demand — Use questions for subjective points: \"What do you think about...?\"\nAcknowledge good work — Call out clean solutions, clever optimizations, or thorough tests\nSeparate blocking from non-blocking — Use severity labels so the author knows what matters" }, { "title": "Example Comments", "body": "Bad:\n\nThis is wrong. Fix it.\n\nGood:\n\n[MAJOR] This query interpolates user input directly into the SQL string (line 42), which is vulnerable to SQL injection. Consider using a parameterized query:\nSELECT * FROM users WHERE id = $1\n\nBad:\n\nWhy didn't you add tests?\n\nGood:\n\n[MINOR] The new calculateDiscount() function has a few branching paths — could we add tests for the zero-quantity and negative-price edge cases to prevent regressions?\n\nBad:\n\nI would have done this differently.\n\nGood:\n\n[NIT] This works well. An alternative approach could be extracting the retry logic into a shared withRetry() wrapper — but that's optional and could be a follow-up." }, { "title": "Review Anti-Patterns", "body": "Avoid these common traps that waste time and damage team trust:\n\nAnti-PatternDescriptionRubber-StampingApproving without reading. Creates false confidence and lets bugs through.BikesheddingSpending 30 minutes debating a variable name while ignoring a race condition.Blocking on StyleRefusing to approve over formatting that a linter should enforce automatically.GatekeepingRequiring your personal preferred approach when the submitted one is correct.Drive-by ReviewsLeaving one vague comment and disappearing. Commit to following through.Scope Creep ReviewsRequesting unrelated refactors that should be separate PRs.Stale ReviewsLetting PRs sit for days. Review within 24 hours or hand off to someone else.Emotional Language\"This is terrible\" or \"obviously wrong.\" Critique the code, not the person." }, { "title": "NEVER Do", "body": "NEVER approve without reading every changed line — rubber-stamping is worse than no review\nNEVER block a PR solely for style preferences — use a linter; humans review logic\nNEVER leave feedback without a severity level — ambiguity causes wasted cycles\nNEVER request changes without explaining why — \"fix this\" teaches nothing\nNEVER review more than 400 lines in one sitting — comprehension drops sharply; break large PRs into sessions\nNEVER skip the security checklist — one missed vulnerability outweighs a hundred style nits\nNEVER make it personal — review the code, never the coder; assume good intent" } ], "body": "Code Review Checklist\n\nThorough, structured approach to reviewing code. Work through each dimension systematically rather than scanning randomly.\n\nInstallation\nOpenClaw / Moltbot / Clawbot\nnpx clawhub@latest install code-review\n\nReview Dimensions\nDimension\tFocus\tPriority\nSecurity\tVulnerabilities, auth, data exposure\tCritical\nPerformance\tSpeed, memory, scalability bottlenecks\tHigh\nCorrectness\tLogic errors, edge cases, data integrity\tHigh\nMaintainability\tReadability, structure, future-proofing\tMedium\nTesting\tCoverage, quality, reliability of tests\tMedium\nAccessibility\tWCAG compliance, keyboard nav, screen readers\tMedium\nDocumentation\tComments, API docs, changelog entries\tLow\nSecurity Checklist\n\nReview every change for these vulnerabilities:\n\n SQL Injection — All queries use parameterized statements or an ORM; no string concatenation with user input\n XSS — User-provided content is escaped/sanitized before rendering; dangerouslySetInnerHTML or equivalent is justified and safe\n CSRF Protection — State-changing requests require valid CSRF tokens; SameSite cookie attributes are set\n Authentication — Every protected endpoint verifies the user is authenticated before processing\n Authorization — Resource access is scoped to the requesting user's permissions; no IDOR vulnerabilities\n Input Validation — All external input (params, headers, body, files) is validated for type, length, format, and range on the server side\n Secrets Management — No API keys, passwords, tokens, or credentials in source code; secrets come from environment variables or a vault\n Dependency Safety — New dependencies are from trusted sources, actively maintained, and free of known CVEs\n Sensitive Data — PII, tokens, and secrets are never logged, included in error messages, or returned in API responses\n Rate Limiting — Public and auth endpoints have rate limits to prevent brute-force and abuse\n File Upload Safety — Uploaded files are validated for type and size, stored outside the webroot, and served with safe Content-Type headers\n HTTP Security Headers — Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security are set\nPerformance Checklist\n N+1 Queries — Database access patterns are batched or joined; no loops issuing individual queries\n Unnecessary Re-renders — Components only re-render when their relevant state/props change; memoization is applied where measurable\n Memory Leaks — Event listeners, subscriptions, timers, and intervals are cleaned up on unmount/disposal\n Bundle Size — New dependencies are tree-shakeable; large libraries are loaded dynamically; no full-library imports for a single function\n Lazy Loading — Heavy components, routes, and below-the-fold content use lazy loading / code splitting\n Caching Strategy — Expensive computations and API responses use appropriate caching (memoization, HTTP cache headers, Redis)\n Database Indexing — Queries filter/sort on indexed columns; new queries have been checked with EXPLAIN\n Pagination — List endpoints and queries use pagination or cursor-based fetching; no unbounded SELECT *\n Async Operations — Long-running tasks are offloaded to background jobs or queues rather than blocking request threads\n Image & Asset Optimization — Images are properly sized, use modern formats (WebP/AVIF), and leverage CDN delivery\nCorrectness Checklist\n Edge Cases — Empty arrays, empty strings, zero values, negative numbers, and maximum values are handled\n Null/Undefined Handling — Nullable values are checked before access; optional chaining or guards prevent runtime errors\n Off-by-One Errors — Loop bounds, array slicing, pagination offsets, and range calculations are verified\n Race Conditions — Concurrent access to shared state uses locks, transactions, or atomic operations\n Timezone Handling — Dates are stored in UTC; display conversion happens at the presentation layer\n Unicode & Encoding — String operations handle multi-byte characters; text encoding is explicit (UTF-8)\n Integer Overflow / Precision — Arithmetic on large numbers or currency uses appropriate types (BigInt, Decimal)\n Error Propagation — Errors from async calls and external services are caught and handled; promises are never silently swallowed\n State Consistency — Multi-step mutations are transactional; partial failures leave the system in a valid state\n Boundary Validation — Values at the boundaries of valid ranges (min, max, exactly-at-limit) are tested\nMaintainability Checklist\n Naming Clarity — Variables, functions, and classes have descriptive names that reveal intent\n Single Responsibility — Each function/class/module does one thing; changes to one concern don't ripple through unrelated code\n DRY — Duplicated logic is extracted into shared utilities; copy-pasted blocks are consolidated\n Cyclomatic Complexity — Functions have low branching complexity; deeply nested chains are refactored\n Error Handling — Errors are caught at appropriate boundaries, logged with context, and surfaced meaningfully\n Dead Code Removal — Commented-out code, unused imports, unreachable branches, and obsolete feature flags are removed\n Magic Numbers & Strings — Literal values are extracted into named constants with clear semantics\n Consistent Patterns — New code follows the conventions already established in the codebase\n Function Length — Functions are short enough to understand at a glance; long functions are decomposed\n Dependency Direction — Dependencies point inward (infrastructure to domain); core logic does not import from UI or framework layers\nTesting Checklist\n Test Coverage — New logic paths have corresponding tests; critical paths have both happy-path and failure-case tests\n Edge Case Tests — Tests cover boundary values, empty inputs, nulls, and error conditions\n No Flaky Tests — Tests are deterministic; no reliance on timing, external services, or shared mutable state\n Test Independence — Each test sets up its own state and tears it down; test order does not affect results\n Meaningful Assertions — Tests assert on behavior and outcomes, not implementation details\n Test Readability — Tests follow Arrange-Act-Assert; test names describe the scenario and expected outcome\n Mocking Discipline — Only external boundaries (network, DB, filesystem) are mocked\n Regression Tests — Bug fixes include a test that reproduces the original bug and proves it is resolved\nReview Process\n\nWork through the code in three passes. Do not try to catch everything in one read.\n\nPass\tFocus\tTime\tWhat to Look For\nFirst\tHigh-level structure\t2-5 min\tArchitecture fit, file organization, API design, overall approach\nSecond\tLine-by-line detail\tBulk\tLogic errors, security issues, performance problems, edge cases\nThird\tEdge cases & hardening\t5 min\tFailure modes, concurrency, boundary values, missing tests\nFirst Pass (2-5 minutes)\nRead the PR description and linked issue\nScan the file list — does the change scope make sense?\nCheck the overall approach — is this the right solution to the problem?\nVerify the change does not introduce architectural drift\nSecond Pass (bulk of review time)\nRead each file diff top to bottom\nCheck every function change against the checklists above\nVerify error handling at every I/O boundary\nFlag anything that makes you pause — trust your instincts\nThird Pass (5 minutes)\nThink about what could go wrong in production\nCheck for missing tests on the code paths you flagged\nVerify rollback safety — can this change be reverted without data loss?\nConfirm documentation and changelog are updated if needed\nSeverity Levels\n\nClassify every comment by severity so the author knows what blocks merge.\n\nLevel\tLabel\tMeaning\tBlocks Merge?\nCritical\t[CRITICAL]\tSecurity vulnerability, data loss, or crash in production\tYes\nMajor\t[MAJOR]\tBug, logic error, or significant performance regression\tYes\nMinor\t[MINOR]\tImprovement that would reduce future maintenance cost\tNo\nNitpick\t[NIT]\tStyle preference, naming suggestion, or trivial cleanup\tNo\n\nAlways prefix your review comment with the severity label. This removes ambiguity about what matters.\n\nGiving Feedback\nPrinciples\nBe specific — Point to the exact line and explain the issue, not just \"this is wrong\"\nExplain why — State the risk or consequence, not just the rule\nSuggest a fix — Offer a concrete alternative or code snippet when possible\nAsk, don't demand — Use questions for subjective points: \"What do you think about...?\"\nAcknowledge good work — Call out clean solutions, clever optimizations, or thorough tests\nSeparate blocking from non-blocking — Use severity labels so the author knows what matters\nExample Comments\n\nBad:\n\nThis is wrong. Fix it.\n\nGood:\n\n[MAJOR] This query interpolates user input directly into the SQL string (line 42), which is vulnerable to SQL injection. Consider using a parameterized query:\n\nSELECT * FROM users WHERE id = $1\n\n\nBad:\n\nWhy didn't you add tests?\n\nGood:\n\n[MINOR] The new calculateDiscount() function has a few branching paths — could we add tests for the zero-quantity and negative-price edge cases to prevent regressions?\n\nBad:\n\nI would have done this differently.\n\nGood:\n\n[NIT] This works well. An alternative approach could be extracting the retry logic into a shared withRetry() wrapper — but that's optional and could be a follow-up.\n\nReview Anti-Patterns\n\nAvoid these common traps that waste time and damage team trust:\n\nAnti-Pattern\tDescription\nRubber-Stamping\tApproving without reading. Creates false confidence and lets bugs through.\nBikeshedding\tSpending 30 minutes debating a variable name while ignoring a race condition.\nBlocking on Style\tRefusing to approve over formatting that a linter should enforce automatically.\nGatekeeping\tRequiring your personal preferred approach when the submitted one is correct.\nDrive-by Reviews\tLeaving one vague comment and disappearing. Commit to following through.\nScope Creep Reviews\tRequesting unrelated refactors that should be separate PRs.\nStale Reviews\tLetting PRs sit for days. Review within 24 hours or hand off to someone else.\nEmotional Language\t\"This is terrible\" or \"obviously wrong.\" Critique the code, not the person.\nNEVER Do\nNEVER approve without reading every changed line — rubber-stamping is worse than no review\nNEVER block a PR solely for style preferences — use a linter; humans review logic\nNEVER leave feedback without a severity level — ambiguity causes wasted cycles\nNEVER request changes without explaining why — \"fix this\" teaches nothing\nNEVER review more than 400 lines in one sitting — comprehension drops sharply; break large PRs into sessions\nNEVER skip the security checklist — one missed vulnerability outweighs a hundred style nits\nNEVER make it personal — review the code, never the coder; assume good intent" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/wpank/code-review", "publisherUrl": "https://clawhub.ai/wpank/code-review", "owner": "wpank", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/code-review", "downloadUrl": "https://openagent3.xyz/downloads/code-review", "agentUrl": "https://openagent3.xyz/skills/code-review/agent", "manifestUrl": "https://openagent3.xyz/skills/code-review/agent.json", "briefUrl": "https://openagent3.xyz/skills/code-review/agent.md" } }