메뉴
Use this skill when reviewing others' code, writing review comments, or responding to code review feedback. Covers actionable comments, question-over-demand style, blocking vs nit distinction, and acknowledging good choices.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Agent guide for running GPU experiments and serverless model deployments with the jl CLI on JarvisLabs.ai.
設計・アーキテクチャの壁打ちを Codex MCP (GPT) と行う。 実装前の方針検討、トレードオフ分析、API 設計の相談に使う。 "codex discuss", "GPTと相談", "壁打ち", "設計を議論" などで呼び出す。
git diff ベースのコードレビューを Codex (GPT) に依頼する。 コード変更後にセカンドオピニオンが欲しいとき、"codex review", "GPTにレビューして", "セカンドオピニオン" などで呼び出す。実体は公式プラグイン codex@openai-codex に 移行済みで、本 skill は自然文トリガーの受け皿 (誘導シム)。
実装・レビュー (Codex MCP / GPT)・修正の反復ループ。 ユーザーの意図する機能が動くこと (= 機能ゲート pass) と Codex の LGTM を AND で満たすまで回す。 タスク説明 / plan ファイル / 既存 diff のいずれを起点にしてもよい。 実装フェーズは Karpathy 4 原則 (think before / simplicity / surgical / goal-driven) に従う。 "lgtm loop", "LGTMまで回す", "実装してレビューして直して", "実装と修正をループで" などで呼び出す。
生成・編集した視覚成果物（Web ページ URL、ローカルの HTML/UI ファイル、 画像・図・PDF/SVG）をスクリーンショットで取得し、Read で実際に見て チェックリスト採点する。崩れ・はみ出し・重なり・コントラスト不足を検出し、 NG なら具体的な修正案を返す。Max プランの画像認識を惜しまず使うための専用コマンド。
人間が読む長めの文章・レポート・ドキュメント・資料を生成するときに使用する。単一の HTML ファイル (+ 必要なら assets/) として出力し、Markdown が 100 行を超えると読まれなくなる問題を sticky TOC・構造化 callout・優先度 pill・数式 (KaTeX)・コードハイライト (Prism)・D2 ダイアグラム・チャート (matplotlib SVG) で解決する。技術分析・応用検討・設計レポート・選択肢比較・サーベイ・議論ログ (Codex 等の第二視点を取り込む review-log 型) など、500 字を超える / 図表を伴う / 改訂を重ねる文書には必ず使用する。"レポート", "ドキュメント", "資料", "サーベイ", "技術レポート", "HTMLレポート", "応用検討", "選択肢比較", "議論ログ", "review log", "Codex レビュー反復" などのトリガーで発動する。
| name | code-review-etiquette |
| description | Use this skill when reviewing others' code, writing review comments, or responding to code review feedback. Covers actionable comments, question-over-demand style, blocking vs nit distinction, and acknowledging good choices. |
| user-invocable | false |
# Bad
グローバル変数を使わないで
# Good
このグローバル変数を Config dataclass に置き換えられませんか？
そうすればテストを並列実行できるようになります。
「何がダメか」だけでなく「代わりにどうするか」と「なぜそうすべきか」を含める。
# Bad
null ケースをハンドルしろ
# Good
ここに null が渡された場合、どうなりますか？
同じ内容でも、質問形は対話を促し、命令形は防御的な反応を引き起こす。著者が意図的にその設計を選んだ場合、質問形なら理由を説明してもらえる。
# Bad
この定数はハードコードしないで
# Good
この値を環境変数にすると、ステージング環境と本番環境で
異なるタイムアウトを使い分けられます。
指摘の背景にある動機を共有する。レビュイーにはその文脈がない場合が多い。
nit: 変数名は users_count より user_count が慣例に合います
blocking: この SQL クエリはユーザー入力を直接埋め込んでおり、
SQL インジェクションの脆弱性があります。プレースホルダーを使ってください。
nit: プレフィックスを使うことで、レビュイーがトリアージ（優先順位付け）できる。
このエラーハンドリングのアプローチ、とてもきれいですね。
再利用しやすい形になっていて参考になります。
レビューコメントが指摘ばかりだとバランスが悪い。良い設計判断も明示する。