日本語推敲スキル (Refine JA)

文章の「誤り」ではなく「質」を向上させるためのスキル。 文脈、ターゲット読者、目的に応じて、より適切な表現や構成を提案する。

誤字脱字・文法の「校正」は proofread-ja スキルが担当する。本スキルは文章の表現力・構成の「推敲」に特化する。

モード定義

ユーザーの指示や文書の内容からモードを推定する。明示されていない場合は「標準（Standard）」とする。

ワークフロー

1. 入力分析

• 文字数、文書タイプ、ユーザーの要望（「もっと感動的に」「短くして」など）を確認。

1. モード決定

• 指定があればそれに従う。なければ文体から推定し、確認する（「ブログ記事として推敲しますか？」）。

1. 推敲提案

• 以下の観点でテキストを分析し、改善案を作成する。
• 全体構成: 段落の長さ、見出しの適切さ、論理構成。
• 文レベル: 一文の長さ、ねじれ文、受動態/能動態の使い分け。
• 表現レベル: 強い動詞への言い換え、同じ単語の繰り返しの回避、オノマトペの使用（小説など）。

1. 出力

• 修正案とその理由を提示する。
• 必要に応じて「Before/After」の対比を見せる。

チェックポイント（モード別）

小説 (Novel)

• [ ] 「〜した。〜した。」のような単調な語尾の連続はないか？
• [ ] 抽象的な表現（「悲しかった」）を具体的な描写（「胸が締め付けられるようだった」）にできないか？
• [ ] 五感（視覚、聴覚、嗅覚、触覚、味覚）に訴える表現はあるか？
• [ ] 意味のない重複（「頭痛が痛い」的なものだけでなく、近い位置での単語重複）はないか？

ブログ (Blog)

• [ ] 「！」や「？」を使って読者に語りかけているか？（適度な距離感）
• [ ] 一文が長すぎないか？（60文字以内推奨）
• [ ] 漢字の含有率は適切か？（開きすぎず閉じすぎず、30-40%目安）
• [ ] 専門用語を平易な言葉に言い換えられないか？

技術文書 (Technical)

• [ ] 主語と述語は明確に対応しているか？
• [ ] 「〜と思われる」「〜の可能性がある」などの曖昧な表現を避け、事実を断定しているか（必要な場合を除く）？
• [ ] 指示代名詞（これ、それ）が何を指すか明確か？
• [ ] 箇条書きを活用して構造化できているか？

ビジネス (Business)

• [ ] 結論が最初に来ているか（結論ファースト）？
• [ ] 二重否定（「〜しなくはない」）のような回りくどい表現はないか？
• [ ] クッション言葉（「恐れ入りますが」）は適切に使われているか？
• [ ] 敬語は正しく、かつ過剰ではないか（二重敬語の回避）？

標準 (Standard)

• [ ] 冗長な表現（「〜することができる」→「〜できる」）はないか？
• [ ] 一文が長すぎないか？（80文字以内推奨）
• [ ] 同じ語尾（「〜です。〜です。」）が連続していないか？
• [ ] 不要な修飾語や副詞を削って簡潔にできないか？

参照ファイル

• references/refinement-patterns.md: モード別の具体的な言い換えパターン集。推敲提案時に参照。
• references/style-guidelines.md: 各モードの文体ルール詳細。モード決定後に該当セクションを参照。

出力フォーマット例

## 推敲提案（モード：小説）

### 表現の強化
原文：
> 彼は悲しそうな顔をした。雨が降っていた。

修正案：
> 彼は眉を寄せ、沈痛な面持ちで俯いた。窓の外では、冷たい雨が降り続いていた。

理由：
「悲しそう」という直接的な形容詞を使わず、表情と情景（雨）で感情を表現することで、読者の想像力を掻き立てます。

---

### リズムの調整
原文：
> ドアを開けた。部屋に入った。電気がついていなかった。誰もいなかった。

修正案：
> ドアを開けて部屋に足を踏み入れると、そこは闇に包まれていた。人の気配はまったくない。

理由：
短文の連続による単調さを解消し、文をつなげることでスムーズな流れを作りました。