菜单
コードの現状を説明したドキュメント（仕様書・設計メモなど）を、その後に入ったコード変更へ追従させて最新化するスキル。次の場合に必ず使う：(1)「このドキュメントを最新の仕様に合わせて」「前回更新以降の変更を取り込んで」「仕様変更をドキュメントに反映して」のような依頼、(2) コードを変更したあとに対応するドキュメントが古くなっていそうなとき、(3) 既存のドキュメントを開いて「これ古くなってない？」という文脈になったとき。ドキュメントの最終更新コミットを起点に、それ以降のコード差分のうちその対象に関わるものだけを抽出して反映する。軽微な文言修正ではなく、ドキュメントとコードの乖離を埋めるのが目的。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
GitHub PRのレビューコメントのうち、Hide・解決済みでないものだけを抽出して対応する。
Commit, push, and create or update a PR
GitHub Actions の CI 失敗を、失敗ジョブの特定 → ログからの原因抽出 → 原因分類 → ローカル再現 → 修正 → 検証まで体系的に進めるスキル。特に、失敗ログのノイズに埋もれて原因が見えないとき、環境依存でフレーキーに落ちているときに役立つ。修正に人の判断が必要な場合は、対話モードでは確認して中断し、--non-interactive 指定時はPRにコメントを投稿して中断する。
`bundle exec erblint app` の既存違反をファイル単位で無効化する todo ファイル群 （`.erb_lint_todo.yml` / `.erb-lint-rubocop-todo.yml`）を生成・初期化する手順。手動起動専用 （`/erblint-todo-init`）。todo を作り直したいときなど、一回性のセットアップ作業でのみ使う。 rubocop 単体・haml-lint・herb-lint の運用には使わない。
プランモードで作成したプランファイル（Markdown）の内容に沿って実装を行う。実装フェーズを軽量なsonnetモデルで実行し、コスト・速度を最適化する。引数でプランファイルのパスを指定できる。省略時は直近のセッションログから対象プランを自動特定してユーザーに確認する。コミット・push・PR作成は、プランに明記されている場合のみ実施する。
APM パッケージ由来ルール（.claude/rules/*.md）と重複するプロジェクト固有ローカルルール （.apm/instructions/*.local.instructions.md）を検出し、ローカル側を削除・縮小する。未管理ルールの 新規移行は行わない（それは migrate-rules-to-apm の役割）。手動実行専用（自動トリガーしない）。
| name | doc-sync |
| description | コードの現状を説明したドキュメント（仕様書・設計メモなど）を、その後に入ったコード変更へ追従させて最新化するスキル。次の場合に必ず使う：(1)「このドキュメントを最新の仕様に合わせて」「前回更新以降の変更を取り込んで」「仕様変更をドキュメントに反映して」のような依頼、(2) コードを変更したあとに対応するドキュメントが古くなっていそうなとき、(3) 既存のドキュメントを開いて「これ古くなってない？」という文脈になったとき。ドキュメントの最終更新コミットを起点に、それ以降のコード差分のうちその対象に関わるものだけを抽出して反映する。軽微な文言修正ではなく、ドキュメントとコードの乖離を埋めるのが目的。 |
| license | MIT |
「コードの現状を説明したドキュメント」は、コードが変わると静かに古くなる。このスキルは、ドキュメントが最後に更新された時点を起点に、それ以降のコード変更のうちそのドキュメントが扱う対象に関わるものだけを拾って反映する手順。
差分の起点を正しく取る。起点がずれると、反映済みの変更を二重に書いたり取りこぼしたりする。ドキュメント自身のコミット履歴が最も確実な起点になる。
対象に関係する変更だけに絞る。起点以降のリポジトリ全体の差分には、依存更新・別機能・設定など無関係な変更が大量に混ざる。「このドキュメントは何を説明しているか」を最初に押さえ、その対象に触れた変更だけを選り分ける。全差分を舐めると時間も精度も落ちる。
ドキュメントは文章なので機械的な置換では壊れる。用語が変わった・概念が廃止された、といった変更は、本文・図・表・手順など複数箇所に波及する。1箇所直して終わりにせず、「その変更がどこに効くか」の観点で全体を見渡す。
会話の文脈や開いているファイルから対象ドキュメントを特定する。不明ならユーザーに確認する。
通読して何を・どの粒度で説明しているかを掴む。特に拾うべきは:
これらが「コードのどの変更がドキュメントのどこに効くか」をマッピングする手がかりになる。
ドキュメント自身のコミット履歴の先頭が原則の起点 <BASE>:
git log --oneline -- <ドキュメントのパス> | head -5
例外・確認:
git log --oneline <BASE>..HEAD
git diff --stat <BASE>..HEAD
手順1で掴んだ固有名・概念をキーに、コミットメッセージやファイルパスで対象に関係する変更だけを選り分ける:
git log --oneline <BASE>..HEAD -- <対象に関わるディレクトリやファイルのglob>
選んだ変更の中身を読み、何がどう変わったかを一文で言えるレベルまで理解する。仕様の挙動に効かない純粋なリファクタやテストだけの変更は本文に影響しないことが多い（ただしドキュメントがコード上の固有名に言及していれば、その名前の変更は反映が要る）。
調査範囲が広く不確実なときは Explore エージェントに「このドキュメントが説明する対象に、起点以降で入った変更」を調べさせると速い。ただし最終的な取捨選択は自分で行う。
抽出した各変更について「ドキュメントのどの記述に効くか」を対応づける。これが反映作業の設計図になる。観点:
機械的に決められない判断が出たら、反映前に AskUserQuestion で確認する。典型例:
明確な変更だけなら確認を省いて進めてよい。
マッピングに沿って順に直す。注意:
反映後、旧記述が残っていないか確認する:
grep -n '<廃止した用語>\|<旧仕様の値>' <ドキュメントのパス>
残ってよいのは「廃止された」「以前は」という経緯説明の文脈だけ。図を変更した場合は変更後のブロックを目視で確認し、記法の整合を取る。
最後に反映した変更の一覧をユーザーに報告する。
git log -- <doc> で確実に押さえる。