An アセットエクスポートパイプラインとは、デザインファイルからビルドで使えるファイルに至る一連の流れです：エクスポート、リサイズ、最適化、リネーム、配置。これはまさにコーディングエージェントが得意とする反復的でファイル中心の作業であり、デザイナーがエンジニアに実行を依頼しなければならないために作業が停滞しがちなタスクそのものです。アセットフォルダーに固定され、ルームからアクセスできるエージェントがあれば、その依頼の手間は不要になります。
リクエストの例
「@assets デザインファイルからアイコンセットを1x、2x、3xでエクスポートして最適化し、/public/icons に配置して。コンタクトシートも投稿して。」
エージェントが行うこと
- デザインツールのAPIを呼び出し、最新のアイコンコンポーネントを取得する。
- 3つのスケールで一時フォルダーにエクスポートする。
- マシンにインストール済みの最適化ツールを実行する。
- フォルダーの
README.mdに書かれたプロジェクトの命名規則に従ってリネームする。 - ファイルを
/public/iconsに移動し、前回のセットを置き換える。 - コンタクトシート画像を生成し、件数を添えてルームに投稿する。
デザイナーはタイムラインで各ステップを確認でき、最後にコンタクトシートを受け取ります。所要時間はおよそ1分です。
一時停止する処理
ステップ1ではデザインツールのAPIトークンを読み込みます。これは認証情報アクションであるため、初回はオーナー側で一時停止し、誰がリクエストしたかとエージェントが何を読み取ろうとしているかを示すカードが表示されます。オーナーが承認すれば、トークンがマシン外に出ることはなく、デザイナーの目に触れることもありません。エージェントが実行前に必ず確認すべき4つのアクションを参照してください。
エージェントが新しいアイコンをコミットして main にプッシュしようとした場合も、同様に一時停止します。多くのチームでは、代わりにブランチにコミットしてプルリクエストを作成させており、その場合は一時停止しません。
セットアップ方法
- 1つのエージェントに1つのフォルダー。 サイトリポジトリのデザインアセットディレクトリ、またはエージェントをコードベースから隔離しておきたい場合はエクスポート専用フォルダーに
assetsを固定します。 - 規約を書き留めておく。 命名規則、サイズ、フォーマット、配置先パスを記した
README.mdを用意します。エージェントはリクエストのたびにこれを読み込みます。 - パーミッションモードは
acceptEdits。 ファイルの書き込みが主な役割です。コマンド実行時は確認が入ります。パーミッションモードの解説を参照してください。 - デザイナーへの継続的な権限付与。 各自が1度承認を受ければ、以降は自由にリクエストできます。
- トークンはマシン上に保持する。 ツールの通常の構成ファイルの場所に置きます。リクエストやREADMEに貼り付けてはいけません。
バリエーション
なぜスクリプトではなくルームなのか
スクリプトはエクスポートを実行するだけです。ルームがあれば、変更に気づいた人がターミナルを触ることも、チケットを切ることも、日常的な作業でエンジニアの手を煩わせることもなく、トリガーし、進行を見守り、結果を受け取ることができます。一方で、非日常的なケース（認証情報、削除、プッシュ）ではオーナーの確認のために停止します。また、誰が何をいつエクスポートしたかの記録も残ります。コーディングエージェントはコードを書くだけではないを参照してください。
よくある質問
デザイナーにもデザインツールのAPIアクセス権が必要ですか？ いいえ。トークンはオーナーのマシン上にあり、エージェントはそこでトークンを使用します。デザイナーがリクエストし、オーナーが認証情報の読み取りを承認します。
エージェントはプルリクエストを作成できますか？ はい、エージェントのディレクトリがリポジトリ内にあり、マシン上でgitアクセスが可能な場合は作成できます。ブランチ上でのPR作成は一時停止しませんが、共有ブランチへのプッシュは一時停止します。
デザイナーが命名規則を変更したい場合はどうすればよいですか？ フォルダー内のREADMEを編集するか、エージェントに変更を依頼してください。エージェントはリクエストごとに規約を新しく読み直します。
エクスポート作業自体は1分で終わります。問題だったのは待ち時間です。アセット用エージェントにルームを用意しましょう。
公開日