prototype について
prototype は、具体的なプロダクトや技術上の疑問に答える使い捨てデモを作るコーディングスキルです。単一 HTML ファイルでのロジック検証と、同じルートで切り替える UI 案の比較に分かれています。
主な機能
- 01ロジックまたは UI の試作経路を選択
- 02単一 HTML ファイルでロジックデモを作成
- 03切り替え可能な UI 案を生成
- 04既定で試作状態をメモリ内に保持
- 05検証済みの判断を実装作業に反映
活用シーン
- 01操作可能な手順で状態モデルを検証
- 02ページのビジュアル案を比較
- 03実装前にデザイン上の疑問を解決
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ c0nant/ c-skills --skill prototypeインストール後、Claude Code で/prototypeを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LOGIC.mdLOGIC.pt-BR.mdRESUMO.mdTRADUCAO.pt-BR.mdUI.mdUI.pt-BR.mdagents/openai.yaml詳細
プロトタイプ
プロトタイプとは、問いに答えるための使い捨てコードです。形は問いによって決まります。
分岐を選ぶ
ユーザーのプロンプトや周辺のコードを手がかりに、またはユーザーが応答できるなら尋ねて、どの問いに答えるのかを特定します。
- 「このロジック/状態モデルは適切でしょうか?」 → LOGIC.md。単一の共有可能な HTML ファイルを作成します(自由に操作できるボタンと、タブ付きのガイド付きウォークスルーを用意)。紙上では推論しにくいケースで状態マシンを動かし、開発者でなくても操作できるようにします。
- 「見た目はどうあるべきでしょうか?」 → UI.md。1 つのルートで大きく異なる UI バリエーションを複数生成し、URL の検索パラメーターと画面下部に固定されたバーで切り替えられるようにします。
2 つの分岐では成果物が大きく異なるため、選択を誤るとプロトタイプ全体が無駄になります。問いが本当に曖昧で、ユーザーに確認できない場合は、周辺のコードにより合う分岐を選びます(バックエンドモジュールならロジック、ページやコンポーネントなら UI)。そして、プロトタイプの先頭にその前提を明記します。
両方に適用されるルール
- 初日から使い捨てとして扱い、それと明確にわかるようにします。 実際に使われる場所の近く(プロトタイプ対象のモジュールやページの隣)にコードを配置し、何のためのものかが明らかになるようにします。ただし、ひと目でプロトタイプだとわかる名前を付けます。使い捨ての UI ルートでは、プロジェクトですでに採用されているルーティング規約に従い、新たなトップレベル構造を作らないでください。
- すぐに実行できるようにします。 UI プロトタイプは、プロジェクトのタスクランナーから 1 つのコマンドで起動します。例:
pnpm <name>、python <path>、bun <path>など。ロジックのデモは、ユーザーがダブルクリックする単一の HTML ファイルにします。どちらの場合も、起動時に考えることは不要です。 - デフォルトでは永続化しません。 状態はメモリ内に保持します。プロトタイプが検証する対象が永続化であっても、それに依存させてはいけません。問いにデータベースが明示的に含まれている場合は、一時的な DB または「PROTOTYPE, wipe me」という名前が明確なローカルファイルを使います。
- 仕上げに時間をかけません。 テストも、プロトタイプを実行可能にするために必要な範囲を超えるエラー処理も、抽象化も不要です。目的は、すばやく学びを得ることです。
- 状態を見えるようにします。 ロジックでは各アクションの後に、UI ではバリエーションを切り替えるたびに、関連する状態全体を出力または表示し、何が変わったかをユーザーが確認できるようにします。
- 完了したら記録します。 検証された決定を実際のコードに反映したうえで、プロトタイプ自体を一次資料として記録します。使い捨てブランチにコミットし、main から切り離して、実装イシューにそのブランチへの参照を残します。結論(判断結果と、決着した問い)もイシューまたはコミットに記録します。main ブランチには検証済みの決定だけを残します。
コメント
Markdown 対応