pre-report-check

name	pre-report-check
description	Run a mandatory self-check before reporting completion so git state, architecture rules, validation, and delivery quality are verified.

Pre-Report Self-Check Skill

ユーザーに「完了」を報告する前に、Gemini CLI 自身が必ず実行し、以下の項目を一つずつ自問自答して確認するためのスキルです。

📋 セルフチェックリスト

1. Git 運用とブランチ戦略

• 現在のブランチは正しいか？: develop や main に直接コミットしようとしていないか。必ず codex/vX-XX-... などのフィーチャーブランチであることを確認したか。
• マージ手順を守っているか？: ユーザーの承認なしに develop へマージ（特に --no-ff なし）やプッシュを行っていないか。
• コミット漏れはないか？: 修正内容はすべて git commit されたか。git status で Changes not staged for commit や Untracked files に修正対象が残っていないか。
• 履歴は正当か？: git log -n 5 等で、意図した通りのコミットメッセージと履歴が積み重なっているか。

2. コーディング規約 (CLAUDE.md / PROJECT_CONTEXT)

• コメントの禁止: コード内に説明的なコメント、TODO、不要なインラインコメントを追加していないか。
• 命名規則: プロジェクト固有の命名規則（C++ のスネークケース、C# のパスカルケース等）に従っているか。
• アーキテクチャの整合性: レイヤー（Domain, Infrastructure, Application, Presentation）の境界を越えた不適切な依存関係を導入していないか。

3. 実装の技術的整合性

• エラーハンドリング: サイレント失敗（エラーを .ok() で無視する、例外をキャッチして何もしない等）をしていないか。必ずユーザーや上位レイヤーにエラーを伝播・報告しているか。
• 副作用のパリティ: C# 参照実装が行っている副作用（ファイル保存、メモリ更新、状態遷移）を、C++ 側でも漏れなく再現しているか。
• リソース管理: RAII (C++) や using (C#) を適切に使い、リソースリーク（ファイルハンドル、メモリ、一時ファイル）を防いでいるか。

4. 検証の網羅性

• ビルド確認: C++ であれば cmake --build、C# であれば dotnet build が警告なしで通るか。
• テスト実行: dotnet test や ctest を実行し、既存および新規のテストがすべてパスすることを確認したか。
• 実機/スモークテスト: 可能な限り、作成したツールや機能が実際のデータに対して期待通り動作することを手動またはスクリプトで確認したか。

🚀 実行フロー

1. activate_skill pre-report-check を呼び出す。
2. 上記のリストを現在の作業内容に照らし合わせて、心の中で（あるいは思考プロセス内で）すべてチェックする。
3. もし一つでもチェックが漏れている、あるいは不確かな場合は、報告を中断して修正に戻る。
4. すべてのチェックが完了したと確信できる場合のみ、ユーザーに報告する。