dotfiles

承認済みの実装プランファイルを、同一セッションの継続または新しいセッションで端から端まで実行する。 feature branch を作成し、プランの `## タスク` をテスト込みで進め、lint / test を緑にする。 リスクに応じた AI レビューを受け、commit-changes で論理コミットを作り、open-pr-followup で PR 作成後の CI と AI レビュー初回フォローまで進める。 承認済みプランを渡されて実装を始めるときに使う。 例: 「implement-plan スキルで実装して」「プランを実装して」 ticket-to-plan がプランファイルを指す実装セッションを起動したときにも使う。 これは ticket-to-plan → implement-plan → commit-changes → open-pr-followup パイプラインの実装フェーズである。

GitHub や Linear のチケット、またはユーザーの自然言語の変更依頼を十分に調査し、承認済みの実装プランファイルに変換する。 コンテキストに余裕があれば同一セッションで implement-plan による実装まで続け、コンテキスト不足が予想されるときだけ別セッションへ引き継ぐ。 ユーザーがチケットを指しただけのとき、チケットを import したとき、またはチケットなしでコーディング前に plan / 計画を求めたときに使う。 例: 「https://github.com/foo/bar/issues/42」「plan ENG-1234」「このissueの実装計画」「github.com/foo/bar/issues/42 のプラン」「ticket-to-plan で X を Y にしたい」「X に変えるプラン」 issue / PR / Linear ID または自然言語の変更依頼を参照して、すぐ実装するのではなく設計、スコープ確定、タスク分解を求める場合にも使う。

GitHub PR の未解決レビューコメントとレビュー本文を取得し、実コードを読んで must-fix / recommend-fix / recommend-skip にトリアージして修正する。 bot コメントも対象にし、解決済みスレッドは除外する。 must-fix は自動で進め、任意対応はユーザー確認後に実装する。 PR のレビュー指摘を処理したいときに使う。 例: 「PRのコメントに対応して」「レビュー対応」「PRの指摘を直して」「レビューを反映」。 対応実装後に commit / push、`update-pr-description` による PR description 更新、対象レビューコメントへの対応済み reply、thread resolve まで行う。

現在のブランチまたは指定した PR の差分を読み、変更内容に応じた動作確認手順を `.ai-loacl/verification/*.local.md` に生成または追記する。 実装完了後やレビュー / CI 対応後に、手動確認が必要な差分を確認可能なチェックリストへ変換したいときに使う。 例: 「変更分の動作確認手順を作る」「PR 123 の verification を更新する」。

PR 作成後に一定時間待ち、GitHub Actions CI と AI レビュー / レビューコメントを確認して、既存スキルへ切り出して後追い対応する。 PR 作成は open-pr、CI 失敗は GitHub plugin の gh-fix-ci、レビューコメント対応は address-pr-comments または GitHub plugin の gh-address-comments を使い、必要なら `update-pr-description` で PR 本文も同期する。 例: 「PR作って、CIとAIレビューまで見て」「PR作成後にレビュー指摘とCI失敗も対応して」「open-pr のあとしばらく待って後追いして」。 implement-plan / commit-changes 完了後に、PR 作成だけで止めずに CI と AI レビューの初回フォローまで進めたいときに使う。

`.ai-loacl/verification/*.local.md` の動作確認手順を順に案内し、 各確認の結果を `✅` または `⏭️` として記録する。 実装完了後やレビュー / CI 対応後に、作成済み verification を対話的に消化したいときに使う。 例: 「今の verification を進める」「この verification ファイルを再開する」。

調査、設計、実装、レビュー対応の途中で、repo や既存資料だけでは解決できない不明点をユーザーへ短く確認する。 スコープ、成功条件、互換性、優先順位、維持したい挙動など、ユーザー判断が必要な open question を整理するときに使う。 例: 「この挙動は維持するか」「どの案を優先するか」「回答がない場合の default assumption は何か」。

未コミット差分を確認し、レビューしやすい粒度の論理コミットに分割して作成する。 コミットしてほしいとき、PR 作成前に差分をコミットする必要があるとき、または implement-plan 完了後に open-pr / open-pr-followup へ渡す前に使う。 例: 「コミットして」「変更をコミット」「commit」「PR 前にコミット」。 push / PR 作成 / GitHub への書き戻しは行わない。

dotfiles リポジトリの agent-resources で skill または agent definition を作成・更新・整理するときに使う。 `agent-resources/skills` と `agent-resources/agents` を source of truth とし、skill は `.agents/skills` と `.claude/skills`、agent definition は `.agents/agents`、`.claude/agents`、`.codex/agents` への公開 symlink と検証を維持する。 例: 「新しいスキルを作って」「対応するスキルを更新して」「agentを追加して」

コミット済みの現在ブランチを push して GitHub PR を作成する。 PR を開きたいとき、または implement-plan / commit-changes 完了後の PR 作成引き継ぎで使う。 例: 「PR作成」「PR作って」「プルリク」。 未コミット差分がある場合は commit-changes に引き渡す。 push / gh pr create は外向きの操作なので、実行前にユーザー確認を取る。

既存の GitHub PR description/body を、現在の実装内容と検証結果に合わせて最小差分で更新する。 PR 本文だけを単独で更新したいときや、レビュー対応・CI 対応の後に本文の整合性を取り直したいときに使う。 例: 「PR本文を更新して」「PR description を最新実装に合わせて」「レビュー対応後に PR 本文も直して」。