菜单
deep OSS の scope 戦略を監査する方法論。鋭い単一用途の楔(wedge)が再利用可能な深い engine を front する構造か(libghostty パターン)を採点する。楔の鋭さ・深さの隠し場所・寄生先・10x の一点を見る。 wedge-scoper agent が使用。 Trigger: scope 監査, wedge 監査, wedge over engine, libghostty パターン, engine shell 分離, scope creep.
用 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 疲労.
dev tool / OSS の Time-to-First-Value(見知らぬ人が install してから本物の価値に触れるまでの秒数)を 監査する方法論。初回ファネルを step 単位で復元し、引数ゼロで動くか・失敗パスが次の手を示すか・ 価値を借りているかを採点する。ttfv-auditor agent が使用。 Trigger: TTFV 監査, 初回体験 監査, time to first value, onboarding friction, first-run, 採用ファネル.
| name | wedge-audit |
| description | deep OSS の scope 戦略を監査する方法論。鋭い単一用途の楔(wedge)が再利用可能な深い engine を front する構造か(libghostty パターン)を採点する。楔の鋭さ・深さの隠し場所・寄生先・10x の一点を見る。 wedge-scoper agent が使用。 Trigger: scope 監査, wedge 監査, wedge over engine, libghostty パターン, engine shell 分離, scope creep. |
| user-invocable | false |
「deep」と「adoptable」は scope を分離すれば喧嘩をやめる。深さは再利用可能な engine に隠し、ユーザーが触れる面は鋭い単一用途の楔にする。「薄いシェル over 深いライブラリ」は本質的にディストリビューション判断。楔の鋭さが「価値が自分ごとになる確率」を決める。
罠: 深い builder ほど「全部入り」を作りたがる。手を広げて全機能が 2x の凡庸より、1 ユースケースが 10x の鋭い楔の方が deep OSS は刺さる。
ユーザーに見せる面が単一の鋭いユースケースか、「何でもできる」曖昧な面か。曖昧さは「これは自分の問題のためのツールだ」という認識を妨げる。
gh-verify を監査 楔: 「GitHub の PR/release/repo の SDLC 健全性を gh CLI 1コマンドで検査」。 単一プラットフォーム(GitHub)・単一の入口(gh extension)・明確な1動詞(verify)。 曖昧な「何でも監査」ではなく鋭い → 強い。深い実装が再利用可能な engine/core に分離され、薄い platform shell が consume する構造か。深さを楔の表面に漏らしていないか。
gh-verify + libverify libverify = platform 非依存 engine、34 controls、Creusot で形式証明(README: "libghostty for SDLC")。深さの貯蔵庫。 gh-verify = 薄い GitHub shell、engine を consume するだけ。 深さは engine に隔離、楔は薄い → 教科書的に強い。別 platform shell を後から足せる拡張性も得る。楔が既存ワークフロー(gh CLI / npx / パイプ / editor / CI)に寄生して採用摩擦を下げているか。ゼロから新習慣を要求していないか。
gh-verify / parsentry gh-verify: `gh` 拡張として寄生 → gh ユーザーは新ツール習得不要。`action.yml` で GitHub Actions にも寄生。 parsentry: `| claude -p` でエージェント CLI に寄生、`npx skills add` で skill エコシステムに寄生。 既存習慣に乗っている → 強い。楔は「最初の鋭い1ユースケースを 10x better」にしてから広げる戦略か。最初から手を広げて全部 2x の凡庸に陥っていないか。
| スコア | 状態 |
|---|---|
| 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 に密結合 | 再利用で面を広げられない |