Menú
捨てられる前提の小さな prototype で、実装前の不確実性を短時間で潰す。 技術選定、UI/UX、業務ロジック、外部 API 接続などを本実装前に試したいとき。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。 接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずに サーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。
調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。 実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。
こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。
Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ 分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。
新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。
| name | prototype |
| description | 捨てられる前提の小さな prototype で、実装前の不確実性を短時間で潰す。 技術選定、UI/UX、業務ロジック、外部 API 接続などを本実装前に試したいとき。 |
この skill は、Matt Pocock さんの prototype を出発点に、GitHub Copilot CLI、日本語での対話、Happy AI Life の「外科的対応」「基礎と型」「ニュートラル」へ合わせて再設計したものです。
本実装を早めるために、捨てる前提の試作で未知を潰します。prototype は成果物ではなく、判断材料です。
design-and-plan の判断材料や implement の実装契約に、実測の根拠を足したいとき| 状況 | 次にやること |
|---|---|
| 用語や要求が曖昧 | 先に interview-with-docs で前提を揃える |
| 構造判断や技術選定の不確実性が高い | prototype で小さく検証し、結果を design-and-plan に渡す |
| 実装契約が十分に固まっている | prototype ではなく implement に進む |
| prototype が本実装に流用されそう | 境界を明示し、必要なら最初から TDD の production slice に切り替える |
prototype の問いを 1 文で固定します。複数の問いを同時に試すと、成功・失敗の理由が曖昧になります。
Prototype Question:
- Can X API return enough data within Y constraint?
- Can this UI state transition be understood without extra explanation?
次を先に決めます。
prototype/ など）原則として、prototype code は production code へそのまま混ぜません。採用するのは知見、テスト観点、設計判断です。
目的に応じて、prototype の型を 1 つ選びます。
| 型 | 確かめること | 注意 |
|---|---|---|
| Logic prototype | 業務ルール、境界値、アルゴリズム | production 品質の抽象化を始めない |
| UI prototype | 画面導線、状態遷移、文言、操作感 | 見た目の完成度より理解可能性を優先 |
| Boundary prototype | 外部 API、ファイル、認証、CLI、性能 | system boundary の観測結果を残す |
Happy AI Life では、prototype でも vertical slice を優先します。1 つのユーザー行動または 1 つの受け入れ条件を、入口から出口まで細く通します。
最後に、prototype の結果を実装契約へ渡せる形にまとめます。
## Prototype Result
- 問い:
- 試した型: Logic / UI / Boundary
- 観測結果:
- 採用する知見:
- 捨てるコード:
- 残った不確実性:
- 推奨される次工程:
references/origin.md — 出典、適用範囲、MIT license noticeinterview-with-docs — prototype 前に用語・前提を揃えるdesign-and-plan — prototype の観測結果を設計判断へ反映するimplement — 実装契約が固まった後、TDD で production slice を進めるimplement で production code として作り直す。