component-docs

コンポーネントのドキュメント

1. references/doc-format.md の見出し一覧を空のドラフトに貼り付けます。
2. コンポーネントを見つけ、コード、props の型、スタイル、ストーリーを読みます。それぞれを references/sources.md の形式で Sources 行に記録します。
3. 実際の使用例を2つ見つけます。貼り付けるか、呼び出し元を検索して見つけるか、sources.md（使用例が2つ未満の場合）を適用します。
4. 以下の停止条件を確認します。該当するものがあれば、停止時の形式で返し、そこで作業を終了します。
5. 各例、バリアント、プロパティ、状態、トークンの情報源を追跡します。意見の相違はすべて Conflicts の項目にします。
6. doc-format.md に従って、情報源に基づく事実を各セクションに順番に記入します。トークン名とサンプルコードは一字一句そのままコピーします。
7. doc-format.md の Usage にあるルールに従い、Usage rules を最後に記入します。形状、根拠、確認項目、Don't と Do の組み合わせをそれぞれ含め、検証するか削除します。
8. Guessed at を記入し、レビューのチェックリストに合格させます。
9. エントリーが仕様の場合は、doc-format.md の When the entry is a spec に記載されたチェックを実行し、その最終行をステータスブロックに入れます。

次のものは絶対に含めないでください。

• 情報源が列挙されていないバリアント、プロパティ、トークン名、例、実際の使用例。予定されている使用例は「予定」と明記します。
• 仕様チェックに合格するために創作した状態や優先順位。
• 引用されたルールなしに解決した意見の相違。ルールがなければ、双方の見解を記載したままにします。
• ドキュメント化の対象であるコード、ストーリー、仕様への編集。
• スキルによるエントリーの公開。これはドラフトであり、配置先はコーディネーターが決定します。公開は担当者が行います。

1つのコンポーネントについて、その情報源に書かれていることだけを基に作成するドラフトエントリーです。不足部分は補わずに明示し、すべての判断を担当者が確認できるように記載します。デザインを評価するものではありません。同階層の項目へのリンクは、このスキルのフォルダーからの相対パスです。

依頼に含まれる情報から始める

コンポーネント名だけで十分です。コード、ストーリー、呼び出し箇所は自分で探し、ツールでは取得できない情報だけを尋ねます。コンポーネント名が複数ある場合は、最初のものをドキュメント化し、残りを列挙します。複合コンポーネント（Tabs と Tab）は1つのエントリーにします。単独でも使われるパーツは、Description の下に ### Parts サブセクションを設けます。

コーディネーターから呼び出された場合

コーディネーターはコード、バリアント一覧、実際の使用例または予定されている使用例を渡します。それらを所与の情報として扱い、質問せず最後まで進めます。未解決の疑問はすべて Conflicts と Guessed at に記載します。呼び出し側は、それらと Gates ブロックをゲートにし、それぞれにデフォルトを設定します。

出力の先頭にはステータス行を置きます。Status: complete、Status: complete with NEEDS REVIEW (n)、Status: ready-with-gaps (<n> real uses)、または Status: stopped: <condition> のいずれかを記載し、次の行に Commit: none と記載します。直接実行の場合も同じステータス行を使用します。エントリーとブロック、または停止時の形式をテキストで返し、ほかのファイルには書き込みません。依頼の SCOPE でパスが指定されている場合を除き、エントリーはコーディネーターが保存します。

出力

貼り付け可能な Markdown エントリーを1つ作成し、その後にエントリーの外側へ次のブロックを記載します。

• Sources：sources.md の形式で、情報源ごとに1行。
• Conflicts：意見の相違ごとに1行。事実、各情報源の記載内容、適用した引用ルール、または「no rule, not chosen」を記載します。
• Guessed at：判断ごとに1行。その根拠を記載するか、「Nothing guessed」と記載します。
• Gates：ルールによって追加される場合のみ記載します。質問とデフォルトを記載します。

直接実行の場合は、エントリーと各ブロックを docs/system/<name>.md に保存し、1行目にドラフトコメントを記載します。また、不足している各例ファイル（doc-format.md の Examples）を書き込みます。返信の冒頭にはそのパス、エントリーの対象、ステータスを記載します。次に、実行した各コマンドと終了コード、Defect 行、デフォルト付きの未解決の質問を最大3つ、そして貼り付けるプロンプトを1つ含む Next: を記載します。返信内のすべての数値は、保存ファイルに対して（ドラフトコメントより下の範囲で）実行した grep -o の結果に基づくものとします。

エントリーがレビューのチェックリストに合格し、仕様の場合は check-spec.mjs が終了コード0を返すか、残る失敗がすべて、どの情報源でも解決できない理由とともに Guessed at に記載されていれば、準備完了です。

停止条件

検索後に不足しているもの	停止する理由	次にコーディネーターが行うこと
コード	バリエーション、プロパティ、動作の情報源がほかにありません	コードパスを渡して再実行するか、コンポーネントを除外し、不足として記録します
コードまたはストーリーにあるバリエーションの一覧	推測したバリエーション一覧では、別のコンポーネントを記録することになります	プロパティの型またはストーリーを渡して再実行するか、オーナーへの確認事項として保留します
実際または予定されている用途	架空の用途が実在するもののように見え、読者はまずそれをコピーしてしまいます	パイロット画面を作成するか、ブリーフにある画面を予定されている用途として1つ渡してから再実行します。エントリー自体は決して作成しないでください

バリエーション用のプロパティを含まないプロパティ型は空の一覧とみなされるため、Variants には「なし」と表示され、処理は続行されます。停止した実行結果には、停止理由、セクションごとにこれまでに入手した事実、次の手順、ブロックを解除するために必要な最小限の返信が含まれます。用途が不足している場合に必要なのは、「画面名、その画面にコンポーネントが使われた理由、表示されたバリエーション」です。

それ以外はすべて続行されます。実際の用途が1つの場合、予定されている用途、非推奨となった旧コンポーネントについては、sources.md（2つ未満の用途）に従います。情報源間の矛盾については、sources.md（情報源間の矛盾）に従い、バグと思われる動作には Defect: 行を追加します（doc-format.md の「状態」を参照）。プロパティ型、トークン一覧、仕様、メモ、アクセシビリティに関するガイダンスが不足している場合は、NOT SUPPLIED、NEEDS REVIEW、または Guessed at 行を記載します。