desainpakeai-prototype

DesainPakeAI プロトタイプ

グローバルにインストールされた dpai CLI を使用してください。DesainPakeAI MCP サーバーを初期化したり呼び出したりせず、ワークスペース操作のたびに npx を使用しないでください。

このスキルがすでに利用可能な場合、通常のタスクでは npx skills add、skills check、skills update を実行しないでください。スキルのインストールは初回セットアップ時のみ行い、確認や更新はユーザーが明示的にスキルの同期を依頼した場合に限ります。

継続中のタスクを開始する

セッション、対象プロジェクト、接続が変わらない限り、確認済みのセットアップを後続の編集でも再利用してください。

1. 最初に <prefix> --version を実行します。コマンドが利用できない場合は、 npm install --global desainpakeai-cli@latest を実行し、その後にもう一度バージョンを確認します。 通常のタスクのたびに再インストールや更新をしないでください。
2. 継続中のタスクでは、以降そのバイナリを使用します。
3. <prefix> auth status --pretty を一度実行します。認証されていない場合は、 ユーザーに <prefix> auth login --api-url <url> --api-key <dpai_key> の実行を依頼し、 その後、ログインを確認するために <prefix> auth status --pretty をもう一度実行します。
4. <prefix> project current --pretty を実行し、対象プロジェクトであることを確認します。
5. <prefix> context --pretty を実行し、最新のリビジョンを保持します。
6. ワークスペースのソースを初めて変更する前に、同じセッション、プロジェクト、ランタイムについてそのガイドをまだ保持していない場合に限り、 <prefix> guide get --topic workspace-authoring --raw を実行します。 後続のタスクでも再利用してください。そのコンテキストが失われた場合、または変更された場合にのみ再取得します。 タスクが読み取り専用のままであれば、この手順は省略します。

認証済み CLI コマンドの成功を接続の確認として扱います。API キーを作成またはコピーしただけでは、コーディングエージェントが接続されている証拠にはなりません。 MCP のハンドシェイクエンドポイントを初期化、呼び出し、または待機しないでください。

CLI の workspace-authoring ガイドは、単一 HTML の最小作成要件に関する正式な情報源です。このスキルはガイドを取得するタイミングを示すだけです。ここに競合する CSS、フォント、コンポーネント、JavaScript の要件をコピーしたり、推測したりしないでください。 ユーザーがファイルシステム上での作業を明示的に依頼した場合に限り、--workspace <path> を使用してください。成功した変更のたびに返されるリビジョンを引き継いでください。

ガイドのカタログと取得タイミング

workspace-authoring はソースを変更する前に一度取得する必要があり、同じセッション、プロジェクト、ランタイムの後続タスクでも保持されます。それ以外のガイドは、タスクに応じて任意に参照できます。対象となる最初の判断の直前に取得し、継続中のタスクでは再利用してください。新たに未解決のリスクが発生した場合にのみ、別のガイドを取得します。任意のガイドをすべて事前に取得しないでください。

• workspace-authoring - ワークスペースのソースを変更する前に必須です。
• design-quality - 視覚デザインに関する重要な判断。
• accessibility - キーボード、フォーカス、フォーム、ARIA、またはズーム。
• layout-responsive - レスポンシブレイアウト、オーバーフロー、RTL、または長いコンテンツ。
• typography - タイポグラフィ、折り返し、省略、または双方向テキスト。
• color-system - トークン、テーマ、ステータスカラー、またはコントラスト。
• product-writing - ラベル、エラー、空の状態、またはローカライズ。
• ui-polish-motion - サーフェス、アイコン、モーション、または視覚的な状態。
• prototype-interactions - モーダル、セレクト、フィルター、フォーム、または状態を持つ UI。
• evidence-and-reference - 外部ページ、スクリーンショット、または提供された参考資料。
• image-to-prototype - 提供された UI 画像またはスクリーンショットの再構築。
• interface-review - ユーザーがインターフェースレビューを依頼した場合のみ。
• component-stress-test - ユーザーがストレステストを依頼した場合のみ。
• variant-exploration - ユーザーがデザインのバリエーションを依頼した場合のみ。
• prototype-to-codebase - ユーザーがコードベースへの引き継ぎを依頼した場合のみ。

対象となる条件に合致する場合に限り、<prefix> guide get --topic <topic> --raw で任意のガイドを取得します。 本格的な視覚デザインの前には design-quality を取得します。ただし、視覚に関わらないメンテナンス、キャンバス上の位置調整、エクスポートのみの作業、マニフェストの確認、範囲を絞った修正では省略してください。ユーザーの依頼が条件となるガイドは、推測に基づいて取得しないでください。

運用上の不変条件

• UI のビジュアル作業を始める前に、<prefix> design context --pretty と <prefix> token list を実行します。利用可能な場合は、DESIGN.md のガイダンス、登録済みコンポーネント、実行時トークンを制約として扱います。これらがない場合、探索的な値はページ内にとどめます。
• 利用可能な登録済みコンポーネントがある場合は再利用します。コンポーネントを作成または登録するのは、ユーザーから明示的に依頼された場合、または再利用可能な形での抽出を求められた場合に限ります。それ以外の場合、実装はページ内にとどめます。
• 一度に作業するページは一つにします。ページ作成コマンドで作成されるのは、骨組みと Canvas フレームのみです。初回のファイル編集ではビジュアルまたはワークフローのグループを一つ追加し、ページの変更を並列で実行しないでください。
• 永続トークンの作成や変更は、ユーザーが方向性を選択した後、または保存を明示的に依頼した後にのみ行います。
• 安定した data-node-id、data-component、data-part、data-action、ブリッジ属性、パブリック props を保持します。ハードコードされた再利用可能な値よりも、既存のトークンを優先します。
• <iconify-icon icon="collection:name"> を直接使用し、ローダーやラッパーを追加しないでください。アイコンのみのコントロールには aria-label を付け、装飾用アイコンには aria-hidden="true" を設定します。
• ページの完成後、<prefix> preview verify --page <page-id> を実行し、該当する診断を修正して、必要に応じて再度検証します。次に、workspace-authoring で求められるレンダリング結果のチェックを実施し、その後 <prefix> work finish --page <page-id> を実行します。

ネイティブコマンドを優先する

インライン JSON を手書きしないでください。通常の作業ではネイティブのフラグを使用します。CLI が操作ペイロードを構築・検証し、最新のリビジョンを自動的に読み込みます。page create では、--route activity のように先頭にスラッシュを付けずにルートを渡します。CLI がスラッシュを追加します。この形式を使うと、Windows で Git Bash/MSYS によるパス変換を回避できます。ページで特定の Canvas ビューポートが必要な場合は、--width <320-3840> と --height <320-2160> を両方指定します。両方のフラグを省略すると、デフォルトの 1440x960 ビューポートが使用されます。片方のサイズだけを指定しないでください。

<prefix> page create --id activity --name "Activity" --route activity --layout app-shell --width 1440 --height 900
<prefix> design context --detail compact --section Overview,Components --pretty
<prefix> token list --type color,spacing --format css
<prefix> token create --name --color-accent --type color --value "#635bff"
<prefix> token set --name --color-accent --value "#574ee8"
<prefix> token delete --name --color-legacy
<prefix> design set-section --heading Overview --content-file overview.md
<prefix> component create --id status-pill --tag x-status-pill --prop tone="Visual tone" --default tone=neutral
<prefix> review get --review <uuid> --output review.png
<prefix> work status --pretty
<prefix> preview verify --page <page-id>
<prefix> work finish --page <page-id>

長い HTML、CSS、JavaScript、Markdown は、生テキストを stdin 経由で渡します。--before、--after、--replace の値には、アンカーとしてのみ機能する短いシェルセーフな値を指定します。複数行を正確に置換する場合は、標準 unified diff を dpai file patch --path <path> にパイプします。一つの diff に複数の関連する hunk を含めることができ、変更はアトミックに適用されます。これがデフォルトのエージェントワークフローであり、一時的な旧ファイルや新ファイルを作成する必要はありません。

シェルでペイロードを正確に保持できない場合、デバッグに役立つアーティファクトを作成する場合、または Windows PowerShell 5.1 が非 ASCII の stdin を破損する可能性がある場合に限り、--content-file、--replace-file、--patch-file を使用します。これらのファイルは UTF-8 にします。

フォールバックファイルが必要な場合は、Git リポジトリのルートを特定し、ファイルは <git-root>/.desainpakeai/tmp/<task-slug>/ にのみ、内容がわかる名前を付けて配置します。最初のファイルを書き込む前に、ルートの .gitignore にルート相対パスのエントリ /.desainpakeai/tmp/ が正確に含まれていることを確認します。存在しない場合は、その行だけを追記し、ファイルの残りの内容は保持します。現在のディレクトリが Git リポジトリ内にない場合は、<cwd>/.desainpakeai/tmp/<task-slug>/ を使用し、そのためだけに .gitignore を作成しないでください。一時入力ファイルをプロトタイプのソースファイルと同じ場所に置かないでください。ファイルを消費するコマンドが成功したら、フォールバックファイルを直ちに削除します。コマンドが失敗した場合は、復旧作業中に限り保持し、その後削除します。work finish の実行前または引き継ぎ前に、タスク固有の一時ディレクトリが残っていないことを確認します。作業完了後にタスク専用ファイルを残さないでください。

セクションごとにページの進行状況を表示する

新しいページでは、セクションごとに2つのコマンドを順に実行し、Canvas の実際の進行状況を表示します。まず、の前に、表示されるセクションのシェルだけを1つ挿入します。最終的なセマンティック要素、安定した `data-node-id`、外側のインラインレイアウトまたはサーフェス、描画に十分なブロックサイズ、そして一意のネストされた アンカーを含めます。次に、そのセクションのコンテンツをネストされたアンカーの前に挿入し、今後の部分編集に備えてアンカーを残します。

次のセクションを作成する前に1つのセクションを完成させ、すべてのコマンドでリビジョンを引き継ぎます。ページの変更を並行して実行しないでください。編集が成功するたびに保存され、Canvas の進行状況が更新されます。ページが完成するまでは、変更の報告で問題が示された場合を除き、preview verify を実行しないでください。

リストのフラグは繰り返し指定するか、カンマ区切りの値を渡してください。編集モードの混在、複数トークンのアトミックバッチ、コンポーネントレシピ、完全な省略項目リスト、または低レベルの統合デバッグを行うアトミックバッチに限り、--input @payload.json を使用してください。ファイルはプログラムで生成し、シェル内で JSON を直接記述しないでください。

DesainPakeAI の操作はすべて <prefix> を通じて実行し、検証、完了、リビジョンの競合、復旧にはコマンドの出力を使用してください。