gatellm-io/Claude Auto Review
Pull request auto review powered by Claude Code. Wraps anthropics/claude-code-action with size gating, comment minimization, and short-result retry.
View on GitHubTrust Signals
- Scorecard Score
- not yet scored
- Maintenance Recency
- Stale
- License
- None
Inputs
| name | description | required | default |
|---|---|---|---|
| anthropic_api_key | Anthropic API key. Caller must pass explicitly; convention is to pass secrets.CODE_REVIEW_API_KEY. | no | "" |
| anthropic_base_url | Anthropic API base URL. Caller must pass explicitly; convention is to pass vars.CODE_REVIEW_BASE_URL. | no | "" |
| github_token | GitHub token with pull-requests/issues permissions. Defaults to GITHUB_TOKEN. | no | ${{ github.token }} |
| model | Model name (REQUIRED in practice). Caller MUST pass vars.CODE_REVIEW_MODEL or a literal; empty triggers fail-fast. The [1m] suffix denotes a 1M-token context-window variant, recommended for large PRs. | no | "" |
| max_lines | Max changed lines in a PR to trigger review. -1 means unlimited. Default 10000. | no | 10000 |
| user_request | User request passed through when triggered by @claude comment (optional). | no | "" |
| prompt | Custom review prompt (optional, has default). | no | **CRITICAL - Language Requirement:** - All review comments MUST be written in Simplified Chinese - English is allowed ONLY for: code snippets, technical terms when necessary, and file paths - This is a mandatory requirement and must not be ignored Please review this pull request and provide feedback on: - Code quality and best practices - Potential bugs or issues - Performance considerations - Security concerns - Test coverage ## Review principles - Choose the most suitable solution for the specific scenario - There may be multiple solutions to the same problem; weigh the pros and cons based on the actual use case - While implementing requirements, consider future extensibility to minimize maintenance costs and security risks - Avoid over-engineering - Pursue simple solutions; simplify complex problems - Do not add entities unless necessary ## Review strategy - Default to a code review mindset: prioritize identifying bugs, risks, behavioral regressions, and missing tests - Findings must be the primary focus of the response - keep summaries or overviews brief and only after enumerating the issues - Present findings first (ordered by severity with file/line references), follow with open questions or assumptions, and offer a change-summary only as a secondary detail - If no findings are discovered, state that explicitly and mention any residual risks or testing gaps ## TODO 修改清单 评论必须包含一个 `## TODO 修改清单` 区块，收录所有**需要代码改动**的 finding；不需要改代码的内容（开放问题、假设、Requires manual attention）不放入此区块，保持在各自小节。 每条 TODO 一行，固定格式（便于机器解析，coding AI 可直接读取和认领）： ``` ## TODO 修改清单 - [ ] **[TODO-1] [P0] `src/app.ts:42`** — 问题简述；修改要求：具体要改成什么 - [ ] **[TODO-2] [P1] `src/utils/date.ts:10-15`** — 问题简述；修改要求：…… ``` 格式规则： - ID 递增且稳定：`TODO-<n>`，同一评论内不重复 - 严重性分级，按严重性排序：`[P0]` 严重 bug/安全问题；`[P1]` 逻辑风险/行为回归；`[P2]` 性能问题/测试缺��；`[P3]` 风格建议 - 位置用反引号包裹的 `file:line` 或 `file:line-line`，必须来自本 PR 的 diff - 每条自包含：问题描述 + 明确的「修改要求」，coding AI 无需回读其他上下文即可执行 - 复选框初始一律 `- [ ]`，认领/销项协议不做规定，由调用方与 coding AI 自行约定 - 既有「findings 优先、按严重性排序、`**Issue Title**`」等格式要求保留，用于 TODO 区块之外的分析性内容；每条 TODO 可在正文 findings 中有对应的详细分析，TODO 行内保持精炼 - 若无任何需要改动的 finding，在 TODO 区块显式注明「无需代码改动」 ## Requires manual attention After presenting findings, include a "Requires manual attention" section highlighting areas that require careful human review. Focus on: - Complex business logic changes that AI cannot fully validate without domain knowledge - Security-sensitive code (authentication, authorization, data encryption, input sanitization) - Performance-critical sections (database queries, loops, memory allocation) - Financial calculations or sensitive data processing - Concurrency patterns, race conditions, or distributed system interactions - Database schema changes or data migration logic - Third-party API integrations or external service dependencies - Edge cases and error handling that may have subtle implications - Architectural decisions that affect system design - Changes to permission/access control logic For each item, briefly explain WHY human review is recommended ## Output formatting - Use `-` for all list items, never use numbered lists like `1.` `2.` - Keep all items flat at the same level, no nested lists or sub-items - For each finding, use `**Issue Title**` followed by description text on the same or next line - Use backticks for file paths, commands, env vars, and code identifiers - Code samples or multi-line snippets should be wrapped in fenced code blocks - File references should include line numbers when relevant (e.g., `src/app.ts:42`) - Tone: collaborative, concise, factual; present tense, active voice When reviewing a PR, use gh command to fetch remote content, like GH_PAGER="cat" gh pr view xxx |
Outputs
no outputs