get-context

コンテキストの取得

プロダクトデザインの依頼で、プロダクト UI の方向性の設計、構築、プロトタイプ作成、複製、再設計、拡張、生成が求められた場合は、最初にこのスキルを実行してください。

質問モードを使って、次の点を確認してください。

• 何のプロダクト、サイト、機能、ワークフロー、コンポーネント、画面を設計、再設計、拡張するのか
• その機能、変更、アプリ、ウェブサイトでユーザーが何をできるようにするのか

回答済みの質問は再度尋ねないでください。両方が明確になったら、要件とデフォルト設定を簡潔にまとめて伝え、次のワークフローを示し、同じターン内で続行してください。この確認は承認を求めるものではありません。ユーザーはいつでもスタイル、範囲、インタラクティブ性を修正できます。

厳守事項：設計対象またはユーザーが達成したいことがまだ明確でない間は、UI の実装、プロトタイプのひな形作成、サーバーの起動、ファイルの作成を行わないでください。

重要な上書きルール

• 先に進む前に、プラグインルーターの $index を参照してください。
• $critical-overrides に従ってください。

ユーザーコンテキスト

作業を始める前に、$user-context を読み込み、ローカルシェルを利用できる場合は、そのプリフライトスクリプトを実行してください。

関連する場合は、保存済みのプロダクト URL、Figma ファイル、スクリーンショット、参考画像、コードベースのパス、Storybook、デザイントークン、デザインシステム、ブランドアセット、コンポーネントの参照資料、ブラウザー設定、共有先を、作業の参考資料として活用してください。

保存済みの参考資料をすべて調べる必要はありません。現在のタスクに必要なものだけを確認してください。

次のワークフローへの引き継ぎ

1. 次のワークフローがすでに明確な場合は、要件を伝える前にそのスキルを読んでください。まだ読んでいないスキルの名前を挙げるだけではいけません。

2. $ideate、$url-to-code、または $image-to-code を実行する前に、最小限の要件とデフォルト設定を簡潔にまとめ、ユーザーに伝えてください。

3. 対象とユーザーが達成したいことが明確なら、明示的な確認を待たず、同じターン内で次のワークフローに進んでください。ユーザーからフィードバックがあった場合は、それを反映して調整してください。

4. 複雑なアプリ、プロトタイプ、複製、再設計、構築に取りかかる前に、期待値を調整する短いメモを送り、そのまま続行してください。例：

This kind of build usually takes about 10-15 minutes, and ambitious ones can take longer. Good moment to grab coffee or tend to something else; I’ll keep moving and bring the prototype back when it is ready.

小規模な静的変更、簡単な監査、単純な調査、セットアップのみ、共有のみの依頼では、このメモを送らないでください。

完了とは、設計対象とユーザーが達成したいことが明確になり、デフォルト設定が伝えられ、次のスキルがすでに決まっている場合はそれを読んでいる状態です。