HikaruEgashira 監査の前提
「deep」と「adoptable」は scope を分離すれば喧嘩をやめる。深さは再利用可能な engine に隠し、ユーザーが触れる面は鋭い単一用途の楔にする。「薄いシェル over 深いライブラリ」は本質的にディストリビューション判断。楔の鋭さが「価値が自分ごとになる確率」を決める。
罠: 深い builder ほど「全部入り」を作りたがる。手を広げて全機能が 2x の凡庸より、1 ユースケースが 10x の鋭い楔の方が deep OSS は刺さる。
監査ステップ
1. 楔の鋭さを見る
ユーザーに見せる面が単一の鋭いユースケースか、「何でもできる」曖昧な面か。曖昧さは「これは自分の問題のためのツールだ」という認識を妨げる。
2. 深さの隠し場所を見る(engine/shell 分離)
深い実装が再利用可能な engine/core に分離され、薄い platform shell が consume する構造か。深さを楔の表面に漏らしていないか。
3. 寄生先を見る(採用摩擦)
楔が既存ワークフロー(gh CLI / npx / パイプ / editor / CI)に寄生して採用摩擦を下げているか。ゼロから新習慣を要求していないか。
4. 「10x の一点」を見る
楔は「最初の鋭い1ユースケースを 10x better」にしてから広げる戦略か。最初から手を広げて全部 2x の凡庸に陥っていないか。
スコアリング・ルーブリック (0-10)
| スコア | 状態 |
|---|---|
| 0-2 | 「何でもできる」曖昧な面。深さが表面に漏れ、初見が用途を掴めない。新習慣を強要 |
| 3-5 | 用途は一応単一だが engine/shell が未分離(深さが楔に癒着)。寄生先なし |
| 6-7 | 鋭い楔 or engine 分離、どちらか + 既存ワークフローへの寄生 |
| 8-9 | 鋭い楔 + engine/shell 分離 + 寄生先、を満たす |
| 10 | 上記全て + 明確な「10x の一点」。engine が複数 shell に再利用され面を広げられる |
engine/shell が別 repo で片方欠如なら見える範囲で採点し欠如側を未検証と明記。
出力フォーマット
_workspace/03_wedge_scoper.md に:
# Wedge Audit: <repo>
## スコア: N/10 — <一言根拠>
## 楔の鋭さ
<単一用途か曖昧か>
## engine / shell 分離
<どこに深さ、どこに楔。分離図>
## 寄生先
<既存ワークフローへの寄生と採用摩擦>
## 10x の一点
<最初に 10x にする鋭い1点はどこか>
## scope リスクと提案
| Severity | リスク | 位置/構成 | 提案(絞る/分離する/寄生する) |
|----------|--------|-----------|--------------------------------|
アンチパターン(減点対象)
| パターン | なぜ減点 |
|---|---|
| 「何でもできる」面 | 自分ごと化を妨げ、誰にも刺さらない |
| 深さを楔に癒着(engine 未分離) | 拡張不能、楔が太って初回が重い |
| 新習慣を強要(寄生しない) | 採用摩擦が最大化 |
| 最初から多機能(10x の一点が無い) | 全部 2x の凡庸、差別化なし |
| engine を1 shell に密結合 | 再利用で面を広げられない |