prototype

プロトタイプ skill の概要

prototype skill で何ができるか

prototype skill は、本番実装に進む前に「ひとつの具体的な疑問」に答えるための使い捨てコードを素早く作るのに役立ちます。単なる短いプロンプトでは足りず、状態遷移、データの形、UI の方向性を、実行できて簡単に捨てられる形で確かめたいときに向いています。

どんな人が install すべきか

「prototype して」「いくつか案を見せて」「どの形が正しいかわからない」とよく言うなら、この prototype skill を install してください。特に、既存 repo で作業していて、空のサンドボックスから始めるのではなく、ローカルの作法に合わせた prototype が必要な agent に向いています。

何が違うのか

この prototype skill は、一般的なブレスト用プロンプトを目指していません。最初の段階で分岐をはっきり決めさせるのが特徴です。つまり、ロジック優先の terminal prototype か、複数の visual variant を持つ UI prototype かのどちらかを選ばせます。この判断が価値の中心で、間違った種類の prototype を作る無駄を防げます。

向いているケースと向かないケース

prototype は、デザイン探索、業務ルールの境界条件、状態マシンの不確実性、「これってどう見えるべき？」という作業に使ってください。すでに最終実装の形がわかっている場合や、実行可能な prototype ではなく文章による説明だけが欲しい場合は、使わないほうがよいです。

prototype skill の使い方

install して source を見つける

prototype skill は npx skills add mattpocock/skills --skill prototype で install します。そのあと、まず SKILL.md を読み、質問に応じて LOGIC.md か UI.md を確認してください。さらに文脈が必要なら、repo 内の README.md、AGENTS.md、metadata.json、および近くにある rules/、resources/、references/ フォルダも確認するとよいです。

正しい branch を選ぶ

prototype の核となる判断はシンプルです。ロジックの質問なら LOGIC.md、見た目の質問なら UI.md です。プロンプトが曖昧なら、周囲のコードから推測してください。バックエンド寄り、あるいはモデル中心のコードなら通常はロジック、ページや component なら UI に寄ります。ユーザーに確認できるなら、作業前にひとつだけ確認質問をしてください。

ラフなアイデアを使えるプロンプトに変える

良い prototype guide プロンプトは、質問、対象 surface、制約を明示します。たとえば「この subscription state machine が cancellation、grace period、resume flow を正しく扱えるか prototype して」は、「billing を prototype して」よりずっと良いです。UI 作業なら、どの screen に属するのか、どの既存 data を本物のまま使うのか、何案ほしいのかも伝えてください。質問が具体的であるほど、skill が違う成果物を作ってしまう確率は下がります。

まず読むべき files

まず SKILL.md を読んで、branch のルールと共通の制約を把握してください。次に、ちいさな interactive state explorer が必要なら LOGIC.md、1 つの route 上で複数 layout が必要なら UI.md を読みます。これらの file は、考え方だけでなく実際の workflow を示しているため、install 判断に最短でたどり着けます。

prototype skill の FAQ

prototype は frontend 作業だけのものですか？

いいえ。prototype skill は意図的に分かれています。ひとつは UI exploration 用、もうひとつは business logic や state modeling 用です。「これをどう見せるべきか」を試したいなら UI branch、「この state change は妥当か」を試したいなら logic branch を使ってください。

普通の prompt とどう違うのですか？

通常の prompt でも mockup は頼めますが、prototype skill は迷いを減らす workflow を追加します。branch を選び、使い捨て前提を保ち、実際に確認できる成果物へ出力を寄せます。設計を誤ったときのコストが高い場面では、こちらのほうが有効です。

prototype skill は初心者向けですか？

質問をはっきり説明できるなら、はい。いっぽうで、依頼が曖昧だと初心者向けとは言いにくくなります。というのも、この skill は正しい branch を選び、ホスト project の作法に合わせることに依存するからです。runtime や page の形がわからない場合は、そのぶん少し多めに文脈を伝える必要があります。

Prototypes に prototype を使わないほうがいいのはどんなときですか？

最終的な production 実装、広範な architecture redesign、あるいは copywriting や ideation だけが必要な依頼には使わないでください。prototype skill が最も強いのは、そのまま出荷する polished な feature ではなく、判断材料になる使い捨ての成果物が欲しいときです。

prototype skill を改善するには

結論ではなく、問いを伝える

prototype skill の出力を改善する最善策は、解消したい不確実性を説明することです。「より良い checkout を作って」ではなく、「coupon 入力、shipping 選択、payment error を、窮屈に感じさせずに 1 ページ checkout で扱えるか試したい」と伝えてください。そうすると、skill に本当の判断対象が渡ります。

実際に必要な文脈だけを与える

よりよい prototype guide の結果を得るには、ホスト route、関連する data shape、残すべき既存 component、framework、runtime、新規 dependency を追加しない制約などを含めてください。実際の環境を skill が再現できるほど、架空の前提を作り込むことなく prototype の品質が上がります。

よくある失敗パターンに注意する

最大の失敗は、早い段階で間違った branch を選んでしまうことです。prototype が「違うもの」を作ってしまうと、見た目がきれいでも役に立ちません。迷う場合は、最初に前提を明示させ、その前提に対してだけ狭く prototype を切らせてください。

ひとつだけ条件を厳しくして反復する

最初の結果を踏まえたら、prototype install の成果を一度にたくさん変えるのではなく、1 回につき 1 点だけ sharpen してください。たとえば、variant を減らす、より現実的な data にする、境界条件を厳しくする、対象 screen をより具体的にする、といった調整です。more options を求めるより、こちらのほうがたいてい効果的です。prototype skill は幅を最大化するためではなく、ひとつの問いに答えるために作られているからです。