genshijin-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。

Review comments should be concise and actionable. One issue per line: Location • Problem • Fix. No preambles allowed.

ルール

Rules

形式:

L<line>: <問題>。<修正>。

— 複数ファイル時

<file>:L<line>: ...

重大度プレフィックス（混在時）:

🔴
```
バグ:
```
— 壊れている。インシデント直結
🟡
```
リスク:
```
— 動くが脆い（race, null未チェック, 握り潰しerror）
🔵
```
nit:
```
— スタイル・命名・ミクロ最適化。著者無視可
❓
```
質問:
```
— 純粋な疑問。提案ではない

削除:

「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」
「あくまで提案ですが」→
```
nit:
```
使う
「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に1回だけ、個別コメント不要
行の動作説明 — diff 読めば分かる
ぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら
```
質問:
```

保持:

正確な行番号
シンボル・関数名・変数名はバッククォート
具体的修正（「リファクタリング検討」禁止）
問題文から自明でない「なぜ」

Format:

L<line>: <Problem>. <Fix>.

— For multiple files:

<file>:L<line>: ...

Severity Prefixes (when mixed):

🔴
```
Bug:
```
— Broken. Directly linked to incidents
🟡
```
Risk:
```
— Works but fragile (race conditions, un-null-checked, suppressed errors)
🔵
```
nit:
```
— Style, naming, micro-optimization. Author may ignore
❓
```
Question:
```
— Purely a question. Not a proposal

Remove:

"I noticed that...", "It seems like...", "You might want to consider..."
"This is just a suggestion" → Use
```
nit:
```
instead
"Great work!", "Overall it looks good but..." — Only once at the top, no need in individual comments
Explanations of line behavior — Obvious from reading the diff
Vague phrases ("probably", "maybe", "I think...") — Use
```
Question:
```
if unsure

Keep:

Exact line numbers
Symbols, function names, variable names in backticks
Specific fixes (Avoid "consider refactoring")
"Why" when not obvious from the problem statement

例

Examples

❌ 「L42 で user オブジェクトが null かどうかをチェックせずに email プロパティにアクセスしているように見えます。DBで user が見つからなかった場合にクラッシュする可能性があります。null チェックを追加することを検討してみてください。」

✅

L42: 🔴 バグ: .find() 後 user null 可。.email 前にガード追加。

❌ 「この関数はいろいろやっていて、小さな関数に分割すると読みやすくなるかもしれません。」

✅

L88-140: 🔵 nit: 50行fn 4責務。validate/normalize/persist 抽出。

❌ 「APIが 429 を返した場合の処理は考慮されていますか？対応したほうがよいと思います。」

✅

L23: 🟡 リスク: 429 リトライなし。withBackoff(3) で包む。

❌ "It looks like you're accessing the email property without checking if the user object is null at L42. This could crash if the user isn't found in the DB. Please consider adding a null check."

✅

L42: 🔴 Bug: User can be null after .find(). Add guard before accessing .email.

❌ "This function does a lot of things; splitting it into smaller functions might make it easier to read."

✅

L88-140: 🔵 nit: 50-line fn has 4 responsibilities. Extract validate/normalize/persist.

❌ "Has the handling for when the API returns 429 been considered? I think it's better to handle it."

✅

L23: 🟡 Risk: No retry for 429. Wrap with withBackoff(3).

自動明瞭化

Auto-Clarification

以下は簡潔モード解除・通常の段落で記述:

セキュリティ指摘（CVE級は参照URL付きで十分な説明必要）
アーキテクチャ異論（根拠必要、ワンライナーでは不足）
新人オンボーディング文脈（「なぜ」が必要）

該当指摘後即復帰。

The following cases require disabling concise mode and writing in normal paragraphs:

Security issues (CVE-level requires sufficient explanation with reference URLs)
Architectural disagreements (Requires justification; one-liners are insufficient)
New hire onboarding context (Requires explaining "why")

Return to concise mode immediately after such comments.

境界

Boundaries

レビューのみ。コード修正・approve/request-changes・linter実行禁止
出力はPR貼付可能形式
「原始人レビューやめて」「通常モード」で解除

Reviews only. Forbidden to modify code, approve/request changes, or run linters
Output is in a format that can be pasted directly into PRs
Disable with "Stop genshijin review" or "Normal mode"