How to

How to は、製品内で 1 つの作業を完了する方法を説明します。トーンは手順的で、率直にします。

読者がすでに製品を選んでおり、その中で特定の 1 作業を完了する必要があるときに How to を使います。次のものではありません。

• チュートリアル。 チュートリアルは何かを作りながら教え、読者を失敗させません。How to は、目標をすでに把握している、作業の途中の読者向けです。
• コンセプト。 製品がこう動く理由を 1 文以上説明しているなら、コンセプトページに移してリンクします。

全体の比較は コンテンツタイプ を参照してください。

• タイトル: 二人称の命令形による短い動詞句にします。動名詞、名詞だけ、または「How to」の接頭辞は使いません。
• 説明: 動詞で始め、Cloudflare の製品または機能を挙げ、達成する作業を述べ、そのあと重要な詳細や前提条件を足します。

Nimbus の how-to レシピを使って、このページを生成します。コーディングエージェントがページのひな形と自己レビュー用チェックリストを取得し、製品に合わせて調整します。

npx @cloudflare/nimbus-docs add content-how-to

yarn @cloudflare/nimbus-docs add content-how-to

pnpm @cloudflare/nimbus-docs add content-how-to

レシピが出力する frontmatter を Cloudflare のスキーマに合わせて調整します。レシピが出力する type などの汎用フィールドではなく、pcx_content_type と products を設定します。

• Steps（手順） が中心の構造です。Steps コンポーネントでも、普通の番号付きリストでも、Markdown 版（twin）では同じ文言になる必要があります。手順が無いページは、How to かどうかを疑ってください。
• Tabs とコードグループ は、言語、プラットフォーム、CLI とダッシュボードなど、バリエーションの軸を 1 つの正規ページにまとめます。別の方法がある場合は推奨方法を選び、残りはリンクします。ページを複製しないでください。
• Callouts（コールアウト） は、破壊的な手順の前に警告します。例外のコールアウトばかりのページは、正常系（happy path）の選び方が間違っています。
• 末尾は固定の順にします。 確認、次に不可逆な締めの手順（ある場合）、次に任意ブロック、最後に Next steps。番号付き手順の最後で終わらないでください。
• 複数手順のページ は、順序がはっきりするようセクション見出しを番号付きにします（## 1.、## 2.）。各段階はおおよそ 10 手順までに抑えます。

pcx_content_type: how-to
products:
  - product-a
  - product-b
  - product-c

詳細は pcx_content_type を参照してください。

• 手順は自己完結させます。 製品エリア、コマンド全文、読者が選ぶ正確なラベルを書きます。「上記で設定したとおり」のような位置参照は使いません。
• 出力はリテラルにします。 期待する出力は、省略したプレースホルダーではなく、完全で現実的な値のフェンス付きコードブロックに置きます。エージェントは表示した文言そのものと照合するためです。
• twin で落ちない手順にします。 手順の文言がタブやほかのコンポーネントの中にしか無い場合、Markdown 版（twin）ではラベル付きテキストとして残るようにします。変換時に落ちないようにするためです。