[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CTCNT56PWVA20XZNDF7TH4":3,"skill-same:01M6CTCNT56PWVA20XZNDF7TH4":88},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":61,"updatedAt":62,"install":63,"resources":75},"01M6CTCNT56PWVA20XZNDF7TH4","code-review",null,"Reviews code in sections (architecture, quality, tests, performance) with interactive feedback. Use for pull request reviews, pre-merge checks or self-review before handoff.","vibbs\u002Fcompany-os","vibbs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7379149?v=4","01M6CT6M03CAS1H7RA89F3965B","Vibbs Dod","01M6CT6M4MY60C9FFQ3AAR2RSK",6,"MIT","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\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,45],"review","code","code review","handoff","performance","merge","architecture","pr","pull request","pull","file","feedback","quality","interactive","use","interactive feedback","self","2026-11-10 10:12:30",false,"---\nname: code-review\ndescription: Reviews code in sections (architecture, quality, tests, performance) with interactive feedback. Use for pull request reviews, pre-merge checks or self-review before handoff.\nruntimes:\n  claude:\n    user-invocable: true\n    argument-hint: \"\u003CPR number or file paths>\"\n---\n\n# Code Review\n\n## Reference\n- **ID**: S-ENG-06\n- **Category**: Engineering \u002F QA\n- **Inputs**: PR diff or file paths, company.config.yaml, standards\u002Fcoding\u002F, standards\u002Fengineering-preferences.md\n- **Outputs**: Interactive review with decisions, review summary artifact in `artifacts\u002Fqa-reports\u002F`\n- **Used by**: Engineering Agent (self-review), QA & Release Agent (release quality), User (ad-hoc)\n- **Tool scripts**: `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`\n\n## Purpose\n\nConduct a structured, multi-section code review that systematically evaluates architecture, code quality, test coverage, and performance. The review is interactive — issues are presented one section at a time, the user provides feedback on each, and decisions are recorded in a review summary artifact.\n\n## When to Use\n\n- Before merging a PR (user invokes `\u002Fcode-review 42` or `\u002Fcode-review \u003Cfile-paths>`)\n- Engineering Agent self-review before handing off to QA\n- QA Agent code quality evaluation during release readiness\n- Ad-hoc review of any code area\n\n## Code Review Procedure\n\n### Step 0: Load Context\n\nBefore reviewing any code:\n\n1. **Read `company.config.yaml`** — extract tech stack, conventions, API standards\n2. **Read `standards\u002Fcoding\u002F`** — load project-specific coding conventions\n3. **Read `standards\u002Fengineering-preferences.md`** — load the team's engineering philosophy:\n   - DRY stance (relaxed \u002F moderate \u002F aggressive)\n   - Testing philosophy (minimal \u002F balanced \u002F thorough)\n   - Engineering calibration (move-fast \u002F engineered-enough \u002F robust)\n   - Edge case handling (optimistic \u002F balanced \u002F thorough)\n   - Explicitness preference (clever-ok \u002F pragmatic \u002F explicit)\n   - Error handling strictness (lenient \u002F moderate \u002F strict)\n   - Performance awareness (not-premature \u002F balanced \u002F performance-first)\n4. If `standards\u002Fengineering-preferences.md` does not exist, use the built-in defaults (see Appendix A) and note this to the user\n\n### Step 1: Determine Review Scope\n\nDetermine what code to review based on the argument:\n\n| Argument | Scope | Method |\n|----------|-------|--------|\n| PR number (e.g., `42`) | PR diff only | Run `gh pr diff 42` (fallback: `git diff origin\u002Fmain...HEAD`) |\n| File paths (e.g., `src\u002Fauth\u002F`) | Specific files\u002Fdirectories | Read files directly |\n| No argument | Uncommitted changes | Run `git diff HEAD` for staged+unstaged |\n| Branch name (e.g., `feature\u002Fauth`) | Branch diff from base | Run `git diff main...feature\u002Fauth` |\n\nAfter determining scope, report:\n- Number of files changed\n- Approximate lines added\u002Fremoved\n- File types involved (e.g., \"12 TypeScript files, 3 test files, 1 migration\")\n\n**Large PR heuristic**: If more than 30 files changed, recommend narrowing scope (review by module or directory) rather than attempting to review everything at once.\n\n### Step 2: Ask Review Mode\n\n**BEFORE YOU START:** Ask whether the user wants:\n\n**1\u002F BIG CHANGE** — Work through interactively, one section at a time (Architecture → Code Quality → Tests → Performance → Security) with at most 4 top issues in each section.\n\n**2\u002F SMALL CHANGE** — Work through interactively, ONE question per review section.\n\nWait for user response before proceeding. The user may also specify a focus mode: \"focus on [section]\" to run only one section with full BIG CHANGE depth.\n\n---\n\n### Section 1: Architecture Review\n\nEvaluate the changed code against architectural concerns. In BIG CHANGE mode, raise up to 4 issues. In SMALL CHANGE mode, raise only the single most important issue (or state \"No architectural concerns\").\n\n**What to evaluate:**\n- Overall system design and component boundaries\n- Dependency graph and coupling concerns (are new dependencies introduced? justified?)\n- Data flow patterns and potential bottlenecks\n- Scaling characteristics and single points of failure\n- Security architecture (auth boundaries, data access patterns, API exposure)\n- Consistency with existing architecture in `artifacts\u002Frfcs\u002F`\n- Tech stack fitness (per `company.config.yaml`)\n\n**FOR EACH ISSUE**: Output the explanation and pros and cons, AND your opinionated recommendation and why. Then use AskUserQuestion to present options. Number issues and letter options (Issue 1, Option A\u002FB\u002FC). Recommended option is always listed first.\n\n**Issue format:**\n\n```\n### Issue 1: [Concise title]\n\n**Problem**: [Concrete description with file path and line reference]\n\n`path\u002Fto\u002Ffile.ts:42-58` — [what is wrong and why it matters]\n\n**Options**:\n\n**Option A (Recommended): [Action name]**\n- Implementation: [what to change]\n- Effort: [low\u002Fmedium\u002Fhigh]\n- Risk: [what could go wrong]\n- Impact: [how it affects other code]\n- Maintenance: [ongoing burden]\n- Why recommended: [map to engineering preferences]\n\n**Option B: [Alternative action]**\n- Implementation: [what to change]\n- Effort: [low\u002Fmedium\u002Fhigh]\n- Risk: [what could go wrong]\n- Impact: [how it affects other code]\n- Maintenance: [ongoing burden]\n\n**Option C: Do nothing**\n- Risk: [what happens if left as-is]\n- When acceptable: [under what circumstances this is OK]\n```\n\nAfter presenting all issues for Section 1, ask:\n\n> **Section 1 (Architecture) complete. [N] issues raised.**\n> Ready to proceed to Section 2 (Code Quality)? Or want to discuss any issue further?\n\nWait for user response.\n\n---\n\n### Section 2: Code Quality Review\n\nEvaluate code organization and craftsmanship. Calibrate against `standards\u002Fengineering-preferences.md`.\n\n**What to evaluate:**\n- Code organization and module structure\n- DRY violations — **be aggressive** per engineering preferences; flag any repeated logic, even 2 occurrences if the pattern is non-trivial\n- Error handling patterns — are errors caught, typed, and not swallowed?\n- Missing edge cases — call these out explicitly with concrete scenarios\n- Technical debt hotspots — code that works but will be painful later\n- Over-engineering vs under-engineering (calibrate against the \"engineered enough\" preference)\n- Naming clarity — is the code self-documenting?\n- Consistency with `standards\u002Fcoding\u002F` conventions\n- Areas that are over-engineered or under-engineered relative to preferences\n- **Feature flag debt**: stale flags past cleanup SLA, flags missing cleanup dates, dead flag branches in code (check `feature_flags.cleanup_sla_days` from config)\n- **Mobile compatibility**: if `platforms.responsive` is true, check for hardcoded widths, missing viewport considerations, touch targets \u003C 44x44px, non-responsive layouts\n\nSame issue format as Section 1. Pause for user feedback after completing.\n\n---\n\n### Section 3: Test Review\n\nEvaluate test coverage and quality.\n\n**What to evaluate:**\n- Test coverage gaps — which new\u002Fchanged code paths have no tests?\n- Test quality and assertion strength — are assertions specific or just \"does not throw\"?\n- Missing edge case coverage — enumerate specific edge cases that should be tested\n- Untested failure modes and error paths — errors that could happen but are not exercised\n- Test isolation — do tests depend on external state or ordering?\n- Mock appropriateness — per coding standards: mock external services only, never your own code\n- Test naming — do test names describe behavior (`should X when Y`)?\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Section 4: Performance Review\n\nEvaluate performance characteristics. Skip issues that are clearly irrelevant to the change scope.\n\n**What to evaluate:**\n- N+1 queries and database access patterns (if applicable)\n- Memory-usage concerns (large allocations, unbounded growth, leaks)\n- Caching opportunities (repeated expensive computation or data fetch)\n- Algorithmic complexity — O(n²) or worse where O(n) or O(n log n) is achievable\n- Unnecessary re-renders (React\u002Ffrontend specific, if applicable)\n- Bundle size impact (if frontend changes)\n- I\u002FO patterns — unnecessary sequential operations that could be parallel\n- Slow or high-complexity code paths\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Section 5: Security Review\n\n**Default: enabled at all stages. In SMALL CHANGE mode, flag at least 1 security consideration.**\n\nCheck for:\n- **Injection patterns**: SQL injection (parameterized queries?), command injection (`exec`\u002F`spawn` with user input?), XSS (output encoding?)\n- **Auth checks**: Every mutating endpoint has authentication middleware? Authorization checked on resource access?\n- **IDOR patterns**: Resource IDs from request params validated against current user's ownership\u002Fpermissions?\n- **Secrets in code**: Hardcoded API keys, tokens, passwords? `.env` files committed?\n- **Header security**: CORS configured restrictively? CSP headers set? HSTS enabled?\n- **Dependency risk**: Known vulnerabilities in dependencies? Outdated packages with security patches?\n\n**Note:** AI-generated code has elevated risk in auth middleware ordering, SQL construction, and ownership checks. Pay extra attention to these patterns.\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Step 3: Review Summary\n\nAfter all five sections are complete (or the focused section if user requested a single one), produce a review summary:\n\n```markdown\n## Code Review Summary\n\n### Scope\n- **Reviewed**: [PR #42 \u002F files \u002F branch diff]\n- **Mode**: [BIG CHANGE \u002F SMALL CHANGE]\n- **Files**: [N files, M lines changed]\n- **Engineering preferences**: [standards\u002Fengineering-preferences.md | built-in defaults]\n\n### Issues by Section\n\n| Section | Issues Found | Resolved | Deferred | Action Items |\n|---------|-------------|----------|----------|--------------|\n| Architecture | N | N | N | N |\n| Code Quality | N | N | N | N |\n| Test | N | N | N | N |\n| Performance | N | N | N | N |\n| Security | N | N | N | N |\n| **Total** | **N** | **N** | **N** | **N** |\n\n### Decisions Made\n1. **Issue 1** ([section]): [chosen option] — [rationale]\n2. **Issue 2** ([section]): [chosen option] — [rationale]\n...\n\n### Action Items\n- [ ] [Specific action with file reference]\n- [ ] [Specific action with file reference]\n\n### Deferred Items\n- [Issue N]: [reason for deferring, conditions for revisiting]\n\n### Overall Assessment\n[APPROVE \u002F APPROVE WITH CHANGES \u002F REQUEST CHANGES \u002F BLOCK]\n\n[1-2 sentence summary of the overall code quality and readiness]\n```\n\n### Step 4: Produce Review Artifact\n\nIf the review was part of a formal workflow (not an ad-hoc quick check), save the summary as an artifact:\n\n1. Use the review report template (see `review-report-template.md` in this skill directory)\n2. Store in `artifacts\u002Fqa-reports\u002F`\n3. Set appropriate lineage:\n   - `parent`: the RFC or PRD this code implements (if known)\n   - `depends_on`: any related artifacts\n4. Set status to `review`\n5. Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh` on the artifact\n\nAsk the user: \"Save this review as a formal artifact in `artifacts\u002Fqa-reports\u002F`? (y\u002Fn)\"\n\n## Focus Mode\n\nIf the user specifies a single section (e.g., `\u002Fcode-review src\u002Fauth\u002F --focus performance`), run only that section with the full BIG CHANGE depth (up to 4 issues), skip the others, and still produce a summary.\n\n## Agent Integration Modes\n\n### Engineering Self-Review (Pre-Handoff)\n\nWhen invoked by the Engineering Agent as a pre-handoff self-review:\n1. Run all five sections in SMALL CHANGE mode (one issue per section) automatically\n2. Do not pause between sections (non-interactive)\n3. If any issue is rated as blocking: stop and address before handoff\n4. Produce the summary artifact automatically and link to the RFC\n\n### QA Release Review\n\nWhen invoked by the QA & Release Agent:\n1. Run Code Quality, Test, and Security sections in BIG CHANGE mode\n2. Run Architecture and Performance in SMALL CHANGE mode\n3. Results feed into the release-readiness-gate Bar 5 (Code Quality) evaluation\n\n## Appendix A: Default Engineering Preferences\n\nIf `standards\u002Fengineering-preferences.md` does not exist, use these defaults:\n\n- **DRY**: aggressive — flag any non-trivial logic that appears twice\n- **Testing**: thorough — well-tested code is non-negotiable; err on the side of more tests\n- **Engineering calibration**: engineered-enough — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction)\n- **Edge cases**: thorough — err on the side of handling more edge cases, not fewer; thoughtfulness > speed\n- **Explicitness**: explicit — bias toward explicit, readable code; no magic\n- **Error handling**: strict — never swallow errors; use typed errors at system boundaries\n- **Performance**: balanced — consider performance for hot paths and database queries; don't micro-optimize cold paths\n\n## Quality Checklist\n\n- [ ] `company.config.yaml` was read for tech stack context\n- [ ] `standards\u002Fcoding\u002F` was read for project conventions\n- [ ] `standards\u002Fengineering-preferences.md` was read (or defaults noted)\n- [ ] Review scope was clearly determined and reported\n- [ ] Review mode (BIG\u002FSMALL) was confirmed with user\n- [ ] Each section paused for user feedback (in interactive mode)\n- [ ] Issues are numbered and options are lettered\n- [ ] Recommended option is always listed first (Option A)\n- [ ] Every issue references concrete file paths and line numbers\n- [ ] Summary includes all decisions made during the review\n- [ ] Action items are specific and actionable\n- [ ] Review artifact was offered\u002Fproduced if part of formal workflow\n","# Code Review\n\n## Reference\n- **ID**: S-ENG-06\n- **Category**: Engineering \u002F QA\n- **Inputs**: PR diff or file paths, company.config.yaml, standards\u002Fcoding\u002F, standards\u002Fengineering-preferences.md\n- **Outputs**: Interactive review with decisions, review summary artifact in `artifacts\u002Fqa-reports\u002F`\n- **Used by**: Engineering Agent (self-review), QA & Release Agent (release quality), User (ad-hoc)\n- **Tool scripts**: `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`\n\n## Purpose\n\nConduct a structured, multi-section code review that systematically evaluates architecture, code quality, test coverage, and performance. The review is interactive — issues are presented one section at a time, the user provides feedback on each, and decisions are recorded in a review summary artifact.\n\n## When to Use\n\n- Before merging a PR (user invokes `\u002Fcode-review 42` or `\u002Fcode-review \u003Cfile-paths>`)\n- Engineering Agent self-review before handing off to QA\n- QA Agent code quality evaluation during release readiness\n- Ad-hoc review of any code area\n\n## Code Review Procedure\n\n### Step 0: Load Context\n\nBefore reviewing any code:\n\n1. **Read `company.config.yaml`** — extract tech stack, conventions, API standards\n2. **Read `standards\u002Fcoding\u002F`** — load project-specific coding conventions\n3. **Read `standards\u002Fengineering-preferences.md`** — load the team's engineering philosophy:\n   - DRY stance (relaxed \u002F moderate \u002F aggressive)\n   - Testing philosophy (minimal \u002F balanced \u002F thorough)\n   - Engineering calibration (move-fast \u002F engineered-enough \u002F robust)\n   - Edge case handling (optimistic \u002F balanced \u002F thorough)\n   - Explicitness preference (clever-ok \u002F pragmatic \u002F explicit)\n   - Error handling strictness (lenient \u002F moderate \u002F strict)\n   - Performance awareness (not-premature \u002F balanced \u002F performance-first)\n4. If `standards\u002Fengineering-preferences.md` does not exist, use the built-in defaults (see Appendix A) and note this to the user\n\n### Step 1: Determine Review Scope\n\nDetermine what code to review based on the argument:\n\n| Argument | Scope | Method |\n|----------|-------|--------|\n| PR number (e.g., `42`) | PR diff only | Run `gh pr diff 42` (fallback: `git diff origin\u002Fmain...HEAD`) |\n| File paths (e.g., `src\u002Fauth\u002F`) | Specific files\u002Fdirectories | Read files directly |\n| No argument | Uncommitted changes | Run `git diff HEAD` for staged+unstaged |\n| Branch name (e.g., `feature\u002Fauth`) | Branch diff from base | Run `git diff main...feature\u002Fauth` |\n\nAfter determining scope, report:\n- Number of files changed\n- Approximate lines added\u002Fremoved\n- File types involved (e.g., \"12 TypeScript files, 3 test files, 1 migration\")\n\n**Large PR heuristic**: If more than 30 files changed, recommend narrowing scope (review by module or directory) rather than attempting to review everything at once.\n\n### Step 2: Ask Review Mode\n\n**BEFORE YOU START:** Ask whether the user wants:\n\n**1\u002F BIG CHANGE** — Work through interactively, one section at a time (Architecture → Code Quality → Tests → Performance → Security) with at most 4 top issues in each section.\n\n**2\u002F SMALL CHANGE** — Work through interactively, ONE question per review section.\n\nWait for user response before proceeding. The user may also specify a focus mode: \"focus on [section]\" to run only one section with full BIG CHANGE depth.\n\n---\n\n### Section 1: Architecture Review\n\nEvaluate the changed code against architectural concerns. In BIG CHANGE mode, raise up to 4 issues. In SMALL CHANGE mode, raise only the single most important issue (or state \"No architectural concerns\").\n\n**What to evaluate:**\n- Overall system design and component boundaries\n- Dependency graph and coupling concerns (are new dependencies introduced? justified?)\n- Data flow patterns and potential bottlenecks\n- Scaling characteristics and single points of failure\n- Security architecture (auth boundaries, data access patterns, API exposure)\n- Consistency with existing architecture in `artifacts\u002Frfcs\u002F`\n- Tech stack fitness (per `company.config.yaml`)\n\n**FOR EACH ISSUE**: Output the explanation and pros and cons, AND your opinionated recommendation and why. Then use AskUserQuestion to present options. Number issues and letter options (Issue 1, Option A\u002FB\u002FC). Recommended option is always listed first.\n\n**Issue format:**\n\n```\n### Issue 1: [Concise title]\n\n**Problem**: [Concrete description with file path and line reference]\n\n`path\u002Fto\u002Ffile.ts:42-58` — [what is wrong and why it matters]\n\n**Options**:\n\n**Option A (Recommended): [Action name]**\n- Implementation: [what to change]\n- Effort: [low\u002Fmedium\u002Fhigh]\n- Risk: [what could go wrong]\n- Impact: [how it affects other code]\n- Maintenance: [ongoing burden]\n- Why recommended: [map to engineering preferences]\n\n**Option B: [Alternative action]**\n- Implementation: [what to change]\n- Effort: [low\u002Fmedium\u002Fhigh]\n- Risk: [what could go wrong]\n- Impact: [how it affects other code]\n- Maintenance: [ongoing burden]\n\n**Option C: Do nothing**\n- Risk: [what happens if left as-is]\n- When acceptable: [under what circumstances this is OK]\n```\n\nAfter presenting all issues for Section 1, ask:\n\n> **Section 1 (Architecture) complete. [N] issues raised.**\n> Ready to proceed to Section 2 (Code Quality)? Or want to discuss any issue further?\n\nWait for user response.\n\n---\n\n### Section 2: Code Quality Review\n\nEvaluate code organization and craftsmanship. Calibrate against `standards\u002Fengineering-preferences.md`.\n\n**What to evaluate:**\n- Code organization and module structure\n- DRY violations — **be aggressive** per engineering preferences; flag any repeated logic, even 2 occurrences if the pattern is non-trivial\n- Error handling patterns — are errors caught, typed, and not swallowed?\n- Missing edge cases — call these out explicitly with concrete scenarios\n- Technical debt hotspots — code that works but will be painful later\n- Over-engineering vs under-engineering (calibrate against the \"engineered enough\" preference)\n- Naming clarity — is the code self-documenting?\n- Consistency with `standards\u002Fcoding\u002F` conventions\n- Areas that are over-engineered or under-engineered relative to preferences\n- **Feature flag debt**: stale flags past cleanup SLA, flags missing cleanup dates, dead flag branches in code (check `feature_flags.cleanup_sla_days` from config)\n- **Mobile compatibility**: if `platforms.responsive` is true, check for hardcoded widths, missing viewport considerations, touch targets \u003C 44x44px, non-responsive layouts\n\nSame issue format as Section 1. Pause for user feedback after completing.\n\n---\n\n### Section 3: Test Review\n\nEvaluate test coverage and quality.\n\n**What to evaluate:**\n- Test coverage gaps — which new\u002Fchanged code paths have no tests?\n- Test quality and assertion strength — are assertions specific or just \"does not throw\"?\n- Missing edge case coverage — enumerate specific edge cases that should be tested\n- Untested failure modes and error paths — errors that could happen but are not exercised\n- Test isolation — do tests depend on external state or ordering?\n- Mock appropriateness — per coding standards: mock external services only, never your own code\n- Test naming — do test names describe behavior (`should X when Y`)?\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Section 4: Performance Review\n\nEvaluate performance characteristics. Skip issues that are clearly irrelevant to the change scope.\n\n**What to evaluate:**\n- N+1 queries and database access patterns (if applicable)\n- Memory-usage concerns (large allocations, unbounded growth, leaks)\n- Caching opportunities (repeated expensive computation or data fetch)\n- Algorithmic complexity — O(n²) or worse where O(n) or O(n log n) is achievable\n- Unnecessary re-renders (React\u002Ffrontend specific, if applicable)\n- Bundle size impact (if frontend changes)\n- I\u002FO patterns — unnecessary sequential operations that could be parallel\n- Slow or high-complexity code paths\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Section 5: Security Review\n\n**Default: enabled at all stages. In SMALL CHANGE mode, flag at least 1 security consideration.**\n\nCheck for:\n- **Injection patterns**: SQL injection (parameterized queries?), command injection (`exec`\u002F`spawn` with user input?), XSS (output encoding?)\n- **Auth checks**: Every mutating endpoint has authentication middleware? Authorization checked on resource access?\n- **IDOR patterns**: Resource IDs from request params validated against current user's ownership\u002Fpermissions?\n- **Secrets in code**: Hardcoded API keys, tokens, passwords? `.env` files committed?\n- **Header security**: CORS configured restrictively? CSP headers set? HSTS enabled?\n- **Dependency risk**: Known vulnerabilities in dependencies? Outdated packages with security patches?\n\n**Note:** AI-generated code has elevated risk in auth middleware ordering, SQL construction, and ownership checks. Pay extra attention to these patterns.\n\nSame issue format. Pause for user feedback after completing.\n\n---\n\n### Step 3: Review Summary\n\nAfter all five sections are complete (or the focused section if user requested a single one), produce a review summary:\n\n```markdown\n## Code Review Summary\n\n### Scope\n- **Reviewed**: [PR #42 \u002F files \u002F branch diff]\n- **Mode**: [BIG CHANGE \u002F SMALL CHANGE]\n- **Files**: [N files, M lines changed]\n- **Engineering preferences**: [standards\u002Fengineering-preferences.md | built-in defaults]\n\n### Issues by Section\n\n| Section | Issues Found | Resolved | Deferred | Action Items |\n|---------|-------------|----------|----------|--------------|\n| Architecture | N | N | N | N |\n| Code Quality | N | N | N | N |\n| Test | N | N | N | N |\n| Performance | N | N | N | N |\n| Security | N | N | N | N |\n| **Total** | **N** | **N** | **N** | **N** |\n\n### Decisions Made\n1. **Issue 1** ([section]): [chosen option] — [rationale]\n2. **Issue 2** ([section]): [chosen option] — [rationale]\n...\n\n### Action Items\n- [ ] [Specific action with file reference]\n- [ ] [Specific action with file reference]\n\n### Deferred Items\n- [Issue N]: [reason for deferring, conditions for revisiting]\n\n### Overall Assessment\n[APPROVE \u002F APPROVE WITH CHANGES \u002F REQUEST CHANGES \u002F BLOCK]\n\n[1-2 sentence summary of the overall code quality and readiness]\n```\n\n### Step 4: Produce Review Artifact\n\nIf the review was part of a formal workflow (not an ad-hoc quick check), save the summary as an artifact:\n\n1. Use the review report template (see `review-report-template.md` in this skill directory)\n2. Store in `artifacts\u002Fqa-reports\u002F`\n3. Set appropriate lineage:\n   - `parent`: the RFC or PRD this code implements (if known)\n   - `depends_on`: any related artifacts\n4. Set status to `review`\n5. Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh` on the artifact\n\nAsk the user: \"Save this review as a formal artifact in `artifacts\u002Fqa-reports\u002F`? (y\u002Fn)\"\n\n## Focus Mode\n\nIf the user specifies a single section (e.g., `\u002Fcode-review src\u002Fauth\u002F --focus performance`), run only that section with the full BIG CHANGE depth (up to 4 issues), skip the others, and still produce a summary.\n\n## Agent Integration Modes\n\n### Engineering Self-Review (Pre-Handoff)\n\nWhen invoked by the Engineering Agent as a pre-handoff self-review:\n1. Run all five sections in SMALL CHANGE mode (one issue per section) automatically\n2. Do not pause between sections (non-interactive)\n3. If any issue is rated as blocking: stop and address before handoff\n4. Produce the summary artifact automatically and link to the RFC\n\n### QA Release Review\n\nWhen invoked by the QA & Release Agent:\n1. Run Code Quality, Test, and Security sections in BIG CHANGE mode\n2. Run Architecture and Performance in SMALL CHANGE mode\n3. Results feed into the release-readiness-gate Bar 5 (Code Quality) evaluation\n\n## Appendix A: Default Engineering Preferences\n\nIf `standards\u002Fengineering-preferences.md` does not exist, use these defaults:\n\n- **DRY**: aggressive — flag any non-trivial logic that appears twice\n- **Testing**: thorough — well-tested code is non-negotiable; err on the side of more tests\n- **Engineering calibration**: engineered-enough — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction)\n- **Edge cases**: thorough — err on the side of handling more edge cases, not fewer; thoughtfulness > speed\n- **Explicitness**: explicit — bias toward explicit, readable code; no magic\n- **Error handling**: strict — never swallow errors; use typed errors at system boundaries\n- **Performance**: balanced — consider performance for hot paths and database queries; don't micro-optimize cold paths\n\n## Quality Checklist\n\n- [ ] `company.config.yaml` was read for tech stack context\n- [ ] `standards\u002Fcoding\u002F` was read for project conventions\n- [ ] `standards\u002Fengineering-preferences.md` was read (or defaults noted)\n- [ ] Review scope was clearly determined and reported\n- [ ] Review mode (BIG\u002FSMALL) was confirmed with user\n- [ ] Each section paused for user feedback (in interactive mode)\n- [ ] Issues are numbered and options are lettered\n- [ ] Recommended option is always listed first (Option A)\n- [ ] Every issue references concrete file paths and line numbers\n- [ ] Summary includes all decisions made during the review\n- [ ] Action items are specific and actionable\n- [ ] Review artifact was offered\u002Fproduced if part of formal workflow\n",{"name":5,"runtimes":51,"description":7},{"claude":52},{"argument-hint":53,"user-invocable":54},"\u003CPR number or file paths>",true,"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4","os\u002Fskills\u002Fcode-review",2,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os","https:\u002F\u002Fgithub.com\u002Fvibbs","Principal Engineer · Applied AI · building ArcAI @ GrowthArc","2026-10-21 02:08:08",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":54},[65,68,71],{"tool":66,"command":67},"npx","npx skills add vibbs\u002Fcompany-os --skill code-review",{"tool":69,"command":70},"bunx","bunx skills add vibbs\u002Fcompany-os --skill code-review",{"tool":72,"command":73},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill code-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fcode-review\u002FSKILL.md",[76,82],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"review-report-template.md","REFERENCE","参考文档",1745,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fcode-review\u002Freview-report-template.md",{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"scripts\u002Fbrave-search-leads.ts","SCRIPT","脚本",16816,"https:\u002F\u002Fgithub.com\u002FFDU-INS\u002FInsurance-Skills\u002Fblob\u002Fmain\u002FSkills\u002Fbrave-instagram-search\u002Fscripts\u002Fbrave-search-leads.ts",[89,98,106,116,131,147],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":46},"01M6CTHBW1E64ECYGD105N4S5E","typo-field","Fixture skill with a misspelled top-level field.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Ftypo-field\u002FSKILL.md",[],[96,97],"typo field","fixture skill",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":46},"01M6CTHABTV8FKVDHFMMKPAV51","spaced-comments","Fixture skill with comments and spaces after block keys.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fspaced-comments\u002FSKILL.md",[],[105,97],"spaced comments",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":46},"01M6CTH8MHC14KB65ZDHYBJW1N","crlf-comments","Fixture skill with Windows line endings.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fcrlf-comments\u002FSKILL.md",[],[113,114,115,97],"crlf comments","CRLF","windows",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":46},"01M6CTH6TBKTDP9G8QB1Z2K0TY","claude-fields","Fixture skill using top-level fields Claude Code documents.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fclaude-fields\u002FSKILL.md",[],[123,124,125,126,127,128,97,129,30,130],"claude fields","explore","documents","src","grep","read","Bash","testing",{"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":140,"publishedAt":46},"01M6CTH46BGKXH80RWS876Y2CW","workflow-router","Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[137],{"categoryNo":138,"categoryName":139,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[141,142,143,144,145,43,146],"workflow","router","workflow router","next","maps","artifacts",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":46},"01M6CTH27653SRVP2FMEQN3J5B","weekly-review","Summarizes your week: what shipped, AI spend, support themes, security health and next priorities. Use at the end of each week.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[154,29,155,144,43,156,157,158,159],"weekly review","priorities","health","save","support","security"]