genshijin-review
interfacex-co-jp/genshijin
Ultra-compressed PR review comments in Japanese: one line per issue with location, problem, and fix.
What is genshijin-review?
A Japanese-language code review skill that delivers concise, actionable PR feedback. Each comment follows a strict format (line number, severity prefix, problem, fix) with no preamble, designed to prioritize signal over noise. Activate with "PRレビューして", "コードレビュー", "/review", or "/genshijin-review".
- Formats PR comments as single-line issues: location, problem, fix (e.g., `L42: 🔴 バグ: user null 可. .email 前にガード追加.`)
- Applies severity prefixes (🔴 バグ/bug, 🟡 リスク/risk, 🔵 nit, ❓ 質問/question) to categorize issues by impact
- Strips filler language ("〜のように見えます", "検討するとよい", praise) to eliminate noise
- Preserves exact line numbers, symbol names in backticks, concrete fixes, and necessary "why" context
- Expands to full paragraphs only for security issues (CVE-level), architectural concerns, or onboarding contexts
How to install genshijin-review
npx skills add https://github.com/interfacex-co-jp/genshijin --skill genshijin-reviewHow to use genshijin-review
- 1.Trigger the skill on a pull request by writing "PRレビューして", "コードレビュー", "/review", or "/genshijin-review" in a comment or commit message
- 2.The skill analyzes the diff and generates one-line comments per issue in the format `<file>:L<line>: <severity> <problem>. <fix>.`
- 3.Copy the generated comments into the PR review interface; they are formatted for direct pasting
- 4.For security, architectural, or onboarding-context issues, the skill automatically expands to full paragraphs with reasoning
- 5.Use "原始人レビューやめて" or "通常モード" to disable the compressed format and return to standard review mode
Use cases
- Review pull requests with rapid, structured feedback that authors can act on immediately without re-reading
- Enforce consistent code review style across Japanese-speaking teams by eliminating hedging and vague suggestions
- Scan diffs for bugs (null checks, race conditions, error handling) and flag them with severity signals
- Provide mentoring feedback on style, naming, and micro-optimizations without blocking approval
- Catch security and architectural issues while keeping routine nits concise
- Japanese-speaking development teams using PR-based workflows
- Code reviewers who want to eliminate ambiguity and filler from feedback
- Teams adopting structured severity-based review signals (bug vs. risk vs. nit)
- Developers seeking rapid, actionable comments that respect author time
genshijin-review FAQ
🔴 バグ (bug) = broken code causing incidents; 🟡 リスク (risk) = works but fragile (race conditions, unchecked nulls, swallowed errors); 🔵 nit = style, naming, micro-optimization (authors can ignore); ❓ 質問 (question) = pure inquiry, not a suggestion.
For CVE-level security issues (with reference URLs), architectural disagreements (requiring justification), or new-team-member onboarding contexts where "why" is essential. After the expanded comment, it returns to compressed mode.
No. It only generates review comments in a format ready to paste into PRs. Code modification, approval decisions, and linter execution are out of scope.
Japanese (日本語). Comments use Japanese terminology and phrasing, with severity prefixes and symbols for universal clarity.
Write "原始人レビューやめて" (stop primitive review) or "通常モード" (normal mode) to switch back to standard paragraph-style feedback.
Full instructions (SKILL.md)
Source of truth, from interfacex-co-jp/genshijin.
name: genshijin-review description: > 超圧縮PRレビューコメント。1行1指摘: 位置・問題・修正。前置き削除、シグナル優先。 日本語対応。「PRレビューして」「コードレビュー」「/review」「/genshijin-review」で起動。 プルリクエストレビュー時に自動起動候補。
レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。
ルール
形式: L<line>: <問題>。<修正>。 — 複数ファイル時 <file>:L<line>: ...
重大度プレフィックス（混在時）:
- 🔴
バグ:— 壊れている。インシデント直結 - 🟡
リスク:— 動くが脆い（race, null未チェック, 握り潰しerror） - 🔵
nit:— スタイル・命名・ミクロ最適化。著者無視可 - ❓
質問:— 純粋な疑問。提案ではない
削除:
- 「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」
- 「あくまで提案ですが」→
nit:使う - 「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に1回だけ、個別コメント不要
- 行の動作説明 — diff 読めば分かる
- ぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら
質問:
保持:
- 正確な行番号
- シンボル・関数名・変数名はバッククォート
- 具体的修正（「リファクタリング検討」禁止）
- 問題文から自明でない「なぜ」
例
❌ 「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) で包む。
自動明瞭化
以下は簡潔モード解除・通常の段落で記述:
- セキュリティ指摘（CVE級は参照URL付きで十分な説明必要）
- アーキテクチャ異論（根拠必要、ワンライナーでは不足）
- 新人オンボーディング文脈（「なぜ」が必要）
該当指摘後 即復帰。
境界
- レビューのみ。コード修正・approve/request-changes・linter実行 禁止
- 出力はPR貼付可能形式
- 「原始人レビューやめて」「通常モード」で解除
Related skills
More from interfacex-co-jp/genshijin and the wider catalog.
genshijin-stats
Display real token usage and estimated savings from Claude Code session logs.
genshijin
Ultra-compressed communication mode: speak like a caveman, cut token usage ~75%, keep technical accuracy.
genshijin-commit
Ultra-concise commit messages in Conventional Commits format, emphasizing why over what.
genshijin-compress
Compress natural-language files (CLAUDE.md, todos, configs) to reduce input tokens while preserving code, URLs, and structure.
forge-idiomatic-engineer
Forge-focused engineering workflow for Rust applications with generated frontend bindings. Activate this skill for repositories containing a `forge.toml` file, Forge macros, or code generated by the Forge CLI.
eloquent-best-practices
Master Laravel Eloquent ORM with query optimization, relationship management, and N+1 query prevention.