Ttfv audit

監査の前提

dev tool の採用率の上限は TTFV が指数的に支配する。新規ユーザーの行動は確率過程で、各ステップで一定割合が脱落する。5 ステップで各 70% 残存なら最後まで来るのは 0.7^5 ≈ 17%。ステップを1個消すと残存が約 1.4 倍になる。機能を1個足すより効く。

罠: deep なツールほど default で TTFV が悪化する。深さ＝設定可能性＝初回の意思決定コスト。だから「作者が自分の深さと戦って初回体験を彫れているか」を見る。

監査ステップ

1. 初回ファネルを step 単位で復元する

README と実コードから、見知らぬ人の経路を機械的に並べる: 発見 → install → 最初のコマンド → 最初の結果。各 step を1行で書き、本物の価値(意味のある結果)に届くまでのコマンド数を数える。

<example> <input>gh-verify を監査</input> <output> | step | 操作 | コスト | |------|------|--------| | 1 | `gh extension install HikaruEgashira/gh-verify` | install | | 2 | `gh verify pr 6933 --repo expressjs/express` | 1 コマンドで本物の findings |

TTFV ≈ install + 1 コマンド。他人の有名 repo(expressjs/express)をデモ対象に借りている → 自分の repo を晒さず試せる。価値が即わかる。 </output> </example>

2. 「引数ゼロで動くか」を見る(推測の ladder)

日常利用での最短コマンドを決めるのは、ツールが省略可能な引数をどこまで推測するか。明示 > 環境 > 文脈、の ladder の最下段が「ふつうの使い方」に据えられているかを確認する。

<example> <input>gh-verify の repo 解決</input> <output> `crates/cli/src/main.rs:840` `resolve_repo`: 明示 `--repo` > 環境 `GH_REPO` > 文脈 `detect_repo_from_git_remote()`。 最下段が `git remote get-url origin` から repo を推測 → repo 内なら `gh verify pr 42` だけで動く。 **評価: ladder の底が日常利用に据えられている → 強い。** </output> </example>

3. 失敗パスを採点する(本体)

脱落が起きるのは成功パスでなく失敗パス。新規ユーザーほど想定外の文脈にいる。全 error が [現象] + [次に打つ手] + (実例) の型かを確認する。

<example> <input>gh-verify のエラー</input> <output> `main.rs:849`: "could not resolve repo. Use --repo OWNER/REPO or set GH_REPO env var" `main.rs:854`: "invalid repo format '{}'. Expected OWNER/REPO (e.g. cli/cli)" 両方とも [現象]+[次の手]+実例(cli/cli)。失敗を1リトライに変換 → 強い。 </output> </example>

4. 「借りているか」を見る

ユーザーの世界に既にあるもの(install: npx / 文脈: git remote / 既存ツール: pipe)へ接続し、自作範囲を減らしているか。

<example> <input>parsentry</input> <output> `npx skills add HikaruEgashira/parsentry` → install を消す。 `parsentry scan owner/repo | claude -p` → 分析エンジンを既存 claude から借りる。証明すべき価値を「良い prompt 生成」に絞れている → 強い。 </output> </example>

スコアリング・ルーブリック (0-10)

スコア	状態
0-2	install 後、本物の結果に届くまで複数の設定/認証/サンプル準備が必須。引数必須。エラーは現象のみ
3-5	1 コマンドだが repo/config を毎回明示要求。失敗パスのエラーが不親切
6-7	引数ゼロで動く文脈推測あり or 良いエラー、どちらか。デモ対象を借りている
8	{推測 ladder, 良い失敗パス, 借りる設計} のうちちょうど 2 つを満たす
9	3 つすべて満たすが install が実質ゼロでない(例: extension/cargo install が必須)
10	3 つすべて + install すら実質ゼロ(npx 等)。初見が秒で「これは凄い」に到達

証拠不足で測定不能なら Indeterminate(スコアを捏造しない)。

出力フォーマット

_workspace/01_ttfv_auditor.md に:

# TTFV Audit: <repo>
## スコア: N/10 — <一言根拠>
## 初回ファネル
<step テーブル>
## 推測の ladder
<resolve 系の評価>
## 失敗パス
<エラーの型評価>
## 借りる設計
<install/文脈/pipe の評価>
## 摩擦と提案
| Severity | 摩擦 | 位置 | 提案(削る/借りる) |
|----------|------|------|----------------------|

アンチパターン(監査で減点する対象)

パターン	なぜ減点
初回に config ファイル必須	ステップ増 = 指数的脱落
全引数 required	日常利用の最短コマンドが伸びる
エラーが現象のみ(次の手なし)	失敗パスで離脱
自前で全部抱える(借りない)	初回到達が重くなる
深さを初回に露出	deep ほど TTFV が悪化する罠