article-writer

name	article-writer
description	記事リポジトリ向けの記事を作成・更新する。話題の整理、関連記事調査、アウトライン作成、章ごとの執筆、推敲、単一ファイル検証まで扱う。/blog-writer の呼び出し、記事を書きたい、下書きを作りたい、既存記事を広げたい、技術記事・調査記事・設計論・雑記・レビュー・考察記事を準備したい場合に使う。

ブログ記事作成

ローカルの記事リポジトリ向けに、話題・メモ・粗いアウトライン・既存下書きから記事を作る。リポジトリの文体を保ち、事実に基づいて書き、記事リポジトリの検証ルールに従う。

役割

このスキルは記事作成の入口である。話題整理、記事タイプ判定、文脈収集、アウトライン、下書き、保存、検証の流れを束ねる。

既存の補助スキルやリポジトリ規則がある場合は、詳細手順をそちらへ委譲する。

• 関連記事調査・タグ候補・記事群比較: article-context-router
• 公開前の基礎編集・保護範囲確認: article-foundation-editor
• 技術記事の再現性評価: tech-article-reproducibility
• AI らしい文体の検出・除去: avoid-ai-writing

基本方針

1. 執筆や保存の前に記事リポジトリの指示を読む。対象は AGENTS.md、CLAUDE.md、.claude/rules/writing/*.md、関連する .claude/skills/* である。
2. 指示が衝突した場合は、ユーザーの明示指示、記事リポジトリの制約、このスキル、既存記事の傾向の順で優先する。ただしフロントマター変更禁止、編集禁止範囲、検証コマンド制約は常に守る。
3. 既存記事は文体・構成の根拠として扱う。事実の根拠にはしない。
4. 日本語の だ・である 調で書く。ユーザーが別文体を明示した場合だけ従う。
5. 短く断定し、観測結果を中心に書く。大げさな評価、汎用的な導入は避ける。
6. 事実、数値、リンク、引用、ベンチマーク、体験談、会社名、内部 URL、秘密情報を捏造しない。
7. 不確かな事実や新しい情報は、可能な限り一次情報・公式情報で確認する。確認できないものは穴埋めせず、未確認として扱う。

不明瞭点の扱い

不明瞭点として扱うのは、作業対象や成果物の方向を決められない矛盾だけである。保存前や公開前に決めればよい項目で下書きを止めない。

不明瞭点にしない例:

• 対象読者、記事タイトル、タグ、フロントマター値
• 技術記事の対象バージョン、既存実装の細部、移行対象ファイル
• 作品考察の対象範囲、ネタバレ許容範囲、扱う作品数
• tag-index.json / article-index.json の鮮度、読み取り専用時の索引再生成有無
• 参考リンク、本文内リンクと参考セクションの使い分け、画像、検証環境、公開可否
• AI エージェント、ツール、ライブラリなどの扱う範囲

下書き・案・相談では、これらを 前提 または 保存時の確認事項 に置いて進める。ファイル作成・編集時に必要なら最大2問だけ確認する。 報告フォームやレビュー依頼で 不明瞭点 欄が求められた場合も、保存時の確認事項をそこへ混ぜない。該当がなければ なし とだけ書く。 読み取り専用モードでは索引を再生成しない。これは固定ルールであり、判断が分かれる不明瞭点として扱わない。

手順

1. 取材

1. 依頼文、メモ、対象ファイル、指定された制約から、話題、想定読者、要点、記事タイプ、新規作成か既存記事の更新かを整理する。
2. 作業モードを決める。回答内で下書きだけ作る場合は読み取り専用、ファイル作成・編集を求められた場合は保存ありとして扱う。読み取り専用では npm run tags:export を実行しない。
3. references/article-types.md で記事タイプを判定する。
4. references/article-repository.md に従って、記事リポジトリの文脈を集める。
   • 関連記事調査やタグ選定が必要なら、article-context-router が存在する場合はそちらを使う
   • ユーザー提供のメモやアウトラインを読む
   • 必要な一次情報・公式情報を集める
   • 作成・保存・検証ルールを確認する
5. 推定できない重要項目だけ質問する。質問は最大2つまでにする。質問しなくても仮定で下書きできる場合は質問しない。
6. ユーザーが「下書き」「案」「相談」を求めている場合は、質問で止めず、未指定条件を仮定として明示して進める。
7. 下書き時の仮定は 前提、保存や公開の前に決める項目は 保存時の確認事項 として扱う。

2. アウトライン

1. references/article-types.md の該当テンプレートを使う。
2. 記事リポジトリにテンプレートや writing rules があれば優先する。
3. 見出しは ## から始める。必要なら簡潔な主張型見出しを使う。
4. タイトルは既存記事の型に寄せる。
5. 各章の役割を明確にする。
6. 長い記事や協調執筆が必要な場合は、アウトラインを提示して承認を待つ。全文作成を直接求められた場合は、前提を明示して進める。

3. 執筆

1. 長い記事では章ごとに展開し、必要に応じて承認を待つ。
2. 短い記事や全文下書きの依頼では、一度に完成稿を書く。
3. コードフェンスには必ず言語を指定する。
4. ハウツー記事では、実行可能な例、コマンド、期待される出力を優先する。
5. コード例の数はタイプで分ける。問題解決型は話題が許す限り5個以上入れる。調査・比較型は比較軸の差分が鋭くなる箇所だけにコード例を絞る。知識共有型は理解に必要な最小限にする。設計論型は主張を裏付ける具体例が要るときだけ入れる。雑記など非技術記事ではコード例の数を要求しない。
6. バージョン未指定の技術記事では、公式情報で確認できる安定版または対象記事の文脈から前提を置き、本文で明示する。既存実装の詳細が不明な場合は、移行時の確認項目として扱い、下書き作成を止めない。
7. 比較は表を使うと読みやすい場合にだけ使う。
8. 結論の前に制約や反論されそうな点を処理する。代替案は公平に比較する。

4. 推敲

1. AI らしい汎用表現、大げさな評価、不要な導入を削る。詳細な検出・rewrite が必要な場合は avoid-ai-writing を使う。
2. 各章が、主張を進める・根拠を示す・条件を絞る・読者の行動を示す、のいずれかを満たすようにする。
3. 公開前の基礎編集が必要な場合は、article-foundation-editor が存在するならそちらを使う。
4. 技術記事で再現性が重要な場合は、tech-article-reproducibility が存在するならそちらを使う。
5. 検証コマンドがある場合は、リポジトリで許可された単一ファイル対象のコマンドだけを実行する。

5. 保存

保存するのは、ユーザーがファイル作成・編集を求めた場合、またはリポジトリの手順上ファイル作成が明らかな場合だけである。

1. 記事リポジトリのルートで新規記事を作る場合は、次のコマンドから始める。

npm run new

2. 既存記事のフロントマターは変更しない。新規生成ファイルの空フロントマターにタイトルやタグが必要でも、リポジトリ指示と矛盾する場合は本文だけ編集し、必要なメタデータを別途報告する。
3. textlint-disable / textlint-enable コメントを削除・移動しない。
4. AI 編集禁止範囲を編集しない。
5. 検証は1ファイルずつ実行する。

npx textlint path/to/article.md
npx prettier --write path/to/article.md
npx markdown-link-check path/to/article.md --config markdown-link-check.config.json

保存先と検証結果を報告する。

報告

下書き・案・相談では、次の順で報告する。

1. 記事タイプ（手順 1 で判定したもの。例: 問題解決型、その他（雑記）など）
2. 成果物
3. 前提
4. 保存時の確認事項
5. 検証方針

対象範囲、バージョン、ネタバレ許容範囲、索引の鮮度、既存実装の詳細など、保存前に決めればよい項目は 保存時の確認事項 に置く。タイトル形式、章立て、想定読者、API の正確な引数・import 元など、下書きで仮定したまま進めた値も同じく 保存時の確認事項 に集約する。作業の解釈に迷った箇所だけを 不明瞭点 として別に出す。不明瞭点 がなければ項目自体を出さない。外部のレポート形式で 不明瞭点 欄が必須の場合は なし と書き、保存時の確認事項を再掲しない。

参照

• references/article-types.md: 記事タイプ判定、章の役割、アウトライン。
• references/article-repository.md: ローカル記事リポジトリの文体、文脈収集、保存、検証ルール。