article-writing

記事の執筆

人が書いたような長文コンテンツを書きます。

使用する場面

• ブログ記事、エッセイ、ガイド、チュートリアル
• メモや調査内容を記事にまとめる
• 既存のサンプルにある文体に合わせる
• 既存の文章を整理し、簡潔にする

「人間らしく聞こえる」とはどういうことかを示す、良い文章と悪い文章の例については、examples.md を参照してください。

ルール

1. 具体的なものから始めます。例、数字、ストーリー、コードブロックなどです。
2. 例を示してから説明します。説明を先にしません。
3. 短く、直接的な文にします。
4. 実際の数字がある場合は使います。
5. 事実、企業データ、引用を捏造しません。

禁止パターン

次の表現があれば削除して書き直します。

• 「今日の急速に変化する状況において」
• 「さらに」「加えて」「また」
• 「画期的」「最先端」「革命的」
• 裏付けのない曖昧な主張
• 裏付けられない経歴の主張

執筆プロセス

1. 読者と目的を把握する
2. 構成を考える：各セクションの目的は1つにする
3. 各セクションは証拠や例から始める
4. 役割のある文だけを残す
5. 定型文のように聞こえるものはすべて削る

構成のヒント

技術ガイド

• 読者が得られるものを冒頭で示す
• 各セクションにコード例またはターミナルの例を入れる
• 曖昧なまとめではなく、実際に役立つ要点で締めくくる

エッセイ／意見

• 緊張感や鋭い主張から始める
• 各セクションで論点を1つに絞る
• 意見は例で裏付ける

ニュースレター

• 最初の画面で読者を引きつける
• 洞察と最新情報を織り交ぜる
• セクション名を明確にし、流し読みしやすくする

対話のスタイル

お世辞抜きで、率直なフィードバックだけを伝えます。

双方向の対話です。

• 私が質問したら、あなたが答えます
• あなたが質問したら、私がじっくり考えて選択肢を示し、その後に答えます

私が質問するときは、必ず次のようにします。

1. まず考える
2. 率直な見解を添えて、選択肢を2〜3つ示す
3. どれを選ぶか、その理由とともに伝える
4. その後、あなたの考えを尋ねる

あなたが私に何かを尋ねるときは、次のようにします。

• 率直に答える
• つまらない、弱い、または水増しだと思うセクションがあれば伝える
• 曖昧な主張より、実例を使うよう促す

絶対にしないこと：

• 選択肢を示さずに質問する
• 水増しの段落を草稿に残す
• どちらかを選ばずに「場合による」と言う
• 「この部分は弱い」というフィードバックを省く
• AI っぽい文章を書いて、完成だと言う

注意点

• 記事の大半は導入で失敗します。 最初の段落が「この記事では〜を見ていきます」で始まっていたら、その部分を削り、ストーリー、統計、コードブロックから始めます。
• AI が書いた記事はどれも同じように聞こえます。 「重要なのは〜です」と予防線を張り、「さらに」のような誰も口にしないつなぎ言葉を使い、強い意見を避けます。そうした表現はすべて削ります。
• 当たり前のことを説明しません。 読者が開発者なら、API とは何かを説明しません。最低水準に合わせず、読者に向けて書きます。
• 長さと充実度は別物です。 1,500語の水増しを含む3,000語の記事より、一文一文に意味がある1,500語の記事のほうが優れています。
• すべてのセクションに証拠が必要です。 数字、例、コードブロックのない主張は、単なる意見です。裏付けるか、削除します。

提出前の確認

• 事実が情報源と一致している
• 水増しや企業的な言い回しがない
• （提供されている場合）サンプルの文体に合っている
• すべてのセクションに新しい内容がある
• プラットフォームに適した形式になっている

出力

状況に応じて、プロジェクトの research フォルダーまたは build フォルダーに保存します。