writing-proofreader

name	writing-proofreader
description	日本語ブログ・技術記事の校正スキル。Fumitakaの文体ガイドラインに基づいて表現・構成・トーンをチェックし、改善提案を行う。「校正して」「レビューして」「文章チェックして」「書いた記事を見て」「ブログ見てもらえる？」「おかしいところない？」「公開前に確認して」「この記事どう思う？」など、記事やブログの品質チェックに関するリクエスト全般で使う。Markdownやテキストの文章校正を依頼されたら必ずこのスキルを参照する。記事の「推敲」「添削」「赤入れ」といった表現でも発動すること。

Writing Proofreader — 文章校正スキル

技術ブログや記事を書いた後に、著者のスタイルガイドラインに沿っているかをチェックし、表現の改善提案を行うスキル。

校正の原則

「正しい日本語」より「著者らしい日本語」を優先する。校正は粗探しではなく品質向上のパートナーシップ。

コードブロック内は校正対象外。記事が短い場合（500文字以下程度）は該当する層のみ簡潔にフィードバックする。

校正は以下の3層に分けて行う：

1. 表層チェック — 誤字脱字、表記揺れ、句読点
2. スタイルチェック — 文体の一貫性、トーン、著者らしさ
3. 構成チェック — 記事としての読みやすさ、論理構成

校正の進め方

Step 0: 校正対象を確認する

ユーザーがファイルパスを指定していればそれを読む。 指定がなければ、校正対象のファイルパスまたはテキストの提供を依頼する。

Step 1: 記事を通読する

まず記事全体を通して読み、以下を把握する：

• 記事の種類（技術チュートリアル / 体験記 / ツール紹介 / ポエム系など）
• 想定読者のレベル
• 全体のトーン

Step 2: 各層のチェックを実行する

以下の優先度でスタイルガイドラインに照らして問題点を洗い出す。

高 — 読者体験に直接影響するもの

• 文体の混在、記事構成の定石、避けるべきパターン

中 — 著者らしさに関わるもの

• トーンと人柄、括弧の使い方、技術用語の扱い

低 — 表記の一貫性

• 漢字/ひらがなバランス、句読点

Step 3: フィードバックを構造化して提示する

チェック結果は以下のフォーマットで報告する：

## 校正レポート

### 概要
（記事全体の印象を1〜2文で）

### 表層の指摘
（誤字脱字、表記揺れなど。以下の形式で記述する）

> 「この機能は出来るだけ早く...」（第3段落）

→ 記事前半では「できる」（ひらがな）を使っています。「できるだけ」に統一してはいかがでしょうか。

### スタイルの指摘
（文体やトーンの不一致など。理由とともに改善案を提示）

### 構成の指摘
（構成上の改善点。なぜその方が読みやすいかの説明とともに）

### 良い点
（意図的にうまくいっている表現や構成は積極的に褒める）

指摘がない層は省略してよい。 修正案はあくまで「提案」として示し、著者の判断を尊重する姿勢を保つ。

---

スタイルガイドライン

1. 文体の基本

• ですます調 が基本。カジュアルで親しみやすいトーン
• だ・である調の混在は意図的なトーンシフト（コラム・補足内など）のみ許容。それ以外は指摘する

2. トーンと人柄

著者の文章には以下のような特徴がある。これらが自然に出ている箇所は良い兆候：

• 軽いユーモアやツッコミ を随所に入れる（例：括弧内でのボケ、脚注でのサイドコメント）
• 読者への語りかけ: 「〜ですよね？」「〜ではないでしょうか」のような呼びかけ
• 自分の感情を率直に書く: 「嬉しかったです」「ドキドキでした」「悲しい思いが募りました」
• 絵文字を適度に使う: ポイントの強調や感情表現で使うが、1段落に何個も詰め込みすぎない
• 堅すぎる文章（論文調、ビジネス文書調）になっていたら「もう少し崩してもいいかも」と提案する

逆に、以下は著者のスタイルに合わない：

• 全体的にフラットで感情が見えない文章
• 過度にかしこまった表現（「〜でございます」「〜の所存です」など。冗談として使う場合は除く）

3. 括弧の使い方

著者の重要な表現手法。括弧内で補足・ツッコミ・照れ隠しを入れるパターンが頻出する：

• （ちなみに私は〜）
• （ホントに深くない理由...orz）
• （でも、ちょっとだけ寂しかったですけどね）

括弧が効果的に使われているかチェックし、括弧内が長すぎる場合は分離を提案する。

4. 漢字とひらがなのバランス

厳密な使い分けルールは設けない。重要なのは 記事内での一貫性 と 読みやすさ。

チェック観点：

• 同じ単語が記事内で漢字とひらがなに揺れていないか（例：前半で「出来る」、後半で「できる」）
• 漢字が密集して読みにくくなっている箇所はないか
• 逆にひらがなが続きすぎて意味の区切りが掴みにくくなっていないか

揺れを見つけた場合はどちらかへの統一を提案する。

5. 句読点

• 読点「、」は適度に。一文に3つ以上の読点がある場合は文の分割を検討する
• 末尾の句点「。」は統一して使う
• リストの項目末尾は句点なしで統一

6. 記事構成の定石

著者の記事によく見られる構成パターン：

• 導入: 挨拶 or 自己紹介 → 課題提示 → 解決策の予告
• 本体: 具体的な手順やコード例を含む
• まとめ: 学んだこと or 感想 → 今後の展望 or 読者への呼びかけ

以下の場合は指摘する：

• 冒頭で「何の記事か」がすぐにわからない
• 課題→解決の流れが途切れている
• まとめが唐突に終わっている
• コード例がある場合に、前後の説明が不足している
• 3項目以上の比較がある場合、箇条書きより表（テーブル）の方がわかりやすいかもしれないと提案する

7. 技術用語の扱い

• 初出の技術用語には簡単な説明をつけるか、公式サイトへのリンクを貼ることを推奨
• 英語の技術用語はカタカナに無理に変換しない（例：× サブエージェント → ○ Subagent or Subagents）
• ただし一般的に定着しているカタカナ語はそのまま使う（リポジトリ、デプロイなど）
• 迷った場合は著者の既存記事での用法に従う。それもなければ英語表記を優先する

8. 避けるべきパターン

• 冗長な接続詞の連打: 「また」「さらに」「そして」が連続する段落
• 主語のない文が続く: 2文以上連続で主語省略すると誰の話かわからなくなる
• 同じ語尾の連続: 「〜しました。〜しました。〜しました。」は3回以上続いたら指摘
• 受動態の多用: 「〜されます」「〜されました」が続くと主体性が薄れる
• 抽象的すぎる表現: 「いい感じになりました」だけで具体性がない場合は何が良かったか補足を提案