| 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」の場合はファイルを編集しない。編集を依頼された場合だけ、保護範囲を避けてファイルを変更する。
- フロントマター、
textlint コメント、AI編集禁止 範囲を確認する
title / tags と本文冒頭から記事タイプを判定する- 記事タイプ別の観点で、必要最小限の補正を行う
- 編集した場合は
npx textlint <filepath> を実行する。エラーが出たら本文を修正し、同じコマンドをエラーゼロまで再実行する
npx prettier --write <filepath> を実行する- 公開前の最終確認まで依頼されている場合は
npx markdown-link-check <filepath> --config markdown-link-check.config.json も実行する
- 実行できない検証があれば、未実行理由を報告する
保護範囲と textlint コメントの扱い
- フロントマターはファイル先頭の
--- から次の --- までとみなし、内容を変更しない
textlint-disable から対応する textlint-enable までの範囲は、編集禁止範囲ではない。内側の本文は必要に応じて編集してよいtextlint-disable / textlint-enable コメント自体の削除・移動・変更、または有効範囲の変更が必要な場合は、実施前にユーザーへ確認するAI編集禁止 コメントがある場合は、そのコメントで示された範囲を編集しない。終了位置が判断できない場合は、該当箇所の編集を避けてユーザーに報告する- 保護範囲や
textlint コメントに問題が見つかった場合は、範囲外に補足を追加するか、変更案として報告する
記事タイプ判定
まずフロントマターの title / tags で早期判定し、見出しと本文冒頭で確認する。迷ったら複数タグの混合として扱い、強い変換を避ける。
| タイプ | 判定材料 | 主な編集方針 |
|---|
| 技術記事 | tags に言語・ライブラリ・ツール名がある、タイトルが [技術名] ... 形式、コード、コマンド、実装手順、エラー対処 | 事実・手順・前提を明確にする。再現性の深掘りは別スキルに渡す |
| 雑記 | 個人的な考え、近況、ゆるい記録 | 主題と話題の流れを整える。説明過多にしない |
| 感想・レビュー | 作品、イベント、製品、体験への評価 | 事実情報と主観を分ける。ネタバレや前提知識に注意する |
| イベント記録 | 日時、会場、プログラム、参加体験 | 記録情報を整理し、感想と混ざりすぎないようにする |
| 短いメモ | 小さな発見、解決ログ、覚え書き | 結論、背景、再利用できる情報を明確にする |
記事タイプ別の編集観点
技術記事
- 問題、背景、解決策、結果の流れが見えるようにする
- 既存のコードやコマンドを壊さない
- 具体的な再現性評価が必要なら
tech-article-reproducibility に渡す
- 公式情報や一次資料が必要な断定は、未確認のまま強く書かない
雑記
- 最初の数段落で主題が分かるようにする
- 話題の飛躍が大きい場合は、見出しを足すか段落順を整える
- 個人の声を残し、一般論に薄めすぎない
- 結論を無理に教訓化しない
感想・レビュー
- 作品名、イベント名、製品名などの対象を早めに明示する
- 事実情報と感想を段落または見出しで分ける
- ネタバレ、価格、開催日、バージョンなど、読者判断に影響する前提を明示する
- 評価は過度に一般化せず、「自分にとって」の範囲を保つ
イベント記録
- 日時、会場、出演者、プログラムなどの事実情報を整理する
- 参加した回や座席など、感想の前提になる情報を必要に応じて明示する
- セットリストや演目が長い場合は、感想と混ざらないように見出しで分ける
短いメモ
- 結論を先に置く
- 何に困ったか、何をしたか、結果どうなったかを短く揃える
- 後で検索できる語をタイトルや本文に残す
編集の強さ
軽い順に、誤字・表記ゆれ、段落内の順序調整、見出し調整、重複削除、段落移動までを行う。段落の大幅削除、記事タイプの変更、体験談の削減は、ユーザーが明示した場合だけ行う。
レポート
編集後は次を簡潔に報告する。
- 判定した記事タイプ
- 変更した土台部分
- 触らなかった保護範囲
- 確認した
textlint コメントと、変更提案の有無
- 実行した検証コマンド
- 未実行の検証と理由
