write-blog

ブログ記事を書く

プロジェクトのウェブサイトに掲載するブログ記事を書く、コントリビューターを支援します。求められる水準は、本人が書いたように読めること、ほかの記事がまだ対象にしていない検索クラスターで上位に表示されること、そしてサイトに正しく組み込まれ、ビルドが成功することです。

記事の技術的な説明文と手順文には、ASD-STE100 Simplified Technical English（STE）を使用してください。短く、直接的な文を使い、用語を統一し、明確な操作を示してください。STE 辞書が利用できる場合は、技術用語を承認された意味で使用してください。慣用表現、俗語、比喩表現、および技術用語を不明瞭にするおそれのある類義語への置き換えは使用しないでください。コード、コマンド、識別子、製品名、引用文は正確に保持してください。記事には人間としての意見や具体例を含めてもかまいませんが、リズムや装飾より明瞭さを優先してください。ASD-STE100 の現行版と辞書を確認せずに、厳密に STE に準拠していると主張しないでください。

このスキルは、すでにプロジェクト独自のルールを知っているかどうかにかかわらず、すべてのコントリビューターが同じ文体で執筆し、重複しないトピックを選び、同じ AI 生成文品質チェックに合格できるようにするものです。

記事が却下される唯一のルール

エムダッシュ（—）もエヌダッシュ（–）も使用禁止です。例外はありません。 プロジェクトの文体では、これらの記号を禁止しています。代わりに、ピリオド、コンマ、「そのため」や「なぜなら」、または括弧を使ってください。下書きにダッシュが1つでもあれば、即時不合格です。スキャナーを利用できます。完成とする前に、下書きに対してスキルのフォルダー内で bash check.sh <file> を実行してください。

ワークフロー

次の順番で進めてください。切り口の確認も、人間らしい表現への仕上げも省略しないでください。

1. まず、事実を確認する

執筆を始める前に、既存の内容を読んで、文体を合わせ、キーワードの競合を避けてください。

• サイトの記事レジストリまたはインデックス。 公開済みの記事をすべて一覧できるものを確認してください（レジストリファイル、コンテンツコレクション、CMS の一覧、またはブログのソースディレクトリにあるフロントマターなど）。これは、公開済みの記事と、それぞれが扱う切り口を記録した最新の情報源です。すべての記事のスラッグ、タイトル、説明、タグのセットを確認してください。
• 公開済みの記事を1〜2本、全文読んでください（文体を把握するための資料です）。
• スキルのフォルダー内にある reference/angles.md を確認してください。競合しない切り口の選び方と、まだ扱われていないトピックを確認します。
• reference/voice.md を確認してください。プロジェクトの文体と、単独で使える AI 生成文チェックリストが記載されています。
• reference/craft.md を確認してください。執筆技術、クリックにつながる導入、記事の構成、各段階で参照するクリエイティブライティングのスキルが記載されています。
• reference/seo.md を確認してください。ページ内のキーワード配置、内部リンク、機械可読な SEO の検証、および最初の被リンクを獲得するための公開後の配信手順が記載されています。

2. 切り口を選び、提案する

各記事は、独自の検索クラスターを対象にする必要があります。 同じキーワードを狙う記事が複数あると、互いの検索順位を下げます。記事インデックスと reference/angles.md を確認し、公開済みの記事がまだ対象にしていない切り口を選んでから、執筆前にコントリビューターへ1行で提案してください。提案には、仮タイトル、1文の主旨、対象とする3〜5個のキーワードフレーズを含めます。本文を書く前に、承認を得てください。提示されたトピックが既存の記事と重複する場合は、そのことを伝え、関連性はありながらも異なる切り口を提案してください。

3. 構成

良い記事には筋が通っていて、単なるリスト記事ではありません。構成を考える前に reference/craft.md を読んでください。リードと H2 の骨組みが、記事を書き上げられるか、検索順位が上がるかの 80％を左右します。構成は次のとおりです。

• 読者が抱えている**具体的で明確な問題を示すリード（説明と冒頭）**を用意します。 「AI エージェントがコラボレーションを変革しています」ではなく、たとえば「2 つのエージェントは、ある変更について一日中話し合えます。しかし、変更そのものをバイト単位で受け渡すとなると、話は別です」のようにします。
• 4～7 個のセクションを設け、それぞれの主張を実際のコード、実際のコマンド、またはプロジェクトの実際の数値で裏付けます。プロジェクトのソースとドキュメントを実際に確認し、正確に引用してください。架空の API は、コードを載せないよりも悪い結果になります。
• 「これは何ではないか」または正直な制限を説明する部分を設けます。少し型破りな語り口で、先送りにしていることも認めます。その正直さによって、宣伝のような印象を避けられます。
• 一般的な「結論として、未来は明るい」といった締めくくりに頼らず、記事の主張が伝わる結びにします。読者が実行または確認できる具体的な内容で締めくくってください。

4. 下書き

まず、ブログのソースディレクトリ（信頼できる唯一の情報源）に、プレーンな Markdown で本文を書きます。執筆中は reference/voice.md、reference/craft.md、上記の STE ガイダンスに従ってください。正直で、具体的で、実際のプロジェクトコードに根差した内容にします。明確な意見を 1 つ示し、証拠で裏付けてください。環境で /direct-response-copy が使える場合は、タイトル、説明文、締めくくりの CTA（この 3 か所のみ。本文は対象外）に適用します。

5. 人間らしい文章にする（必須）

下書きに人間らしさを加える工程を実施します。環境で /humanizer が使える場合は、下書きに適用してください。使えない場合は、reference/voice.md のチェックリストを自分で確認します。その後、STE の工程を実施します。文の長さ、明確な主語と動作、一貫した技術用語、利用可能な場合は承認済みの語義、意図的な例外を確認してください。誇張表現、宣伝的な形容詞、三つ並べる表現、「-ing」で続く分析、否定を使った対比表現（「X ではなく Y」）、類義語の使い回し、曖昧な表現、あらゆるダッシュを取り除きます。見出し、説明文、CTA の仕上げには、利用可能であれば /direct-response-copy を使ってもかまいません。

次に bash check.sh <draft-file> を実行し、指摘された点を修正します。

6. サイトに組み込む

reference/wiring.md に従います。要点は、ブログで使っているインデックスやレジストリに記事を登録し、ブログの形式に合わせて本文を追加し、新しい記事が SEO 関連の要素（サイトマップ、RSS、OG／Twitter カード、JSON-LD）に含まれていることを確認し、カバー画像を追加してビルドすることです。キーワードの配置（タイトル／説明文／最初の H2／タグ）、内部リンク数、アンカーテキストのルールについては、reference/seo.md に従います。最も関連性の高い既存記事から、新しい記事へのリンクも追加します。

7. 完了前に確認する

サイトのビルドコマンドが正常に完了する必要があります。その後、記事をスモークテストします。記事ページ、カバー画像、ブログのインデックス、サイトマップ、RSS フィードがすべて読み込め、新しい記事が含まれていることを確認します。記事ページのソースを表示し、メタ説明文、OG／Twitter タグ、BlogPosting JSON-LD が正しい値で実際に出力されていることを確認します（確認項目は reference/seo.md を参照してください）。最後に bash check.sh を最終版の Markdown に対して再実行します。ここまで済んで初めて、記事そのものが完成です。

8. 配信する（これが読者を獲得します）

外部からのリンクがない正しい記事は、検索順位が上がりません。公開後、最初のシグナルを作ります。環境で /x-tweet が使える場合は、記事の核心となる洞察を題材に、考え方を解説して記事へリンクするスレッドを作成します。関連ドキュメントから記事へリンクし、記事が解決する実際の疑問がすでに話題になっている場所で回答します。reference/seo.md の配信ループを参照してください。必ず正規の本番 URL（<your-site-url>/blog/<slug>）をリンクし、ステージング環境やプレビュー環境のホストは使わないでください。

ガードレール

• プロジェクトの API、フラグ、数値を決して作り出さないでください。ソースを読み、そのまま引用してください。
• 「プロフェッショナル」に聞こえるように、チームの文体を決して弱めないでください。洗練されていてありきたりな表現より、具体的で少し型破りな表現を常に優先してください。
• 技術文書や手順を説明する文章には STE を使用してください。技術的な明確さを損なうおそれがある場合は、比喩的な表現や装飾的な言い回しを使わないでください。
• 公開済みの記事と切り口が重なる記事は公開しないでください。切り口を変えてください。
• カバーには SVG またはラスター画像を使用できます。サイトのブランドパレットに合わせてください。良いカバーを作れない場合は、見栄えの悪いものを公開するのではなく、既存のカバーを再利用してください。

このスキルのファイルに関する注意

スキャナーは、禁止文字 (—) (–) を記載し、説明用の表記として → を使用しているため、SKILL.md と reference/ ファイルを検出します。これは想定どおりです。スキャナーの対象はブログ記事の下書きと、レンダリング済みの記事本文であり、このスキルのドキュメントではありません。