메뉴
dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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生成コード 検証, 捏造チェック.
Builds a harness: a meta-skill that defines specialist agents and generates the skills they use. Trigger when the user (1) asks to 'build/set up/construct a harness', (2) asks for 'harness design' or 'harness engineering', (3) wants a harness-based automation system for a new domain/project, (4) wants to restructure or extend an existing harness, or (5) asks to inspect, audit, sync, or maintain an existing harness (agents/skills drift, status check).
dev tool / OSS が「刺さるか(PMF)」をエンジニアリング観点で監査するオーケストレーター。 3 specialist agent (ttfv-auditor / trust-calibrator / wedge-scoper) をチームで起動し、 初回体験(TTFV)・出力の信頼(false-positive economics)・scope の鋭さ(wedge over engine)を 並行監査して、合成 PMF readiness スコアと優先度付き改善提案を1つのレポートに統合する。 Trigger: PMF 監査, PMF audit, dev tool 採用, なぜ自分のOSSが採用されない, ローンチ前監査, TTFV, time to first value, false positive, 誤検知, 信頼設計, wedge, scope 設計, this tool isn't getting adopted, audit my OSS before launch, 再監査, re-audit, 改善後の再評価. CLI/library/dev tool/security tool の repo を渡された採用観点の監査依頼で発火する。 単なるコードレビューやバグ探し、一般的な品質監査では発火しない(それらは別 skill)。
security / correctness tool(linter, scanner, verifier)の出力が信頼を獲得・維持できる設計かを 監査する方法論。false-positive economics、Indeterminate verdict、audit-first rollout、 suppression の使い勝手、FP feedback loop を採点する。trust-calibrator agent が使用。 Trigger: 信頼設計 監査, false positive 監査, FP economics, verdict 設計, audit-first, suppression, linter 疲労.
deep OSS の scope 戦略を監査する方法論。鋭い単一用途の楔(wedge)が再利用可能な深い engine を front する構造か(libghostty パターン)を採点する。楔の鋭さ・深さの隠し場所・寄生先・10x の一点を見る。 wedge-scoper agent が使用。 Trigger: scope 監査, wedge 監査, wedge over engine, libghostty パターン, engine shell 分離, scope creep.
| 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 が悪化する罠 |