beedle は何をしますか？
検索エンジンやAIクローラーが読めて、見知らぬ人が10秒で理解でき、証明できることだけを主張するマーケティングページを構築します。より少なく、より豊かに：すべてのセクションはその存在価値を証明しなければなりません。各ラウンドは独立したレビューで終了します。
教訓： ステップ1の前に、プロジェクトの design/LESSONS.md があればそれを読み、マーケティングサイトに関する内容に従ってください。それらはオーナーによる修正です。
1. プロジェクトを読む
何かを尋ねる前に、すでに存在するものを調べてください：スタックとホスト、現在のサイト、製品の実際の名前、リポジトリ、ストア掲載情報、価格、スクリーンショット、デザイントークンまたはテーマ、アナリティクス、そして docs/marketing/page-brief.md です。
プロジェクトがすでに使用しているスタックで構築してください。新しいサイトの場合は、reference/seo.md（「スタックの選択」）に従ってください。マーケティングコンテンツはFlutter Webやクライアントサイドレンダリングを使用しません。クローラーがそれを認識できない可能性があるためです。
プロジェクトにテーマがあればそれを使用してください（design/THEME.md、*.tokens.json）。ない場合は、アプリからトークンを移植してください。移植するアプリもない場合は、reference/small-theme.md の1つの小さなファイルを記述してください。1ページにデザインシステムは必要ないからです。ultrahand:theme スキルは、ユーザーがテーマを要求した場合、または複数のサイトやアプリがそれを共有する必要がある場合にのみ使用してください。
2. タイプとローンチ状態を選択する
reference/page-types.md を読んでください。1つのタイプと1つの状態（プレローンチまたはライブ）を選択し、サイトが必要とするサポートページを記録してください。
3. ブリーフを作成する
プロジェクト内に docs/marketing/page-brief.md を保存します。このテンプレートを使用してください。これはレビューアがページをチェックするための契約書であり、次回セッションの出発点です。
# ページブリーフ
- タイプと状態：
- 対象読者：（誰か、そして彼らがすでに知っていること）
- ページの唯一の役割：
- プライマリCTA：（正確な文言と遷移先）
- セカンダリアクション：（1つ、軽め、または「なし」）
- 検索フレーズ：（この対象読者が実際に入力する3〜5のフレーズ）
- 反論：（誰かが離脱する本当の理由）
- アナリティクスとCookie：（何が読み込まれるか、または「なし」）
## 主張
| ページ上の主張 | 証拠 |
| --- | --- |
| <すべての数字、引用、比較、「初めて」「最速」など> | <証拠となるファイル、リンク、または測定値（日付付き）> |
| <それが何であるか、または何をするかの平易な説明> | <ファイルまたはリンク、それがすべてであれば `README only`> |
## 人を待っている項目
- <誰が：何をしなければならないか、または「なし」>
ユーザーに質問するのは、プロジェクトが答えられないものだけにしてください。通常は対象読者と証拠です。証拠をでっち上げないでください。足りない推薦文は、埋めるプレースホルダーではなく、欠落したセクションです。APP_STORE_ID_TODO のように、失敗するセンチネルを使用し、もっともらしい偽の値は使用しないでください。
READMEだけがある場合でも、ページを構築できます。製品が何であり何をするかを率直に述べられます。その行には README only とマークしてください。ただし、番号、日付、バージョン、ライセンス、価格、セキュリティ、プライバシー、可用性は証明できません。それぞれについて一次情報源を探してください：コード、LICENSEファイル、リリースページ、レジストリまたはストア掲載情報、測定値、またはオーナーの日付入りの言葉。その情報源を引用してください。ない場合は、ページから主張を削除してください。
人だけが提供できるものは、それがわかった時点ですぐに「人を待っている項目」に記載します：実際のスクリーンショット、ドメイン、確認する価格など。それが完了するまでそこに残ります。
4. まず言葉を書く
reference/message.md に従ってください。レイアウトの前にコピーを書いてください。そこにある5つのブロックから始めてください。セクションを追加するのは、それが答える反論に名前を付けられる場合のみで、その反論をブリーフに記録してください。
5. 構築する
ページ内およびページと一緒に含めるものについては、reference/seo.md に従ってください。実際の製品スクリーンショットまたは映像を使用し、再現画像をスクリーンショットと決してラベル付けしないでください。実際のアプリでサンプルデータを実行しているキャプチャは本物です：ページ上でそれがサンプルであると述べ、どのように作成したかを主張テーブルに記載してください。表示する本物のものがない場合は、画像を省略するか、ページタイプが必要とする場合はセンチネルを残してください。メッセージリファレンスにリストされているデザイン上の特徴を避けてください。それらは誰かが読む前にページが生成されたように見せるからです。
6. 自己チェック
サイトをビルドし、ビルド出力に対して監査を実行し、修正可能なすべてのエラーを修正してください：
beedle audit --dir <ビルドされたサイト>
マーケティング以外のセクションごとに --exclude docs を追加してください（繰り返し可能）。beedle がPATHにない場合は、ユーザーに監査が実行されなかったことと、INSTALL.md で追加方法が説明されていることを伝えてください。
人だけが解決できるエラーはそのまま残します。例えば、誰も購入していないドメインの DOMAIN_TODO センチネルなどです。クリーンな実行を得るために偽の値を入れ替えないでください。それが「人を待っている項目」にあることを確認し、レビューに進んでください。
7. ラウンドをレビューする
各ラウンドは、ページが準備できたとユーザーに伝える前に、新しいレビューアが独自のセッションでレビューを行って終了します。ラウンドとは、最初のビルドと、その後のページを変更するすべてのプロンプトです。したがって、1行のコピー変更もレビューされます。ユーザーが今ラウンドではスキップすると明示的に言った場合のみスキップし、スキップしたことを伝えてください。
自分で開始し、依頼されるのを待たないでください。自分のページを公平にレビューすることはできません：自分が構築しようとしたものを見てしまいます。review/round.md に従ってください。簡単に言うと、ブリーフを書き、バックグラウンドで beedle review --brief <brief> --add-dir <project> を実行し、結果に対処してください。この前に公開、デプロイ、またはページ完了と呼んではいけません。
8. 報告する
構築したもの、タイプと状態、判定結果、レビューで見つかったもの、修正したもの、未解決のまま残っているもの、およびそのコストを伝えてください。
判定が「人が行動するまで出荷できない」の場合は、それを先頭に持ってきます：ページは準備できていない、誰が何をしなければならないか、そして彼らがそれを実行した後に次のラウンドが何をチェックするかを伝えてください。「ほぼ完了」と和らげてはいけません。
ローンチ後にオーナーに残されているものを常にリストアップしてください：Search ConsoleとBing Webmasterの確認、そしてデプロイされたページでのリッチリザルトテストです。
ユーザーが要求しない限りデプロイしないでください。
9. 学ぶ
オーナーが結果を修正したり、永続的な好みを述べた場合は、プロジェクトの design/LESSONS.md に行を1つ追加してください（必要に応じて作成します）。修正がこれらのルールがすべてのプロジェクトに対して間違っていることを示している場合は、ここでもルールを修正してください。