authoring-user-guide

authoring-user-guide — SKILL.md

バリアント： 標準 · 使用する場面： プロデューサーが製品のエンドユーザーガイドを作成する場合 別のテンプレートツールでセクション構成を組み立てながら、Diataxis に基づく作成方法と、ユーザビリティ／正確性の基準（平易な言葉、アクセシビリティ、見つけやすさ、改訂を含む）が必要な場合です。

概要

このスキルは、エンドユーザー向けユーザーガイド、つまり実際のユーザーが製品を使って目標を達成するためのヘルプを作成する際に役立ちます。上流のドキュメントからユーザーの目標ごとに 1 つのハウツーを導き出し、手順を創作しない方法、Diataxis の 4 つのドキュメントモードを明確に区別する方法（モードの混在は、ドキュメントがわかりにくくなる最も一般的な原因です）、各手順を製品の実際の動作に即したものにし、正確な UI ラベルで表記する方法、技術に詳しくない読者にも伝わる平易な言葉で書く方法、ガイドのアクセシビリティと見つけやすさを確保する方法、そして製品の変更に応じて公開済みガイドを改訂する方法を扱います。セクションの一覧を定めるものではありません。それはテンプレートツールが担います。対象読者は、ツールを統合する開発者ではなく、（通常は技術に詳しくない）エンドユーザーです。開発者向けツールの導入／統合に関する説明は別の authoring-developer-guide が担当し、HTTP／SDK エンドポイントの一覧は別の authoring-api-reference が担当します。このガイドの「リファレンス」モードは、API ではなく、エンドユーザー向けの製品リファレンス（機能、設定、CLI コマンド）です。このガイドは、説明対象である製品／動作のドキュメントをもとに作成され、reviewing-user-guide によってユーザビリティ／正確性の基準に照らして確認されます。

使用する場面

• 上流のドキュメント（通常は feature-spec、user-flows、wireframes）をもとに、製品のエンドユーザー向け／顧客向けユーザーガイド、ヘルプセンター、または製品マニュアルを作成する場合。
• 実際のユーザーがサポート対象のすべての目標を達成できるよう、エンドユーザー向けドキュメント一式（入門チュートリアル、タスク別ハウツーガイド、概念の説明、エンドユーザー向けの機能／設定リファレンス、トラブルシューティング／FAQ、用語集）を作成する場合。
• 上流の変更（設定名の変更、機能の削除／追加、フローの変更、画面の再設計）の後に、公開済みガイドを改訂する場合 — バージョンごとに古くなった箇所を確認します。

次の場合は使用しないでください：

• 完成したユーザーガイドをレビュー／評価する場合 — その場合は、このスキルが定めるものと同じ基準への準拠を確認する、レビュー側のゲートである reviewing-user-guide を使用します。
• ライブラリ、SDK、CLI、フレームワーク、API プラットフォーム向けに、開発者向けツールの導入／統合／オンボーディングに関する説明を作成する場合 — その場合は authoring-developer-guide を使用します。
• HTTP／SDK エンドポイントの一覧（インテグレーター向けのエンドポイントごとのワイヤー契約）を作成する場合 — その場合は authoring-api-reference を使用します。このスキルのリファレンスモードは、API ではなくエンドユーザー向けの製品領域を対象とします。
• 社内エンジニアリングドキュメント（feature-spec、data-model、architecture）を作成する場合 — ユーザーガイドは、それらをもとに作成する外部向けヘルプであり、契約そのものではありません。

入力

計画から渡されたすべてのドキュメント、つまり depends_on セット（上流ドキュメントのうち、このドキュメントに関係するとディスカバリーで判断されたもの）を読み、各ハウツーとセクションを、それぞれの根拠となるドキュメントまでたどってください。一般的な上流ドキュメントは、feature-spec（ガイドで説明する動作）、user-flows（各ハウツーで説明するタスクの流れ）、wireframes（手順で参照する画面）です。該当する場合は、PRD（何を、なぜ）、design-system（UI の用語。ガイドの語彙を製品に合わせるため、そのコンポーネント名や用語を使用）、api-reference（開発者向け製品の場合）も含めてください。入力が固定だと想定しないでください。この一覧は手法の指針であり、受け取る入力の上限ではありません。狭い入力を1つだけハードコードしてはいけません。

自己完結型で、柔軟に対応できるようにしてください。実際に受け取ったコンテキストだけからガイドを作成します。想定される根拠ドキュメントがない場合（例：wireframes がない場合）は、利用できる情報に基づいて作成し、不足している点を明示的な前提として示してください。不足を補うために、機能、設定、画面、手順を捏造してはいけません。また、利用できる場合は調査機能を使用してください（deep-research 機能、またはそれがなければウェブ検索）。テンプレートを埋めるだけでなく、確立されたエンドユーザー向けドキュメントの実践（Diátaxis、タスク指向の簡潔さ、平易な言葉のガイドライン、テキスト形式のヘルプに関する WCAG、信頼できるドキュメントスタイルガイド）に基づいて、ガイドを網羅的なものにします。

**反復（改訂）時：**フローから渡されるのは、既存のガイド＋変更リクエスト＋変更された上流ドキュメントです。全面的な書き直しではなく、ステップ9（改訂）を実行してください。入力の契約は同じです。

ワークフロー

**まずテンプレートツールを使って構成を作成してください。**下書きを始める前に、コンテンツテンプレートツール（content-template-gateway 機能、またはインストール済みのテンプレートプロバイダー）から、ユーザーガイドのセクション構成を取得してください。テンプレートが用意するのは、セクションの枠です。導入／概要、はじめにのチュートリアル、ハウツーガイド、概念の説明、機能／設定リファレンス、トラブルシューティング／FAQ、用語集、バージョニングと変更履歴／改訂履歴のセクション（改訂時にガイド自体のドキュメントバージョンを記録するため）、前提の提示欄が含まれます。競合するアウトラインをハードコードしてはいけません。このスキルでは、テンプレートの枠を根拠に基づいた内容で埋めます。枠を再定義するものではありません。不明なドキュメント作成の慣例を確認する際は、調査機能を使用してください。

ステップ1：ユーザーの目標を列挙する — 目標ごとにハウツーを1つ作成し、孤立した項目を残さない

渡された上流ドキュメントからユーザーの目標を列挙します。user-flows がある場合はそこから（各フローがユーザーの目標／作業です）、なければ feature-spec / PRD から目標を抽出します。目標ごとに、タスク指向のハウツーを必ず1つだけ作成してください。すべての目標にハウツーがあり、すべてのハウツーが目標に対応している状態にします。これが「孤立項目なし」のカバレッジルールです。入力に user-flows が含まれているとは限らないため、実際に受け取った上流ドキュメントから目標を抽出し、柔軟に対応してください。

ステップ2：はじめにのチュートリアルは、確実に成功する一本道として作成する

チュートリアルは、実際に操作しながら学ぶ1つのレッスンです。経路は1つだけにし、選択肢や代替手順を入れず、すべてのステップで目に見える結果が得られるようにします。成功させる責任は作成者にあります。「なぜ」は概念説明のセクションに回し、失敗時の分岐はすべてトラブルシューティングに移してください。分岐したり失敗したりするチュートリアルは、チュートリアルとはいえません。新しいユーザーが最初に達成できる意味のある成功を選び、手順数を最小限に抑えてください（「製品を開く」から「最初に目に見える成功」を得るまでの前提条件や判断をできるだけ減らします）。

ステップ3：各ハウツーは命令形の番号付き手順で書く — 概念を羅列しない

各ハウツーでは、すでに基本を理解しているユーザーが、1つの目標を達成できるようにします。見出しにはタスクを示す表現を使い、基本形の動詞で記述してください。確立されたドキュメントスタイルの作法に従い、番号付きの手順を1ステップにつき1つの操作で書きます（長くなるステップは分割してください）。二人称、現在形、命令形／能動態を使用します。成功までの手順を説明し、失敗した場合はトラブルシューティングを参照するよう案内してください。ハウツーを散文や概念説明として書くことは、Diátaxis で最もよく見られる欠陥の1つです。必ず手順形式にしてください。

ステップ 4：手順を含めず、網羅的なリファレンスを添えて解説を書く

• 解説では、メンタルモデルと「なぜそうするのか」を説明します。手順は含めず、概念に基づいて操作する方法を説明するガイドやリファレンスに相互リンクします。ユーザーが本当に必要とする概念に絞り、内部アーキテクチャの紹介に終始しないようにします。
• 機能／設定リファレンスは、中立的かつ事実に基づき、エンドユーザー向け製品の機能を網羅します。すべての機能、設定、CLI コマンド／ショートカットを含めます。操作方法ではなく説明を記載し、ユーザーが製品とガイドの両方で同じ構成をたどれるよう、構成を製品に合わせます。これは製品リファレンスであり、HTTP API エンドポイントのカタログではありません。

ステップ 5：既知のエラー状態をもとにトラブルシューティングを作成する

トラブルシューティングの一覧は、ユーザーフローのエラー／復旧パスと機能仕様のエラー処理をもとに作成します。既知のエラー状態はすべて項目にします。内部原因ではなく、ユーザーに見える症状ごとに整理します。各項目では、症状から原因、対処法の順に説明し、対処法は番号付きの手順にします。エラーメッセージやコードがある場合は、それも記載します。繰り返し寄せられる質問に対応する FAQ と、「さらにサポートを受ける」ための案内も追加します。チュートリアルや操作ガイドでは意図的に扱わない、エラーに関する情報はここに記載します。

ステップ 6：コントロールは正確なラベルで示し、画面は文章で説明する

成果物は Markdown テキストです。スクリーンショットを埋め込むのではなく、画面を文章で説明し、ワイヤーフレームにリンクします。すべてのコントロールは、製品画面に表示されている正確な UI ラベルで示します。デザインシステムにコンポーネント名や用語がある場合は、それを常に同じように使用します。こうすることで、ユーザーが手順を画面上で見つけられます（ボタンの表示が「適用」なのに手順に「保存をクリック」と書かれていると、技術に詳しくないユーザーは先に進めません）。コマンドや設定の内容はフェンス付きコードブロックに記載します。

ステップ 7：平易な言葉で書き、誰もが理解できるガイドにする

• 平易な言葉（技術に詳しくない読者向け）。 まず目的を示し、短い文を使い、日常的な言葉を選びます。製品固有の用語や略語は、初めて使うときにすべて説明し、用語集にもまとめます。説明のない略語は使いません。読みやすさのスコアではなく、実際のユーザーが内容に沿って操作できるかどうかを基準に、幅広い読者が理解できるレベルを目指します。
• アクセシビリティ（テキスト形式のヘルプ資料向け）。 コントロールはラベルで示し、色だけ（「緑のボタン」）や位置だけ（「右側のボタン」）で示すことは避けます。リンクには、「ここをクリック」ではなく、リンク先が分かる意味のあるテキストを付けます。見出しの階層を飛ばさず、順番に並べます。ワイヤーフレームを見られない読者にも内容が伝わるよう、説明する画面を記述します（代替テキストの意図）。ピクセル単位のコントラストやフォーカスの表示は、レンダリング後のドキュメントサイト／デザインシステムで対応するものであり、このテキスト資料で扱うものではありません。

ステップ 8：「まずここから」を示し、すべての手順を追跡可能にし、不足情報は前提として明示する

• 見つけやすさ。 §1 に**「まずここから」の案内**を設け、初めて読む人にはチュートリアルを、特定の作業をしたい人には対応する操作ガイドを、情報を調べたい人にはリファレンスを、困っている人にはトラブルシューティングを案内します。製品をまだ知らない読者でも、自分に合った入口を見つけられるようにします。
• 正確さ。 各手順を、機能仕様（または提供された他の上流資料）の挙動に照らして確認します。上流資料の情報が不十分または存在しない場合は、採用した前提を明示し、レビュー担当者が異議を唱えられるようにします。未解決の疑問は未解決の質問として列挙します。機能、設定、手順を勝手に作り出し、手順の中に紛れ込ませてはいけません。

ステップ 9：改訂時 — 変更範囲を定め、古くなった記述を洗い出し、一貫性を取り戻す

既存のガイド、変更リクエスト、変更された上流資料を受け取ったら、書き直すのではなく編集します。

1. 変更単位（操作手順／リファレンス項目／はじめにのステップ／画面の説明／トラブルシューティング項目／用語集の用語／説明上の主張）を特定します。
2. 上流資料の古さを洗い出します（最も重要な作業です）。 変更・削除・名称変更された機能ごとに、それを参照していたガイド内のすべての箇所を探します。すべてのモード（手順、リファレンス項目、画面／ワイヤーフレームへのリンク、トラブルシューティング、用語集、説明）を対象に、製品の現状に合うように修正します。削除・名称変更された機能を説明する手順を残すことは、最も影響の大きい欠陥です（古い記述による捏造）。
3. 内部の一貫性を取り戻します。 新しい動作でもチュートリアルを最初から最後まで実行でき、各モードの種類が保たれ、リファレンスが製品を正しく反映し、相互リンクと用語集が維持されていることを確認します。
4. バージョンと変更履歴。 ガイド独自の Doc バージョンを更新し、変更内容、時期、理由を記した変更履歴を追加します。製品バージョンやスキルのセマンティックバージョニングとは別に管理します。
5. 置き換え・削除された機能を明示します。 削除された機能の操作手順は削除するか、置き換え先を記してマークします。名称変更された設定は、検索するユーザーのために旧名称を一度記載し、その後は使わないようにします。ユーザーガイドはリーフであり、その下流に派生ドキュメントはありません。

ステップ 10：引き渡し前に、以下の使いやすさ・正確さの基準に照らして自己確認する

品質基準（12 項目の自己確認）を実施します。レビューに回す前に、見落としをすべて修正します。各手法の詳細は references/method-depth.md にあります。

ルール

必ず守るルール（違反禁止）：

• 組み立て、重複させない。 セクション構成はテンプレートツールに従います。このスキル独自の構成案を追加してはいけません。
• 導き出し、創作しない。 すべての手順は、提供された上流資料に記載された動作に基づくものとします。不足している上流情報は、補完のために捏造せず、明示的な仮定として示します。
• 目標ごとに操作手順を 1 つ設け、孤立させない。 提供された上流資料にあるすべてのユーザー目標に操作手順を用意します。目標は、ユーザーフローがある場合はそこから、ない場合は機能仕様書／PRD から導きます。
• Diataxis の 4 つのモードを明確に分ける。 チュートリアル、操作手順、説明、リファレンスをそれぞれ別の種類として正しく扱い、混同してはいけません（概念の羅列を操作手順にしたり、説明をチュートリアルに埋め込んだりしないでください）。
• エンドユーザー向けにし、製品を参照する。 ガイドはエンドユーザー向けです。リファレンスの対象は製品の機能、設定、コマンドであり、HTTP／SDK API ではありません。
• 平易な言葉を使い、最初からアクセシビリティに配慮する。 専門用語や略語は初出時に定義します。操作部は色や位置だけで示さず、ラベル名で示します。リンクには内容がわかるテキストを付けます。
• 改訂は範囲を定め、網羅的に洗い出し、バージョン管理する差分です。 影響を受ける単位を編集し、変更された機能への古い参照をすべて洗い出し、一貫性を取り戻し、バージョンと変更履歴を更新し、置き換えられた機能を明示します。何も記録せずにその場で書き換えてはいけません。

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

• 手順の構成：番号付きステップにし、各ステップに 1 つの操作を記載します。二人称、現在形、命令形を使い、タスクを示す見出しを付けます。
• タスクを優先した簡潔さを保ちます。ユーザーの実際の作業に沿って、行動を先に示します。タスクに役立たない記述は削除します（エラーは、トラブルシューティングで活用できる学びの機会です）。
• 製品の目標や機能の範囲に応じた分量にします。水増しも過度な短縮もしません。

注意点

• 手順ではなく、概念を羅列している。 詳細に見えても、ユーザーが知りたかった手順が埋もれてしまいます。手順書は命令形の番号付き手順で構成し、「なぜ」は解説に記載します。
• 分岐したり、失敗したりするチュートリアル。 分岐や失敗の経路がある入門レッスンは、チュートリアルではありません。実際には、手順書かトラブルシューティングを装ったものです。必ず成功する一本道にし、失敗時の対応はトラブルシューティングに記載します。
• 不完全なリファレンス。 「明らかに見える」設定やコマンドを省くと、ユーザーが情報を調べられなくなります。リファレンスでは、製品の機能全体を網羅する必要があります。
• 正しくないコントロール名を使った手順。 ボタンの表示が「Apply」なのに「Save」をクリックするよう書かれていると、技術に詳しくないユーザーは先に進めません。コントロールは、製品やデザインシステムで使われている正確なラベルで示します。
• 説明のない専門用語／略語だけの記載。 正確でも、技術に詳しくない読者には理解できません。初出時に定義し、用語集にも記載します。
• 色や位置だけに頼った指示。 「緑色のボタンをクリック」や「右側にあるもの」といった指示は、色を認識できない読者や画面レイアウトが見えない読者には役立ちません。コントロール名を示します。
• 情報の乏しい上流資料から手順をでっち上げる。 上流資料に記載がない場合に、製品が実際に行うとは限らない手順を作り出すのは、隠れた欠陥です。前提事項として不足を明示します。
• 製品変更後の更新漏れ。 削除または名称変更された機能について説明する手順、リファレンス、用語集の項目は、古い情報をもとにした捏造です。修正時の陳腐化チェックですべてのモードにおける記載を漏れなく確認する必要があります。
• スクリーンショットを埋め込む。 Markdown にはバイナリアセットを含められません。画面を文章で説明し、ワイヤーフレームにリンクします。実際のスクリーンショットは、将来的なバックエンドの課題です。
• リファレンスと API カタログを混同する。 エンドユーザー向けの機能／設定リファレンスは、HTTP／SDK エンドポイントのリファレンス（authoring-api-reference）ではありません。

アンチパターン

• 「セクション一覧は自分でドキュメントに書き込もう。」 テンプレートと内容が重複し、テンプレートとのずれが生じます。必ずテンプレートツールから構成を組み立てます。
• 「大きなウォークスルー1つですべてを説明しよう。」 チュートリアル、手順書、解説、リファレンスを1つの説明にまとめることは、ドキュメントがわかりにくくなる最大の原因です。それぞれのモードを分けてください。
• 「上流資料に書かれていないから、たぶんこう動くと説明しておこう。」 明示せずに動作を作り出すのではなく、前提事項や未解決の質問として記載します。手順には含めません。
• 「読者は専門用語を理解できるだろう。」 技術に詳しくない読者には理解できません。定義してください。
• 「製品が変わったから、覚えている画面だけ修正しよう。」 全体の陳腐化チェックをしなければ、ほかの古い記載が残ります。すべてのモードを確認してください。
• 「これは開発者向けツールだから、ここに連携／オンボーディングの説明を書こう。」 それは authoring-developer-guide の役割です。このスキルはエンドユーザー向けの製品ヘルプを扱います。
• 「API エンドポイントの表をリファレンスとして埋め込もう。」 リファレンスが扱うのは製品の機能であり、エンドポイントのカタログは authoring-api-reference です。

使いやすさ／正確性の品質基準

ユーザーガイドが完全で、使いやすく、正確であるのは、以下のすべてを満たす場合です（これはレビュー側のゲートで適用されるものと同じ12項目の基準であり、単一の情報源に基づき、同じ番号を付けています）。

1. 目標を網羅 — 目標ごとに1つのハウツーがあり、孤立した項目がない。 提出された上流資料（ユーザーフローがある場合はそれ、なければ機能仕様／PRD）に記載されたすべてのユーザー目標に、ハウツーがちょうど1つ対応しています。すべてのハウツーは、いずれかの目標に対応しています。
2. 4つのディアタクシスモードがすべて揃い、適切に分類されている。 チュートリアル（保証された手順が1つ）、ハウツー（概念の羅列ではなく、命令形の手順）、解説（手順なし）、リファレンス（中立的で、網羅的）を、混同せずに提示しています。
3. エンドユーザー向けの機能／設定リファレンスが完全である。 ユーザー向けの機能、設定、CLI コマンド／ショートカットをすべて記載し、リファレンスが製品を正確に反映しています。（HTTP API ではなく、製品の機能範囲が対象です。）
4. 手順が実際の製品の動作と一致している。UI の用語も含む。 すべての手順が、提出された上流資料の動作と一致しています。存在しない手順、設定、画面を作り出していません。各コントロールは、製品／デザインシステムで使われている正確なラベルで示されています。捏造があれば、重大な不合格です。
5. 手順の仕組みが適切である。 番号付きの手順で、1つの手順につき1つの操作を記載し、二人称、現在形、命令形を用い、タスクに基づく見出し（正確なラベルを使用）を付けています。
6. トラブルシューティングが既知のエラー状態を網羅している。 上流資料にあるエラー／復旧の経路をすべて、ユーザーに見える症状ごとに整理した「症状 → 原因 → 対処」の項目として記載しています。よくある質問は FAQ にまとめ、「さらにサポートを受ける」ための案内もあります。
7. 対象読者が利用できる。 実際のユーザー（通常は技術者ではないユーザー）が、ガイドだけでサポート対象のすべての目標を達成できます。前提条件を明示し、画面の説明とワイヤーフレームへのリンクを用意しています。（言語の分かりやすさは条件10です。この条件は、目標達成／前提条件／画面の説明に関する結果を評価します。ここで専門用語を二重に評価しないでください。）
8. 前提や不足が明示されている。 上流資料が存在しない、または情報が乏しい場合、前提を（異議を唱えられる形で）明示し、黙って補っていません。
9. 改訂が範囲を限定し、全体を確認した、バージョン管理済みの差分である。 改訂時には、変更箇所が基準を満たしています。上流資料の陳腐化に関する確認を完了し、削除または名称変更された機能がどのモードにも残っていません。文書内の一貫性を保ち、改訂履歴を更新し、置き換えられた項目や削除された項目に印を付けています。（グリーンフィールドでの初回作成には適用されません。）
10. 平易な言葉で書かれ、読みやすい。 目的を先に示し、文を短くします。すべての用語／頭字語を初出時に定義し（用語集にまとめ）、説明のない頭字語を残さず、対象読者に合った読みやすさにします。評価基準はスコアではなく、技術者ではない読者が理解できるかどうかです。（条件7とは別の項目です。専門用語や読みやすさの問題は条件10、手順の流れが追えない、または前提条件が欠けている問題は条件7で評価します。）
11. アクセシビリティ（内容に応じた対応）。 意味の分かるリンクテキストを使い（「ここをクリック」のような表記は避け）、見出しを正しく階層化し、色や位置だけに依存する手順を避け、画面の説明には代替テキストで伝えるべき内容を含めています。（リンク／画像／色の手がかりがない場合は適用されません。ピクセルコントラストとフォーカスの表示はデザインシステムの対象であり、ここでは評価しません。）
12. 見つけやすさ／最初に読む場所。 初めて読む人が、文書群の中から「最初に読む場所」と、自分の目標に対応するセクションを見つけられます。（条件1の「目標ごとに整理」と条件2の「モードの適切な分類」とは別の項目です。ここでは、読者がそれらにたどり着けるかを評価します。1ページのガイドでは自明に満たされます。条件1または条件2ですでに捉えた不備を二重に減点しないでください。）

出力

ツールの構成に合わせたテンプレートを用いて作成する、エンドユーザー向けの Markdown ユーザーガイドです。導入／概要（最初に読む場所への案内と、平易な言葉遣い／アクセシビリティに関する方針を含む）、利用を開始するためのチュートリアル（確実に成功する手順を1つ）、ユーザーの各目標に対応するタスク指向の手順（命令形の番号付き手順）、概念の説明（手順なし）、エンドユーザー向けの機能／設定リファレンス（HTTP API ではなく、製品の機能、設定、CLI コマンド）、既知のエラー状態に基づくトラブルシューティング／FAQ、用語集、バージョニングと変更履歴／改訂履歴のセクション（ガイド自体のドキュメントバージョン）、および前提と未解決の質問を記載します。画面は文章とワイヤーフレームへのリンクで説明し、コマンド／設定はフェンス付きコードブロックで示します。コントロールは正確なラベル名で記載します。改訂時の出力は、範囲を限定したバージョン付きの差分と、更新された改訂履歴であり、全面的な書き直しではありません。この成果物は、レビュー側のゲート（上記の12条件の基準に照らして評価）で確認され、最終的には、実際のユーザーがサポート対象のすべての目標を達成するために使用します。この手法と基準は媒体に依存しません。将来、ドキュメントプラットフォームやスクリーンショットを多用するバックエンドが登場しても変わるのは表示方法（画面の見せ方）だけであり、導出方法や基準は変わりません。

関連項目

• テンプレートプロバイダー（content-template-gateway capability） — このスキルが構成に用いるユーザーガイドのセクション構成を提供します。ここでは重複して記載しません。
• リサーチ機能（deep-research、利用できない場合はウェブ検索） — ドキュメントの方針（Diataxis、ミニマリズム、平易な言葉遣い、ドキュメント向け WCAG、スタイルガイド）と、導出の根拠を明らかにします。
• 上流入力 — 渡された depends_on セット。 通常は機能仕様、ユーザーフロー、ワイヤーフレーム（利用可能な場合は PRD／デザインシステム／API リファレンスも含む）です。白紙の状態から作成することはありません。
• reviewing-user-guide — 同じ12条件のユーザビリティ／正確性基準を検証する、レビュー側のゲートです。作成側とレビュー側は単一の情報源を共有します。
• authoring-developer-guide — 開発者ツールの導入／統合に関する説明を担う兄弟スキルです。このスキルはエンドユーザー向けの製品ヘルプであり、役割が異なります。
• authoring-api-reference — HTTP／SDK エンドポイントのカタログを担う兄弟スキルです。このスキルのリファレンスはエンドユーザー向けの製品機能を扱い、役割が異なります。

段階的な情報開示

• references/method-depth.md — 手法の詳細です。平易な言葉遣い／読みやすさに関する方針、テキスト形式の成果物に対する WCAG 準拠のアクセシビリティチェック、情報アーキテクチャ／最初に読む場所から始まる読者の導線、UI 用語の統一、タスク指向のミニマリズム、改訂時の陳腐化箇所の一括確認手順を説明します。詳しく知りたいセクションを作成するときに読み込んでください。
• references/sources.md — セクション構成、Diataxis に基づく作成方法、ユーザビリティ／正確性基準の調査根拠です。記述の根拠を確認するときに読み込んでください。

本文の上限

• description は1,024文字以下（agentskills.io の上限）。
• 本文は約500行／5,000トークン以下に抑え、毎ターンのコンテキストに含めます。
• 各リファレンスファイルは10kトークンを超える場合に警告し、25kを超える場合はエラーとします。

変更履歴

• 1.1.0（2026-06-15）— 本番品質に向けて構成を再編しました。12条件の基準を単一の情報源に統合しました（条件9「改訂」、条件10「平易な言葉遣い」、条件11「アクセシビリティ」、条件12「見つけやすさ」を追加し、条件4／5の UI 用語に関する内容を拡充し、専門用語に関する条項を条件7から条件10に移行）。ステップ6（正確なラベル）／ステップ7（平易な言葉遣い＋アクセシビリティ）／ステップ8（最初に読む場所）／ステップ9（改訂）を追加し、references/method-depth.md を追加しました。追加的な変更であり、入力契約と基準の骨子に変更はありません。（1.0.0 → 1.1.0。）