菜单
dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/HikaruEgashira/agent-skills --skill ttfv-audit命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
codex CLI をツール実行エンジンとして使い、codex 側にのみ接続済みの能力 (Apps Connectors, MCP servers, computer use, web search) を `codex exec` 経由で 外部エージェント (Claude Code / opencode 等) から利用する。 Trigger: codex as tool, Google Drive アクセス, Apps Connector 利用, codex exec, ツール借用
agentops のオフライン記憶整理 (consolidation) 機能。会話 transcript は読まず、 既存の memory entry を「精緻化のみ」する。新しい記憶が獲得されたセッションでだけ Stop hook から自動発火する (fingerprint trigger gate)。手動実行は /dream。 Trigger: dreaming, memory consolidation, 記憶整理, refine memory, dream, memory dedup, /dream
AI 生成(vibecoding)成果物に潜む「それっぽい虚偽」を、固定された検査カタログ(検査ID・手順・ 合格基準つき)で系統的に検出する監査規格。主張面を列挙し、各主張面に対応する検査を 機械的に適用し、カバレッジマトリクスに全セルの実施状態を記録する。 内部整合(テスト全パス・schema valid・CI green)は証拠として認めない。 Trigger: 虚偽検出, ハリボテ検出, vibecoding 監査, 本物か確認, それっぽい嘘, fabrication audit, AI生成コード 検証, 捏造チェック.
基于 SOC 职业分类
正在显示 SKILL.md
| name | ttfv-audit |
| description | dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル. |
| user-invocable | false |
dev tool の採用率の上限は TTFV が指数的に支配する。新規ユーザーの行動は確率過程で、各ステップで一定割合が脱落する。5 ステップで各 70% 残存なら最後まで来るのは 0.7^5 ≈ 17%。ステップを1個消すと残存が約 1.4 倍になる。機能を1個足すより効く。
罠: deep なツールほど default で TTFV が悪化する。深さ＝設定可能性＝初回の意思決定コスト。だから「作者が自分の深さと戦って初回体験を彫れているか」を見る。
README と実コードから、見知らぬ人の経路を機械的に並べる: 発見 → install → 最初のコマンド → 最初の結果。各 step を1行で書き、本物の価値(意味のある結果)に届くまでのコマンド数を数える。
gh-verify を監査 | 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 を晒さず試せる。価値が即わかる。
日常利用での最短コマンドを決めるのは、ツールが省略可能な引数をどこまで推測するか。明示 > 環境 > 文脈、の ladder の最下段が「ふつうの使い方」に据えられているかを確認する。
gh-verify の repo 解決 `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 の底が日常利用に据えられている → 強い。**脱落が起きるのは成功パスでなく失敗パス。新規ユーザーほど想定外の文脈にいる。全 error が [現象] + [次に打つ手] + (実例) の型かを確認する。
ユーザーの世界に既にあるもの(install: npx / 文脈: git remote / 既存ツール: pipe)へ接続し、自作範囲を減らしているか。
parsentry `npx skills add HikaruEgashira/parsentry` → install を消す。 `parsentry scan owner/repo | claude -p` → 分析エンジンを既存 claude から借りる。証明すべき価値を「良い prompt 生成」に絞れている → 強い。| スコア | 状態 |
|---|---|
| 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 が悪化する罠 |