specify

Specify — ビルドに向けてデザインをパッケージ化する

概要

このスキルは、承認済みのデザインを、実装を担うエンジニアリングチームまたはコーディングエージェントに引き渡せる形にまとめます。引き渡すのは、プロジェクト自体の成果物です。ブリーフにはプロダクトの目的を、ワイヤーフレームには各画面の内容を、ジャーニー、情報アーキテクチャ、ブループリントには画面どうしのつながりや背後で動く仕組みを示します。状態一覧、アクセシビリティのドキュメント、計測フレームワークには、理想どおりに進まない場合のデザインの振る舞いと、成功の評価方法を示します。これらの成果物の内容を改めて説明することはありません。このスキルでは、成果物の前に1ページを作成し、プロダクトの概要、パッケージの内容、各要素のつながり、ビルダーに委ねる範囲を記します。

ビジュアルデザインは含みません。パッケージには、ジャーニーのインタラクション仕様に記載された内容を除き、色、書体、余白、動きに関する指定はありません。技術スタックはビルダーが選びます。

---

スキルファミリー

以下のスキルは、プロジェクトで作成済みの場合に、パッケージに含める成果物を作成します。

• /strategize：デザインブリーフです。必ずパッケージに含めます。エントリーページの最初の段落は、ブリーフをもとに作成します。
• /wireframe：全ページのワイヤーフレームと、存在する場合はプロトタイプビューです。必ずパッケージに含めます。ジャーニーで示されるすべての画面にワイヤーフレームが必要です。
• /journey：ユーザージャーニーマップとインタラクション仕様です。
• /organize：情報アーキテクチャです。
• /blueprint：サービスブループリントです。
• /fortify：状態一覧とエッジケースカタログです。
• /include：スクリーンリーダーの操作フローのドキュメント、キーボードナビゲーションマップ、修正計画です。
• /measure：計測フレームワークです。
• /articulate：ワイヤーフレームに含まれる内容以外のコピー（エラーメッセージ一覧、ボイスフレームワークなど）がある場合のコピー集です。
• /transpose`` および /localize`：プロジェクトが新たなプラットフォームまたは市場に展開する場合の、プラットフォーム適応仕様、クロスデバイスジャーニーマップ、市場要件マトリックス、文化的適応ブリーフです。
• /evaluate：調査結果はパッケージ化の前にすべて解決しておきます。未解決の重大な調査結果がある場合、デザインは準備できていません。
• /present：デッキを作成します。このスキルでは作成しません。ビルドの承認を得るために関係者が集まる場が必要な場合は、パッケージを /present に資料として渡します。
• /philosopher：分野横断的な認知モードです。準備が何度も整わず、その理由を説明できる人がいない場合や、各要素のつながりを示した図から、デザインドキュメントが覆い隠していた継ぎ目が見つかった場合に使用します。

---

準備状況

以下のすべてを満たす場合にのみパッケージ化します。

• ブリーフが作成され、承認済みである。
• ワイヤーフレームが全ページの段階、またはプロトタイプビューの段階まで作成され、承認済みである。サムネイルだけのアイデアボードでは不十分です。
• ジャーニーがある場合、そこで示されるすべての画面にワイヤーフレームがある。
• 評価で見つかった重大な問題が未解決のまま残っていない。
• ホストアプリでは、承認はホスト側の状態で判断します。それ以外の場合は、デザイナーが会話の中で承認したかどうかで判断します。

条件を満たしていない場合は、何が不足しているかを1〜2文で伝え、解決に必要な手順を提案します。ブリーフなら /strategize、不足している画面なら /wireframe、未解決の重大な調査結果なら、それを解決するスキルを案内します。条件を満たす前にパッケージ化を提案してはいけません。

---

倫理的なチェック

パッケージ化する前に、Intent のアンチパターンカタログに照らしてデザインを確認します。対象には、事前にチェック済みの同意、確認を恥じ入らせる表現、捏造された緊急性、選択肢の非対称性、依存を促す仕組みなどがあります。結果は意思決定ログに1件記録します。このデザインに当てはまる可能性のある各パターンと、デザイン上どのように対応しているかを記します。カタログのコードは使わず、デザインが審査を通過したという記述もしません。パッケージには別の資料を含めません。ログを通じてビルダーに内容が伝わるため、同意チェックボックスが意図的に未選択になっていることも把握できます。

ユーザーの立場から正当化できないパターンがある場合は、パッケージ化を中止します。デザイナーとの会話で取り上げ、該当する画面を担当するスキルに戻します。

パッケージに含めるもの

必ず含めるもの：

• デザインブリーフ。
• 全ページの段階のワイヤーフレーム。プロトタイプビューがある場合は、それも含めます。

プロジェクトで作成した場合は、プロジェクトで作成し、何を構築するかを示すものはパッケージに含めるというルールに従い、以下を含めます。

• サービスブループリント。
• ユーザージャーニーマップ。
• 情報アーキテクチャ。
• 状態の一覧とエッジケースのカタログ。
• スクリーンリーダーのフロー文書、キーボードナビゲーションマップ、改善計画。
• 測定フレームワーク。
• ワイヤーフレームに記載されている内容を超えるコピーがある場合は、コピー資料。
• プラットフォーム適応仕様とデバイス間ジャーニーマップ、市場要件マトリクス、文化的適応ブリーフ。
• 倫理レビューの結果を記載した項目を含む、意思決定ログ。

含めないもの：ビジュアルデザイン。ジャーニーのインタラクション仕様に記載されたものを超える色、書体、余白、動きは含めません。技術スタックはビルダーが選びます。

コピーとラベルはワイヤーフレームに含めます。ワイヤーフレームにはルールとして実際のコンテンツを記載するため、/articulateの成果物は、独立したファイルが作成されていない限り、専用のファイルを必要としません。

---

エントリーページ

このスキルが作成する唯一のものです。パッケージディレクトリのルートに置くREADME.mdで、コーディングエージェントが最初に読みます。タイトルにはプロダクト名と変更内容を記載します。

# [Product and change]

[One paragraph: the product, the change, who it is for, from the brief.]

## Contents

| Artifact | Path | What it holds |
|---|---|---|
| Brief | ../brief-<topic>.md | … |

## How the pieces fit

| Screen | Wireframe | Journey step | IA node | Blueprint touchpoint | States | Copy |
|---|---|---|---|---|---|---|

## Left to the builder

- Visual design: color, type, spacing, motion beyond the journey's interaction specification
- Technology
- [anything the design leaves open on purpose]

## Open questions

- [a plain question] (the artifact that holds the detail)

これは何か。 ブリーフに基づき、プロダクト、変更内容、対象者を1つの段落で説明します。

内容。 各成果物について、エントリーページからの相対パスと、内容を説明する1行を記載します。読む順序は、最初にブリーフ、次に各種マップ、次にワイヤーフレーム、その後に堅牢化と要件、最後に意思決定ログです。この表はパッケージのスナップショットです。引き継ぎの根拠となったものを正確に記載します。

各要素の関係。 画面ごとに1行を設け、ワイヤーフレームのフレーム、その画面が担うジャーニーのステップ、属する情報アーキテクチャのノード、背後にあるブループリントのタッチポイント、その画面用に描かれた状態、フレーム内にない場合のコピーの保存場所を記載します。各行で、その画面の目的を説明します。これはコーディングエージェントにとって最も必要なマップであり、どの成果物にも記載されていません。

ビルダーに委ねるもの。 ビジュアルデザイン。技術。デザインで意図的に未確定としたものは、すべて列挙します。デザインで確定しておくべき事項を記載する場所ではありません。状態の欠落は準備不足であり、ビルダーが選ぶものではありません。

未解決の質問。 構築に影響する成果物内の未解決の質問を、それぞれ具体的な質問の形で記載し、詳細が記載されている成果物を示します。作業に関する質問だけを記載します。

このページに語り手は登場しません。署名、作成経緯の説明、デザインの承認済みであるという表明、所有者の記載はありません。画面ごとのセクションを設けることもありません。画面について1行を超える説明が必要な場合は、ワイヤーフレームまたはジャーニーに記載します。

---

形式

プロジェクト内にhandoffというディレクトリを作成し、プロジェクトに複数ある場合はhandoff-<topic>という名前にします。このディレクトリにエントリーページを置きます。成果物は各スキルが作成した場所に残し、エントリーページではそれぞれを相対パスで参照します。何もコピーしません。読み取りツールを使ってコピーすると、ツールの上限を超えた部分が通知なく切り捨てられ、ワイヤーフレームを二重にコピーすると内容に差異が生じるためです。「内容」表がスナップショットになります。コーディングエージェントにはエントリーページのパスを渡し、参照先をたどってもらいます。

パッケージ作成後にデザインが変更された場合は、会話でそのことを伝え、再パッケージ化を提案します。再パッケージ化によってエントリーページを書き換えます。古いエントリーページには何も書き込みません。ホストアプリでは、ディレクトリの保存場所はホストが決定し、参照先の成果物を独自のストアからバンドルする場合があります。

---

文体とアプローチ

項目の羅列より意図を重視します。 マップの各行には、画面が何を備えているかだけでなく、何のための画面なのかを記します。「ブラウズ：ブリーフで地理がプロダクトの単位として示されているため、マップをホームにする」は一つの行です。「ブラウズ：マップ、リスト、タブバー」は項目の羅列です。

このスキルは会話の中でこのように話します。成果物には語り手を置きません。一人称も署名も、文書自体への言及も、作成方法の説明も、デザイナーやチームについての記述も、主張に付ける記号やキーもありません。最初のセクションから始めます。主張には引き続き、キーを付けずに角括弧または脚注で出典を示します。また、チームの作業を主語にした文は使いません（「ブリーフでは却下されている」「レビューでは判明した」など）。依頼が範囲を定めます。意思決定を変えるケースを取り上げ、依頼されていないセクションは省き、各事実の記載場所を一つに絞ります。ある調査結果を一度記述したら、後のセクションではそのタイトルで言及します。削除したセクションだけにあった事実は、適切な場所に移します。決して削除しません。短縮する際も、ビルダーが設定する値（タイミング、サイズ、しきい値、文字列など）は削りません。値は値そのものとして一度だけ記し、その理由はログに残します。成果物の中で、値が未確定、提案中、未テストなどとは記しません。未解決の質問には、デザイナーだけが答えられることだけを含めます。語り手をなくしても、内容は何も削りません。提出前に、依頼に明記されたすべての条件に成果物で回答しているか、未解決の質問として尋ねているかを確認します。意思決定ログには、後から見直される可能性のある意思決定を一件ずつ記載します。日付と意思決定を記した見出しに続けて、「決定者」「理由」「却下した案」「根拠」をそれぞれ一文で記します。ファイル名、形式、個別の文字列は意思決定ではありません。成果物に添える返信は数文にまとめます。ファイルの場所、次のステップに進むために回答が必要な質問を一つ（選びやすいよう選択肢は短く）、デザイナーが覆す可能性が最も高いデフォルト設定を一つ、依頼の範囲内で成果物がカバーしていないこと、次の担当者を記します。成果物を語り直したり、二つ目のデフォルト設定を追加したり、ログを参照させたり、担当者ごとに調査結果を並べ替えたりしません。平易な文を使い、前置きの書き出しは避けます。リストの導入に数字を使いません。/articulate のライティングルールは、書くものすべてに適用されます。

---

範囲の境界

このスキルで行うこと：

• 準備状況を確認し、不足しているものを伝えます
• 倫理チェックを実施し、その結果を記録します
• プロジェクトの成果物を集めます
• エントリーページを作成します

このスキルで行わないこと：

• 独自の仕様書を書くこと（成果物が引き継ぎ資料です）
• デザイン上の意思決定を行うこと（それはデザイナーの仕事です）
• コードを書いたり、技術を選んだりすること
• 成功指標を定義すること（/measure）
• UX の品質を評価すること（/evaluate）
• スライド資料を作成すること（/present）
• デザインの不足を補うこと（不足は準備状況の問題、または未解決の質問です）

---

このスキルを使うタイミング

次の場合に Specify を実行します。

• 「引き継ぎを準備して」または「引き継ぎ資料を書いて」：デザインが承認され、誰かが実装する必要があるとき
• 「これを実装向けにまとめて」
• 「コーディングエージェントには何が必要？」
• 「実装の準備はできている？」：準備状況を確認し、不足しているものを伝えるとき