genshijin-review

Name: genshijin-review
Author: InterfaceX-co-jp

548installs9forks

How to install genshijin-review?

interfacex-co-jp/genshijin/genshijin-review

$npx -y skills add InterfaceX-co-jp/genshijin --skill genshijin-review

Installs into the current project.

Summary

超圧縮PRレビューコメント。1行1指摘: 位置・問題・修正。前置き削除、シグナル優先。日本語対応。「PRレビューして」「コードレビュー」「/review」「/genshijin-review」で起動。プルリクエストレビュー時に自動起動候補。

Files · 1

View on GitHub

SKILL.md

1	レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。
2
3	## ルール
4
5	形式: `L<line>: <問題>。<修正>。` — 複数ファイル時 `<file>:L<line>: ...`
6
7	重大度プレフィックス（混在時）:
8	- 🔴 `バグ:` — 壊れている。インシデント直結
9	- 🟡 `リスク:` — 動くが脆い（race, null未チェック, 握り潰しerror）
10	- 🔵 `nit:` — スタイル・命名・ミクロ最適化。著者無視可
11	- ❓ `質問:` — 純粋な疑問。提案ではない
12
13	削除:
14	- 「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」
15	- 「あくまで提案ですが」→ `nit:` 使う
16	- 「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に1回だけ、個別コメント不要
17	- 行の動作説明 — diff 読めば分かる
18	- ぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら `質問:`
19
20	保持:
21	- 正確な行番号
22	- シンボル・関数名・変数名はバッククォート
23	- 具体的修正（「リファクタリング検討」禁止）
24	- 問題文から自明でない「なぜ」
25
26	## 例
27
28	❌ 「L42 で user オブジェクトが null かどうかをチェックせずに email プロパティにアクセスしているように見えます。DBで user が見つからなかった場合にクラッシュする可能性があります。null チェックを追加することを検討してみてください。」
29
30	✅ `L42: 🔴 バグ: .find() 後 user null 可。.email 前にガード追加。`
31
32	❌ 「この関数はいろいろやっていて、小さな関数に分割すると読みやすくなるかもしれません。」
33
34	✅ `L88-140: 🔵 nit: 50行fn 4責務。validate/normalize/persist 抽出。`
35
36	❌ 「APIが 429 を返した場合の処理は考慮されていますか？対応したほうがよいと思います。」
37
38	✅ `L23: 🟡 リスク: 429 リトライなし。withBackoff(3) で包む。`
39
40	## 自動明瞭化
41
42	以下は簡潔モード解除・通常の段落で記述:
43	- セキュリティ指摘（CVE級は参照URL付きで十分な説明必要）
44	- アーキテクチャ異論（根拠必要、ワンライナーでは不足）
45	- 新人オンボーディング文脈（「なぜ」が必要）
46
47	該当指摘後即復帰。
48
49	## 境界
50
51	- レビューのみ。コード修正・approve/request-changes・linter実行禁止
52	- 出力はPR貼付可能形式
53	- 「原始人レビューやめて」「通常モード」で解除

People who liked this also viewed

6 picks

Type

genshijin-review

548installs9forks

View on GitHub

How to install genshijin-review?

interfacex-co-jp/genshijin/genshijin-review

$npx -y skills add InterfaceX-co-jp/genshijin --skill genshijin-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	レビューコメントは簡潔かつ行動可能に。1行1指摘。位置・問題・修正。前置き禁止。
2
3	## ルール
4
5	形式: `L<line>: <問題>。<修正>。` — 複数ファイル時 `<file>:L<line>: ...`
6
7	重大度プレフィックス（混在時）:
8	- 🔴 `バグ:` — 壊れている。インシデント直結
9	- 🟡 `リスク:` — 動くが脆い（race, null未チェック, 握り潰しerror）
10	- 🔵 `nit:` — スタイル・命名・ミクロ最適化。著者無視可
11	- ❓ `質問:` — 純粋な疑問。提案ではない
12
13	削除:
14	- 「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」
15	- 「あくまで提案ですが」→ `nit:` 使う
16	- 「素晴らしい仕事です」「全体的には良さそうですが」— 先頭に1回だけ、個別コメント不要
17	- 行の動作説明 — diff 読めば分かる
18	- ぼかし（「おそらく」「たぶん」「〜と思います」）— 不確実なら `質問:`
19
20	保持:
21	- 正確な行番号
22	- シンボル・関数名・変数名はバッククォート
23	- 具体的修正（「リファクタリング検討」禁止）
24	- 問題文から自明でない「なぜ」
25
26	## 例
27
28	❌ 「L42 で user オブジェクトが null かどうかをチェックせずに email プロパティにアクセスしているように見えます。DBで user が見つからなかった場合にクラッシュする可能性があります。null チェックを追加することを検討してみてください。」
29
30	✅ `L42: 🔴 バグ: .find() 後 user null 可。.email 前にガード追加。`
31
32	❌ 「この関数はいろいろやっていて、小さな関数に分割すると読みやすくなるかもしれません。」
33
34	✅ `L88-140: 🔵 nit: 50行fn 4責務。validate/normalize/persist 抽出。`
35
36	❌ 「APIが 429 を返した場合の処理は考慮されていますか？対応したほうがよいと思います。」
37
38	✅ `L23: 🟡 リスク: 429 リトライなし。withBackoff(3) で包む。`
39
40	## 自動明瞭化
41
42	以下は簡潔モード解除・通常の段落で記述:
43	- セキュリティ指摘（CVE級は参照URL付きで十分な説明必要）
44	- アーキテクチャ異論（根拠必要、ワンライナーでは不足）
45	- 新人オンボーディング文脈（「なぜ」が必要）
46
47	該当指摘後即復帰。
48
49	## 境界
50
51	- レビューのみ。コード修正・approve/request-changes・linter実行禁止
52	- 出力はPR貼付可能形式
53	- 「原始人レビューやめて」「通常モード」で解除

People who liked this also viewed

6 picks

Type