article-foundation-editor

name	article-foundation-editor
description	技術記事、雑記、レビュー、イベント感想、短いメモなど記事タイプを問わず、記事の土台を整えるスキル。フロントマターを変更せず、AI編集禁止範囲、textlint-disable/textlint-enable コメント、画像パス、見出し階層、である調、事実と主観の分離、読者前提、公開前の基礎品質を確認・修正する。記事初稿の整理、公開前の基礎チェック、技術記事以外の記事の最低限の読みやすさ調整で使う。

Article Foundation Editor

記事タイプを問わず、公開前の記事として破綻しない土台を整える。技術記事の再現性や詳細な事実調査は扱わない。

範囲外:

• 技術記事の再現性検証。tech-article-reproducibility を使う
• 外部一次資料の詳細調査
• 誤字修正だけで完結する依頼。このスキルを通さず直接修正してよい

絶対制約

• フロントマターを変更しない
• textlint-disable / textlint-enable コメントは textlint ルール制御として扱う。削除・移動・変更が必要な場合は、実施前にユーザーへ確認する
• AI編集禁止 コメント範囲を編集しない
• 画像パスを追加・修正する場合は /images/ で開始する
• コードブロックを追加・修正する場合は言語指定を付ける
• 見出しは ## から開始する
• 文体はである調に揃える。引用・例文として意図的に残された「です・ます」調は変更しない
• ユーザーの体験談、感想、言い切りの強さを勝手に中和しない
• 記事タイプを変える編集をしない。雑記を技術記事風に、感想を解説記事風に寄せすぎない

ワークフロー

依頼が「レビュー」「提案」「dry-run」の場合はファイルを編集しない。編集を依頼された場合だけ、保護範囲を避けてファイルを変更する。

1. フロントマター、textlint コメント、AI編集禁止 範囲を確認する
2. title / tags と本文冒頭から記事タイプを判定する
3. 記事タイプ別の観点で、必要最小限の補正を行う
4. 編集した場合は npx textlint <filepath> を実行する。エラーが出たら本文を修正し、同じコマンドをエラーゼロまで再実行する
5. npx prettier --write <filepath> を実行する
6. 公開前の最終確認まで依頼されている場合は npx markdown-link-check <filepath> --config markdown-link-check.config.json も実行する
7. 実行できない検証があれば、未実行理由を報告する

保護範囲と textlint コメントの扱い

• フロントマターはファイル先頭の --- から次の --- までとみなし、内容を変更しない
• textlint-disable から対応する textlint-enable までの範囲は、編集禁止範囲ではない。内側の本文は必要に応じて編集してよい
• textlint-disable / textlint-enable コメント自体の削除・移動・変更、または有効範囲の変更が必要な場合は、実施前にユーザーへ確認する
• AI編集禁止 コメントがある場合は、そのコメントで示された範囲を編集しない。終了位置が判断できない場合は、該当箇所の編集を避けてユーザーに報告する
• 保護範囲や textlint コメントに問題が見つかった場合は、範囲外に補足を追加するか、変更案として報告する

記事タイプ判定

まずフロントマターの title / tags で早期判定し、見出しと本文冒頭で確認する。迷ったら複数タグの混合として扱い、強い変換を避ける。

タイプ	判定材料	主な編集方針
技術記事	tags に言語・ライブラリ・ツール名がある、タイトルが [技術名] ... 形式、コード、コマンド、実装手順、エラー対処	事実・手順・前提を明確にする。再現性の深掘りは別スキルに渡す
雑記	個人的な考え、近況、ゆるい記録	主題と話題の流れを整える。説明過多にしない
感想・レビュー	作品、イベント、製品、体験への評価	事実情報と主観を分ける。ネタバレや前提知識に注意する
イベント記録	日時、会場、プログラム、参加体験	記録情報を整理し、感想と混ざりすぎないようにする
短いメモ	小さな発見、解決ログ、覚え書き	結論、背景、再利用できる情報を明確にする

記事タイプ別の編集観点

技術記事

• 問題、背景、解決策、結果の流れが見えるようにする
• 既存のコードやコマンドを壊さない
• 具体的な再現性評価が必要なら tech-article-reproducibility に渡す
• 公式情報や一次資料が必要な断定は、未確認のまま強く書かない

雑記

• 最初の数段落で主題が分かるようにする
• 話題の飛躍が大きい場合は、見出しを足すか段落順を整える
• 個人の声を残し、一般論に薄めすぎない
• 結論を無理に教訓化しない

感想・レビュー

• 作品名、イベント名、製品名などの対象を早めに明示する
• 事実情報と感想を段落または見出しで分ける
• ネタバレ、価格、開催日、バージョンなど、読者判断に影響する前提を明示する
• 評価は過度に一般化せず、「自分にとって」の範囲を保つ

イベント記録

• 日時、会場、出演者、プログラムなどの事実情報を整理する
• 参加した回や座席など、感想の前提になる情報を必要に応じて明示する
• セットリストや演目が長い場合は、感想と混ざらないように見出しで分ける

短いメモ

• 結論を先に置く
• 何に困ったか、何をしたか、結果どうなったかを短く揃える
• 後で検索できる語をタイトルや本文に残す

編集の強さ

軽い順に、誤字・表記ゆれ、段落内の順序調整、見出し調整、重複削除、段落移動までを行う。段落の大幅削除、記事タイプの変更、体験談の削減は、ユーザーが明示した場合だけ行う。

レポート

編集後は次を簡潔に報告する。

• 判定した記事タイプ
• 変更した土台部分
• 触らなかった保護範囲
• 確認した textlint コメントと、変更提案の有無
• 実行した検証コマンド
• 未実行の検証と理由