tech-code-review-team

name	tech-code-review-team
description	End-to-end code review workflow. Use when the user wants a complete code review package covering GitHub PR or git diff intake, strict bug/security/performance review, project coding standards, security auditing, clean-code maintainability checks, and structured Chinese review reports. Coordinates pr-reviewer, critical-code-reviewer, project-code-standard, security-audit, clean-code-review, and code-review-assistant.
metadata	{"short-description":"Complete code review workflow"}

Tech Code Review

Use this skill as the workflow entry point for a complete code review package. It coordinates the companion skills in this bundle instead of replacing them.

Workflow

1. Use pr-reviewer to collect PR or git diff context, changed files, lint signals, test coverage hints, and initial risk level.
2. Use critical-code-reviewer to examine the changed code for bugs, edge cases, security holes, performance risks, type-safety gaps, and maintainability failures.
3. Use project-code-standard to check lint, formatting, naming, import order, file structure, and team conventions.
4. Use security-audit when changes touch authentication, authorization, credentials, dependencies, configuration, deployment, or input handling.
5. Use clean-code-review to evaluate code smells, anti-patterns, responsibility boundaries, readability, KISS/DRY/YAGNI, and refactoring opportunities.
6. Use code-review-assistant to assemble a structured Chinese review report with severity, evidence, file/line references where available, and actionable fixes.

Routing

• If the user gives a GitHub PR URL or PR number, start with pr-reviewer when gh is available.
• If the user asks for a strict or adversarial review, use critical-code-reviewer early.
• If the request emphasizes lint, style, formatting, or team standards, use project-code-standard.
• If the request mentions credentials, auth, permissions, CVEs, deployment, or hardening, use security-audit.
• If the request asks whether the code is maintainable, readable, or clean, use clean-code-review.
• If the user wants a final review report in Chinese, use code-review-assistant for report assembly.

Project-First Rules

When working in a local codebase:

1. Inspect the current git status and protect user changes before reading diffs or running tools.
2. Prefer the repository's real lint/test commands and established review conventions over generic advice.
3. Ground findings in code evidence: file path, line, behavior, risk, and a concrete fix.
4. Separate blocking bugs/security issues from style or maintainability suggestions.
5. Do not claim a PR is safe unless the relevant diff, tests, and risk areas were actually checked.

Output Package

For a full code review package, produce:

1. PR or diff intake summary: changed files, scope, risk areas, and available test/lint evidence.
2. Findings list: grouped by severity with file/line references where possible.
3. Security audit notes: credentials, auth, dependency, input validation, and config risks.
4. Standards report: lint, formatting, naming, import order, and team convention gaps.
5. Clean-code assessment: maintainability risks, code smells, and refactoring suggestions.
6. Final Chinese review report: concise verdict, required fixes, suggestions, and verification notes.

Operating Notes

• Keep review comments specific and actionable.
• Avoid style-only noise when a stronger correctness or security issue exists.
• Do not post comments to GitHub unless the user explicitly asks.
• If tooling is unavailable, state the verification limit and continue with source-based review.