markdown-drafts

Markdown の下書き

ユーザーが、GitHub の issue、プルリクエストの説明、Jira チケット、Wiki ページ、設計ドキュメント、RFC など、外部システムにコピーするコンテンツの下書き、作成、執筆を依頼した場合は、書式がコピー＆ペースト後も維持されるよう、常に Markdown 構文を使用してください。

適用されるケース

• GitHub の issue とプルリクエストの説明
• Jira チケットの説明とコメント
• Confluence／Wiki ページの下書き
• 設計ドキュメントと RFC
• Slack メッセージ（Slack は Markdown の一部をレンダリングします）
• ユーザーが他の場所にコピーすると明示したコンテンツ

書式設定ルール

• #、##、### の見出しを使用して構成を作ります
• 順序なしリストには - または *、順序付きリストには 1. を使用します
• コードには、言語タグ（例：```cpp）を付けたトリプルバッククォートのコードブロックを使用します
• 識別子、ファイルパス、コマンド、設定値には インラインコード のバッククォートを使用します
• 重要なポイントの強調には **太字**、補足的な強調には _斜体_ を使用します
• 比較やデータを構造化して示す場合は、Markdown の表を使用します
• 呼び出し、引用文、重要な注記には > 引用 を使用します
• 参照には [リンクテキスト](url) を使用し、文章中に URL をそのまま記載しないでください
• 必要に応じて、主要なセクションを区切るために --- の水平線を使用します
• 対応項目やチェックリストの下書きには、タスクリスト（- [ ]／- [x]）を使用します
• 行の長さは適切に保ちます（例：80～120 文字）

構成のガイドライン

• 詳細に入る前に、簡潔な要約の段落から始めます
• 見出しを使って、ざっと目を通しやすい構成にします
• 段落は短く保ちます。長い文章のかたまりは、issue トラッカーでは読みづらくなります
• 最も重要な情報を先に示します（逆ピラミッド型）
• 必要に応じて、次のステップ、未解決の質問、対応項目で締めくくります

レンダリング：常に生の Markdown を出力する

チャットインターフェースは Markdown をレンダリングし、生の構文（###、**、` など）を取り除きます。これらの下書きは外部システムにコピー＆ペーストするためのものなので、ユーザーが生のマークアップ文字をそのまま確認できる必要があります。

下書き全体を必ずフェンス付きコードブロックで囲み、チャットインターフェースにリテラルテキストとして表示させてください。言語タグのないプレーンなトリプルバッククォートを使用します。

```
## 見出し

- 箇条書き 1
- **太字テキスト** と `コード`
```

こうすることで、ユーザーは Markdown のソースを正確に確認してコピーできます。下書きをコードフェンスの外で書式付きテキストとしてレンダリングしてはいけません。チャット UI によってマークアップが気づかないうちに消費されます。

してはいけないこと

• 下書きをコードフェンスの外で書式付き Markdown としてレンダリングしないでください。ユーザーが構文を失うことになります
• プレーンテキストの書式（例：見出しをすべて大文字にする、==== の下線、手動のインデント）を使用しないでください
• 対象システムで必要とされ、Markdown では不十分な場合を除き、HTML タグを使用しないでください
• ユーザーの下書きに含まれている場合、または明示的に求められた場合を除き、絵文字を追加しないでください
• 三段論法のような表現や、決まり文句、定型句、不要な文言など、AI が生成したようなありきたりな表現を使わないでください。簡潔に、要点を明確に伝えてください
• 編集者としてのコメントや、裏付けのない主張を加えないでください。事実とユーザーの指示に厳密に従ってください。確認が必要な場合は、推測せずに質問してください