final-verification

Sterne0

Forks0

Aktualisiert3. Juli 2026 um 01:47

Final pre-commit, pre-push, or pre-merge verification for implementation work. Use when Codex needs to confirm the change satisfies the user's request before committing, pushing, opening, updating, or merging a PR; when asked for a final check; or when PR-linked context such as issues, review comments, CI checks, changed files, and acceptance criteria must be verified against the implementation.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

m3m0r7

m3m0r7/dotfiles

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

Datei-Explorer

2 Dateien

SKILL.md

readonly

name	final-verification
description	Final pre-commit, pre-push, or pre-merge verification for implementation work. Use when Codex needs to confirm the change satisfies the user's request before committing, pushing, opening, updating, or merging a PR; when asked for a final check; or when PR-linked context such as issues, review comments, CI checks, changed files, and acceptance criteria must be verified against the implementation.

Final Verification

変更を commit / push / PR 更新 / merge する直前に、実装が本当に仕様を満たしているか確認する workflow。不一致、未解決レビュー、CI 失敗、未検証の重要リスクがある場合は作業を止め、commit / push / merge へ進まない。

1. 確認元を集める

次の情報を、推測ではなく確認元として扱う。

ユーザーの最新依頼、会話内の制約、明示された受け入れ条件
git status --short、git diff、必要に応じて base branch との差分
関連するテスト、lint、型チェック、ビルド設定
PR がある場合は PR の title / body / changed files / commits / comments / reviews / CI checks
PR に紐づく issue、closing keywords、本文やコメント内の issue / ticket / docs リンク

PR 情報を取れる場合は gh を優先する。

gh pr view --json number,title,body,url,baseRefName,headRefName,state,isDraft,files,commits,comments,reviews,latestReviews,reviewDecision,statusCheckRollup
gh pr view --comments

PR 本文・タイトル・コメントから Closes / Fixes / Resolves、#123、owner/repo#123、GitHub issue URL、外部 ticket URL を探す。 GitHub issue は可能なら gh issue view <number> --comments で確認する。 gh が使えない、未ログイン、ネットワーク不可、外部 ticket が認証不可の場合は、その制約を最終報告に明示する。

2. 仕様チェックリストを作る

確認元から満たすべき仕様を短いチェックリストに分解する。

ユーザー依頼の必須要件
PR / issue の受け入れ条件
レビューコメントで要求された修正
既存挙動を壊してはいけない箇所
UI 変更、API 契約、DB 状態、権限、エラー処理などの品質観点

各項目について「対応する変更箇所」「確認方法」「結果」を対応付ける。対応箇所や確認方法が見つからない項目は未達または未検証として扱う。

3. 差分を検査する

git diff を読み、仕様チェックリストと差分が対応しているか確認する。

要件に対して実装が不足していないか
仕様と無関係な変更、デバッグコード、不要なログ、生成物、秘密情報が混ざっていないか
同じ修正が必要な類似箇所に横展開されているか
既存 API、保存データ、権限、バリデーション、エラー表示、i18n、アクセシビリティに副作用がないか
テストが実装の重要な分岐とリグレッションを押さえているか

PR の changed files とローカル diff が食い違う場合は、どちらを確認対象にしたか明示する。

4. PR に紐づくものを確認する

PR が存在する場合は、実装だけでなく PR 周辺の状態も確認する。

PR title / body が実装内容と一致しているか
linked issue / ticket の要求、受け入れ条件、コメントに未対応がないか
review comments と requested changes が解決済み、または今回の差分で明確に対応済みか
CI / status checks が成功しているか。失敗・pending・skipped があれば意味を確認する
draft / base branch / head branch / merge target が意図どおりか
PR に含まれる commit と changed files が今回の目的に対して過不足ないか

レビューコメントを確認した場合は、重要な指摘ごとに「対応済み」「未対応」「対象外」の判断を残す。

5. 検証を実行する

リポジトリの既存手順に従い、必要な検証を実行する。不明な場合は package scripts、README、CI 設定、memory、プロジェクトの plan / QA 系 md を確認する。

変更範囲に対応する unit / integration tests
lint、format check、type check
build または compile
UI 変更がある場合はブラウザ確認。必要なら automatic-e2e を使い、スクリーンショットを残す
DB / API / cookie / localStorage / sessionStorage など状態整合性が関係する場合は quality-mind の観点で確認する

検証を実行できない場合は、理由と代替確認を明示する。重要な検証が未実行のままなら、commit / push / merge に進まない判断を優先する。

6. 最終判断を出す

最後に、commit / push / merge に進めるかを明確に判断する。

OK: 仕様チェックリストを満たし、必要な検証が通り、PR 関連の未解決事項がない
Blocked: 仕様未達、テスト失敗、CI 失敗、未解決レビュー、PR-linked issue の未対応、重要な未検証リスクがある
Limited: 外部情報や権限不足で一部確認できないが、ローカルで確認可能な範囲は満たしている

最終報告には次を含める。

満たした仕様
確認した PR / issue / review / CI の範囲
実行した検証コマンドと結果
未対応または未検証のリスク
commit / push / merge に進めるかの判断

Mehr aus diesem Repository

gleiches Repository

clear-japanese

m3m0r7/dotfiles

日本語の応答を、明瞭・簡潔・LLM 口調なしで書くための規範。会話、説明、提案、相談のすべてで適用する。

2026-07-170

cognitive-rhythm-writing

m3m0r7/dotfiles

説明的な文章に緩急を設計するための規範。緩急を装飾ではなく認知モードの切替（観察→逡巡→断定→再観察）と未回収の緊張の管理として扱い、文の拍、段落の密度波形、節の入り方、緩みと駄文の判別、執筆後の機械的な点検手順を定める。読み物として読ませたい章・記事・解説文を生成するとき、または「密度はあるが平坦でおもしろくない」文章を診断・修正するときに使用する。

2026-07-170

automatic-e2e

m3m0r7/dotfiles

Web アプリの E2E テストを「計画 → 実行 → エビデンス保存 → 後始末」まで自律的に進めるための skill。グローバルの agent-browser CLI を headless で使い、quality-mind の共通品質観点（正常系、境界値、ドメイン外値、悪意ある異常系、状態整合性、リグレッション）に沿ってブラウザ操作と検証を行い、確認結果をスクリーンショットとして ./tmp/e2e/ 配下にエビデンスとして残す。認証が必要なアプリの動作確認、フォーム投入・バリデーションの検証、リリース前の通し確認をするときに使う。単体テストや read-only のコード調査だけで完結するとき、ブラウザ操作を伴わないときは使わない。

2026-07-030

design-mind

m3m0r7/dotfiles

UI・フロントエンドの実装・修正・レビューで必ず使う skill。画面、コンポーネント、フォーム、ダイアログ、スタイル、文言、状態管理、UX を扱うときに、既存デザインシステムの再利用、i18n、操作性の定番作法、再レンダリング、日本語入力(IME)の観点で判断する。バックエンドのみ・CLI のみの作業では使わない。

2026-07-030

implementation-mind

m3m0r7/dotfiles

コードの実装・修正・リファクタリングを行うすべての作業で必ず使う skill。書き始める前に「正しい置き場所」「既存の同種実装」「本質的な解決策」を確認し、フォールバック、ハードコード、スタブ、名前文字列による分岐、指示されていない互換レイヤーといった対症療法を検知して排除する。責務分離、命名、ファイル分割、破壊的変更の要否など設計判断にも使う。read-only の調査・説明だけで完結するときは使わない。

2026-07-030

product-mind

m3m0r7/dotfiles

仕様を決める・機能を切る・UX を判断する・優先順位を提案する・仕様の妥当性をレビューするときに必ず使う skill。実装依頼に仕様の曖昧さが含まれるとき、エラー時の振る舞いを決めるとき、フェーズやスコープを切るとき、機能提案を求められたときに使う。仕様が完全に確定していて実装するだけのときは軽く通す。

2026-07-030

name	final-verification
description	Final pre-commit, pre-push, or pre-merge verification for implementation work. Use when Codex needs to confirm the change satisfies the user's request before committing, pushing, opening, updating, or merging a PR; when asked for a final check; or when PR-linked context such as issues, review comments, CI checks, changed files, and acceptance criteria must be verified against the implementation.

Final Verification

1. 確認元を集める

次の情報を、推測ではなく確認元として扱う。

ユーザーの最新依頼、会話内の制約、明示された受け入れ条件
git status --short、git diff、必要に応じて base branch との差分
関連するテスト、lint、型チェック、ビルド設定
PR がある場合は PR の title / body / changed files / commits / comments / reviews / CI checks
PR に紐づく issue、closing keywords、本文やコメント内の issue / ticket / docs リンク

PR 情報を取れる場合は gh を優先する。

gh pr view --json number,title,body,url,baseRefName,headRefName,state,isDraft,files,commits,comments,reviews,latestReviews,reviewDecision,statusCheckRollup
gh pr view --comments

2. 仕様チェックリストを作る

確認元から満たすべき仕様を短いチェックリストに分解する。

ユーザー依頼の必須要件
PR / issue の受け入れ条件
レビューコメントで要求された修正
既存挙動を壊してはいけない箇所
UI 変更、API 契約、DB 状態、権限、エラー処理などの品質観点

3. 差分を検査する

git diff を読み、仕様チェックリストと差分が対応しているか確認する。

要件に対して実装が不足していないか
仕様と無関係な変更、デバッグコード、不要なログ、生成物、秘密情報が混ざっていないか
同じ修正が必要な類似箇所に横展開されているか
既存 API、保存データ、権限、バリデーション、エラー表示、i18n、アクセシビリティに副作用がないか
テストが実装の重要な分岐とリグレッションを押さえているか

PR の changed files とローカル diff が食い違う場合は、どちらを確認対象にしたか明示する。

4. PR に紐づくものを確認する

PR が存在する場合は、実装だけでなく PR 周辺の状態も確認する。

PR title / body が実装内容と一致しているか
linked issue / ticket の要求、受け入れ条件、コメントに未対応がないか
review comments と requested changes が解決済み、または今回の差分で明確に対応済みか
CI / status checks が成功しているか。失敗・pending・skipped があれば意味を確認する
draft / base branch / head branch / merge target が意図どおりか
PR に含まれる commit と changed files が今回の目的に対して過不足ないか

レビューコメントを確認した場合は、重要な指摘ごとに「対応済み」「未対応」「対象外」の判断を残す。

5. 検証を実行する

リポジトリの既存手順に従い、必要な検証を実行する。不明な場合は package scripts、README、CI 設定、memory、プロジェクトの plan / QA 系 md を確認する。

変更範囲に対応する unit / integration tests
lint、format check、type check
build または compile
UI 変更がある場合はブラウザ確認。必要なら automatic-e2e を使い、スクリーンショットを残す
DB / API / cookie / localStorage / sessionStorage など状態整合性が関係する場合は quality-mind の観点で確認する

検証を実行できない場合は、理由と代替確認を明示する。重要な検証が未実行のままなら、commit / push / merge に進まない判断を優先する。

6. 最終判断を出す

最後に、commit / push / merge に進めるかを明確に判断する。

OK: 仕様チェックリストを満たし、必要な検証が通り、PR 関連の未解決事項がない
Blocked: 仕様未達、テスト失敗、CI 失敗、未解決レビュー、PR-linked issue の未対応、重要な未検証リスクがある
Limited: 外部情報や権限不足で一部確認できないが、ローカルで確認可能な範囲は満たしている

最終報告には次を含める。

満たした仕様
確認した PR / issue / review / CI の範囲
実行した検証コマンドと結果
未対応または未検証のリスク
commit / push / merge に進めるかの判断