日本語テキストの校正(誤字脱字・同音異義語・表記揺れ・文法の誤り)を 依頼されたときに使用。トリガー: 「校正して」「誤字脱字チェック」 「表記揺れ確認」「軽くチェック」「しっかり校正」。 小説・技術文書・ブログ・ビジネス文書に対応。 表現力・構成の改善(推敲・リライト)は refine-ja が担当。
refine-ja
日本語文章の推敲・リライト支援スキル。文章の「質」を向上させるために、 表現のブラッシュアップ、構成改善、言い換えを提案する。 小説・ブログ・技術文書・ビジネス・標準の5モードに対応。 トリガー:「推敲して」「リライトして」「もっと良くして」「文章を磨いて」 「小説っぽく」「ブログ風に」「技術文書として」「ビジネスメールで」 「描写を豊かに」「読みやすく」「丁寧に」「自然に直して」「表現を良くして」。 校正(誤字脱字・文法チェック)ではなく文章の表現力・構成を改善したい場合に使用する。
インストール方法を見る含まれるファイル(7)
- SKILL.md8.0 KB
- references/common.md1.1 KB
- references/modes/blog.md1.8 KB
- references/modes/business.md2.0 KB
- references/modes/novel.md2.6 KB
- references/modes/standard.md2.3 KB
- references/modes/technical.md2.5 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
日本語推敲スキル (Refine JA)
文章の「誤り」ではなく「質」を向上させるためのスキル。 文脈、ターゲット読者、目的に応じて、より適切な表現や構成を提案する。
誤字脱字・文法の「校正」は
proofread-jaスキルが担当する。本スキルは文章の表現力・構成の「推敲」に特化する。
推敲の原則(全モード共通)
- 意味を変えない: 原文の主張・事実関係・ニュアンスを保持する。
- 情報を創作しない: 原文にない数値・固有名詞・事実を補わない。具体化が望ましい箇所は「(具体的な数値を明記)」のようにプレースホルダーで提案する。
- 固有名詞・引用は原文のまま: 人名、製品名、引用文は変更しない。
- 書き換えは必要な範囲だけ: 原文の声(作者らしさ)を尊重し、目的に照らして必要な箇所だけ手を入れる。
モード定義
ユーザーの指示や文書の内容からモードを推定する。明示されていない場合は「標準(Standard)」とする。
| モード | ターゲット・特徴 | 重視するポイント | トリガー例 | リファレンス |
|---|---|---|---|---|
| 小説 | 読者を楽しませる物語、エッセイ | 情景描写、五感への訴求、リズム、単調な語尾の回避、比喩表現 | 「小説っぽく」「描写を豊かに」「情緒的に」 | references/modes/novel.md |
| ブログ | Web記事、note、SNS | 親しみやすさ、共感、リズム、目を引く見出し、結論ファースト | 「ブログ風に」「読みやすく」「親しみやすく」 | references/modes/blog.md |
| 技術文書 | マニュアル、仕様書、技術記事 | 正確さ、簡潔さ、曖昧さの排除、論理的な構造、用語の統一 | 「技術文書として」「わかりやすく」「厳密に」 | references/modes/technical.md |
| ビジネス | メール、報告書、提案書 | 礼儀正しさ、簡潔さ、クッション言葉、定型表現、結論ファースト | 「ビジネスメールで」「丁寧に」「報告書として」 | references/modes/business.md |
| 標準 | 一般的な文章 | 自然な日本語、冗長表現の削減、わかりやすさ | 「推敲して」「もっと良くして」「自然に直して」 | references/modes/standard.md |
ワークフロー
0. 入力の受け取り
| 入力形式 | 対応 |
|---|---|
| テキスト直貼り | そのまま推敲対象とする |
| ファイルパス指定 | ファイルを読み込んで推敲対象とする |
| IDE選択範囲 | 選択されたテキストを推敲対象とする |
| 入力なし | 「推敲するテキストを貼り付けるか、ファイルパスを指定してください」と案内 |
1. 入力分析
文字数、文書タイプ、ユーザーの要望(「もっと感動的に」「短くして」など)を確認し、 文字数に応じて処理方針を決める。
| 文字数 | 処理方針 |
|---|---|
| 〜3,000字 | 全文を対象に推敲 |
| 3,000〜10,000字 | セクション単位で順次推敲。リライト型の場合はセクションごとに提示 |
| 10,000字〜 | 全体の改善方針 + 代表箇所の Before/After を提示し、続きは分割を提案 |
2. モード決定
指定があればそれに従う。なければ文体から推定し、出力の冒頭で「◯◯モードで推敲します」と宣言して進める。 確認の質問で作業を止めない(モードが違っていればユーザーが指定し直せる)。
モードが決まったら references/common.md(全モード共通の文体ルール)と、そのモードのファイル(references/modes/<mode>.md)だけを読む。モードファイルには文体ルール・チェックポイント・Before/After の推敲パターンがまとまっている。他モードのファイルは読まない。
3. 推敲提案
モードファイルのチェックポイントを順に当てたうえで、以下の観点でテキストを分析し、改善案を作成する。
- 全体構成: 段落の長さ、見出しの適切さ、論理構成。
- 文レベル: 一文の長さ、ねじれ文、受動態/能動態の使い分け。
- 表現レベル: 強い動詞への言い換え、同じ単語の繰り返しの回避、オノマトペの使用(小説など)。
4. 出力
依頼の言葉遣いに応じて出力形式を切り替える。
| 依頼の例 | 出力形式 |
|---|---|
| 「推敲して」「もっと良くして」「磨いて」 | 提案型: 箇所ごとの Before/After と理由を提示 |
| 「リライトして」「書き直して」「〜風にして」 | リライト型: 修正後の全文 + 主要な変更点と理由のサマリ |
| どちらとも取れない場合 | 提案型をデフォルトとし、末尾に「全文リライトも可能」と添える |
出力フォーマット例(提案型)
## 推敲提案(モード:小説)
### 表現の強化
原文:
> 彼は悲しそうな顔をした。雨が降っていた。
修正案:
> 彼は眉を寄せ、沈痛な面持ちで俯いた。窓の外では、冷たい雨が降り続いていた。
理由:
「悲しそう」という直接的な形容詞を使わず、表情と情景(雨)で感情を表現することで、読者の想像力を掻き立てます。
---
### リズムの調整
原文:
> ドアを開けた。部屋に入った。電気がついていなかった。誰もいなかった。
修正案:
> ドアを開けて部屋に足を踏み入れると、そこは闇に包まれていた。人の気配はまったくない。
理由:
短文の連続による単調さを解消し、文をつなげることでスムーズな流れを作りました。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ