菜单
現在のブランチまたは指定した PR の差分を読み、変更内容に応じた動作確認手順を `.ai-loacl/verification/*.local.md` に生成または追記する。 実装完了後やレビュー / CI 対応後に、手動確認が必要な差分を確認可能なチェックリストへ変換したいときに使う。 例: 「変更分の動作確認手順を作る」「PR 123 の verification を更新する」。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | create-verification |
| description | 現在のブランチまたは指定した PR の差分を読み、変更内容に応じた動作確認手順を `.ai-loacl/verification/*.local.md` に生成または追記する。 実装完了後やレビュー / CI 対応後に、手動確認が必要な差分を確認可能なチェックリストへ変換したいときに使う。 例: 「変更分の動作確認手順を作る」「PR 123 の verification を更新する」。 |
変更差分を読み、手動確認に使う verification ドキュメントを作るスキルです。 初回は新規作成し、レビュー / CI 対応後は同じ verification ファイルへ必要分だけ追記します。
.ai-loacl/verification/*.local.md に verification ドキュメントを新規作成または追記する。references/verification-template.md: 出力フォーマットと、変更種別ごとの確認観点を組み立てる直前に読む。.ai-loacl/verification/ 配下の .local.md に固定する。pr-<PR番号>-<ブランチ名スラッグ>.local.md を優先し、PR番号が無い場合は worktree-<ブランチ名スラッグ>.local.md にする。## チェックリスト にある ✅ / ⏭️ / □ は保持し、既存項目を勝手にリセットしない。gh pr view <番号> --json title,body,number、gh pr diff <番号> --name-only、gh pr diff <番号> を使う。git diff main...HEAD を使う。references/verification-template.md を読み、出力構造を決める。## 確認N とチェック項目として足す。日本語で次を報告してください。
承認済みの実装プランファイルを、同一セッションの継続または新しいセッションで端から端まで実行する。 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 作成後に一定時間待ち、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 は何か」。