authoring-user-flows

authoring-user-flows — SKILL.md

バリアント： 標準 · 使用するタイミング： プロデューサーが、製品／機能の ユーザーフロー文書を作成（または修正）しており、別のテンプレートツールでセクション構成を 組み立てる際に、導出方法と本番品質の基準（たどりやすさ＋構造＋回復力＋アクセシビリティ＋ 品質＋修正）を必要としている場合。

概要

このスキルでは、製品のナビゲーション／インタラクショングラフを示すユーザーフロー文書の 作成方法を説明します。ユーザーがどこから入るのか、フローがどのIAフレーム内で展開されるのか、 ユーザーがたどる基本経路、経路が分岐する箇所、通過する画面／状態、問題発生時の動作、経路に 回復力とアクセシビリティがあるか、そしてフローとして良質かどうかを扱います。このスキルが 担うのは、上流の目標や先行事例からフローを導き出す方法（作り上げない方法）、経路が行き止まりに ならないよう確認する方法、図と説明文の整合性を保つ方法、描き直さずに修正する方法といった 判断であり、セクション一覧ではありません。構成はテンプレートツールから得ます。この文書は、 承認済みのPRD（目標とペルソナを提供します）の下流に位置し、ワイヤーフレーム作成の上流に 位置します（フローで指定するすべての画面がワイヤーフレームの対象になります）。対象範囲は インタラクショングラフであり、ピクセルでも、PRDにおける製品の意思決定でも、ジャーニーマップ （時間経過に伴う感情／チャネル／タッチポイント）でもありません。

起動するタイミング

• 目標とペルソナを含む承認済みPRDを受け取り、製品または機能のユーザーフロー／タスクフロー／ インタラクションフロー文書を作成する場合。
• スコープを限定した変更（フローまたは経路の追加／変更／削除）を既存のユーザーフロー文書に 加える場合。再生成ではなく、バージョン管理された差分として扱います（ステップ11を参照）。
• 後続のワイヤーフレーム作成で画面をすべて列挙できるよう、ユーザーがたどる経路 （入口 → ステップ → 分岐 → エラー／復旧 → 出口）をマッピングする場合。

次の場合は起動しないでください：

• 完成済みのユーザーフロー文書をレビュー／評価する場合。これはレビュー側のゲートである reviewing-user-flows が担当します。このスキルが作成するものと同じ基準を適用します。
• 画面レイアウト／ピクセルを設計する場合。これは、これらのフローを利用する authoring-wireframes が担当します。画面ごとのピクセル単位のアクセシビリティ （コントラスト／ターゲットサイズ）も同様です。
• 上流にあるPRD自体を作成する場合、または製品の目標／ペルソナを再決定する場合。
• ユーザージャーニー（感情／チャネル／時間経過）を作成する場合。これは別の成果物です。

入力

計画から渡されたすべての文書、つまり依存関係セット（発見プロセスで、この文書に情報を提供 すると判断された上流文書）を読み、文書の内容をそれらにたどれるようにしてください。一般的な 上流文書はPRD（目標＋ペルソナ）です。デザインシステムが存在する場合は、フローで参照する ナビゲーション／アプリシェルとコンポーネントの用語を提供します。修正の場合は、既存の ユーザーフロー文書が入力として渡されます。入力が固定されていると想定しないでください。 指定された上流文書は参考であり、上限ではありません。自己完結型にしてください。実際に受け取った コンテキストから成果物を作成し、期待される情報提供文書がない場合は、手元の情報に基づいて進め、 不足を明示的な前提として示してください。補うために捏造してはいけません。また、利用できる場合は 必ずリサーチ機能（deep-research）を使い、テンプレートを埋めるだけでなく、ドメインの慣習や 先行事例のフローパターンを根拠づけてください。

ケイパビリティのコンテキスト（提供されている場合）： 呼び出し元から capability_record（capability-map.yaml product_capabilities のレコード）が渡された場合は、 ステップ1の前に読み込んでください。これはスコープの境界を定めます。owns は対象とする エンティティ、refs は参照するが所有しないエンティティ、publishes／consumes は表面化する イベント、entry_points／exit_points はユーザーの流入元と離脱先、has_ui／has_api／ has_persistence は適用されるサーフェスを示します。存在する場合はハード制約として扱い、定義された 境界から逸脱しないでください。

ワークフロー

まずテンプレートツールで構成を作成します。 作成を始める前に、content-template ツール（content-template-gateway 機能、またはインストールされているテンプレートプロバイダー）から、ユーザーフローセクションの構成を取得してください。テンプレートには、フローごとの項目（目標／PRD との関連、入口、フローチャート、説明、分岐、エラー／復旧、レジリエンスとシステム状態、アクセシビリティ、画面／状態、成功）に加え、ナビゲーションと IA、フロー間の遷移、画面インデックス、前提条件、バージョン管理／変更履歴のセクションが含まれます。独自の構成をハードコードしてはいけません — このスキルは、テンプレートの項目を導出した内容で埋めるものであり、テンプレート自体を再定義するものではありません。

すべての機能レコードが注入される場合は、exit_points → entry_points の連鎖を使って、機能をまたぐユーザージャーニーを対応付けます。各フローには、経由する機能 ID を記載します。機能ごとのフローは、その機能の entry_points／exit_points の範囲内に収めます。

ステップ 1：目標／ペルソナごとにフローを 1 つ導出する — ジョブとして捉え、既存の実例に基づかせる

各 PRD の目標を、ペルソナが達成しようとしているジョブとして捉えます（機能的・社会的な背景を含む、本人の言葉での目標です）。目標／ペルソナの組み合わせごとに、フローを 1 つ作成します。ペルソナによって同じ目標への取り組み方が異なる場合は、それぞれに独自のフローを与え、ひとつにまとめるのではなく、メンタルモデルや状況の違いなど、その理由を明記します。これにより、すべての PRD の目標／ペルソナにフローが割り当てられ、すべてのフローがいずれかに対応することが保証されます。各フローは、そのジョブにおける確立されたインタラクションパターン（標準的な認証／パスワードリセット／チェックアウト／オンボーディング／OAuth）と、製品の既存の実例に基づかせます。解決済みのフローを一から作り直さず、逸脱する場合は理由を明記します。まずカバレッジマップに対応関係を記入します。これが以降の内容を支える骨格になります。ドキュメントはジャーニーではなくフローとして記述し、各ステップに感情やチャネルを割り当てないでください。

ステップ 2：ナビゲーションと IA の枠組みを対応付ける

個々の経路を描く前に、その経路が置かれる構造的な枠組みを明確にします（規模に応じて記入してください。単一画面のツールでは、この大半が不要になります）。

• 入口の分類 — あらゆる入口（ホームページ、ディープリンク、メール／招待、通知、キャンペーン）と、各入口から遷移する状態（ディープリンクでアクセスしたユーザーは一部のステップをスキップする場合があります）。
• ナビゲーション／アプリシェルのモデルと道案内 — フローが動作する中で常に表示される UI 要素、IA における各フローの位置、ユーザーがいつでも既知の場所に戻れる仕組み（アプリシェルから離れて戻れなくなる状態にしない）。デザインシステムにアプリシェルがある場合は、それを参照します。
• ディープリンク／ルーティング — ルーティング可能な製品では、経由するルートと、前提条件が満たされない場合のガード／再開処理（事前のステップが必要な状態へのディープリンク → 中間画面 → 再開）。
• デバイス間の差異 — フォームファクターによって経路が異なる箇所（レイアウトだけでなく、モバイルで追加されるステップやネイティブのサブフローなど）。

ステップ 3：まず基本フローを対応付ける

各フローについて、ほとんどのユーザーがたどる主要経路を、入口から順序立てたステップを経て成功時の出口に至るまで、エラーは含めず、平易な言葉で記述します。各ステップが経由する画面／状態にはすべて、図、説明、インデックスで一貫して同じ表記を使う固有名を付けます。この骨格に複雑な要素を加えていき、例外ケースから着手しないでください。

ステップ 4：すべての意思決定の分岐を列挙する

ユーザーが複数の選択肢を選べる箇所では、すべての分岐先を明記し、それぞれをステップ、別のフロー、または明確な出口につなげます。片側の行き先が記載されていない意思決定は、実装後半になって表面化する抜け漏れです。行き先のない「はい／いいえ」の分岐を残さないでください。フロー間で引き継ぎが発生する場合は、フロー間の遷移セクションに記録し、遷移先のフローが存在することを確認します（未定義または削除済みのフローには引き継がないでください）。

ステップ 5：エッジケースのチェックリストと状態を確認する — 行き止まりを作らない

各ステップでこの固定チェックリストを確認し、網羅性を感覚頼みにせず体系的に確保します。 また、状態を経路がたどるノードとして扱います（ワイヤーフレームの対象になります）。

• 空／null · 無効な入力と極端な入力（境界値 0／1／最大値／最大値+1） · タイムアウト／ネットワーク／連携エラー · 中断／セッション喪失 · 権限／認証の拒否 · 戻る／キャンセル。
• 読み込み中／処理中の状態 — 非同期または時間のかかる各ステップで必ずこうした状態を経由させます （スケルトン／スピナー／進行状況）。図に起こし（非同期ステップ = トリガー → 処理中 → 成功 | エラー）、画面一覧に含めます。
• 成功／確認の状態 — 抽象的な「成功」ではなく、ユーザーが目にする具体的な「目的達成」の状態 （確認画面／照会番号／領収書）です。

該当するケースごとにユーザーの状態を示し、生産的なステップに戻るための回復経路を用意します。 ユーザーを決して行き詰まらせないでください。すべてのエラー状態で、何が問題だったのかと どうすれば解決できるのかを伝えます。

ステップ 6：操作の回復性とシステム状態を加える

エラーからの回復に加えて、経路に回復性を持たせます（該当するものを記入してください。詳しくは references/resilience-and-states.mdを参照）。

• 取り消し／取り消し不能な操作の確認 — 削除／支払い／送信／最終送信など、破壊的または取り消し不能な操作には、 確認または取り消しを必ず用意します。取り消し可能な操作では、モーダルでの確認よりも取り消しを優先します。
• 再開とやり直し — 複数ステップの各フローで、中断時の挙動（何がどれだけの期間保持されるか）を明記します。 再読み込み時に何も知らせず破棄してはいけません。
• 「何が変わったか」のフィードバック — 状態が変わる各ステップで、単に「完了」と伝えるのではなく、 結果を示します（下書きとして保存、$X を承認、#1234 として送信）。
• 楽観的処理と確定済み処理 — 非同期アクションについて、どちらの方式かを明記します。楽観的処理は リスクが低い場合に限ります（支払いや削除には使用しません）。失敗時の取り消しとフィードバックも 定義する必要があります。

ステップ 7：フローレベルのアクセシビリティを確認する

支援技術を使うユーザーも含め、すべてのペルソナが各経路を完了できるようにします （references/flow-accessibility.mdを参照）。これはフローレベルのアクセシビリティであり、 画面ごとのピクセル単位の WCAG 対応ではありません（それはワイヤーフレーム／デザインシステムの範囲です）。

• 最初から最後までキーボードで完了できること。トラップを設けないこと。
• ステップ／経路の変更時のフォーカス順序（WCAG 2.2 SC 2.4.3） — 意味のつながりを保つ順序で フォーカスを移動します。ステップ／経路の変更時には、新しいコンテンツにフォーカスを移し、フォーカスを 放置しないでください。
• すべての経路を支援技術で完了できること — 成功時も失敗時も対象です。エラーは通知され、 プログラムから判別可能である必要があります。色や位置だけで伝えてはいけません。
• マウスのみ／ジェスチャーのみを必要とするステップがないこと（各ステップにキーボードでの代替手段があること）。

ステップ 8：フロー品質の客観的なヒューリスティクスを適用する

フローを、単に網羅的なだけでなく、優れたものにします。ここでは客観的に確認できる項目を対象とします （主観的な好みは対象外です。references/flow-quality.mdを参照）。

• 回復よりもエラー防止を優先 — 取り消し不能な操作は、実行後に回復するだけでなく、実行前に防止します （確認／プレビュー／有効化前の検証）。
• 記憶よりも認識を優先 — ステップで、前のステップで確定した情報を表示します。「画面 2 のコードを覚えて、 画面 4 で入力してください」のように、情報を引き継がない設計にしてはいけません。
• 不要なステップを設けない — 経路を、作業に必要な長さを超えて長くしません（経路の長さはここで一度だけ評価し、 アクセシビリティでは評価しません）。
• 一貫性 — 類似した作業では、フロー全体で類似した経路を使用します。プラットフォーム／DS の規約に従うか、 逸脱する場合はその旨を明記します。

ステップ 9：2 つの表記法で描画し、同期を保つ

各フローを 2 回 描画します。1 つは Mermaid フローチャート（開始／終了は端子、画面／状態は長方形、判断はひし形、エッジにはラベルを付ける）、もう 1 つは番号付きの説明と、分岐／エラーパスの明示的な一覧です。複数のアクターが登場するフロー（ユーザー ⇄ システム ⇄ 管理者、サードパーティプロバイダー、承認の引き継ぎ）では、誰が何をするかを明確にするため、スイムレーン（アクターごとに Mermaid の subgraph）を使います。2 つの表記法では、同じ グラフを記述しなければなりません。一方にだけノード／分岐がある場合は欠陥です。重要な状態のメッセージの意図を明示し（エラー＝原因＋修正方法、空＝操作への案内、成功＝結果）、図／説明／インデックス全体で、画面ごとに正式名称を 1 つ使います。

ステップ 10：簡潔な PRD にある不足を、前提／未解決の質問として明らかにする

PRD でフローに必要な内容が指定されていない場合は、前提を明記します（レビュー担当者が異議を唱えられるようにするためです）。未解決の判断事項は未解決の質問として列挙します。プロダクト上の判断を黙って作り、フローに埋め込んではいけません。ユーザージャーニーだけに関する内容（感情／チャネル）は含めず、本当に必要な場合は上流の参照資料に移します。

ステップ 11：修正時 — 影響範囲を特定し、描き直さずに編集し、ドキュメントのバージョンを更新する

既存のユーザーフロー文書と範囲を限定した変更を受け取った場合は、バージョン管理されたソースコードのように扱います（references/amend-method.md を参照）。

1. 影響範囲を特定する — 変更が及ぶフロー／分岐／パスと、その波及範囲を特定します。波及範囲には、変更／削除したフローへのフロー間の引き継ぎ、削除したパスを参照する画面インデックスの項目、移動した分岐先も含まれます。
2. 描き直さずに編集する — 必要最小限のインプレース編集を行います。変更しないフロー（図、説明、インデックス行）は、バイト単位で変更せずに保ちます。不必要な番号の振り直しは行いません。
3. バージョンと変更履歴 — 文書独自のバージョンを更新し（MAJOR ＝ フローの削除／名称変更、または到達可能なパスの削除、MINOR ＝ フロー／分岐／パスの追加、PATCH ＝ 文言／表記法の変更）、フロー／パス単位で Keep-a-Changelog 形式の項目を追加します。
4. 安全に非推奨にする — MAJOR で削除する前に、MINOR でフロー／パスを非推奨にします（非推奨と明記し、置き換え先を示します）。画面を削除する場合は、インデックスから削除し、残っているパスがそれを参照していないことを確認します。

ステップ 12：引き渡し前に、以下の基準に照らして自己チェックする

品質基準に沿って確認します。レビューまたはワイヤーフレーム作成に文書を引き渡す前に、基準を満たさない箇所をすべて修正します。

ルール

必ず守るルール（決して違反しないこと）：

• 重複させず、組み立てる。 セクション構成はテンプレートツールが決定します。このスキルで競合するアウトラインを作成することはありません。
• 創作せず、導き出す — 双方向で。 すべてのフローは PRD の目標／ペルソナに対応し、すべての PRD の目標／ペルソナにはフローが必要です。標準フローは確立されたパターンに従うか、逸脱する理由を明記します。孤立した要素や、すでに解決済みのフローの再発明はありません。
• 行き止まりを作らない。 すべての判断分岐で解決策を示し、すべてのエラー状態／エッジケース状態に、生産的なステップへ戻るための回復経路を設けます。
• 2 種類の表記を同期させる。 各フローには、Mermaid フローチャートと、番号付きの説明および分岐／エラーの一覧を用意し、同じグラフを表します。複数のアクターがいる場合はスイムレーンを使います。
• 画面名は 1 つに統一する。 図、説明、フロー別一覧、インデックスで同一の名前を使います。改訂後も統一します。名前の不一致は画面の網羅性を損ないます。
• 画面をすべて列挙できるようにする。 画面インデックスには、すべてのフローの画面／状態（読み込み中＋成功を含む）を漏れなく含め、ワイヤーフレーム作成時にすべてを列挙できるようにします。
• 取り消せない操作にはガードを設ける。 破壊的な操作／取り消せない操作には、確認または取り消しの手段を必ず用意します。
• ジャーニーではなく、フローを扱う。 インタラクショングラフのみを対象とし、感情／チャネル／時間経過は扱いません。
• 再生成せず、改訂する。 変更時は該当するフローをその場で編集し、ドキュメントのバージョンを更新します。変更のないフローは描き直しません。
• 機能の境界（capability_record が指定されている場合）。 ドキュメントの出力範囲を、そのレコードの境界内に限定します。境界外の内容を作成すること（refs エンティティを自分の管理対象であるかのように扱うことや、exit_point を超えたフローを設計すること）は、スコープ違反です。仕様にない内容を創作することと同等です。

推奨事項（必要に応じて変更可能）：

• 目標／ペルソナの組み合わせごとにフローを 1 つ作成します。ペルソナによって共通の目標に対するフローが異なる場合は分割し、その理由を明記します。
• 説明は平易な言葉で書き、略語は展開し、図のすべてのエッジにラベルを付けます。
• PRD の目標／ペルソナの数と、プロダクトの複雑さに応じてドキュメントの分量を調整します。シンプルなユーティリティなら、記載するセクションは少なくてかまいません（アプリシェルやレジリエンスの項目は不要です）。水増しも省略もしません。該当する場合は、ナビゲーションと情報アーキテクチャ／レジリエンス／アクセシビリティを記載します。

注意点

• ハッピーパスのみのフロー。 もろいフローになります。実際のユーザーの多くは理想的な経路から外れます。エッジケースのチェックリスト（ステップ 5）とレジリエンス（ステップ 6）を活用し、網羅的に検討します。
• 状態変化が通知されない。 状態を変更して次へ進むステップで、「何が変わったか」を知らせないと、ステップ 6 のフィードバックがなく、完了したように見えてもユーザーは状況がわからず困惑します。
• 読み込み中／成功状態の欠落。 トリガーから成功へ一気に進むフローでは、ワイヤーフレームで設計すべき処理中画面と確認画面が見えません（ステップ 5）。
• 図と説明の不一致。 片方だけ編集してもう片方を忘れると、矛盾が生じます。同じ成果物の 2 つの表現として、変更のたびに整合性を確認します。
• フロー内でプロダクト上の判断を創作する。 その前提を切り出します（ステップ 10）。
• セクション間（または改訂間）で画面名が揺れる。 どこでも同じ安定した名前を使います。これは改訂時に最も起こりやすい退行です。
• 支援技術の利用者が取り残されるエラー。 視覚的には明らかなエラーでも、通知されなければ、スクリーンリーダーの利用者は、視覚で状況を確認できる利用者なら回復できる経路で立ち往生します（ステップ 7）。
• 変更時の再生成。 改訂時に変更のないフローを描き直すと、ドキュメントに不要な変更が増え、フロー間のグラフが壊れます（ステップ 11）。

アンチパターン

• 「図だけで十分です。」 フローチャートだけではテキストでたどれません。番号付きの説明と分岐一覧は必須です。
• 「セクション一覧は自分でドキュメントに書き込んでおきます。」 重複が生じ、テンプレートから乖離します。必ずテンプレートツールから構成してください。
• 「エッジケースは端の問題です。ハッピーパスだけで出荷します。」 分岐の欠落、未処理の状態、ガードされていない取り消し不能なアクションは、ユーザーを行き詰まらせる欠陥です。
• 「PRDに書かれていないので、自分で決めます。」 明示されていないプロダクト上の決定は、前提・未解決の質問に記載します。
• 「ついでにレイアウトも作成します。」 画面レイアウトは後続のドキュメントで扱います。ここではナビゲーショングラフのみを扱います。画面ごとのピクセル単位のアクセシビリティも同様に、ワイヤーフレームやデザインシステムで扱います。
• 「各ステップでの感情を整理します。」 それはユーザー フロー ではなく、ユーザー ジャーニー です。
• 「新しいフローを1つ追加するために、ドキュメント全体を描き直します。」 変更箇所だけを修正し、ドキュメントのバージョンを更新します。

本番品質の基準

ユーザーフローのドキュメントは、以下のすべてを満たすと基準に達します（これはレビュー側のゲートで確認される基準と同じです。各項目はプロダクトに応じて適用されます。適用される項目をすべて満たす簡潔なドキュメントは合格です）。

1. 目標・ペルソナを網羅し、孤立した項目がない。 すべてのPRDの目標・ペルソナ（ジョブとして表現）にフローが対応し、すべてのフローがその目標・ペルソナにたどり着けます。標準的なフローは、それぞれのパターンに基づいています。
2. ナビゲーションとIAの枠組み（該当する場合）。エントリーポイントの分類を網羅します。複数のサーフェスを持つプロダクトでは、ナビゲーション／アプリシェルのモデルと道案内を含めます。該当する場合は、ディープリンクとデバイスごとの差異に対応し、フロー間の引き継ぎを解決します。
3. 開始点と終了点を定義する。 すべてのフローで、すべてのエントリーポイント（および遷移先の状態）と、具体的な成功／確認状態を明記します。別の終了経路も明確です。
4. すべての判断分岐を解決する。 各判断ですべての分岐を列挙し、それぞれの遷移先を明確にします。
5. すべてのエラー／エッジ状態に回復手段があり、行き止まりがない。 チェックリストにある状態（読み込み中や成功を含む）は、該当する場合に記載し、元のフローに戻れるようにします。エラーには内容と対処方法を記載します。
6. 操作のレジリエンス（該当する場合）。取り消し不能なアクションをガードします。複数ステップのフローでは再開／やり直し方法を記載します。状態が変化するステップでは「変更内容」を知らせます。楽観的なアクションには取り消し手段を設けます。
7. フローレベルのアクセシビリティ。 どの経路もキーボードと支援技術（AT）で完了できます。ステップ／ルートの変更時にフォーカス順序を適切に管理し、エラーを通知します。マウス操作だけに依存するステップはありません。
8. フローの品質（客観的な観点）。 不要なステップがありません。取り消し不能なアクションは、事後に回復するだけでなく、事前に防止します。ステップをまたいで情報を覚えておく負担がなく、同種のジョブは一貫しています。
9. ステップが明確で、たどれる。 読者が推測せずに説明をたどれます。各ステップに画面／状態とユーザーのアクションを記載します。
10. 2種類の表記が同期している。 フローチャートと説明・分岐／エラー一覧が同じグラフを示しています。複数のアクターがいる場合はスイムレーンを使用します。
11. ワイヤーフレーム作成に必要な画面を列挙できる。 インデックスには画面の完全な一覧（読み込み中や成功を含む）が含まれています。画面ごとに正式名称が1つだけあり、孤立した画面はありません。
12. 前提・未解決の質問を明らかにする。 情報の少ないPRDに関する前提を明記し、明示されていないプロダクト上の決定を残しません。ジャーニーの内容は含めません。
13. 修正範囲が適切である（反復時）。変更範囲を限定して該当箇所を修正し、変更しないフローはそのままにします。ドキュメントのバージョンと変更履歴を更新し、互換性を損なう削除は非推奨として扱います。

出力

Markdown 形式のユーザーフロー文書です。文書ごとのバージョンヘッダーと、網羅性マップ（PRD の目標／ペルソナ → フロー）、ナビゲーションと IA のセクション、フローごとのセクション（同期された Mermaid フローチャート＋番号付きの説明＋分岐／エラーの一覧を含み、エントリーポイント、レジリエンスとシステムステータス、フロー単位のアクセシビリティ、読み込み中＋成功を含む画面／状態、成功基準を記載）、フロー間の遷移一覧、画面インデックス、前提／未解決の質問のセクション、バージョン管理／変更履歴のセクションで構成され、テンプレートツールの構造に沿って作成されます。レビュー側のゲート（上記の基準に照らして評価）と、後続のワイヤーフレーム作成（フローに記載されたすべての画面を列挙）で使用されます。手法と基準は媒体に依存しません。将来デザインツール用のバックエンドが導入されても、変わるのはレンダリングだけで、導出方法や基準は変わりません。

関連項目

• テンプレートプロバイダー（content-template-gateway の機能）— このスキルが構成に使用するユーザーフローのセクション構造を提供します。ここで重複して定義しません。
• リサーチ機能（deep-research、利用できない場合はウェブ検索）— ドメインの慣例、先行事例のフローパターン、導出根拠を裏付けます。
• 上流の入力 — PRD（フローで実現する目標とペルソナ）、および存在する場合はデザインシステム（フローで参照するナビゲーション／アプリシェルとコンポーネント）です。白紙から作成することはありません。反復時には、既存のユーザーフロー文書が入力として渡されます。
• reviewing-user-flows — 同じ基準を評価するレビュー側のゲートです。作成側とレビュー側の基準は一元管理されています。
• authoring-wireframes — 後続の利用者です。フローに記載された各画面がワイヤーフレームの対象となるため、完全な画面インデックスが引き継ぎの契約となります。画面単位のピクセルレベルのアクセシビリティは、このスキルではなく、こちらが担当します。

段階的な開示

• references/resilience-and-states.md — 元に戻す／確認、再開／再起動、システムステータス、楽観的な状態と確定済みの状態、読み込み／成功／状態マトリックスの詳細（ステップ 5〜6）。
• references/flow-accessibility.md — フローに適用する WCAG 2.2 SC 2.1.1 / 2.4.3、ルート変更時のフォーカス順序、支援技術で完遂可能なこと、フローとピクセルの境界（ステップ 7）。
• references/flow-quality.md — フローに対応付けたニールセンの 10 のユーザビリティヒューリスティクス、客観的な評価対象、誤った修正を行わないための境界（ステップ 8）。
• references/amend-method.md — 影響範囲の特定、描き直しではなく編集、文書のバージョン管理と変更履歴、非推奨化（ステップ 11）。
• references/sources.md — 導出方法と基準のリサーチに関する出典情報。

本文の上限

• description は 1,024 文字以下（agentskills.io の上限）。
• 本文は約 500 行／5,000 トークン（目安。品質を優先し、700 行／7,000 トークンを恒常的に超える場合は警告）— 毎ターンのコンテキストに保持されます。
• 参照ファイルごとに、10k トークン超で警告、25k 超でエラー。