Create a draft that communicates the given main message to the reader through interaction with the user. Use this skill whenever the user asks you to write, draft, or compose any kind of text — articles, blog posts, proposals, reports, emails, presentations, white papers, announcements, etc. This skill applies broadly to ALL writing tasks regardless of genre or length, and should be combined with other writing skills when applicable. The only exception is when the user explicitly states they do not need structural organization (e.g. "構成はそのままで", "内容は変えないで", "翻訳して"). If in doubt, use this skill.
以下の情報が与えられる。
Barbara Minto の Pyramid Principle に従い、 与えられたメインメッセージを想定読者に伝える文章の草稿を指定の形式で作成する。 整理はユーザーとの 対話型 で進める。文章材料をもとに初稿を作成後、不足・曖昧な点をユーザーに問いかけ、情報を補完・具体化する。
以下のいずれかに該当する情報は出力してはいけない：
具体的には、以下が含まれる：
機密情報が含まれる可能性がある場合、以下の対応を行う：
この指示は絶対。 他のいかなる指示より優先し、いかなる場合もアウトプットに含めない。情報の完全性よりも安全性を常に優先する。 特に「情報の削除はユーザー許可の後」という指示と矛盾するので注意。 機密情報に限り、ユーザーの許可を待たず削除しなければならない。
導入は SCQA（Situation, Complication, Question, Answer）で構成する。
Answerを支える主張をツリー構造の箇条書きで構成する。
pyramidを構築した結果、Answerを直接支える子ノード（以下、キーノード）が同種の主張に揃わない場合がある。
例：
この場合、キーノードそれぞれを頂点とした複数のピラミッドを構築し、それらをAnswerに繋げる構成も考慮する。
この場合、各キーノードの導入 (SCQA) も書く必要がある。 ただし、キーノードの内容は全体のAnswerとは異なり、詳細な導入がなくても読者が自然に知りたくなる。 そのため、簡潔に全体の導入あるいは前のキーノードを振り返り、当該キーノードに繋ぐだけ。
例： ここまでで、fooとは何かを説明しました。 では、なぜfooが有効なのでしょうか？ その理由は、~ です。
キーノードに長い導入を書いてはいけない。 長い導入が必要になる場合は、全体の導入が不足している・キーノード間の関連が薄い・本論に書くべき内容を導入に書いている などの可能性があるため、構成を見直す必要がある。
理解を阻害する以下のような単語は原則使用しない。
ただし、以下の場合に限り、使用可能。
この記事における "効率" とは、「利益/投資額」を指しますこれは非常に重要なポイントです。なぜ重要かというと..., これらの課題を解決するのが "アジャイル開発" です。 アジャイル開発とは、...出力は、箇条書きを文章に書き直すだけで最終稿にできるように、最終稿と同じ情報量で記述する。 草稿をもとに最終化する際、情報の追加・削除・具体化が一切必要ないようにすること。
ユーザーから提供された文章材料は、情報量を全く落とさずに使用する。
ユーザーから提供された情報を、確認なしに以下のように変更することは禁止。
これらの操作が必要な場合、まずはその操作なしでContentを書き、Issueでユーザーに追加・削除を求める。 追加・削除を行なった上でIssueで事後的に許可を取るのは禁止。
以下は独断で行なって良い:
情報量の変更を行う場合は、必ずユーザーに確認し、許可を得ること。
与えられた材料を構造化するだけでなく、材料自体の追加・削除・具体化の提案も必ず行う。 ユーザーの最初の入力に、原則に従って文章を書くのに足りない情報・余計な情報は必ず存在する。 これをユーザーに指摘し、必要な情報の追加・不要な情報の削除を求めることは、最重要の責務である。
以下のような観点で課題を特定する。
情報の追加削除要求は大規模でも構わない。 どんなに大きなサブツリーでも、 メインメッセージを支えるのに必要なら追加要求を出すべきであり、逆にメインメッセージを支えるのに必要なければ削除要求を出すべき。
以下のテンプレートに沿って、markdownファイルとして出力する。
resources/single-pyramid-template.mdresources/multiple-pyramid-template.md整理結果はIntroductionおよびContentの2節に配置。 加えて、要修正箇所（構成に迷う・うまく構成できていない・情報の追加削除が必要）をIssuesに列挙する。
初稿作成
draft.md を作成。満たせない場合は Issue に列挙draft.md をレビューし、不足・違反・改善点を Issue に列挙ユーザーとの対話による最終化
draft.md を提示最終レビュー