デザインプロセス
ユーザーが方向性とテイストを決定します。モデルは実行を評価します。タスクが実行可能か、数値が正しいか、何かが壊れたり、隠れたり、誤解を招いたりしていないかを確認します。スコア、評議会、モデルの合意が方向性の選択、方向性の統合、または記録された決定の上書きを行うことは決してありません。
プロジェクトに独自のデザインスキルがある場合は、それに従ってください。必要に応じて、ここに戻ってフェーズを実行するよう指示される場合があります。
プロジェクトのファイル
docs/design/ 内にあります。ただし、プロジェクトの AGENTS.md で別の場所が指定されている場合は除きます。
product-brief.md: プロダクトの真実。誰が使うか、各画面がユーザーに何をさせなければならないか（主要な質問とモード：操作、読む、または説得）、データと状態、コピー、信頼の境界。プロジェクトに既にPRODUCT.mdがある場合、ブリーフはそれを繰り返す代わりにリンクします。DESIGN.md: ユーザーの決定、例外、承認済みの参照画面、および反応ログ。記録された決定はあなたの好みよりも優先されます。記録がない場合、ルックは未決定です。現在のUIは証拠であり、決定ではありません。harness.md: 画面とプロトタイプを実行しキャプチャする方法：コマンド、シナリオ、ビューポート、競合アプリ、キャプチャの保存先。runs/<YYYY-MM-DD-name>/run.md: 1回のランの質問、修正済みおよび未解決の事項、既知の制限、評議会メンバーとターゲット、スタンスキー、結果。
これら4つのテンプレートは templates/ にあります。最初の3つのファイルのいずれかが欠けている場合は、まずブートストラップを行ってください。ブートストラップをスキップするランも含め、すべてのランは独自の run.md を開始します。キャプチャ、マニフェスト、調査台帳、バリアントシートは harness.md で指定されたgitignoredフォルダに保存されます。評議会パックはリポジトリ外、セッションのスクラッチパッドまたは一時フォルダに保存します。
プロジェクト独自のルールがこのスキルよりも優先されます。依存関係、開発サーバー、コミット対象に関するプロジェクトの AGENTS.md に従ってください。ランに、それらのルールが禁止または議論のために予約している何かが必要な場合は、実行する前にユーザーに確認してください。
フロー
- 新しいUI: ブートストラップ → 探索 → ユーザーが選択 → 洗練 → 評議会 → リファレンスを承認 → ホールドアウト → プロジェクトのロールアウトパスを通じて出荷。
- 既存のUI: ブートストラップ → 評議会 → 承認 → 出荷。ユーザーが最初に目に見える変更を望む場合は、評議会の前に洗練を行います。
リクエストが指定するフェーズから開始します。狭い調整は洗練フェーズから開始します。
| フェーズ | 最初に読むもの |
|---|---|
| ブートストラップ | references/bootstrap.md、次にランに必要な各機能について references/harness-contract.md |
| 探索 | references/explore.md |
| 洗練 | references/refine.md、そして最初のUI編集の前に references/craft.md |
| 評議会 | references/council.md |
| 別のデザインスキルの使用 | references/integrations.md（呼び出す前に） |
評議会メンバー。 ランが評議会に到達する場合、ユーザーが既にメンバーを指名していない限り、開始時に誰がメンバーかを（各メンバーのモデルと推論努力を含めて）ユーザーに尋ねてください。異なるプロバイダのメンバーを提案してください。メンバーを run.md に記録し、ラン全体でそれらのメンバーを正確に使用してください。メンバーが利用できない場合は、その旨を伝えてください。決して代役を立てないでください。
リファレンスを承認。 ユーザーの言葉だけが画面を承認します。スコアが代わりになることは決してありません。そのキャプチャを docs/design/references/ にコピーし、DESIGN.md の「参照画面」の下にリストし、それぞれが何のリファレンスであるかを示します。
ホールドアウト。 最初の承認済みリファレンスの後、新しいエージェントが、このスキル、プロジェクトのファイル、およびハーネスのみから、まだデザインされていないサーフェスをデザインし、推測しなければならなかったすべてのポイントをリストします。結果をユーザーに表示します。推測ごとに、それに答えるべきであったファイルを修正するか、run.md に未解決として記録します。ユーザーが反応し、すべての推測が修正または記録された時点で完了です。
反応を記録する
ユーザーがデザインに反応するたびに、どのフェーズでも、以下の手順を実行します。
- 反応ごとに、
DESIGN.mdの反応ログに1行追加します。日付（UTC）、サーフェスとビューポート、どのデザインとキャプチャランか、ユーザーの言葉を正確に引用、タイプ、スコープ、ステータスobserved。- タイプ:
like（そのまま維持）、dislike（変更）、またはdefect（タスクの失敗または何かの破損。調査台帳にも追加します）。1つの反応で一部をlikeし、別の部分をdislikeすることもできます。各部分に名前を付けてください。まだ構築されていない機能は反応ではありません。run.mdの既知の制限の下にリストしてください。 - スコープ はユーザーが表明した内容です。この要素、このサーフェスタイプ、またはサイト全体。何も表明されていない場合は、要素とします。決して自分で範囲を広げないでください。
- それに応じて変更した内容は、行ではなく調査台帳に記録します。
- タイプ:
- ユーザーが一般的に述べた場合、その行を決定に昇格させます。同じ反応が2番目のサーフェスで再発した場合、それが一般的に適用されるかどうかを尋ね、はいの場合のみ昇格させます。行に
promotedのマークを付け、リンクを追加します。 - 反応が決定と矛盾する場合、どちらが優先されるかを尋ね、古い決定を編集または削除し、負けた行に
supersededのマークを付けます。
すべての反応に行が追加され、すべての昇格がユーザーの一般的な声明または「はい」を引用するまで完了です。
プライバシー
キャプチャには、フィクスチャデータ、シードデータ、またはデモアカウントを使用し、ユーザー自身のアカウントや実際の人物の記録は決して使用しません。個人データやアダルトコンテンツが表示されるものは、評議会パック、リファレンスキャプチャ、またはコミットに含めてはいけません。