reviewing-user-guide

reviewing-user-guide — SKILL.md

バリアント： standard · 使用するタイミング： 完成したエンドユーザーガイドを受け入れ判定の基準として評価するとき — 実際のユーザーが、単一の情報源に基づく12項目の基準をすべて満たし、サポート対象のすべての目標を達成できるかを確認し、実行可能な指摘事項とともに VERDICT: approve|revise を出力します。

概要

このスキルは、エンドユーザーガイドを作成する側と評価する側のペアのうち、レビューを担います。完成したエンドユーザーガイド（製品を使う人が目標を達成するために読む、利用者向けのヘルプ。通常は技術者以外を対象とするもので、スタートガイドのチュートリアル、タスク指向のハウツーガイド、概念の説明、エンドユーザー向けの機能／設定リファレンス、トラブルシューティング／FAQ、用語集など）を持つレビュアーが読み込み、次の1つの問いに照らしてガイドを評価します。製品の実際のユーザーは、著者に質問することなく、このガイドだけを使ってサポート対象のすべての目標を達成できますか。また、手順は製品の実際の動作に沿っており、技術者以外の読者にも理解できる言葉で書かれていますか。 固定のユーザビリティと正確性に関する12項目のチェックリストを適用します。ユーザーガイドの著者が従う基準と同じであり、作成側の基準とレビュー側の基準にずれが生じないよう、単一の情報源に基づいて同じ番号で定義されています。その後、機械で解析可能な単一の判定と、著者が1回の改訂で対応できる指摘事項を出力します。評価対象は、テキスト形式の Markdown 成果物（本文、コードフェンス付きのスニペット、ワイヤーフレームへのリンクとともに文章で説明された画面）であり、レンダリングされたヘルプサイトではありません。この方法と基準は、媒体に依存しません。これは受け入れ判定のゲートであり、ガイドの作成、修正、書き換えは行いません。評価して指摘事項を返し、作成者が改訂します。

有効化するタイミング

• 完成したエンドユーザーガイドの公開前に、承認／修正の判定が必要な場合。
• 作成者が直前に作成したエンドユーザーガイドについて、独立したレビュアー／ゲート担当者として評価する場合。
• 前回の判定が revise だったエンドユーザーガイドの改訂版を再評価する場合。
• 公開済みガイドに上流の変更を反映したバージョン管理済みの差分である amend をレビューする場合（差分の範囲に限定して評価します。cond-9）。

次の場合は有効化しないでください：

• エンドユーザーガイドを作成または修復する場合 → ユーザーガイド作成スキルを使用してください（このスキルが定めるものと同じ基準に沿って作成します）。このスキルがガイドを書くことはありません。
• 開発者向け導入／統合ガイド（開発者がツールを統合するために読む、SDK、ライブラリ、CLI、フレームワーク、API プラットフォームのオンボーディング解説）をレビューする場合 → 開発者ガイドのレビュー用スキルを使用してください。このゲートが評価するのは開発者向けの導入であり、このゲートが評価するのはエンドユーザー向け製品のガイドです。
• API リファレンス（開発者向けの HTTP／SDK エンドポイントカタログ。エンドポイント、フィールド、エラー、契約との整合性を記載）をレビューする場合 → API リファレンスのレビュー用スキルを使用してください。そのゲートが評価するのは契約との整合性であり、エンドユーザーにとっての使いやすさではありません。ここでいうエンドユーザー向けリファレンスは製品の表面（機能、設定、CLI コマンド）であり、HTTP API ではありません。
• エンジニアリング設計ドキュメント（アーキテクチャ仕様書、設計ドキュメント、ADR、RFC）をレビューする場合 → 設計レビュー用スキルを使用して、設計に関する主張をコードベースと照合してください。別のゲートであり、別の基準です。
• テンプレート／セクションへの準拠を確認する場合 → これはテンプレートに関する事項です。このスキルは、見出しがすべて存在するかではなく、基準に照らした品質を評価します。

ワークフロー

Step 1: ガイド全体を先入観なく独立した視点で読み、上流ドキュメントを確認します

対象となるユーザー（通常は技術に詳しくないユーザー）になったつもりで、作者の説明に頼らず、ガイドを最初から最後まで読んでください。あなたの立場はユーザーのための門番です。指摘に重みがあるのは、ガイドの記載どおりではユーザーがサポートされている目標を達成できないことが実際に示されている場合、または手順が製品と一致せず、ユーザーを誤った方向へ導く場合に限られます。

次に、ガイドの作成元となった提供済みの上流ドキュメント、つまり depends_on のセットを特定します（通常は機能仕様、ユーザーフロー、ワイヤーフレームのいずれかまたは複数です。PRDのみの場合や、UI用語のデザインシステムが含まれる場合もあります）。ユーザーフローがある場合は、ユーザーフローからユーザーの目標を列挙します（各フローがユーザーの目標／作業です）。**ユーザーフローがない場合は、機能仕様／PRDから目標を抽出します。**実際に提供された上流ドキュメントに照らして網羅性を判断してください。ユーザーフローが必ずあると思い込んではいけません。想定される上流ドキュメントがない場合は、そのことをレビュー時の前提として記載します。上流ドキュメントが裏付けていない目標を作り上げたり、プロジェクトで作成されていないドキュメントを理由にガイドを批判したりしないでください。

修正モード（入力シグナルで判定）：既存のガイド、変更依頼、変更された上流ドキュメントが渡された場合は、全体を再レビューするのではなく、cond-9に基づいて変更差分を評価します。

Step 2: ユーザビリティと正確性に関する12項目のチェックリストを実施し、各項目を判定します

以下の各項目について、合格またはギャップありを判定してください。項目を不合格とするのは、実際に確認できる明確な不備がある場合のみです。「別の表現のほうがよい」というだけではギャップになりません。ギャップごとに、正確な箇所と不足している内容を記録してください（Step 4で、対応可能な指摘事項にまとめます）。各項目は、唯一の基準となるチェック項目です（作者のStep-10自己チェックと内容・番号が同一です）。独自の項目を追加しないでください。

1. 目標の網羅性 — 各目標にハウツーを1つ用意し、孤立した項目をなくす。 提出された上流資料から列挙されたすべてのユーザー目標（Step 1）に、タスク指向のハウツーが1つずつ対応しており、すべてのハウツーが目標に紐づいています。目標にハウツーがない場合（網羅性の欠落）、または上流資料に目標がないのにハウツーがある場合（機能を創作した可能性を示す孤立項目）は、ギャップです。
2. 4つのDiataxisモードがすべて存在し、正しく分類されている。 チュートリアル、ハウツー、解説、リファレンスがすべて存在し、混同されていません。チュートリアルは、確実に完了できる一本道（選択肢や失敗分岐がなく、すべてのステップで目に見える結果が得られるもの）です。ハウツーは、命令形の番号付き手順です（概念の羅列ではありません）。解説には手順がありません。リファレンスは中立的で、完全です。モードが欠けている場合や、別のモードとして書かれている場合は、ギャップです。たとえば、概念の羅列で水増しされたハウツー、手順が紛れ込んだ解説、代替案に分岐するチュートリアルなどです。（モードの混在は、ドキュメントの混乱を招く最大の原因です。）
3. エンドユーザー向け機能・設定リファレンスが完全である。 製品が公開している、ユーザー向けのすべての機能、設定、CLIコマンド／ショートカットが文書化されています。リファレンスは製品の内容を反映し、使い方を指示するのではなく、説明します。ユーザー向けの機能、設定、コマンドが欠落または古くなっている場合は、ギャップです。（これはエンドユーザー向けの製品機能であり、HTTP APIではありません。エンドポイントが記載されていないことを問題にしないでください。）
4. 手順が実際の製品の動作に合致している — UIの用語も含む。 すべての手順が提出された上流資料にある動作と一致しています（機能仕様／ユーザーフローと照合して抜き取り確認済み）。創作された手順、設定、画面、メニューがなく、各コントロールは製品／デザインシステムで使われている正確なラベルで示されています。（製品にないコントロールを示す手順や、誤ったラベルで示す手順は、正確性のギャップです。）上流資料の動作に反する手順、根拠となる上流資料がない機能／画面の捏造、または製品と一致しないラベルは、ギャップです。捏造は重大な不合格です。
5. 手順の仕組みが適切である。 ハウツーとチュートリアルでは、番号付き手順を使い、1つの手順につき1つの操作、二人称、現在形、命令形、タスクを示す見出し（動詞の原形。例：「アカウントを追加する」）を用い、コントロールは正確なラベルで示します。手順が番号なしの文章の塊になっている、1つの手順に複数の操作をまとめている、またはタスクを示す見出しではなく名詞句や機能名を見出しにしている場合は、ギャップです。
6. 既知のエラー状態をトラブルシューティングで網羅している。 提出された上流資料にあるすべてのエラー／復旧パス（ユーザーフローのエラー／復旧パスと、機能仕様のエラー処理）が、ユーザーに見える症状ごとに整理された症状 → 原因 → 解決方法の項目として記載されています。よくある質問はFAQにまとめられ、「さらにサポートを受ける」ための案内があります。既知のエラー状態が文書化されていない場合や、項目がユーザーに見える症状ではなく内部的な原因ごとに整理されている場合は、ギャップです。
7. 対象読者が使いやすい。 実際のユーザー（通常は技術者ではない人）が、著者に質問することなく、ガイドだけでサポート対象のすべての目標を達成できるようになっています。前提条件が明記され、画面は説明文で示され、ワイヤーフレームへのリンクがあり、読者が画面を見ていることを前提としていません。あいまいな点、前提条件の欠落、未定義の手順により、作業の途中でユーザーが行き詰まる場合は、ギャップです。(言葉のわかりやすさ — 専門用語／読みやすさ — は条件10で評価し、ここでは二重に評価しないでください。この条件では、目標の達成、前提条件、画面の説明という観点で評価します。)
8. 前提やギャップを明示している。 上流資料がなかったり情報が乏しかったりする場合、ガイドで置いた前提を明記し、異議を唱えられる状態にしています。上流資料で答えが得られない内容を、前提として明示せず、完全に見せるために捏造した場合は、ギャップです。
9. 改訂は対象を限定し、全体を点検した、バージョン管理された差分である（新規作成では該当なし）。改訂では、変更対象が基準を満たしています。上流資料の陳腐化点検が完了しており、変更／削除／名称変更された機能が、古い手順、リファレンス項目、画面リンク、トラブルシューティング項目、用語集の用語に残っていません（すべての参照箇所を探す構造的な確認）。内部の一貫性が保たれ（チュートリアルを引き続き完了でき、モードが正しく分類され、リファレンスが引き続き製品を反映している）、改訂履歴が更新され、置き換え／削除された項目にその旨が示されています。点検が不完全で古い記述が残っている場合、一貫性が損なわれている場合、変更履歴がない場合、または削除項目に印がない場合は、ギャップです。既存ガイド、変更リクエスト、変更された上流資料という入力から検出します。
10. 平易な言葉／読みやすさ。 技術者ではない読者がガイドに従えます。目的を先に示し、文の長さが適切で、製品固有の用語と略語は初出時にすべて定義し（用語集にも収録し）、説明のない略語がなく、対象読者に合った難易度になっています。読みやすさのスコアではなく、結果（実際のユーザーが読んで理解できるか）で評価します。説明のない専門用語や、定義のない略語により、技術者ではない読者が手順の途中で行き詰まる場合は、ギャップです。(重複評価の防止：専門用語／読みやすさの問題は条件10、手順の流れを追えない／前提条件が足りない問題は条件7です。同じ問題を両方で減点しないでください。)
11. アクセシビリティ（規模に応じた評価）。 テキスト形式の成果物では、リンクテキストに意味があり（「ここをクリック」のような単独の表現がなく）、見出しが正しく入れ子になっており（レベルを飛ばさず）、色だけ（「緑のボタンをクリック」）や位置だけ（「右側のボタン」）に依存する手順がありません。コントロールはラベルで示し、説明する画面には代替テキストの意図を記載します。手掛かりを認識できない読者の妨げとなる、リンクテキストの不備、色だけに依存する指示、位置だけに依存する指示は、ギャップです。(規模に応じた評価 — リンク／画像／色の手掛かりがない場合は該当なしです。ピクセルのコントラストとフォーカスの表示は、サイトのレンダリング／デザインシステムに関するものであり、ここでは評価しません。)
12. 見つけやすさ／最初に読む場所。 初めて読む人が、製品を知らなくても、ドキュメント一式から最初に読む場所（チュートリアル）と、自分の目標に対応するセクションを見つけられます（セクション1に案内があり、移動しやすい構成になっています）。最初に読む場所の案内がなく、どのドキュメントが質問への答えになるのか読者にわからない場合は、ギャップです。(重複評価の防止：条件1の「目標ごとの構成 — 網羅性」と条件2の「モードの分類」とは、意味が重ならないようにしてください。1ページのガイドでは自明に満たされます。条件1／2ですでに検出された問題を、条件12を理由に修正しないでください。) 比例性。「利用者があらゆる目標を達成できること」は、製品の規模に応じて判断します。小規模な製品のガイドで、不要なセクションを正当に省略し、いくつかのハウツーだけを掲載するのは、適切な規模であり、抜けではありません。小規模なガイドには、修正する内容がない（初回ビルドでは cond-9 は該当なし）、定義すべき専門用語がない（cond-10 は問題なく合格）、画像や色による手がかりがない（cond-11 は該当なし）、そして簡単に見つけられる（cond-12）ことも正当にあり得ます。セクション数や語数ではなく、上流の情報源に実際に含まれる目標の網羅性＋正確さ＋技術に詳しくない読者が理解できることを基準に評価してください。該当する条件をすべて満たす、小規模でも完全なガイドは合格です。簡潔さを理由に、存在しない抜けを作り出してはいけません。（条件 1 の最低基準は、どの規模でも変わりません。上流の情報源に含まれる目標には、ハウツーが必要です。）

ステップ 3：判定を決める

• approve — 該当する条件をすべて満たしています。実際の（技術に詳しくない）ユーザーが、記載されたガイドを使って、サポート対象のあらゆる目標を達成できます。モードの分類は正しく、手順は製品に即しており、コントロールの名称も正確で、内容を理解できます。言い回しを改善できると思える場合でも承認してください。基準は使いやすさと正確さであり、完璧さでも、最大限の網羅性でもありません。
• revise — 1 つ以上の条件に、ユーザーの妨げとなる具体的な抜けがあります（目標に対応するハウツーがない、Diataxis のモードが混同されている／誤分類されている、リファレンスが不完全、手順が創作されている／不正確／誤ったラベルが付いている、既知のエラー状態が文書化されていない、修正時の古くなった記述の確認が不完全、専門用語の説明がない、色や場所だけを頼りにした指示になっている、読者がそこから進める「まずはこちら」がない、など）。

努力を示したり、あるとよいだけの要望を出したりするために修正を求めてはいけません。条件は、満たされているか、満たされていないかのどちらかです。

ステップ 4：判定と実行可能な指摘を出力する

判定は、独立した 1 行にそのまま VERDICT: approve または VERDICT: revise と出力します。コードフェンス、引用符、その他の語句で囲んではいけません（ここにあるフェンスは説明用です）。

VERDICT: approve

続く行には、指摘事項を列挙します。revise の場合、各指摘は実行可能でなければなりません。該当する条件（番号）、正確な箇所、修正方法を示し、著者が一度の作業で解決できるようにしてください。approve の場合、指摘は必須ではありません。記載する場合も、修正が必要だと受け取られる内容にしてはいけません。

良い指摘は、抜けと修正方法を明確に示します。

revise — 目標の網羅性（条件 1）：ユーザーフローには「パスワードをリセットする」という目標がありますが、ガイドにそのハウツーがありません。修正：フローの通常の手順に沿って、タスク指向の「パスワードをリセットする」ハウツーを追加してください（番号付き手順にします）。

revise — 平易な言葉（条件 10）、「SSO を設定する」ハウツー：ステップ 2 に「SAML メタデータで IdP をプロビジョニングする」とありますが、技術に詳しくない読者向けに IdP／SAML の説明がありません。修正：IdP と SAML を初出時および用語集で定義するか、手順を平易な言葉で言い換えてください。

悪い指摘は、曖昧で実行に移せません。

ガイドをもっと分かりやすくできるかもしれません。 (どの目標か、どのモードか、どのステップか、どう修正するのかが不明です。)

ルール

必ず守るルール（決して違反しないでください）：

• 判定行をちょうど1行出力してください。VERDICT: approve または VERDICT: revise のいずれかを、それだけを記した行にしてください。 下流のツールがこの行を解析します。
• 評価に徹し、執筆はしないでください。 指摘事項を返してください。ガイドを書き直したり、修正したり、内容を補完したりしないでください。修正は作成者が行います。
• 評価基準は単一のものを使ってください。 ステップ2の12項目（作成者がガイドを作成する際に用いるものと同じ基準）に照らして評価してください。条件を独自に追加したり、より厳しい基準を適用したりしないでください。
• 誤った revise 判定を避けてください。 該当する条件をすべて満たしているガイドは、たとえ小規模な製品向けで内容が簡潔でも承認してください。目標を満たしているなら、規模に応じた内容量は欠陥ではありません。実在する、具体的な不足がある場合に限り、修正を求めてください。
• 誤った approve 判定を避けてください。 迎合するために、実際の不足を見過ごして承認してはいけません。重大な不足があれば revise としてください。
• 重複評価を防ぐ2つのルールを守ってください。 二重に減点しないでください。専門用語や読みやすさの問題は条件10で扱い（条件7では扱いません）、ナビゲーションや見つけやすさの問題は条件12で扱います（条件1または条件2では扱いません）。1つの欠陥は、その欠陥を扱う条件のもとで1つの指摘として報告してください。
• 提供された上流資料から目標を洗い出してください。 目標は、ユーザーフローがある場合はユーザーフローから、ない場合は機能仕様書／PRDから抽出してください。ユーザーフローが常にあると想定してはいけません。未作成の上流資料がないことを理由に修正を求めてはいけません。不在であることは前提として指摘してください。一方、提供された上流資料を無視したガイド（提出されたユーザーフローの目標に対する手順がない、または提出された機能仕様書の内容と手順が矛盾するなど）は、正当な指摘対象です。
• 評価対象はHTTP APIではなく、エンドユーザーが利用する製品の機能です。 製品が提供する機能、設定、CLIコマンドを対象に網羅性を評価してください（条件3）。エンドポイントが省略されていることを問題にしてはいけません。
• 捏造は重大な不合格要因です。 上流資料に根拠のない手順、設定、画面、機能を追加すると、条件4に違反します。実際に不足している情報は、架空の手順で補うのではなく、前提として指摘してください（条件8）。改訂後に削除または名称変更された機能について古い説明が残っている場合も、古い情報による捏造として扱います（条件9）。
• すべての修正指摘を実行可能な内容にしてください。 不合格となった条件、該当箇所、具体的な修正方法を示してください。曖昧な指摘は避けてください。

推奨事項（必要に応じて変更できます）：

• 指摘事項は重大度の高い順に並べ、重大な不足を先に記載してください。
• 作成者が評価基準と照合できるよう、各指摘に条件番号または条件名を記載してください。
• 承認時の注記は少数にとどめ、修正を要しないことが明確に伝わるようにしてください。

注意点

• 使いやすさではなく、項目がそろっているかで承認する。 すべてのセクションがそろっていても、ユーザーが行き詰まることはあります（実際には説明にすぎない手順ガイド、製品と矛盾する手順、具体的な方法のない目標、対象読者には理解できない専門用語など）。テンプレートが埋まっているかではなく、実際のユーザーがすべての目標を達成できるかを判断してください。
• モードの取り違え。 最もよくある不備は、背景説明が3段落続き、手順がない「手順ガイド」（実際には説明）や、分岐する選択肢を提示するチュートリアル（実際には手順ガイド／リファレンス）です。各セクションは、タイトルではなく、実際にどのような内容かを確認してください（条件2）。
• 架空の機能を示す、孤立した手順ガイド。 提出された上流資料に目標がない手順ガイドは、多くの場合、架空の機能や画面が紛れ込んでいることを意味します（条件1＋条件4）。すべての手順ガイドを上流資料の目標までたどって確認してください。
• 誤った操作部を示す手順。 製品のボタン名が「Apply」なのに「Save」をクリックするよう指示すると、技術に詳しくないユーザーは先へ進めません。ラベルの不一致は些細な指摘ではなく、条件4における正確性の欠落です。
• リファレンスと API の混同。 エンドユーザー向けリファレンスに HTTP エンドポイントがないことを指摘したり、エンドユーザー向けリファレンスとしてエンドポイント一覧を認めたりしないでください。エンドユーザー向けリファレンスが扱うのは製品の画面や機能です（条件3）。
• 製品を実際に操作できない状態での手順の正確性。 稼働中の製品をクリックして確認することはできなくても、提出された機能仕様やユーザーフローと各手順を照合することはできます（条件4）。上流資料に根拠のない手順を、仮定と明示せず事実として提示しているなら、それが不備です。
• 症状ではなく原因別に構成されたトラブルシューティング。 トラブルシューティングのセクションに内部エラーコードがすべて列挙されていても、「ページが読み込まれない」という症状しかわからないユーザーの役には立たないことがあります。ユーザーが目にする症状から、原因、解決策の順にたどれる項目にしてください（条件6）。
• 重複する条件で二重に減点する。 説明のない略語1つを条件10と条件7の両方で指摘したり、「最初に読む」案内の不足を条件12と条件1の両方で指摘したりしないでください。不備は1つ、該当条件も1つです。この重複防止策は、それを防ぐためのものです。
• 読みやすさのスコアを合否基準にする。 特定の Flesch-Kincaid スコアや学年相当のレベルを求めないでください。条件10で判断するのは、技術に詳しくない読者が内容を理解できるかどうかであり、スコアではありません（スコアは執筆を補助するものです）。
• 簡素なガイドに対して、アクセシビリティを過度に厳しく求める。 リンクが2つあり、画像のないガイドは、条件11を問題なく満たします。画像がないのに「代替テキストがない」と指摘するのは、誤った修正要求です。条件11はガイドの規模に応じて判断し、ピクセルのコントラストは対象外です（これはデザインシステムが担う役割です）。
• 修正時の全体確認が不完全なまま見逃される。 修正時に1つの画面を更新しただけでは、全体確認を行ったことにはなりません。用語集やトラブルシューティングの項目など、別のモードに古い記述が残っていれば、条件9を満たしません。すべてのモードを確認してください。
• 体系的な過剰指摘（誤った修正要求）。 問題を見つけるよう求められたレビュアーは、適切なガイドまで不備と見なし、過剰に修正を求めがちです。基準に照らして判断してください。条件における不備とするのは、実在する具体的な欠陥が明示できる場合に限り、単に自分なら別の言い回しにするという理由では指摘しないでください。
• 規模に見合ったガイドに対する誤った修正要求。 製品の規模が小さいなら、ガイドも適切に小さくなります。手順ガイドが数本だけ、折りたたみ式のセクション、初稿には変更履歴がない、といった構成は、文書不足ではなく、規模に合わせた設計です。
• ヘルプサイトでないことを理由に、Markdown を指摘する。 成果物はテキスト形式です（画面を文章で説明し、ワイヤーフレームへのリンクを付けます）。ピクセルがないことではなく、説明とリンクを評価してください。
• 判定トークンの揺れ。 「承認済み」、「LGTM」、「要修正」、または段落の途中に埋め込まれた判定では、正しく解析できません。VERDICT: approve|revise をそのまま単独行に出力してください。

アンチパターン

• 承認のスタンプ化。 修正のやり取りを避けるためにざっと目を通して承認すると、モードの誤記、手順の捏造、未確認の修正内容、説明のない専門用語が見過ごされ、ユーザーが行き詰まったり誤解したりする原因になります。
• 細部への過剰な指摘。 言葉の選び方、見出しの好み、必須ではない要望を不足事項として扱い、修正を求めることです。修正は、ユーザビリティや正確性を実際に損なう問題に限ります。
• 無断での書き換え。 「手順を直したほうが簡単だった」――レビュー中に執筆まで行うと、作成と評価の分離が崩れ、執筆者が不足に気づいて学ぶ機会が失われます。
• 条件の捏造。 基準にない独自の要件（「動画も含めるべき／マーケティング向けの導入を入れるべき／特定の読解レベルのスコアを満たすべき」など）を加えることです。評価するのは12の条件だけです。簡潔さ、ナビゲーションカテゴリの品質、代替テキストの手法、セクション構成は、結果に基づいて評価する補助要素であり、要求事項ではありません。
• 上流の期待の捏造。 プロジェクトが作成していない文書にしか記載されていない目標を、ガイドが扱っていないと指摘することです。上流の情報が欠けているのは前提の問題であり、修正理由にはなりません。
• 最大主義。 内容の少ない製品のガイドに、広範なセクション構成すべて（変更履歴や用語集も含む）を要求することです。基準となるのは目標の網羅性、正確性、手順の追いやすさであり、可能な限り最大のガイドではありません。
• 曖昧な判定。 「おおむね承認だが……」や、判定を2行に分けることです。判定は1つだけ、トークンも1つだけにしてください。

出力

エンドユーザー向けガイド1件のレビュー結果を1つ出力します。

• 判定行を1行 — VERDICT: approve または VERDICT: revise を、そのまま単独の行に記載します。
• 指摘事項 — revise の場合、修正を妨げる問題ごとに、実行可能な指摘を1件ずつ記載します（不合格となった条件番号＋場所＋具体的な修正内容）。approve の場合、任意で、承認を妨げない注記を記載できます。

抽象的な利用者は、作成からレビューまでのループを統括するものです。approve は、そのガイドが利用者に提供できる状態であることを認めます。revise は、指摘事項を作成者に返し、範囲を限定した修正作業を依頼します。

関連項目

• user-guide-authoring スキル — この組み合わせにおける作成側のスキルです。このスキルが評価するのと同じ、ユーザビリティと正確性に関する12条件の基準に沿ってガイドを作成します。作成側とレビュー側は同じ情報源を使用します。このスキルは基準を references/usability-bar.md に記載し、作成側はステップ10のセルフチェックで同じ基準を同じ番号で使うため、両者にずれが生じません。
• developer-guide-review スキル — 開発者向けの導入・統合ガイド（SDK／ライブラリ／CLI／フレームワーク／APIプラットフォームのオンボーディング）を評価するためのゲートです。文書も対象読者も異なります。このスキルが評価するのはエンドユーザー向け製品ガイドであり、開発者向けオンボーディングの説明ではありません。
• api-reference-review スキル — 開発者向けHTTP／SDKエンドポイントカタログ（契約の一貫性）を評価するためのゲートです。文書も基準も異なります。ここで評価するエンドユーザー向けリファレンスの対象は、製品の機能であり、APIではありません。
• design-review スキル — エンジニアリング設計文書（アーキテクチャ仕様、設計文書、ADR、RFC）を評価し、コードベースに照らして記述内容を検証するゲートです。ゲートも基準も異なり、エンドユーザー向けガイドには使用しません。
• user-guide template / content-template ツール — セクションの構成を定めます。このスキルが評価するのは、基準に照らした品質であり、構成への準拠ではありません。

段階的な情報開示

• references/usability-bar.md — 12条件の基準を詳しく記載した、唯一の情報源です。各条件の合格／不足を示す兆候と、具体的な指摘例（新設された条件9の修正内容の陳腐化チェック、条件10の平易な言葉、条件11のアクセシビリティ、条件12の見つけやすさ、および条件4／5のUI用語の拡充）、さらに重複を防ぐ2つのガードを含みます。判断が難しい条件を評価する際に読み込んでください。
• references/sources.md — レビュー手法の調査根拠（単一の情報源による品質基準：Diataxisの4つのモード分類、目標ごとのハウツー網羅ルール、手順の仕組みに関する慣例、平易な言葉とドキュメント向けWCAGの根拠、誤った修正要求を避けるための規律を裏付ける、レビュアーの過剰修正に関する根拠）を示します。指針の出典を監査する場合にのみ読み込んでください。

本文の予算

• description は1,024文字以下にしてください（agentskills.io の上限）。Claude は、一覧表示で description と when_to_use の合計が1,536文字を超えると切り捨てます。
• 本文は約500行／5,000トークン以下にしてください。毎ターン、コンテキスト内に保持されます。
• 参照ファイルごとに、10kトークンを超えると警告、25kトークンを超えるとエラーになります。参照ファイルの合計は、25kトークンを超えると警告、50kトークンを超えるとエラーになります。

変更履歴

• 1.1.0 (2026-06-15) — 本番環境向けに再構成：12条件の基準を単一の情報源に統合（8 → 12。条件9の修正、条件10の平易な言葉、条件11のアクセシビリティ、条件12の見つけやすさを追加。条件4/5をUI用語で強化。専門用語に関する条項を条件7から条件10に移行）。2つの明示的な重複ガード（条件10↔条件7、条件12↔条件1／条件2）と、各条件の比例性を追加。references/usability-bar.md を追加。基準をペアごとの出典に基づいて再構成。追加的な変更であり、VERDICT の出力と入力コントラクトに変更はありません。（1.0.0 → 1.1.0。）