[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73EAVCSPTBYDPPFJS3JSFQT":3,"skill-same:01M73EAVCSPTBYDPPFJS3JSFQT":67},{"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":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M73EAVCSPTBYDPPFJS3JSFQT","code-review",null,"Conducts thorough code reviews focusing on correctness, maintainability, security, and best practices. Use when: reviewing pull requests, evaluating code quality, providing constructive feedback, or ensuring code standards compliance. Software-engineering variant capability: composes with refactoring and follows test-driven-development.","5throck\u002Fai-workspace-standards","5throck","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F10958964?v=4","01M73BFEH0V0VS483TW4JD49JW","01M73BFEJ5VQZJHJSFTVPAZGDM",25,"AGPL-3.0","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-develop\u002F.gemini\u002Fskills\u002Fcode-review\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: code-review\ndescription: >\n  Conducts thorough code reviews focusing on correctness, maintainability, security, and\n  best practices. Use when: reviewing pull requests, evaluating code quality, providing\n  constructive feedback, or ensuring code standards compliance. Software-engineering\n  variant capability: composes with refactoring and follows test-driven-development.\ncapability: swe-code-review\nversion: 1.1.0\nscope: co-develop\nstatus: active\nowner: pm\nlast_reviewed: 2026-11-02\nprerequisites: none\nrelates_to:\n  - skill: refactoring\n    type: composes_with\ngemini-parity: skip\nmetadata:\n  type: process\n  triggers:\n    - code review\n    - review pr\n    - evaluate code\n    - check code quality\n    - pull request review\n    - code inspection\n---\n\n## Context\n\nThis skill provides systematic code review capabilities, ensuring code changes are correct, maintainable, secure, and follow best practices. It balances thoroughness with efficiency, providing actionable feedback while maintaining team velocity.\n\n## When to Use\n\n**Pull Request Reviews**:\n- Trigger: \"Review this PR\" or \"Check pull request\"\n- Use Case: Evaluating proposed code changes before merging\n\n**Code Quality Assessment**:\n- Trigger: \"Evaluate code quality\" or \"Review codebase\"\n- Use Case: Assessing overall code health and identifying improvements\n\n**Security Reviews**:\n- Trigger: \"Security review\" or \"Check for vulnerabilities\"\n- Use Case: Identifying security issues and potential exploits\n\n**Best Practices Compliance**:\n- Trigger: \"Check if code follows standards\" or \"Review against guidelines\"\n- Use Case: Ensuring code follows project conventions and best practices\n\n---\n\n## Execution Steps\n\n## Step 1: Review Preparation\n\n**Purpose**: Understand context and scope of the code review.\n\n**Preparation Steps**:\n1. **Understand the Purpose**:\n   - What problem does this code solve?\n   - What are the requirements or acceptance criteria?\n   - What changes are being made?\n\n2. **Review Context**:\n   - Related issues or tickets\n   - Design documents or specifications\n   - Previous discussions or decisions\n   - Dependencies and related code\n\n3. **Review Scope**:\n   - Files changed and lines affected\n   - Complexity of changes\n   - Risk level (high-risk areas need more scrutiny)\n   - Testing coverage included\n\n**Preparation Checklist**:\n- [ ] Understand the purpose and requirements\n- [ ] Review related documentation\n- [ ] Identify high-risk areas\n- [ ] Check test coverage\n- [ ] Set review focus areas\n\n---\n\n## Step 2: Code Quality Assessment\n\n**Purpose**: Evaluate code for correctness and maintainability.\n\n**Quality Criteria**:\n1. **Correctness**:\n   - Does the code solve the intended problem?\n   - Are there obvious bugs or logic errors?\n   - Are edge cases handled?\n   - Is error handling appropriate?\n\n2. **Readability**:\n   - Is the code easy to understand?\n   - Are variable and function names descriptive?\n   - Is the logic clear and straightforward?\n   - Are comments helpful and accurate?\n\n3. **Maintainability**:\n   - Is the code modular and well-organized?\n   - Are functions\u002Fclasses focused on single responsibilities?\n   - Is the code DRY (Don't Repeat Yourself)?\n   - Is it easy to modify or extend?\n\n4. **Performance**:\n   - Are there obvious performance issues?\n   - Are algorithms and data structures appropriate?\n   - Are there unnecessary computations or allocations?\n   - Is database access optimized?\n\n**Review Focus Areas**:\n- High-risk code (security, data handling, payments)\n- Complex logic or algorithms\n- Error handling and edge cases\n- Database queries and I\u002FO operations\n- Resource management (memory, connections, files)\n\n---\n\n## Step 3: Security Review\n\n**Purpose**: Identify security vulnerabilities and potential exploits.\n\n**Security Checklist**:\n1. **Input Validation**:\n   - Are user inputs validated and sanitized?\n   - Is there protection against injection attacks (SQL, XSS, command injection)?\n   - Are file uploads properly validated?\n\n2. **Authentication & Authorization**:\n   - Are authentication checks properly implemented?\n   - Are authorization checks enforced consistently?\n   - Are sensitive operations protected?\n\n3. **Data Protection**:\n   - Are sensitive data properly handled?\n   - Are secrets\u002Fcredentials properly stored?\n   - Is data encrypted at rest and in transit?\n   - Is logging free of sensitive information?\n\n4. **Dependencies**:\n   - Are dependencies up-to-date and secure?\n   - Are there known vulnerabilities in dependencies?\n   - Are dependencies from trusted sources?\n\n**Common Security Issues**:\n- SQL injection\n- Cross-site scripting (XSS)\n- Authentication bypass\n- Authorization flaws\n- Sensitive data exposure\n- Cryptographic weaknesses\n- Injection vulnerabilities\n- Insecure dependencies\n\n---\n\n## Step 4: Testing Assessment\n\n**Purpose**: Evaluate test coverage and quality.\n\n**Testing Review**:\n1. **Test Coverage**:\n   - Are new features tested?\n   - Are edge cases covered?\n   - Is error handling tested?\n   - Are there integration tests?\n\n2. **Test Quality**:\n   - Are tests clear and focused?\n   - Do tests have good assertions?\n   - Are test cases realistic?\n   - Are tests maintainable?\n\n3. **Test Gaps**:\n   - What scenarios aren't tested?\n   - What edge cases are missing?\n   - What error conditions aren't covered?\n   - What integration points aren't tested?\n\n**Testing Recommendations**:\n- Add unit tests for untested functions\n- Add integration tests for API endpoints\n- Add tests for edge cases\n- Add tests for error conditions\n- Improve test assertions and clarity\n\n---\n\n## Step 5: Standards Compliance\n\n**Purpose**: Ensure code follows project conventions and best practices.\n\n**Standards Checklist**:\n1. **Code Style**:\n   - Does code follow project style guide?\n   - Is formatting consistent (indentation, spacing)?\n   - Are naming conventions followed?\n   - Is file organization consistent?\n\n2. **Architecture Patterns**:\n   - Are design patterns used appropriately?\n   - Is the code consistent with existing architecture?\n   - Are separation of concerns maintained?\n   - Are dependencies managed properly?\n\n3. **Documentation**:\n   - Is complex code documented?\n   - Are public APIs documented?\n   - Are comments helpful and accurate?\n   - Is README or CHANGELOG updated?\n\n4. **Best Practices**:\n   - Are language\u002Fframework best practices followed?\n   - Are anti-patterns avoided?\n   - Is code idiomatic for the language?\n   - Are performance considerations addressed?\n\n---\n\n## Step 6: Feedback Delivery\n\n**Purpose**: Provide constructive, actionable feedback.\n\n**Feedback Principles**:\n1. **Be Specific**:\n   - Point to exact code locations\n   - Explain why something is problematic\n   - Provide concrete examples\n   - Suggest specific improvements\n\n2. **Be Constructive**:\n   - Focus on the code, not the coder\n   - Explain the reasoning behind feedback\n   - Offer solutions, not just problems\n   - Acknowledge good parts of the code\n\n3. **Prioritize Issues**:\n   - **Must Fix**: Critical bugs, security issues, breaking changes\n   - **Should Fix**: Important improvements, maintainability issues\n   - **Nice to Have**: Minor optimizations, style improvements\n   - **Future Consideration**: Ideas for future improvements\n\n4. **Balance Feedback**:\n   - Start with positive observations\n   - Group related issues together\n   - Provide explanations for suggestions\n   - End constructively\n\n**Feedback Structure**:\n```markdown\n## Summary\n[Brief overview of the review]\n\n## Strengths\n- [What's done well]\n- [Good patterns or practices]\n\n## Issues to Address\n\n### Must Fix\n1. [Critical issue with explanation and suggestion]\n\n### Should Fix\n1. [Important improvement with explanation]\n\n### Nice to Have\n1. [Minor optimization with explanation]\n\n## Approval Status\n[Approved \u002F Approved with changes \u002F Request changes]\n```\n\n---\n\n## Output Format\n\n**For Pull Request Reviews**:\n- Comprehensive code review feedback\n- Security vulnerability identification\n- Test coverage assessment\n- Standards compliance evaluation\n- Actionable improvement suggestions\n\n**For Code Quality Assessment**:\n- Overall code quality score\n- Specific improvement areas\n- Best practices recommendations\n- Refactoring suggestions\n- Technical debt inventory\n\n---\n\n## Best Practices\n\n**Review Quality**:\n✅ **Do**:\n- Be thorough but efficient\n- Provide specific, actionable feedback\n- Explain the \"why\" behind suggestions\n- Acknowledge good code and patterns\n- Prioritize issues by severity\n- Follow project review guidelines\n\n❌ **Don't**:\n- Be overly nitpicky about style\n- Provide vague feedback without specifics\n- Focus only on problems without solutions\n- Use harsh or dismissive language\n- Block PRs for trivial issues\n- Ignore context or requirements\n\n**Communication Quality**:\n✅ **Do**:\n- Start with positive observations\n- Group related feedback together\n- Use clear section headers\n- Provide code examples for suggestions\n- Offer to discuss in person if needed\n- Be respectful and collaborative\n\n❌ **Don't**:\n- Use sarcasm or humor that could be misinterpreted\n- Make it personal (\"you should have...\")\n- Overwhelm with too many comments\n- Comment on every minor issue\n- Be dismissive of approach or effort\n- Assume malice for mistakes\n\n---\n\n## Common Mistakes to Avoid\n\n**Review Anti-Patterns**:\n1. **Style Police**: Focusing only on formatting rather than substance\n2. **Approval Yea-Saying**: Not providing critical feedback when needed\n3. **Context Ignoring**: Reviewing code without understanding requirements\n4. **Solution Forcing**: Suggesting preferred approach without considering trade-offs\n5. **Delay Tactics**: Holding up reviews for minor issues\n\n**Feedback Anti-Patterns**:\n1. **Vague Criticism**: \"This is bad\" without explanation\n2. **Negativity Bias**: Only commenting on problems, not strengths\n3. **Overwhelming**: Too many comments that drown out important issues\n4. **Inconsistency**: Different standards for different people\n5. **Timing**: Waiting until last minute to review\n\n---\n\n## Spoke Derivation Note\n\nThis file is the hub-doctrine canonical for the co-develop generic dev spine\n(spec 2026-11-01-hub-consolidation-design, Phase 1 batch D). Co-develop\npipelines run it as written. A spoke variant derives from this doctrine by\nsubstituting the bindings below — the derivation never edits the\nsingle-valued frontmatter doctrine: `scope: co-develop` and\n`capability: swe-code-review` stay as written here, and the spoke labels\nlive in this note only.\n\nNo {{PROJECT_*}} placeholder is needed in this skill: its per-spoke deltas\nare frontmatter labels and skill-graph edges, not body prose, so they are\ndocumented as bindings rather than parameterized.\n\n| Spoke | Derivation binding |\n|---|---|\n| co-game | Renders `capability: game-code-review`, `scope: co-game`; `relates_to` swaps the `refactoring`\u002F`composes_with` edge for `arcade-physics` + `test-driven-development` (both `follows`); the description's closing sentence names the game-development variant capability. |\n| co-learning | Not adopted — absent from Projects\u002Fco-learning and its template. The fleet skill-graph projection carries only dangling reference nodes for it (content_hash null); it is not an installed consumer. |\n| co-abap | Not adopted — co-abap derives the domain-specific `abap-code-review` instead, which is outside this generic spine. |\n\n---\n\n## Related Skills\n\n- **security-review**: For specialized security auditing\n- **testing-qa**: For evaluating test coverage and quality\n- **refactoring**: For suggesting code improvements\n- **performance-optimization**: For identifying performance issues\n\n---\n\n## Code Review Tools\n\n**Automated Tools**:\n- Linters (ESLint, Pylint, RuboCop)\n- Static analysis tools (SonarQube, CodeQL)\n- Security scanners (Snyk, Dependabot)\n- Code coverage tools (Istanbul, JaCoCo)\n\n**Review Platforms**:\n- GitHub pull requests\n- GitLab merge requests\n- Bitbucket pull requests\n- Code review tools (Review Board, Phabricator)\n\n**Productivity Tips**:\n- Use keyboard shortcuts for navigation\n- Batch related comments together\n- Use templates for common feedback\n- Leverage automated tools first\n- Focus review time on high-risk areas\n","## Context\n\nThis skill provides systematic code review capabilities, ensuring code changes are correct, maintainable, secure, and follow best practices. It balances thoroughness with efficiency, providing actionable feedback while maintaining team velocity.\n\n## When to Use\n\n**Pull Request Reviews**:\n- Trigger: \"Review this PR\" or \"Check pull request\"\n- Use Case: Evaluating proposed code changes before merging\n\n**Code Quality Assessment**:\n- Trigger: \"Evaluate code quality\" or \"Review codebase\"\n- Use Case: Assessing overall code health and identifying improvements\n\n**Security Reviews**:\n- Trigger: \"Security review\" or \"Check for vulnerabilities\"\n- Use Case: Identifying security issues and potential exploits\n\n**Best Practices Compliance**:\n- Trigger: \"Check if code follows standards\" or \"Review against guidelines\"\n- Use Case: Ensuring code follows project conventions and best practices\n\n---\n\n## Execution Steps\n\n## Step 1: Review Preparation\n\n**Purpose**: Understand context and scope of the code review.\n\n**Preparation Steps**:\n1. **Understand the Purpose**:\n   - What problem does this code solve?\n   - What are the requirements or acceptance criteria?\n   - What changes are being made?\n\n2. **Review Context**:\n   - Related issues or tickets\n   - Design documents or specifications\n   - Previous discussions or decisions\n   - Dependencies and related code\n\n3. **Review Scope**:\n   - Files changed and lines affected\n   - Complexity of changes\n   - Risk level (high-risk areas need more scrutiny)\n   - Testing coverage included\n\n**Preparation Checklist**:\n- [ ] Understand the purpose and requirements\n- [ ] Review related documentation\n- [ ] Identify high-risk areas\n- [ ] Check test coverage\n- [ ] Set review focus areas\n\n---\n\n## Step 2: Code Quality Assessment\n\n**Purpose**: Evaluate code for correctness and maintainability.\n\n**Quality Criteria**:\n1. **Correctness**:\n   - Does the code solve the intended problem?\n   - Are there obvious bugs or logic errors?\n   - Are edge cases handled?\n   - Is error handling appropriate?\n\n2. **Readability**:\n   - Is the code easy to understand?\n   - Are variable and function names descriptive?\n   - Is the logic clear and straightforward?\n   - Are comments helpful and accurate?\n\n3. **Maintainability**:\n   - Is the code modular and well-organized?\n   - Are functions\u002Fclasses focused on single responsibilities?\n   - Is the code DRY (Don't Repeat Yourself)?\n   - Is it easy to modify or extend?\n\n4. **Performance**:\n   - Are there obvious performance issues?\n   - Are algorithms and data structures appropriate?\n   - Are there unnecessary computations or allocations?\n   - Is database access optimized?\n\n**Review Focus Areas**:\n- High-risk code (security, data handling, payments)\n- Complex logic or algorithms\n- Error handling and edge cases\n- Database queries and I\u002FO operations\n- Resource management (memory, connections, files)\n\n---\n\n## Step 3: Security Review\n\n**Purpose**: Identify security vulnerabilities and potential exploits.\n\n**Security Checklist**:\n1. **Input Validation**:\n   - Are user inputs validated and sanitized?\n   - Is there protection against injection attacks (SQL, XSS, command injection)?\n   - Are file uploads properly validated?\n\n2. **Authentication & Authorization**:\n   - Are authentication checks properly implemented?\n   - Are authorization checks enforced consistently?\n   - Are sensitive operations protected?\n\n3. **Data Protection**:\n   - Are sensitive data properly handled?\n   - Are secrets\u002Fcredentials properly stored?\n   - Is data encrypted at rest and in transit?\n   - Is logging free of sensitive information?\n\n4. **Dependencies**:\n   - Are dependencies up-to-date and secure?\n   - Are there known vulnerabilities in dependencies?\n   - Are dependencies from trusted sources?\n\n**Common Security Issues**:\n- SQL injection\n- Cross-site scripting (XSS)\n- Authentication bypass\n- Authorization flaws\n- Sensitive data exposure\n- Cryptographic weaknesses\n- Injection vulnerabilities\n- Insecure dependencies\n\n---\n\n## Step 4: Testing Assessment\n\n**Purpose**: Evaluate test coverage and quality.\n\n**Testing Review**:\n1. **Test Coverage**:\n   - Are new features tested?\n   - Are edge cases covered?\n   - Is error handling tested?\n   - Are there integration tests?\n\n2. **Test Quality**:\n   - Are tests clear and focused?\n   - Do tests have good assertions?\n   - Are test cases realistic?\n   - Are tests maintainable?\n\n3. **Test Gaps**:\n   - What scenarios aren't tested?\n   - What edge cases are missing?\n   - What error conditions aren't covered?\n   - What integration points aren't tested?\n\n**Testing Recommendations**:\n- Add unit tests for untested functions\n- Add integration tests for API endpoints\n- Add tests for edge cases\n- Add tests for error conditions\n- Improve test assertions and clarity\n\n---\n\n## Step 5: Standards Compliance\n\n**Purpose**: Ensure code follows project conventions and best practices.\n\n**Standards Checklist**:\n1. **Code Style**:\n   - Does code follow project style guide?\n   - Is formatting consistent (indentation, spacing)?\n   - Are naming conventions followed?\n   - Is file organization consistent?\n\n2. **Architecture Patterns**:\n   - Are design patterns used appropriately?\n   - Is the code consistent with existing architecture?\n   - Are separation of concerns maintained?\n   - Are dependencies managed properly?\n\n3. **Documentation**:\n   - Is complex code documented?\n   - Are public APIs documented?\n   - Are comments helpful and accurate?\n   - Is README or CHANGELOG updated?\n\n4. **Best Practices**:\n   - Are language\u002Fframework best practices followed?\n   - Are anti-patterns avoided?\n   - Is code idiomatic for the language?\n   - Are performance considerations addressed?\n\n---\n\n## Step 6: Feedback Delivery\n\n**Purpose**: Provide constructive, actionable feedback.\n\n**Feedback Principles**:\n1. **Be Specific**:\n   - Point to exact code locations\n   - Explain why something is problematic\n   - Provide concrete examples\n   - Suggest specific improvements\n\n2. **Be Constructive**:\n   - Focus on the code, not the coder\n   - Explain the reasoning behind feedback\n   - Offer solutions, not just problems\n   - Acknowledge good parts of the code\n\n3. **Prioritize Issues**:\n   - **Must Fix**: Critical bugs, security issues, breaking changes\n   - **Should Fix**: Important improvements, maintainability issues\n   - **Nice to Have**: Minor optimizations, style improvements\n   - **Future Consideration**: Ideas for future improvements\n\n4. **Balance Feedback**:\n   - Start with positive observations\n   - Group related issues together\n   - Provide explanations for suggestions\n   - End constructively\n\n**Feedback Structure**:\n```markdown\n## Summary\n[Brief overview of the review]\n\n## Strengths\n- [What's done well]\n- [Good patterns or practices]\n\n## Issues to Address\n\n### Must Fix\n1. [Critical issue with explanation and suggestion]\n\n### Should Fix\n1. [Important improvement with explanation]\n\n### Nice to Have\n1. [Minor optimization with explanation]\n\n## Approval Status\n[Approved \u002F Approved with changes \u002F Request changes]\n```\n\n---\n\n## Output Format\n\n**For Pull Request Reviews**:\n- Comprehensive code review feedback\n- Security vulnerability identification\n- Test coverage assessment\n- Standards compliance evaluation\n- Actionable improvement suggestions\n\n**For Code Quality Assessment**:\n- Overall code quality score\n- Specific improvement areas\n- Best practices recommendations\n- Refactoring suggestions\n- Technical debt inventory\n\n---\n\n## Best Practices\n\n**Review Quality**:\n✅ **Do**:\n- Be thorough but efficient\n- Provide specific, actionable feedback\n- Explain the \"why\" behind suggestions\n- Acknowledge good code and patterns\n- Prioritize issues by severity\n- Follow project review guidelines\n\n❌ **Don't**:\n- Be overly nitpicky about style\n- Provide vague feedback without specifics\n- Focus only on problems without solutions\n- Use harsh or dismissive language\n- Block PRs for trivial issues\n- Ignore context or requirements\n\n**Communication Quality**:\n✅ **Do**:\n- Start with positive observations\n- Group related feedback together\n- Use clear section headers\n- Provide code examples for suggestions\n- Offer to discuss in person if needed\n- Be respectful and collaborative\n\n❌ **Don't**:\n- Use sarcasm or humor that could be misinterpreted\n- Make it personal (\"you should have...\")\n- Overwhelm with too many comments\n- Comment on every minor issue\n- Be dismissive of approach or effort\n- Assume malice for mistakes\n\n---\n\n## Common Mistakes to Avoid\n\n**Review Anti-Patterns**:\n1. **Style Police**: Focusing only on formatting rather than substance\n2. **Approval Yea-Saying**: Not providing critical feedback when needed\n3. **Context Ignoring**: Reviewing code without understanding requirements\n4. **Solution Forcing**: Suggesting preferred approach without considering trade-offs\n5. **Delay Tactics**: Holding up reviews for minor issues\n\n**Feedback Anti-Patterns**:\n1. **Vague Criticism**: \"This is bad\" without explanation\n2. **Negativity Bias**: Only commenting on problems, not strengths\n3. **Overwhelming**: Too many comments that drown out important issues\n4. **Inconsistency**: Different standards for different people\n5. **Timing**: Waiting until last minute to review\n\n---\n\n## Spoke Derivation Note\n\nThis file is the hub-doctrine canonical for the co-develop generic dev spine\n(spec 2026-11-01-hub-consolidation-design, Phase 1 batch D). Co-develop\npipelines run it as written. A spoke variant derives from this doctrine by\nsubstituting the bindings below — the derivation never edits the\nsingle-valued frontmatter doctrine: `scope: co-develop` and\n`capability: swe-code-review` stay as written here, and the spoke labels\nlive in this note only.\n\nNo {{PROJECT_*}} placeholder is needed in this skill: its per-spoke deltas\nare frontmatter labels and skill-graph edges, not body prose, so they are\ndocumented as bindings rather than parameterized.\n\n| Spoke | Derivation binding |\n|---|---|\n| co-game | Renders `capability: game-code-review`, `scope: co-game`; `relates_to` swaps the `refactoring`\u002F`composes_with` edge for `arcade-physics` + `test-driven-development` (both `follows`); the description's closing sentence names the game-development variant capability. |\n| co-learning | Not adopted — absent from Projects\u002Fco-learning and its template. The fleet skill-graph projection carries only dangling reference nodes for it (content_hash null); it is not an installed consumer. |\n| co-abap | Not adopted — co-abap derives the domain-specific `abap-code-review` instead, which is outside this generic spine. |\n\n---\n\n## Related Skills\n\n- **security-review**: For specialized security auditing\n- **testing-qa**: For evaluating test coverage and quality\n- **refactoring**: For suggesting code improvements\n- **performance-optimization**: For identifying performance issues\n\n---\n\n## Code Review Tools\n\n**Automated Tools**:\n- Linters (ESLint, Pylint, RuboCop)\n- Static analysis tools (SonarQube, CodeQL)\n- Security scanners (Snyk, Dependabot)\n- Code coverage tools (Istanbul, JaCoCo)\n\n**Review Platforms**:\n- GitHub pull requests\n- GitLab merge requests\n- Bitbucket pull requests\n- Code review tools (Review Board, Phabricator)\n\n**Productivity Tips**:\n- Use keyboard shortcuts for navigation\n- Batch related comments together\n- Use templates for common feedback\n- Leverage automated tools first\n- Focus review time on high-risk areas\n",{"name":5,"owner":23,"scope":24,"status":25,"version":26,"metadata":27,"capability":36,"relates_to":37,"description":41,"gemini-parity":42,"last_reviewed":43,"prerequisites":44},"pm","co-develop","active","1.1.0",{"type":28,"triggers":29},"process",[30,31,32,33,34,35],"code review","review pr","evaluate code","check code quality","pull request review","code inspection","swe-code-review",[38],{"type":39,"skill":40},"composes_with","refactoring","Conducts thorough code reviews focusing on correctness, maintainability, security, and best practices. Use when: reviewing pull requests, evaluating code quality, providing constructive feedback, or ensuring code standards compliance. Software-engineering variant capability: composes with refactoring and follows test-driven-development.\n","skip",1793577600000,"none","main","1162ccc568cf90c01b3886d6143cbfd851a37883","templates\u002Fco-develop\u002F.gemini\u002Fskills\u002Fcode-review",9,"https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards","https:\u002F\u002Fgithub.com\u002F5throck","Experienced in digital transformation, enterprise IT, startup acceleration, and business strategy. Focused on building practical systems that connect technolo","2026-11-14 21:22:34",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add 5throck\u002Fai-workspace-standards --skill code-review",{"tool":59,"command":60},"bunx","bunx skills add 5throck\u002Fai-workspace-standards --skill code-review",{"tool":62,"command":63},"pnpm","pnpm dlx skills add 5throck\u002Fai-workspace-standards --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fco-develop\u002F.gemini\u002Fskills\u002Fcode-review\u002FSKILL.md",true,[],[68,74,80,86,93,100],{"skillNo":69,"name":70,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":18},"01M73HG1JK5J3A3AMG6WNH8V6E","discovery","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Ftemplates\u002Fco-fixt\u002Fskills\u002Fdiscovery\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":18},"01M73HG0VZMCNH9YJX8ERV6R7C","x","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Ftemplates\u002Fco-bad\u002Fskills\u002Fx\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":18},"01M73HFZR1J6DMW5BRXG1ND6ET","root-skill","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftests\u002Fprocedures-fixtures\u002Fskills\u002Froot-skill\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":18},"01M73HFSYWV2FPF895DK295NCV","update-bun-packages","Scans, updates, and upgrades Bun dependencies and packages across the AI workspace (L0) or standalone project (L2\u002FL3) while ensuring lockfile consistency, package.json version bumps, and security compliance. Use when: updating bun dependencies, upgrading packages to @latest, checking outdated packages in workspace or templates.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Fupdate-bun-packages\u002FSKILL.md",[],[],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":18},"01M73HFPZ7G1AHF80CDEJ94SZ9","ui-ux-design-intelligence","Provides comprehensive UI\u002FUX design capabilities including design system creation, component design, visual hierarchy, and user-centered design principles. Use when: building design systems, creating visual designs, designing UI components, or establishing design specifications.","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Fui-ux-design-intelligence\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":18},"01M73HFMBER8AQEX2HF02JE2G4","translate","Translation helper for README and documentation files with diff preview and guidance","https:\u002F\u002Fgithub.com\u002F5throck\u002Fai-workspace-standards\u002Fblob\u002Fmain\u002Ftemplates\u002Fcommon\u002Fskills\u002Ftranslate\u002FSKILL.md",[],[]]