菜单
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: プレフィックスを使うことで、レビュイーがトリアージ（優先順位付け）できる。
このエラーハンドリングのアプローチ、とてもきれいですね。
再利用しやすい形になっていて参考になります。
レビューコメントが指摘ばかりだとバランスが悪い。良い設計判断も明示する。