# Pre Completion Self Audit

> 何かを実装・実行・配線した後、「完了」と言う前に必ず実行する敵対的セルフ監査。予測できる不具合(並行/失敗時/冪等/境界/セキュリティ)を自分で洗い出して潰し、監査表で先回り報告する。ユーザーに「漏れ全部潰してる？」と聞かせない。

- Skill: `bokuwalily/pre-completion-self-audit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add bokuwalily/pre-completion-self-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/bokuwalily/pre-completion-self-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: bokuwalily (https://skillmd.com/u/bokuwalily)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/bokuwalily/pre-completion-self-audit

---


## Procedure

実装/スクリプト/パイプライン/設定/インフラを書いた・変えた・配線したら、完了宣言の前に頭からこれを潰す。

1. **並行/競合** — 同時実行・連投・定時ジョブの重複でrace、git index.lock競合、二重deploy/書き込みは起きないか。→ mkdirロック(待ち+stale奪取)・冪等upsert・直列化で防ぐ。
2. **失敗時の挙動** — 通信失敗・ファイル欠落・部分データ・外部API仕様変更・クォータ超過で、**安全に止まるか / データ消失・フラップ(消えて復活)しないか**。→ fail-safe(破棄して停止)・前回成功値のキャッシュ復元・「失敗なら何もしない」。
3. **冪等性** — 同じ入力で再実行してバイト同一/無害か。二重登録・重複生成しないか。
4. **境界/空入力** — 0件・空文字・最大件数・想定外形式・**新旧フォーマット混在**(片方しか対応してないと崩れる)。
5. **セキュリティ** — 秘密値・実ホームパス混入、owner/remoteガード、push先が自分のprivate repoか。
6. **自己修復/可観測性** — 失敗が次サイクル(cron/reminder)で再浮上して回復するか。ログ/Discord通知/フラグで気づけるか。
7. **実検証(必須)** — 「動くはず」で止めない。**実際に走らせる/全分岐をテスト/期待件数vs実件数/ファイルmtime**で実体確認してから報告（捏造防止）。
   - **配布物・特典（zip/テンプレ/スクリプトを他人に渡す時）は「受け取った初心者の手順」を頭から実走**：クリーン環境に展開→READMEどおりコマンドを順に実行→最後まで通るか。「雛形だから」「骨格だから」は免罪符にならない（2026-07-11 Brain iOS特典: コード0行のproject.ymlが`xcodegen generate`即死・全行コメントのshを売って本人指摘で発覚）。売り物は自分のマシン前提を捨てて検証する（前提ツールの有無・PATH・アカウント固有値）。
8. **単純化/過剰抽象** — LLM/Codex生成コードは大げさになりがち。**もっと少ないファイル・関数・新概念でできないか**、既存パターンに素直に乗っているか、Dead code・不要コメント・関係ない変更が混じっていないか。「1000行の複雑」より「100行の明快」。削れるなら削ってから完了にする（重い時は `/simplify`・`code-simplifier`agentへ委譲）。

各項目で「該当する弱点」を見つけたら、軽微でも一旦挙げ、直すか・見送るか(理由つき)を判断する。

## 適用例: 自律ビルド後の出力検証（旧 autonomous-build-verify から吸収）

大規模実装・スクレイパー・フルスタック生成の完了宣言前は、7観点に加えて具体的に:
- **ダミーデータ残存**: `grep -r "dummy\|placeholder\|TODO\|FIXME\|lorem\|example.com" src/` で0件を確認
- **壊れた画像/URL**: `<img>` src の実在、スクレイパー出力の期待件数 vs 実件数（大きく下回れば問題として報告）
- **デプロイ状態**: `git status`（コミット漏れ）→ push 済み → 本番URLで動作確認。コミットだけでは本番に反映されない
- **スクレイパーUA**: Googlebot UA は多くのサイトでブロックされる。Chrome UA を使う
- **owner確認**: `git remote -v` が自分のprivate repoか、APIキーが環境変数経由か、.env が .gitignore に入っているか

## Pitfalls

- 「ビルド通った」「pushした」だけで完了にしない＝それは検証の一部でしかない。挙動の境界・失敗時を必ず見る。
- サブエージェント/Codexの「やった」報告を鵜呑みにしない。git diff・mtime・実行で実体確認してからレビュー。
- フラップ系(一時失敗で全消去→次回復活)は「動いてる時は見えない」ので特に意識して探す。外部fetchを使う生成器は要注意。
- 「全部潰した」と軽々しく言わない。無人系に絶対は無い。代わりに三層(①安全に止まる②自己修復③気づける)を示す。

## Verification

完了報告に必ず次を含める:
- **潰した**(実在バグ→修正＋検証結果) / **既に堅牢**(確認済み) / **あえて見送り**(理由・軽微) の3区分の短い表。
- 実際に走らせた検証コマンドと実結果(件数・200・diff等)。
- 「①安全に止まる②自己修復③気づける」がどう担保されているか1行で。

ユーザーが「漏れ全部潰してる？」と聞く前にこの表が出ていれば成功。聞かれたら運用失敗とみなし、次から発火を早める。