component-docs

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

ソースに書かれている内容だけを基に作成する、1つのコンポーネントのドラフト項目です。不足箇所は補完せず、明示します。設計の評価は行わず、公開もしません。見出しの順序と記入例は references/doc-format.md にあります。

手順

1. references/doc-format.md の9つの見出しを、空の状態でドラフトに貼り付けます。
2. コンポーネントを見つけます。コード、props 型、スタイル、ストーリーを読み、それぞれを Sources 行に記録します。
3. 呼び出し箇所の検索、または依頼内容から、実際の使用例を2つ見つけます。実際の使用例が1つ、または0件の場合は、下記の停止テーブルに従います。
4. 各例、バリアント、prop、状態、トークンの根拠となったソースを追跡します。ソース間の不一致はすべて、矛盾を解決する規則を引用した行、または「規則なし、選択せず」を Conflicts の下に記載します。
5. 各セクションを根拠のある事実で埋め、トークン名とサンプルコードは一字一句そのままコピーします。
6. Usage rules は最後に記述します。各ルールには、rule/<component>-<slug>、条件、アクション、理由、根拠（2つの呼び出し箇所、パス付きの測定値、名前のある原則、または本人の言葉）、そして実際のコードで違反例を示す Don't: 行を含めます。コード断片で違反を示せないルールは削除します。
7. Guessed at に、判断した内容を1行ずつ記入します。以下の Done リストに照らしてドラフトを読み直します。

出力

項目の後に、Sources、Conflicts、Guessed at、さらにルールによって追加される場合に限り Gates（質問とそのデフォルト値）を記載します。単独で実行した場合は、1行目にドラフトのコメントを付けて docs/system/<name>.md に保存し、不足している各サンプルファイルを書き出します。返信はパス、項目の対象範囲とステータスで始まり、その後にデフォルト値付きの質問を最大3つ、さらに次のステップへ進むために本人が貼り付けられるプロンプトを1つ記載します。

停止条件

検索しても見つからないもの	停止する理由
コード	バリアント、props、動作の根拠となるものが他にありません
バリアント一覧（props 型またはストーリー）	推測した一覧を記載すると、別のコンポーネントについてのドキュメントになります
使用例（実際のもの、または予定されているもの）	架空の使用例が実例のように見え、読者が最初にそれをコピーしてしまいます

バリアント用のpropがないprops 型は、空の一覧として扱います。Variants には「なし」と記載し、処理を続行します。実際の使用例が1つの場合、予定されている使用例、および非推奨の前身は、その旨を明記し、停止条件にはしません。停止した場合は、停止理由、セクションごとにそこまでに得られた事実、そして停止解除に必要な最小限の返信（画面名を1つ、コンポーネントをそこに配置した理由、表示されたバリアント）を返します。

ルール

• ソースの記載がないバリアント、prop、トークン名、例、使用例は決して記載しません。予定されている使用例には、予定であることを明記します。
• セクションを埋めるために状態や優先順位を決して捏造しません。
• 不具合に見える動作は、そのまま記載したうえで、ユーザーに何が起こるかと最小限の修正を含む、担当者向けの Defect: 行を追加します。
• 単独でも使用されるパーツには、Description の下に ### Parts サブセクションを設けます。複合コンポーネント（Tabs と Tab など）は1つの項目とします。
• ドキュメント化の対象となるコード、ストーリー、仕様は編集しません。
• 返信内の件数は、保存したファイルのドラフトコメントより下を対象に grep -o で取得します。

完了条件

すべてのバリアント、prop、トークン、例に Sources 行があります。すべての Usage rule に根拠と Don't: 行があります。矛盾はすべて示されています。9つの見出しが順番どおりに存在し、根拠のある記載がないセクションには Not applicable: <reason> と記載されています。