菜单
構築前に「なぜ作るのか」を検証し、プロダクト診断を実行し、リクエストが実装契約になる前にプロダクト方針を圧力テストするためのスキルです。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
キャプチャ、診断、抑制されたリカバリ、内省レポートを用いた、AI エージェント障害向けの体系的なセルフデバッグワークフローです。
リポジトリ認識の並列レビューパスを使用してスキル、コマンド、ルール、フック、その他を DAILY と LIBRARY のバケットに分類することで、特定のリポジトリ向けにエビデンスに基づく ECC インストールプランを構築します。フルバンドルをロードするのではなく、プロジェクトが実際に必要とするものに ECC をトリミングすべき場合に使用します。
対象リポジトリの既存の統合パターンに正確に合わせて新しい API コネクタやプロバイダを構築します。第二のアーキテクチャを発明することなく、もう一つの統合を追加する場合に使用します。
Write articles, guides, blog posts, tutorials, newsletter issues, and other long-form content in a distinctive voice derived from supplied examples or brand guidance. Use when the user wants polished written content longer than a paragraph, especially when voice consistency, structure, and credibility matter.
ECC 向けのエビデンスファーストな自動化インベントリと重複監査のワークフローです。何かを修正する前に、どのジョブ、フック、コネクタ、MCP サーバー、またはラッパーがライブ、壊れている、冗長、または欠落しているかをユーザーが知りたい場合に使用します。
CodeTour の `.tour` ファイルを作成します。実際のファイルと行のアンカーを持つペルソナ対象のステップバイステップウォークスルーです。オンボーディングツアー、アーキテクチャウォークスルー、PR ツアー、RCA ツアー、および構造化された「これがどのように動作するか説明して」というリクエストに使用します。
| name | product-lens |
| description | 構築前に「なぜ作るのか」を検証し、プロダクト診断を実行し、リクエストが実装契約になる前にプロダクト方針を圧力テストするためのスキルです。 |
| origin | ECC |
このレーンが担当するのはプロダクトの診断であり、実装可能レベルの仕様作成ではありません。
ユーザーが PRD から SRS、あるいはケイパビリティ契約といった永続的なアーティファクトを必要とする場合は、product-capability に引き継いでください。
YC のオフィスアワーを自動化したようなものです。厳しい質問を投げかけます:
1. 誰のためのものか？（「開発者」ではなく、具体的な人物）
2. 何が痛いのか？（定量化: 頻度、深刻さ、現在の対処法は？）
3. なぜ今なのか？（何が変わって可能/必要になったのか？）
4. 10つ星バージョンは？（お金も時間も無制限なら）
5. MVP は？（仮説を証明する最小のもの）
6. アンチゴールは？（明示的に作らないものは何か？）
7. うまくいっている指標は？（感覚ではなく、メトリクス）
出力: 回答、リスク、Go/No-Go 推奨を含む PRODUCT-BRIEF.md。
結果が「Yes、作るべき」となった場合、次のレーンは product-capability であり、これ以上ファウンダー劇を続けるべきではありません。
現在のプロジェクトを創業者の視点でレビューします:
1. README、CLAUDE.md、package.json、最近のコミットを読む
2. 推測: これは何になろうとしているのか？
3. スコアリング: プロダクトマーケットフィットのシグナル（0-10）
- 利用成長の軌跡
- リテンション指標（リピートコントリビューター、リピートユーザー）
- 収益シグナル（価格ページ、課金コード、Stripe 連携）
- 競合に対する堀（真似しにくいものは何か？）
4. 特定: これを10倍にする一つのこと
5. フラグ: 作っても意味のないもの
実際のユーザー体験をマッピングします:
1. 新規ユーザーとしてプロダクトをクローン/インストール
2. すべての摩擦ポイントを記録（分かりにくい手順、エラー、ドキュメント不足）
3. 各ステップの時間を計測
4. 競合のオンボーディングと比較
5. スコアリング: Time-to-Value（ユーザーが最初の成功体験を得るまでの時間）
6. 推奨: オンボーディング改善トップ3
10個のアイデアから2つを選ぶ必要がある場合:
1. 候補機能をすべてリストアップ
2. 各機能をスコアリング: Impact (1-5) x Confidence (1-5) / Effort (1-5)
3. ICE スコアでランキング
4. 制約を適用: 資金余力、チーム規模、依存関係
5. 出力: 根拠付きの優先順位付きロードマップ
すべてのモードはエッセイではなく、アクショナブルなドキュメントを出力します。すべての推奨には具体的な次のステップが含まれます。
以下と組み合わせて使用できます:
/browser-qa でユーザージャーニー監査の結果を検証/design-system audit でビジュアルの仕上がりを評価/canary-watch でローンチ後のモニタリングproduct-capability