ds-ai-rails

デザインシステムの基盤に沿って AI を導く

チームは、コンポーネント、トークン、アクセシビリティ、ドキュメント、 そして作業方法に投資してきました。その投資を活用できるよう支援しましょう！デザインシステムと Web サイトを構築する AI ツールの間に実用的な接続を確立し、 その接続で実際にどのようなことを信頼して任せられるのかを示します。

上記の公開名称を一貫して使用してください。一人称でアシスタントが語るのではなく、 二人称または中立的な表現で、作業を直接提示してください。 実際のデザインシステムの確かな基盤を AI が活用し、UI を幻覚で作り出さないよう支援するという 目的を明確にしてください。

組織のエコシステムや用語に合わせてください。レシピ、パターン、 モジュール、テンプレート、ページは、所有者が異なる別々の場所に存在することがあります。 特定のフレームワーク、MCP、ベンダー、パッケージ構成、その他のスキルは必要ありません。

承認済みの提示文言にはユーザー向けワークフローを使用してください。 作業の進行に合わせて、関連する段階を確認してください。未回答の質問だけを尋ね、 該当する分岐だけを示し、すべての調査結果を根拠に基づいて記入してください。 以下の手順リファレンスに従って、調査と作業を進めてください。

作業を選ぶ

依頼内容と既存のコンテキストからモードを推測してください。回答によって実施内容が変わる場合に限り、質問してください。

モード	実施内容	完了時点
評価	利用可能な環境を調査し、優先順位を付けた改善案を提示します。準備状況に関する質問では、これがデフォルトです。	根拠、実行可能な計画、未解決のチーム内判断事項。設定や製品の変更は行いません。
セットアップ	依頼された変更を行うのに十分な範囲で評価したうえで、対象を限定した指示、設定、チェックを準備または適用します。	レビュー可能な変更、適用状況、利用可能なアクセス範囲内での検証。
検証	既存のセットアップを試すか、変更後に再確認します。	観察された結果、失敗、介入、主張できる範囲の正確な限界。

ユーザーがより広い範囲を指定しない限り、まずは1つのシステム、1つの利用プロジェクトまたは承認済みサンドボックス、1つの AI 環境を対象にしてください。自由な試行、システムを使ったプロトタイプ、本番作業を区別してください。どの部分が 乖離したりモック化されたりする可能性があるか、また本番展開前に何を再確認すべきかを記録してください。 レガシーページの変更を、製品全体の移行許可と見なしてはいけません。

コンテキストを把握する

ユーザーへの聞き取りを始める前に、アクセス可能なプロジェクト指示、システムプロファイル、マニフェスト、カタログ、 ツール設定を確認してください。競合する情報源を作るのではなく、保守されているプロファイルを再利用してください。 作業内容に影響する不足情報だけを尋ねます。具体的には、ユーザーのニーズ、関連するシステムと環境、 必須の再利用対象、許可されている拡張方法、所有者、アクセス権限です。

評価または新規セットアップでは、Discoveryを確認してください。 検証では、評価を最初から繰り返すのではなく、関連する調査の根拠を更新してください。情報源とバージョンを記録してください。以前に接続が成功していても、現在も機能している証明にはなりません。

評価中は、手法レビューを使い、観察された弱点と State of AI in Design Systems の調査で取り上げられている関連アプローチを結び付けてください。 チームに合うものを選んでください。手法の数は準備状況のスコアではありません。会話形式でのドライランでは、 環境を調査したかのように示すことなく、ユーザー向けのやり取りを進めてください。

作業中は、次の区別を保ってください。

• **ナレッジ：**どのアセットやガイダンスが存在するか、誰が保守しているか、プロジェクトが実際にどのバージョンを使用しているか。
• **ポリシー：**どのような行動をエージェントに求めているか。どこで合成、拡張、試行を認めるかを含みます。
• **強制：**各サーフェスで、違反を検出または阻止する仕組みが実際に確認されているか。指示だけでは助言にとどまります。
• **品質：**結果として得られる体験がユーザーにとって機能するか。準拠したインポートが、優れたデザインや正常に動作する挙動を証明するわけではありません。

作業方針を定める

再利用方針を提案したり、網羅されていないニーズへの対応を決めたりする前に、ポリシーとギャップの振り分けを読んでください。

この作業では、チームがこれまで明示的に決めていなかった事項が表面化することがよくあります。そのことを認識してください。権限がある場合は、適用範囲を限定した暫定的な判断を下せるよう支援しつつ、チームでの議論が引き続き必要な事項を記録してください。パイロットでの合意が、そのまま組織全体の方針になるわけではありません。

評価と、対応方針が定まっている作業は進めてください。未解決の判断によって新しい UI が許可されるかどうかが変わる場合は、具体的な選択肢を提示し、権限のある判断ルートが整うまで、その部分の作業を中断してください。システム上のギャップがあるからといって、技術スタックを全面的に切り替えたり、代替システムを独自に作ったりする包括的な許可が得られるわけではありません。

ワークフローを接続して実行する

セットアップ作業については、セットアップを読んでください。新たなプロセスを導入するのではなく、次の動作を既存のデリバリープロセスに合わせてください。

1. 適用されるルールを読み込み、信頼できる情報源にアクセスできることを確認します。
2. 要求されたエクスペリエンスを、実際のコンポーネント、トークン、適切な構成に対応付けます。使用するバージョンの API と利用ガイダンスを確認します。
3. 対応方針に従って、網羅されていないニーズを振り分けます。
4. 実際の依存関係と許可された拡張ポイントを使って構築します。
5. 関連するコード、動作、アクセシビリティ、レンダリング結果の確認を実施します。
6. 出所、結果、制限事項、例外を提示してレビューを受けます。
7. 既存のリリースプロセスに従い、プロダクトから得られた学びを上流に共有します。

パイロットまたは検証を依頼された場合は、検証を読んでください。意味のあるインタラクションと、網羅されていない要件を含む、小規模で代表的なタスクを使います。出力だけでなく、確認項目もテストしてください。エクスペリエンスに関する人間の判断を維持してください。

主張を誠実に保つ

• 可能な限り、実際の API とレンダリングされた実装を確認してください。スクリーンショット、デザインファイル、未使用のインポート、エージェントの自己申告だけでは、コードが再利用されている証拠にはなりません。
• 証拠には、場所、バージョン／リビジョン、日付、適用範囲を添えて、検証済み、報告済み、または不明と明記してください。調査結果には、対応済み、一部対応、未対応、未確認、または該当なしのステータスを付けてください。重要なギャップを隠してしまう単一の準備状況パーセンテージは避けてください。
• 各コントロールに助言、検出、ブロック、または未検証のラベルを付けてください。対象となる正確な経路と、既知の回避方法を明記してください。
• ある機能がブロックされている場合、それに依存する作業とその主張には制約が生じます。有用で独立した作業は続けてください。代替手段を使うのは、ポリシーで許可されており、対象バージョンに関する適切な証拠を提供できる場合に限ります。
• 既存の権限を維持してください。評価の依頼は、設定を変更する許可ではありません。セットアップの依頼では、範囲を限定したローカルな変更が許可されることがありますが、認証情報の取得、組織のポリシーの拡大、メッセージの送信、公開、または無関係なプロジェクトの変更は許可されません。
• 準備された変更と有効化された変更、下書きの課題と提出済みの課題、リリース済みのシステム修正とプロダクトでの採用を、それぞれ区別してください。

チームが活用できる成果を残す

成果物を作成する際は、Artifactsをお読みください。 チームで既存のドキュメントやトラッカーがあれば、そちらを優先してください。ない場合は、合意済みのプロジェクト内に ds-ai-rails/ディレクトリを使用します。通常のチャットでは、保存可能なテキストとして同じ記録を提示し、確認または実行できなかった内容を明記してください。

評価では、プロファイルと優先順位を付けた計画を作成します。セットアップでは、具体的な差分、アクティベーション／ロールバックに関する注記、および利用可能な検証内容を追加します。検証では、実際に実施したことを記録します。作業範囲を限定した実施上の選択肢、未解決の質問、担当者、レビューの契機を含む簡潔な意思決定リストを作成してください。既存のバックログがある場合は、並行するバックログを新たに作成しないでください。

最後に、機能している内容、未検証またはブロックされている内容、この作業に必要な具体的なチームの意思決定をまとめてください。組織全体を先に再設計する必要があると思わせずに、最も有用な次のアクションを説明してください。

このスキルは、AIを活用したウェブサイトのワークフローを確立するものです。システム全体の健全性検査、製品の移行、ネイティブレンダリング、ランタイムでの生成 UI、組織全体のモニタリングは、それぞれ別の作業です。ほかのスキルから得られたエビデンスがあれば再利用してください。このスキルの完了にあたって、それらは前提条件ではありません。