ce-prototype

プロトタイプ

後の作業で前提として扱う方法を決める前に、その疑問に答えられる忠実度で使い捨てのプロトタイプを作成します。その後、決定事項を適用するか、引き継ぎます。

検証対象の要素を偽装しないでください。 モダリティ、忠実度、媒体は、すべてこのルールに従います。フローや状態モデルの動作に関する疑問は、実際に動かして確かめる必要があります。製品のように見えるだけの画面では答えになりません。レイアウトやマークの見え方に関する疑問は、実際の仕上がりで確認する必要があります。簡単なスケッチでは答えになりません。疑問に決着をつけるのはユーザー自身の認識であり、成果物に対するあなたの判断ではありません。

結果： ユーザーは、判断対象を偽装していないプロトタイプを見て、製品の動作や見た目を決定しました。 次の利用者： 既存の Markdown Product Contract、またはこのセッションを種として使う ce-brainstorm / ce-plan。 完了条件： 成果物を必要とする疑問にユーザーが決着をつけた、またはユーザーがその判断を適用してブレインストーミングや計画に進みました。あなたが推測した方向性ではなく、ユーザーの選択が決着となります。 対象外： 簡単なスケッチで決着する判断、仕上げ、またはプロトタイプを最終製品としてリリースすること。

プロトタイプを体験する人がいない場合 — mode:pipeline、ヘッドレス実行、または人間が参加していないと報告する呼び出し元のスキル — は、そこで停止します。プレビューを開始したり、どう感じるかを作り上げたりしないでください。このスキルには人間が必要だと返答します。人間が参加している呼び出し元のスキル（たとえば、対話型の lfg 実行）は、通常どおり立ち会いありで実行します。

ユーザーが実行できる呼び出し形式の表示。 上記の拒否における立ち会い付きの再実行と、ユーザーが適用する場合の次のスキルの推奨には、呼び出し構文を表示します。既定では /ce-prototype、/ce-brainstorm、/ce-plan を使用します。ドル記号で始まるスキル呼び出しが文書化されている Codex またはホストでのみ、$ce-prototype、$ce-brainstorm、$ce-plan を使用します。インラインコードにするのは呼び出し部分だけにします。形式は1つだけ表示してください。

疑問の範囲を定める

ユーザーに何か尋ねたり、リポジトリに触れたりする前に、references/scoping.md を読んでください。この読み取りは必須です。このファイルでは、疑問がどのように提示されるか、また疑問が触れる範囲に限ってリポジトリを読む方法を定めています — ツリーをスキャンしないでください。また、範囲の狭い場合と広い場合、規模の見積もり、着手許可のメッセージ、各判断後に残る疑問がどう変わるかも定めています。許可を得るまで作成を始めないでください。特定の対象のプロトタイプ作成をすでに依頼されている場合は、範囲を定めた後、それが着手許可となります。

構築する

何かを書く前に、references/build.md と references/preview.md を読んでください。分離されたウェブプレビューが起動したら、references/annotation-loop.md を読み込んでください。オーバーレイでの実行とウェブ以外での実行は、チャット上で続けてください。

それらが進んだ後は、新たにできることがある場合に限り、何が起きたかを示す短い一文だけで伝えてください。画面が表示された、ヘルパーの URL が利用可能になった、または相手にしか解消できないブロッカーがある、といった内容です。アノテーションループでは、修正を適用した後に伝える一文と、待機中は何も伝えないことが定められています。

判断が確定するのは、レンダリング結果を見て判断する場合です。たとえば、レイアウトの読みやすさ、配色の効果、画面の密度などです。ユーザーが操作する際に何が起こるかを見て判断する場合、つまりフロー、状態モデル、コントロールの応答などは、操作して判断します。見ることで答える質問には、references/craft-floor.md を読み込んでください。ここには品質の最低基準とアプローチの違いに関するルールが定められています。どちらもこの文書には記載されていません。操作して答える質問では、これを読み込まず、これによって仕上がりが向上することもありません。

デフォルトの基盤はウェブです。製品が何で書かれているかは問いません。ネイティブアプリのナビゲーションの感覚は、SwiftUI ではなくウェブで近似してください。成果物と生成物については、references/build.md に定められています。

後続の実装でもプロトタイプが残るように、.context/compound-engineering/ce-prototype/<date>-<slug>/ の下に構築してください。使えない場合は、/tmp/compound-engineering-<uid>/ce-prototype/<date>-<slug>/ にフォールバックしてください。存続はベストエフォートです。フォールバック用のルートが必要になるすべてのケースは、references/build.md に記載されています。

.context のパスは、先に gitignore に追加する必要があります。リポジトリのルートから git -C <repo root> check-ignore -q .context/compound-engineering/ を実行して確認してください。末尾のスラッシュは必須です。対象外の場合は、ルートを決める前にその行の追加を提案してください。そうしないと、追加に同意しても今回の実行には役立ちません。

追加の提案と、その後の解決方法については、references/preview.md に定められています。実行ディレクトリを自分で作成しないでください。二重に確保すると、画面がカプセルから分離されます。

ユーザーに求められた場合、または既存ページの密度やクロームに関する質問の場合は、既存アプリ内で使い捨てのオーバーレイとして拡張してください。分離されたページでは、その内容が隠れてしまいます。これは製品ツリーに触れる唯一の経路です。決してコミットしないでください。試行が終わったら、自分が変更したファイルだけを元に戻してください。きれいに元に戻せない場合は、汚れたツリーを引き渡すのではなく、変更したまま残したファイルを明示してください。保存されたプロトタイプは決して削除しないでください。「使い捨て」とはコードのことであり、削除する依頼ではありません。

決定を残す

次のスキルでこのセッションが不要になるよう、この実行のディレクトリにある decisions.md に実行カプセルを残してください。カプセルに含める内容は、references/build.md に記載されています。プロトタイプを参照し、内容を再現しないでください。後続の計画に影響するものだけを含めてください。decisions.md を計画として扱わないでください。適用時にプロダクト契約または要約が作成され、カプセルは引き継ぎだけを担います。

選択が確定したと確信できたら、カプセルを更新してください。ユーザーが成果物を評価して選択し、追加の調整も含めた場合がこれに当たります。確信が持てない場合は、書き込まないでください。書き込むたびに確認のため作業を止める必要はありません。選ばれた案と調整内容はプロトタイプに残してください。

次の関連する質問に取り組む前に decisions.md を読み、引き続き構築する価値がある質問を見極めてください。そのリストの変更方法は references/scoping.md に定められています。決定によって、聞いた質問への回答ではなく、構築したいもの自体が変わった場合は、学んだ内容を引き継いで止めてください。すでに過去のものとなった質問に向けて構築してはいけません。それ以外の場合は、このスキルを続けてください。関連する質問にまだ成果物が必要であれば、ブレインストーミングや計画に戻らないでください。無関係な取り組みを始めず、適用後にプロトタイピングを続けないでください。

適用または続行

ユーザーが適用する場合：

• この実行に直接関連するブレインストーミングまたは計画がある場合（呼び出し時に渡されたもの、呼び出し元のスキルから渡されたもの、またはこのプロトタイプ用のファイルとしてこのセッション内で指定されたもの）は、references/write-back.md を読み込み、その指示に従ってください。Markdown と HTML の両方が対象です。decisions.md がある場合は使用してください。リポジトリに存在するという理由だけで計画を選ばないでください。
• そのようなファイルがない場合、または関連性が不明確な場合は、計画や3つ目のメモを作成しないでください。decisions.md がある場合は、そこから決定事項を引き継いで要点をまとめ、今回の実行でプロトタイプのパスが残された場合はそのパスも記載してください。オーバーレイ実行にはパスがないため、元に戻したものを示すのではなく、その旨を伝えてください。その要約は完全な成果であり、劣った成果ではありません。

その後、続行してください。呼び出し元のスキルから呼び出された場合は、decisions.md の選択肢を返し、そのスキルに続行させてください。それ以外の場合は、次のスキルを推奨し、このセッションを種として渡してください。書き戻しの後は、変更された要件に基づいて実装計画を再生成するため、ce-plan を推奨してください。ファイルを作成しない実行の後は、プロダクトレベルの疑問が残っている場合は ce-brainstorm を、セッションの内容だけで計画を立てられる場合は ce-plan を推奨してください。上記のレンダリングルールに従って、その推奨を出力してください。