メニュー
実装計画・ADR・Issue・PR diff・特定ディレクトリを対象に、計画に書かれていない前提／未接続の境界／将来の運用条件など「計画を無効化しうる未知 (unknown unknowns)」をコード・設定・テスト・ドキュメントの証拠で洗い出し、意思決定可能な形で報告する review-only スキル。実装開始前・PR 前・ADR/設計レビュー時に使う。設計は変更しない。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
本体（Makefile / CI / scripts）から切り離した品質ゲート検査を走らせる。HTTP マジックナンバー・100% カバレッジ・IAM Description ASCII・merge 整合・submodule pin を検査する。コミット前チェック、PR 前の品質確認のときに使う。
TenkaCloud architecture harness を実行し、.claude/harness の決定論的 enforcement rule 違反を検出する。コミット前のアーキテクチャ整合チェック、リファクタ後の確認、rule ID の意図や修正方法を調べるときに使う。判断原則の評価ではなく、機械判定可能なリポジトリ状態を検査する。
TenkaCloud の複雑な機能追加、障害修正、アーキテクチャ変更を、問題の形式化、独立した approach family の探索、証拠と exact gap の管理、TenkaCloud 固有の敵対的監査、TDD 実装、完了監査の順で進める適応型オーケストレーションスキル。Control Plane、Application Plane、problem runtime、認証、cross-account trust、データ整合性、CFn 物理変更、running cost、複数 mode にまたがる変更で使う。固定人数・固定役割ではなく、課題のリスクに応じて探索観点を動的に選ぶ。
Coach a TenkaCloud local-play drill problem — after solving (or while stuck on) a `make local` problem, explain what happened, the root cause, how it generalizes to competing in TenkaCloud Battle/Challenge, and code-free remediation, then answer follow-ups. Learner-facing; runs in the learner's own Claude Code (no platform, no API cost). Invoked as `/tenka-drill <problemId>`.
TenkaCloud tech-debt analyzer を実行し、test smell / 結合漏れ / magic number 等の技術的負債を検出する。コード品質、テスト改善、リファクタの優先順位、技術的負債バックログを訊かれたときに使う。
Write technical specifications in Open Web Docs format (MDN style). Use this skill when creating API documentation, function specs, or technical references.
| name | blindspot-pass |
| description | 実装計画・ADR・Issue・PR diff・特定ディレクトリを対象に、計画に書かれていない前提／未接続の境界／将来の運用条件など「計画を無効化しうる未知 (unknown unknowns)」をコード・設定・テスト・ドキュメントの証拠で洗い出し、意思決定可能な形で報告する review-only スキル。実装開始前・PR 前・ADR/設計レビュー時に使う。設計は変更しない。 |
実装計画・ADR・Issue は既知の要件を整理するには強いが、計画に書かれていない前提・未接続の境界・将来の運用条件までは保証しない。個々のスライスがテスト green でも、producer/consumer が互いに接続されていない、同じ操作でも経路ごとに account 解決の前提が違う、データ面が分断されている、といった「計画を破綻させうる未知」は後から見つかる。
このスキルは、そうした未検証の前提を証拠付きで探し、report として出すためのもの。参考: A Field Guide to Fable: Finding Your Unknowns。
/security-review / /simplify / 通常テストゲートを置換しない。review-only で、コード変更は一切行わない。対象は次のいずれか（複数可）を受け取れる。
#<番号> — gh issue view <n> で本文・完了条件を読むdocs/architecture/adr-*.html などのパス#<PR番号> または git diff <base>...<head>（未完成ブランチも可）infrastructure/lib/intent-ingress/ のような範囲対象が曖昧なときは推測で補完せず、後述の「未確定」として残す。
入力から短く抽出する。情報不足は推測で埋めず 未確定 と記す。
各主張を、確認すべき producer / consumer / transport / identity / storage / cleanup / observability に紐付ける。例:
| 観点 | 探すもの |
|---|---|
| Producer / consumer | producer のない consumer、consumer のない producer、片側だけの schema / event / env var |
| 経路差分 | API・Worker・Lambda・CLI・workflow など、同じ操作の別経路で異なる既定値・認可・account 解決 |
| Identity / tenancy | tenant / event / actor / role / audience の生成元・伝搬・検証・欠落時の挙動 |
| Data seam | DB / projection / cache / queue 間で writer がない・読まれない・schema が別・同期契約がない箇所 |
| Lifecycle | create / deploy / update / destroy / retry / rollback / sweeper が同じ resource identity を参照するか |
| Failure mode | 4xx / 5xx / timeout / retry / partial failure / idempotency / default が fail-open になっていないか |
| Security | secret 配置・署名方式・鍵ローテーション・scope・最小権限・cross-account 境界 |
| Operations | tag・監査ログ・メトリクス・alert・コスト backstop・手動復旧手順 |
| Spec drift | doc / コメント / 型の記述と実装（既定値・分岐）が食い違っていないか |
| Test illusion | 単体テストは green だが実経路・別プロセス・別アカウント・実データ面を通っていない箇所 |
メタパターン: 並行スライスを個別に作ると「producer のない consumer / consumer のない producer」が量産される。各片が green のテストを持つため完成に見える — ここを最優先で疑う。
発見は推測だけで確定しない。可能な限り以下を添える。
規模が大きければ Explore / general-purpose サブエージェントに観点を割り当てて並行探索し、結論だけ集約してよい。
Critical / High は「次の実装前に解くべき blocker か」を明記する。
# Blindspot pass: <対象>
## 結論
- 計画を進めてよい / 条件付きで進めてよい / blocker を先に解くべき
- 最重要の未知: <1行>
## 対象と前提
- 対象:
- 成功条件:
- 未確定な前提:
## 発見
### [Critical|High|Medium|Low] <短いタイトル>
- **何が起きるか**:
- **なぜ見落としやすいか**:
- **証拠**: `path:line` / symbol / command output
- **影響範囲**:
- **最小の是正方向**:
- **blocker 判定**: yes / no
## 接続マップ
- producer -> transport -> consumer
- identity / tenancy propagation
- lifecycle ownership
## 未検証のまま残る事項
- <調査不能だったものと理由>
## 次のアクション
1. <最優先>
2. <次点>
grep empty だけを根拠にしない）。仮説 と明示し、Critical と断定しない。main にないこと」と「設計上不要なこと」を区別する。複数の並行スライス（署名付き intent seam / 常設 Control Plane / データシーム）を横断した blindspot pass の抜粋。各発見はコードで裏取り済み。
[Critical] ingress 起源の deploy が誤アカウントに入る
- 何が起きるか: ある操作の デフォルト経路 が切り替わった後、別 producer（署名 intent の ingress）は AssumeRole 用メタデータ（role ARN / ExternalId）を event に載せない前提のままだった。新デフォルト経路のハンドラは event の該当フィールドが無いと同一アカウント経路へ fallback するため、競技者アカウントのはずの deploy がプラットフォームアカウントに入る。
- なぜ見落としやすいか: producer 側・consumer 側とも単体テストは green。旧経路には「下流が verified account を解決する」前提が成り立っていたが、デフォルト切替でその前提が別 consumer では崩れた（経路差分 + test illusion）。
- 証拠:
detail-builder.ts（両フィールドを未設定にする doc コメント）とcreate-stack.ts（event 値をそのまま使い、欠落時 undefined creds = 同一アカウント）。- 最小の是正方向: ingress で verified account を解決し、未検証は fail-closed。
- blocker 判定: yes
[High] per-event lifecycle が実体を持たない（consumer with no producer）
- 何が起きるか: 掃除の sweeper は特定タグのスタックだけを削除するが、そのタグを付与する構成コードがテスト内にしか存在しない。lifecycle workflow は event id を受けるが entrypoint がそれを読まず singleton を再デプロイし、destroy は
--all。- 証拠: タグ適用関数の唯一の呼び出し元がユニットテスト（
grepで本番コードに producer 無し）。- blocker 判定: yes
[Medium] データ面の分断（data seam）
- 何が起きるか: 常設面は D1、既存シームは DDB/Turso。同じ event/team が二つのストアに分かれ、片方で作ったデータがもう片方から見えない。橋渡しコードが無い。
- 是正方向: 収斂方針（どちらを canonical にし、どう橋渡すか）を決める。
（結論としては「Critical/High を先に解くべき blocker」と判定し、各々を独立 Issue 化した。）
report のみを出す。修正を勝手に実装しない。ユーザーが是正を指示したら、Critical から着手する。