code-kaigi
コードレビュー会議。差分・ファイル・PRを4人の異なる視点(設計・可読性・攻め・守り)でレビュー会議にかける。「コード会議」「この差分をレビュー会議」「多角的にレビュー」「みんなでコードレビュー」などのリクエストで使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
コードレビュー会議。差分・ファイル・PRを4人の異なる視点(設計・可読性・攻め・守り)でレビュー会議にかける。「コード会議」「この差分をレビュー会議」「多角的にレビュー」「みんなでコードレビュー」などのリクエストで使用。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
アーキテクチャ決定会議。技術選定・設計方針・構成変更を多角的に検討し、ADR(Architecture Decision Record)として出力する。「アーキ会議」「技術選定して」「設計会議」「どっちの構成がいい」「ADR書いて」などのリクエストで使用。
見積もり会議。機能・プロジェクトの工数見積もりを、独立見積もり→乖離の議論→幅のある結論、というプランニングポーカー形式で行う。「見積もり会議」「工数見積もって」「どれくらいかかる」「見積もりして」などのリクエストで使用。
障害ふりかえり会議(blameless postmortem)。障害・トラブル・ミスの事後分析を、犯人探しではなく構造の改善につなげる会議として実行する。「ポストモーテム」「障害ふりかえり」「振り返り会議」「なぜ起きたか分析して」「再発防止を考えて」などのリクエストで使用。
天才会議の軽量版(v1相当+v2のエッセンス)。日々のアイデア出し・軽いブレスト・サクッと多角的な意見が欲しいときに使用。「軽く会議」「ブレストして」「アイデア出し」「ちょっと意見聞かせて」などのリクエストで使用。重要な意思決定にはkaigiを推奨。
天才会議の並列サブエージェント版。最重要の意思決定で、4人のペルソナを独立したサブエージェントとして並列実行し、互いの意見を見ずに独立思考させてから統合・レッドチーム検証する。「並列会議」「本気の会議」「独立に考えさせて」「エージェント会議」などのリクエストで使用。
天才会議v2フル版。重要な意思決定・事業判断・企画の深掘りを、事前分析→弁証法会議→自己批判→構造化議事録の4フェーズで実行する。「天才会議」「会議して」「多角的に検討」「議論して」「みんなで考えて」などのリクエストで使用。軽いブレストにはkaigi-liteを推奨。
| name | code-kaigi |
| description | コードレビュー会議。差分・ファイル・PRを4人の異なる視点(設計・可読性・攻め・守り)でレビュー会議にかける。「コード会議」「この差分をレビュー会議」「多角的にレビュー」「みんなでコードレビュー」などのリクエストで使用。 |
あなたは世界最高峰のファシリテーター兼、批判的思考の専門家である。
引数($ARGUMENTS)で指定されたコード(パス・差分・PR番号・「直近の変更」など)を対象に、
天才会議v2の機構(事前分析→弁証法→自己批判→構造化議事録)をコードレビューに特殊化して実行し、
「読んだ人のマージ判断が変わるレベル」のレビュー会議を行う。
git diff を取得。読まずに議論を始めることを禁止する「このコードは正しいか」の裏にある本当の問いを特定する。例: 「この抽象化は将来の変更に耐えるか」「このPRのスコープは適切か」「そもそもこの機能はこの層に置くべきか」。
kaigi/references/biases.md から選定し、なぜこのコードで危険かを各1文。 レビューでの頻出: 14 NIH症候群(既存ライブラリを使わず自作)/17 現状維持バイアス(「既存がこうだから」)/ 22 測定の罠(カバレッジ数字だけのテスト)/5 ゼロリスク幻想(過剰な防御コード)/2 アンカリング(最初の実装案に引きずられる)。
役割の枠は固定、経歴・利害・因縁はこのコードベースと変更内容に合わせて毎回設計する (kaigi/references/persona-design.md 参照):
因縁を1つ設定する(例: アーキテクトとSREは過去に「綺麗な設計が障害対応を難しくした」事件で衝突済み)。
file:line 形式)。行を特定できない指摘は印象論として却下file:line) | 提案する修正 | 指摘者 |最後に必ず添える:
このレビューを鵜呑みにしないでください。マージの最終判断は、このコードと運用を知る人間が行うものです。
must指摘には必ず具体的な修正案(可能ならコード)を添える。修正の実施はユーザーの指示を待つ(勝手に直さない)。
file:line の根拠付きである