product-lens

product-lens の概要

product-lens は、機能開発が実装段階に入る前に一歩立ち止まって判断するための意思決定支援スキルです。product-lens skill を使うと、why を検証し、プロダクトアイデアを精査し、曖昧な依頼を、エンジニアリングの計画に入る前のより鋭いプロダクトブリーフへと落とし込めます。

product-lens は、完全な仕様書が必要なときではなく、プロダクト診断が必要なときに使います。創業者、PM、ビルダーに向いており、アイデアを追う価値があるのか、本当に解決している問題は何か、最小限で信頼できる形はどこかを見極めるのに役立ちます。

product-lens が最も向いている用途

product-lens for Decision Support の主な役割は、チームが実行に一直線で進む前に見落としがちな問い――誰のためのものか、どんな痛みがあるのか、なぜ今なのか、成功をどう測るのか――をきちんと掘り下げることです。特に、機能の確定前、週次のプロダクトレビュー中、あるいはアイデアが魅力的でも未検証なときに有効です。

通常のプロンプトと何が違うか

一般的なプロンプトでも機能のアイデア出しはできます。対して product-lens はより狭く、診断的な対話を促し、リスク、進める／見送る判断、次の一手を含む PRODUCT-BRIEF.md を生成します。そのため、一度きりの助言ではなく、繰り返し使えるレビューの流れが必要な場面でより役立ちます。

product-lens が適さないケース

すでに耐久性のある PRD から SRS への成果物や、capability contract が必要なら、このスキルは意図的に product-capability へ引き継ぎます。まず product-lens でアイデアを検証し、提供内容の細部を確定する用途には使わないでください。

product-lens skill の使い方

product-lens をインストールする

スキルファイルに記載されたリポジトリのインストールコマンドを使います: npx skills add affaan-m/everything-claude-code --skill product-lens。これが product-lens install の手順です。インストール後は、単体アプリではなくワークフロー用スキルとして扱ってください。

実際のプロダクト課題を入力する

product-lens usage で最も効果が高いのは、具体的な意思決定から始めることです。ざっくりした目標、その対象ユーザー、今の挙動や代替手段、そして迷っている判断を渡してください。たとえば、「初回出品者のオンボーディング離脱を減らしたいが、原因が価格設定なのか、セットアップの複雑さなのか、信頼不足なのかわからない」といった入力は、「オンボーディングを改善したい」だけよりはるかに良いです。

先に読むべきファイル

まず SKILL.md でワークフローを理解し、次に README.md、AGENTS.md、metadata.json、さらに存在するなら rules/、resources/、references/、scripts/ フォルダを確認してください。このリポジトリでは主な情報源はスキルファイルそのものなので、最速の product-lens guide は、実案件に当てる前に診断用の質問と2つのモードを読むことです。

スキルをプロダクトブリーフ生成エンジンとして使う

実務の流れはこうです。機会を説明し、スキルに仮説を問いたださせ、足りない事実を拾い、生成された PRODUCT-BRIEF.md を見て進める／見送るを判断します。出力がまだ抽象的に感じるなら、対象を1つのユーザーセグメントと1つのつらい業務フローに絞り、条件を明確にしてからもう一度実行してください。

product-lens skill のFAQ

product-lens は初心者に向いていますか？

はい。作る前に考えを整理したいなら向いています。使い始めるのは簡単ですが、具体的な問題、対象ユーザー、そして今の業務フローの基本的な理解を入力できると、より力を発揮します。

product-lens は一般的な AI プロンプトとどう違いますか？

一般的なプロンプトは、広めのプロダクト助言を返すことがあります。product-lens は、意思決定の質に耐える入力と出力を強制するよう設計されており、痛み、タイミング、やらないこと、成功指標を尋ねます。そのため、気軽なブレストよりも、プロダクトレビューや product-lens for Decision Support に向いています。

いつ使わないほうがよいですか？

チームにすでに検証済みのブリーフがあり、必要なのが提供物、実装の詳細、API レベルの契約である場合には使わないでください。その場合は、リポジトリ内でも product-capability へ引き継ぐよう案内されています。

product-lens を最も活かせる入力は何ですか？

最も強い入力には、名前のあるユーザー、具体的な痛み、現状の行動、なぜ今のタイミングが重要なのか、成功と見なす基準が含まれます。下したい判断を説明できれば、スキルはたいてい十分に精査できます。

product-lens skill を改善する方法

制約をもっと鋭くする

最も大きな品質向上は、スコープを絞ることから生まれます。「継続率を改善する」ではなく、「無料プランを使う個人クリエイターの1週目離脱を減らす」といった具合に絞ってください。制約があるほど、product-lens は適切なトレードオフを表に出し、ありがちな一般論を避けやすくなります。

アイデアだけでなく根拠も渡す

あれば、ユーザーの声、サポートチケット、ファネルの離脱、営業での反論、ローンチ後のフィードバックも入れてください。product-lens は抽象的な勘よりも、実際のシグナルを評価できるときに最も強く働き、そのぶん提案の質も上がります。

ブレストではなく判断を求める

このスキルが最も強いのは、進める／見送るの判断、リスクレビュー、より鋭い MVP 仮説がほしいときです。機能案だけを求めるなら価値は下がりますが、「何を最初に検証すべきか、何を作らないべきか」を聞けば、得られる価値は大きくなります。

1回目の結果をもとに反復する

最初の product-lens usage の結果を使ってブリーフを磨き、そこで見えてきた不足情報を補って再実行してください。最良の成果は、1回で完璧なプロンプトを作ることではなく、短い診断ループを1回回すことから生まれることが多いです。