# Exploratory Nightly Verification

> Nightly Checking ワークフロー上で 60 分 budget の単発探索的検証を行う運用規約。 PR 差分ではなく main の最新を対象に、 ライブラリ本体・integrationTest・docs 全体を 多角的に揺さぶり、発見都度 `.local/nightly-exploration/issues/` へ Markdown 起票する。 Kotlin / Compose / Gradle / AGP の最新 release 情報も探索範囲に含める。 Use when requested: "nightly 探索", "夜間探索的検証", "exploratory-nightly".

- Skill: `tbsten/exploratory-nightly-verification-2` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add tbsten/exploratory-nightly-verification-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tbsten/exploratory-nightly-verification-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: tbsten (https://skillmd.com/u/tbsten)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tbsten/exploratory-nightly-verification-2

---


# Exploratory Nightly Verification

GitHub Actions の Nightly Checking ワークフロー (`anthropics/claude-code-action`) から
このスキルを起動して、 main の最新コードを 60 分 budget で探索的に検証する。

PR 差分ベースの `exploratory-pr-verification` とは別物。 ループ運用や PR コメント投稿、
ticket 番号予約、 メンテナ反応 latency 等の概念は **すべて廃止** している。

## 0. 最重要の不変条件

| # | 条件 | 違反した場合の影響 |
|---|------|--------------------|
| A | **逐次書き出し**: 発見ごとに即 `.local/nightly-exploration/issues/<NN>-<slug>.md` を書く | 最後にまとめて出力すると、 60 分タイムアウト時に丸ごと失われる |
| B | **時間予算は 60 分・50 分時点で打ち切り**: 残り 10 分は新規探索を止め、 起票済み issue の整形と書き込みに使う | 探索の途中で kill されると不完全な issue が出る |
| C | **issue ファイル名は連番**: `01-<kebab-slug>.md` から始まる 2 桁連番 | Discord 通知側が `sort` 前提でパースするため、 順序が壊れると整合性が崩れる |
| D | **PR への副作用は一切行わない**: コメント投稿、 issue 起票、 push、 branch 操作などはすべて禁止 | nightly は read-only 検証なので、 副作用は事故の元 |

## 1. ワークフロー（PDCA を 60 分 single shot で）

1. **環境確認（〜3 分）**
   - `pwd` / `git rev-parse HEAD` / `git status --short`
   - `cat gradle/libs.versions.toml | head -30` で現バージョン把握
2. **計画（〜5 分）**
   - `references/categories.md` を読み、 cat1 → cat5 のうち回す順序を決める
   - TodoWrite 等で各 cat の所要時間目安をメモ
3. **逐次探索（〜50 分）**
   - cat1 → cat5 の順で 1 つずつ、 各 8〜10 分目安
   - 発見ごとに即 issue file を書く（後述の固定フォーマット）
   - 1 件書いたら次の探索に移る
4. **終盤整形（50〜58 分）**
   - 既存 issue を読み直し、 重複統合・タイトル整形・本文の最終チェック
   - `.local/nightly-exploration/SUMMARY.md` に件数とカテゴリ別内訳を書き出す
5. **終了報告（〜60 分）**
   - SUMMARY.md と件数を最終 message に出して終わる

## 2. 探索カテゴリ

詳細は [`references/categories.md`](references/categories.md) を参照。 サマリだけ:

- **cat1 静的解析**: KDoc / Single source of truth / silent failure / 型設計 / TODO 残骸
- **cat2 CI ログ・apiDump baseline**: nightly 系の warning grep、 apiDump roundtrip、 docs 整合
- **cat3 動的ビルド・テスト**: `./gradlew jvmTest` `integrationTest` `docs` を必要に応じ走らせて failure / warning を拾う
- **cat4 外部依存リリース監視**: Kotlin / Compose Multiplatform / Gradle / AGP の最新 release を確認し、 libs.versions.toml と比較して乖離を起票
- **cat5 比較・残角度**: 他 KCP との比較、 過去 TODO grep、 BCP/SemVer 観点、 dev module の起動可否

並列 subagent kick は **しない**。 GitHub Actions の単一 VM 内で Claude 自身が cat1 → cat5
を sequential に回す。 これは時間予算とリソースの制約による。

## 3. issue の固定フォーマット

詳細は [`references/issue-format.md`](references/issue-format.md) を参照。 必須項目:

- ファイル名: `.local/nightly-exploration/issues/<NN>-<kebab-slug>.md`
  - `NN` は `01` から始まる 2 桁連番（書き出し順）
  - `<kebab-slug>` は半角英数とハイフン、 40 文字以内
- 本文 1 行目: `# <短いタイトル>` （日本語可、 60 文字以内）
- 続いて以下のメタ行と見出し:
  - `**カテゴリ**: cat<N> (<名前>)`
  - `**重要度**: P0 | P1 | P2 | P3`
  - `**検出時 commit**: <git rev-parse HEAD の先頭 12 文字>`
  - `## 再現手順`
  - `## 詳細`
  - `## 修正案（任意）`

タイトルとメタ行と `## 詳細` の先頭数行は Discord 通知にそのまま転載されるため、
**Discord で読んで意味が通る粒度で書く**。

## 4. 重要度の目安

| 重要度 | 目安 |
|--------|------|
| P0 | ライブラリ利用者の手元で確実にビルド失敗・実行失敗する |
| P1 | 公開 API の挙動が壊れている / セキュリティ懸念 / docs の致命的な誤り |
| P2 | 内部実装の不整合・改善余地・将来の brittleness |
| P3 | 体感ノイズ・小さな typo・改善提案 |

P0/P1 はその場で必ず起票。 P2/P3 は時間に余裕があるときに掘り下げる。

## 5. ツールの使い分け

- `Read` / `Glob` / `Grep`: 静的解析（cat1, cat2, cat5）
- `Bash`: gradle コマンド・git ・apiDump roundtrip（cat2, cat3）
  - 長時間 task は `timeout 8m` でガード（60 分 budget を保護）
  - 出力はログ切り捨てず `.local/nightly-exploration/tmp/<ts>-<cmd>.log` にリダイレクト
- `WebFetch`: Kotlin / Compose / Gradle / AGP の releases（cat4）
- `WebSearch`: cat5 で残角度を探す場合のみ

`.local/nightly-exploration/tmp/` 配下のログは artifact として残らない（issue だけが残る）ので、
**重要な発見はかならず issue Markdown に転記** する。

## 6. 想定外の失敗時の挙動

- `WebFetch` 失敗 / レート制限 → その事実自体を P3 issue として起票し、 次のカテゴリへ進む
- gradle コマンドの失敗 → 失敗内容を P1 として起票（CI 環境固有の問題なら P2 に下げる）
- スキル本体の読み込み失敗 → 起動できないので action 側の `if: always()` でカバー

## 7. 終了処理

- 探索ループを抜けたら `.local/nightly-exploration/SUMMARY.md` を書く（テンプレ）:

```markdown
# Nightly Exploration Summary

- 実施日時: <iso8601>
- 対象 commit: <git rev-parse HEAD>
- 発見件数: N 件

## カテゴリ別内訳
- cat1: N 件
- cat2: N 件
- cat3: N 件
- cat4: N 件
- cat5: N 件

## 重要度別内訳
- P0: N 件
- P1: N 件
- P2: N 件
- P3: N 件
```

- ループ運用はしない。 `/loop` も再 kick も呼ばない。
- 最後の message では「N 件起票」「SUMMARY.md を書いた」とだけ伝えて終わる