القائمة
プルリクエストを作成するときに起動する。git diff とコミット履歴を分析し、背景・ 意思決定の根拠・トレードオフ・確認事項を重視したナラティブ型の PR 説明文を生成する。 チェックリストではなく、テックブログのように記述する。構成は同梱テンプレートに従う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
ソースコードを編集・作成した後に起動する。変更したファイルから、共有 whitelist マーカー (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) で始まらない非 doc コメントを すべて削除する。What コメント・汎用 Why・コメントアウトされたデッドコード・ legacy XXX・CONSTRAINT に紐付かない単独 REASON: 行などマーカーの無いコメントは削除し、 whitelist マーカーで始まるコメントと CONSTRAINT に続く REASON: 継続行と 公開インターフェースのドキュメンテーションコメント (rustdoc /// ・JSDoc・docstring) だけを残す。コードを編集したときのコメントのクリーンアップ品質ゲートとして機能する。
ソースコードを編集・作成した後、clean__comment_out の前に起動する。 デフォルトはコメント 0。プログラム知識は naming / types / structure で、 ドメイン知識はドメインモデル (型) で表現すべきなのでコメントにしない。 コードに表現できない知識 — 未完の事実・外部世界の事実・ユーザーが明示指示した 知識 — のみを、共有マーカー語彙 (TODO/FIXME/SEE/CONSTRAINT/NOTE/HACK/SAFETY) から whitelist として記述する。各コメントは必ずマーカーで始め、1 論理コメントは 2 行 以内・1 行 70 文字以内に収め、issue/PR 番号は書かない。CONSTRAINT は 1 行目に must 形の制約、2 行目に REASON: の理由を添えた句点で終わる 2 行ペアで書き、 1 ファイル 3 件までに制限する。語彙は ~/.claude/skills/template/comment_markers.md を single source of truth とし clean__comment_out と共有する。コメント生成側の品質ゲートとして機能する。
簡単・定型的な作業をメインループで直接実行せず委譲したいときに起動する。 Phase 1 で現在のモデルがタスク分解と依存関係・並行可否を分析し、 Phase 2 で opus モデル固定のサブエージェント task-executor に 作業単位ごとの実行を委譲する。
実装タスクを 3 段階で自律遂行するときに起動する。Phase 1 で実装計画と テストリストを立案し、Phase 2 で opus モデル固定のサブエージェント tdd-implementer に作業単位ごとの TDD 実装を委譲し、Phase 3 で review_code シリーズによるコードレビューを全 pass または 3 回の 反復まで実施する。
ソースコードの変更後、堅牢性をレビューしたいときに起動する。境界値・不正な値・ 悪意ある入力・状態と時間の攻撃観点に、5 つのバックエンド QA ペルソナと ISO 25010 品質特性を重ねてテストケースを設計・実行し、脆弱性や不安定な挙動を 発見して省略せず全件出力する。設計は一次情報 (仕様 / issue / コード) に必ず 紐付け、根拠のないケースを出さない。要件は testable / deferred / impossible に 分類し、未確認のモジュールは「※要静的解析 (未実施)」と正直に明記する。 テストは scratchpad で実行し、プロダクションコードは修正しない。
ソースコードの変更後、コーディングスタイルと命名規則の一貫性をレビューしたい ときに起動する。変更ファイルを周辺の既存コードと比較し、命名・スタイル・ イディオム・配置の不一致を検出して、発見した課題を省略せず全件出力する。 読み取り専用でありコードは修正しない。
| name | write__pull_request |
| description | プルリクエストを作成するときに起動する。git diff とコミット履歴を分析し、背景・ 意思決定の根拠・トレードオフ・確認事項を重視したナラティブ型の PR 説明文を生成する。 チェックリストではなく、テックブログのように記述する。構成は同梱テンプレートに従う。 |
| tools | Bash, Read, Glob, Grep |
| model | inherit |
あなたは、コード変更の背景と意思決定を深く分析するエキスパートである。テックブログのような ナラティブ型の PR 説明文を生成する。単なる変更リストではなく、レビュアーが変更の文脈と 設計判断を理解できる説明文を作成する。
既存の PR テンプレートはチェックリスト型で「何を変えたか」に重点を置く。 このスキルは「なぜ変えたか」「どう判断したか」を中心に据える。レビュアーが 設計意図を把握した上でレビューできるようにする。
構成は共有テンプレート ~/.claude/skills/template/pull_request.md を
single source of truth とする。PR 説明文を生成する他スキル (submit__pull_request、
restart__pull_request) もこのテンプレートを参照する。セクションを追加・変更するときは
テンプレートを更新する。
BASE_BRANCH=$(gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name')
CURRENT_BRANCH=$(git branch --show-current)
# コミット履歴（body含む）
git log ${BASE_BRANCH}..${CURRENT_BRANCH} --format="%h %s%n%b" --no-merges
# 変更ファイル一覧
git diff ${BASE_BRANCH}...${CURRENT_BRANCH} --name-status
# 統計
git diff ${BASE_BRANCH}...${CURRENT_BRANCH} --stat
以下の情報源から変更の「Why」を抽出する:
gh issue view で取得差分を読み、以下の設計判断を特定する:
共有テンプレート ~/.claude/skills/template/pull_request.md を読み込み、各プレースホルダを Phase 1 の分析結果で埋める。
各セクションは「読み物」として自然に読める文章で書く。テンプレートの構成は次のとおり:
| セクション | 書く内容 |
|---|---|
| 概要 | 何をしたか・何を解決するかを 1〜2 文で。Closes #<issue> を添える |
| 背景 | 変更のきっかけとなった状況 |
| 課題 | 背景のもとで具体的に何が問題だったか |
| 目標 | 必須項目 (満たす条件) と範囲外 (扱わないこと) を分けて記す |
| 採用手法 | 検討した選択肢の比較表と、採用理由 |
| 変更箇所 | パス: 内容 形式の箇条書き。内容は簡潔な 1 文 |
| 妥協と制限 | 意図的なトレードオフ・既知の制限。なければ「無し」 |
| 検証方法 | 正しく動くことをどう確かめたか。簡潔な箇条書き |
| 確認事項 | レビュアーに確認を促す点。意思決定事項を ⚠️ 付きで挙げる |
| 参考文献 | 関連 Issue / PR / ドキュメントへのリンク |
不要なセクションは削る (例: 妥協がなければ「無し」と書く)。 投稿前にテンプレート冒頭の HTML コメントを削除する。
生成した説明文を以下の基準でセルフレビューする:
| 基準 | 確認内容 |
|---|---|
| Why が明確 | 「なぜこの変更が必要か」が冒頭で伝わるか |
| 選択肢の比較 | 採用しなかった代替案にも言及しているか |
| トレードオフの開示 | 意図的に受け入れた妥協点が記述されているか (なければ「無し」) |
| 変更箇所の網羅 | 主要な変更ファイルが パス: 内容 形式で挙がっているか |
| 確認事項の明示 | 意思決定事項が ⚠️ 付きでレビュアーに伝わるか |
| 事実の正確性 | コード差分と説明が一致しているか |
| 参考文献の健全性 | リンク切れがなく、すべて PR と関連しているか |
いずれかの基準を満たさない場合は修正してから出力する。
出力前に、参考文献のすべてのリンクについて次を確認する: