GitHub Actions の CI 失敗を、失敗ジョブの特定 → ログからの原因抽出 → 原因分類 → ローカル再現 → 修正 → 検証まで体系的に進めるスキル。特に、失敗ログのノイズに埋もれて原因が見えないとき、環境依存でフレーキーに落ちているときに役立つ。修正に人の判断が必要な場合は、対話モードでは確認して中断し、--non-interactive 指定時はPRにコメントを投稿して中断する。

2026-07-100

erblint-todo-init

aki77/skills

`bundle exec erblint app` の既存違反をファイル単位で無効化する todo ファイル群（`.erb_lint_todo.yml` / `.erb-lint-rubocop-todo.yml`）を生成・初期化する手順。手動起動専用（`/erblint-todo-init`）。todo を作り直したいときなど、一回性のセットアップ作業でのみ使う。 rubocop 単体・haml-lint・herb-lint の運用には使わない。

2026-07-090

implement-plan

aki77/skills

プランモードで作成したプランファイル（Markdown）の内容に沿って実装を行う。実装フェーズを軽量なsonnetモデルで実行し、コスト・速度を最適化する。引数でプランファイルのパスを指定できる。省略時は直近のセッションログから対象プランを自動特定してユーザーに確認する。コミット・push・PR作成は、プランに明記されている場合のみ実施する。

2026-07-080

dedupe-apm-local-rules

aki77/skills

APM パッケージ由来ルール（.claude/rules/*.md）と重複するプロジェクト固有ローカルルール（.apm/instructions/*.local.instructions.md）を検出し、ローカル側を削除・縮小する。未管理ルールの新規移行は行わない（それは migrate-rules-to-apm の役割）。手動実行専用（自動トリガーしない）。

2026-07-080

name	pr-summary
description	GitHub PR URLを受け取り、レビュアー向けに日本語でサマリーを生成する。
license	MIT
argument-hint	[PR URL] [--dry-run]
context	fork
disable-model-invocation	true
model	sonnet

PR サマリー生成

予備知識のないレビュアーがPRの目的・変更内容・注意点をすぐに把握できるサマリーを生成する。

手順

--dry-run フラグを確認する
- 入力に --dry-run が含まれる場合 → ドライランモード（サマリーをチャット画面に出力するのみ。PR本文は更新しない）
- 含まれない場合 → 通常モード（サマリー生成後に mcp__github__update_pull_request でPR本文を書き換える。add_issue_comment でコメントを追加するのではない）
GitHub MCPでPR情報を並列取得する
- mcp__github__pull_request_read の get メソッドでPRのメタ情報（タイトル・本文・統計）を取得
- mcp__github__pull_request_read の get_diff メソッドでdiffを取得
- mcp__github__list_commits（owner・repo・pullNumber を渡す）でコミットメッセージを取得
- 3つのリクエストは並列で送ること
- コミットメッセージは意図・設計判断を読み取る一次情報として常に参照する。diffが「何を変えたか（What）」を示すのに対し、コミットメッセージは作者が書いた「なぜ・何のために変えたか（Why）」を含む。各コミットのタイトル（subject）だけでなく本文（body）まで読むこと。設計判断・トレードオフ・背景は本文に書かれていることが多い。ただしコミットメッセージはあくまで Why の根拠であり、取り上げる変更（What）の対象範囲を決めるのは最終diff（get_diff）である（詳細は「変更内容」セクション）。
- get でPR本文（body）が空または取得できなかった場合も、diffとコミットメッセージから背景・意図を構成できる
サマリーを構成する

以下の3セクションで構成する。各セクションは必要な情報量に応じて伸縮させてよい。情報が少なければ箇条書き1〜2行でも構わないし、複雑なPRなら詳しく書く。

背景・課題

なぜこのPRが必要か。どんな問題を解決するか。コードを読まなくても背景が伝わるように書く。技術的な前提知識が必要な場合は簡単に補足する。背景・意図はdiffには現れにくいため、コミットメッセージ（本文含む）とPR本文を主な根拠にして書く。

変更内容

取り上げる対象は base↔head の最終diff（get_diff の結果）に現れる変更に限る。 PR内で一度加えて後続コミットで作者自身が取り消した／作り直した変更（同一PR内で自己解決した中間的な変更）は、最終diffに残らないため「変更内容」には含めない。コミットメッセージは Why（なぜ変えたか）の根拠として参照するが、What（何を取り上げるか）の対象範囲を決めるのは最終diffである。コミットメッセージに痕跡があっても最終diffに現れない変更は書かない。

人間のレビュアーが知っておくべき変更にフォーカスする。すべての変更を網羅する必要はなく、ファイルや差分を一つずつ羅列しない。以下のような変更を優先的に取り上げる：

振る舞い・仕様が変わる変更（ロジック変更・API変更・UI変更）
設計や構造に影響する変更（責務の移動・抽象化の追加/削除）
副作用や互換性に関わる変更（DB・設定・外部連携・公開インターフェース）
レビュアーの判断が必要な箇所（トレードオフを含む実装選択）

逆に、自明なリネーム・フォーマット修正・タイポ修正・機械的な追従変更などは、まとめて1行触れるか省略する。「何のために何を変えたか」が伝わる粒度で書く。

加えて、何を変えたか（What）だけでなく、**なぜその方法を選んだか（作者の設計判断・トレードオフ）**を言語化する。複数の選択肢がありえた箇所では「Aではなく B を選んだ」という判断が伝わるように書く。判断の意図が出力に現れることで、レビュアーはその判断の妥当性を評価できる。

判断の根拠は、まずコミットメッセージの本文に書かれていないか確認する（作者が意図を残す主要な場所）。コミットメッセージにもdiffにも根拠が見当たらない場合は、推測で断定せず、その旨を残してレビュアーが確認できるようにする。

レビューのポイント

人間のレビュアーにしか判断できない観点に絞る。AIレビューやCI（Lint・型チェック・テスト・静的解析・脆弱性スキャンなど）で検出可能な内容は書かない。以下のような、人の判断や文脈理解が必要な観点を優先する：

仕様・要件との整合性（このPRが本当に解決したい課題に対する適切な解か）
設計上のトレードオフや代替案の妥当性
ドメイン知識・業務ルールに照らした正しさ
ユーザー体験・運用への影響（移行手順、リリース順序、関係者への周知が必要かなど）
既存機能・他チームとの整合性、影響範囲の見落としがないか

「Null チェックが漏れているかも」「テストが足りないかも」のような自動検出可能な指摘は書かない。判断の目安：ツールが機械的に判定できるもの（構文エラー・未使用変数・型の不整合・テストカバレッジ不足など）は除外し、仕様の妥当性・ビジネスルールへの適合・ステークホルダーへの影響など人の文脈理解が不可欠なものだけを書く。該当する観点がなければセクションごと省略してよい。

サマリーを推敲する（些細な内容を削ぎ落とす）

手順3でサマリーを書き上げたら、出力・PR本文更新の前に、レビュアー（読み手）の視点でサマリー全体を一度読み返し、シニアエンジニアならわざわざ言及しない些細な記述を削ぎ落とす。手順3の各セクション基準が「書く最中の粒度指針」であるのに対し、このステップは「書き上がったサマリー全体を俯瞰して、読み手の負荷になる些末な記述を取り除く」最終工程である。

判定の原則：

レビュアーの「何を見るべきか」という判断に影響しない記述、変更の意図・影響・リスクの理解に寄与しない記述は削る。
残すか迷ったら「これが無いとレビュアーが困るか？」で判断する。困らないなら削る。
削るのは記述であって変更そのものではない。重要な変更を取りこぼしてはならない。これは過剰に書かれた些末な記述の除去であり、重要情報の圧縮ではない。
削った結果あるセクションが空になるなら、そのセクションごと省略してよい。

推敲後のサマリーを、後続の出力（ドライラン）／PR本文更新の入力とする。

PR本文更新の投稿処理（通常モード）

ドライランでない通常モードの場合、サマリー生成後に以下を実行する。基本方針は 既存本文を全置換 し、別の自動化ツールが埋め込んだブロックのみを保持することである。

更新後のPR本文を組み立てる

まず既存本文（get で取得済み）から、別ツールが埋め込んだコメント囲みブロックを検出し、開始・終了のコメントマーカーを含めたブロック全体を、内容を一切変更せず原文のまま退避する。
- 検出の基本形は  〜 （xxx は任意のツール名）。
- 厳密なパターンマッチに限定せず判断してよい。機械的に生成されたと見られるコメント囲みブロック（集計テーブル、bot署名付きブロック、 等の別記法）も自動化ブロックとみなして保持対象にする。
- 保持する際は、囲みコメント（ /  などの開始・終了マーカー）を含めてブロック全体を丸ごと保持する。マーカーを除去したり中身だけを取り出したりしてはならない。別ツールはこの囲みコメントを目印に自分のブロックを再検出・更新するため、マーカーが落ちるとそのツールが動作しなくなる。
- pr-summary自身のマーカー（）は自動化ブロックとして扱わない。
その上で、現在のPR本文に基づいて以下の3パターンで処理する：

パターンA: 既存本文に  と  の両マーカーが存在する場合 → マーカー間の内容だけを新しいサマリーで置き換える（マーカー自体は維持する）。マーカー外の既存本文・自動化ブロックはそのまま温存する（このパターンでは全置換しない）。

パターンB: pr-summaryマーカーが無く、自動化ブロックが1つ以上検出された場合 → 既存本文は破棄して全置換する。サマリーブロックを本文の先頭に配置し、改行2つを挟んで、退避した自動化ブロックを本文の末尾に集約する（複数あれば元の出現順を保ち、各ブロック間は改行2つで区切る）。退避したブロックは囲みコメント込みで原文のまま再配置し、マーカーや中身を改変しない。

パターンC: pr-summaryマーカーも自動化ブロックも無い場合 → 既存本文を全置換し、サマリーブロックのみを本文にする。

サマリーブロックの形式：
```

（サマリー本文）

```
ユーザーに確認を求める

更新前に更新後のPR本文全体をチャットに出力し、ユーザーの確認を求める。パターンB・Cでは既存本文を全置換するため、差分ではなく全体を見せて意図しない情報の喪失がないことを確認することが特に重要。パターンB・Cで既存本文に人間が手書きしたコンテンツ（自動化ブロック以外の部分）が含まれる場合は、確認画面でその旨を明示し「この内容は削除されます」と伝えること。
- ユーザーが承認（y/yes/はい等）した場合のみ mcp__github__update_pull_request を実行する
- キャンセルの場合は更新せず終了する
PR本文を更新する

mcp__github__update_pull_request（owner・repo・pullNumber・body を渡す）で更新し、成功後「PR本文を更新しました: （PR URL）」と報告する。

出力の注意点

常に日本語で出力する
Markdownの見出し・箇条書きを使って読みやすく整形する。セクション見出しは ##（H2）を使う
コードの詳細な解説は不要。変更の意図と影響が伝われば十分
diffの全行を説明する必要はない。重要な変更にフォーカスする