yomiyasu

---
name: yomiyasu
description: AIが生成した不自然な日本語を、人間が読みやすく情報密度の高い自然な文章へ書き直すAgent Skill。「この文章を読みやすくして」「aiっぽさをなくして」「AI臭さを消して」「自然な日本語にして」「文章を脱臭して」という依頼や、技術記事、業務仕様書・PR説明文、エッセイ・noteの推敲時に使用する。非生物主語の解体、比喩的動詞の具体化、絵文字や文末コロンの完全排除、不要な補足カッコの削除、英単語前後の不自然な半角空白の排除、過剰な太字・箇条書き・否定対比の平文化を行い、文単体で誰が何をどうしたかが伝わる文章へ再構築する。
license: MIT
---

# yomiyasu

AIが生成した文章の不自然な比喩、曖昧な主述関係、偏った構文を直し、読みやすく自然な日本語に整えるスキルです。

※ 文体調整や日本語校正を目的とした他のエージェントスキルが同一環境で有効化されている場合、指示同士の干渉によって出力が乱れるおそれがあります。本スキルを使用する際は類似スキルの無効化を検討してください。

---

## 1. 基本原則

本スキルの最優先ルールは「**意味の保持（主張・比重・言い切りの強さ・文の働きを変えないこと）**」と「**情報の不増補（勝手に足さないこと）**」です。
元の文章が伝えている内容は変えずに、AI特有の不自然さ（不自然な比喩、余計な装飾、歪んだ構文、不自然な文のつながり、立場の混ざった文末）だけを直します。

### 最優先ルール: 意味の保持
書き直す前に元の文の次の4点を確かめ、書き直したあとも必ず同じに保ちます。他の原則は、この4点を変えない範囲でのみ適用します。
1. **主張（何を言っているか）**: 伝えたい要点や論理関係を維持します。「本質」「核」などの論点を「目的」など別の概念にすり替えたり、勝手に動詞を足して論点を変えたりしません。
2. **比重（何を一番大事とし、何を軽く扱っているか）**: 否定していたものを並列（Aに加えてB）にしたり、勝手に順位づけを変えたりしません。
3. **言い切りの強さ（断定・推量・可能性）**: 元の文が言い切っていることは言い切ったまま、推量や可能性で書いていることはその強さのまま書きます（「おそれがあります」と弱めたり、「〜と言えるでしょう」を断定に上げたりしません）。
4. **文の働き（評価・説明・依頼・予定・感想）**: 評価の文は評価のまま、説明は説明のまま保ちます（「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文に変えません）。文末は、文書の目的を手がかりに、各文・各節の動作主と働きに合う形を選びます。常体・敬体の選択とは分けて判断します（詳細は「文書の立場と文末」を参照します）。

### 文書の立場と文末
日本語は主語を書かないことが多く、そのぶん文末の形が「誰が動くのか」「決まりなのか、勧めなのか、説明なのか」を伝えます。先に「誰が、誰に、何のために書くか」を確かめ、その中で各文・各節の働きを見ます。文書の目的をそろえることと、すべての文末を同じ種類にすることは別です。助言を含む文書でも、事実や道具の動作を説明する文は説明のまま残します。
常体・敬体は、変更の指定がない限り原文を保ちます。技術記事という分野だけを理由に敬体へ変えません。混在を直す場合も、文の働きとは別に文体を選びます。
- 立場は次の3つのどれかです。
  - **勧め**: 読み手に勧める・頼む文書（心得、助言、呼びかけ）。動作をするのは読み手です。
  - **決まり**: 決まり・手順を伝える文書（運用ルール、手順書、お知らせ、仕様）。動作をするのは手順に従う読み手、または方針を決めた書き手です。
  - **説明**: 事実・結果・考えを伝える文書（技術の説明、報告、体験）。
- 立場は、上の手がかりほど優先して決めます。
  1. 依頼にある行き先と読み手（「社内ブログ向け」「上長への報告」「チームの運用ルールとして」など）。「技術記事向け」「業務仕様向け」「エッセイ向け」のような分野の名前だけでは、立場を決めません。同じ分野の中に、決まり・報告・勧めの文書があるためです。
  2. 本文の手がかり（「私は」「当チームでは」などの主語、宛名・署名・日付、見出し）。
  3. 決まりと読む手がかりがないことだけでは、勧めとも決めません。助言・決まり・予定・説明のどれかを確定できないときは、文末で勝手に決めず、原文を保って書き手に確認します。
- 文末を直すのは、次のときだけに限定します。
  - 文末によって動作主や文の働きが意図とずれて読めるとき。助言・説明・予定が同じ文書にあることだけでは、混在の誤りとみなしません。
  - 指定された文体へ変えるときや、箇条書きを地の文に書き直すとき（文末の形を選び直しても、各文の働きは保ちます）。
  - 依頼にある行き先や読み手と、文末の立場が合わないとき。
  文末が文書の中でそろい、動作をする人と文の働きが依頼や本文の手がかりに合っているときは、文末を変えません。文末がそろっていることだけでは、立場が適切だとは判断しません。
  実際の処理や操作を「〜します」で説明し、最後の1文だけを「〜しましょう」で結ぶ形は、混ざっているとみなしません。ただし、読み手への助言を、書き手の予定のような「〜します」で書いていないかは確かめます。原則や大事な点を述べる文と、行動を示す文も、それぞれの働きに合っていれば残します。
- 直すときは、立場に合わない文末だけを直します。
  - 読み手への助言を、書き手の予定のような「〜します」「〜しておきます」で書いているときは、動作主と助言の働きが伝わる形に直します。敬体への指定がなければ、助言を表す自然な常体も保ちます。「まず」「次に」「最後に」は順序を示す語であり、動作主や文の働きを決める語ではありません。設計上の助言と、構成された道具の実際の動作が一文にある場合も、節ごとに区別します。
  - 決まりの文書で、「〜しましょう」「〜ことが重要です」が決まりそのものを書いているときは、「〜します」にそろえます。決まりの理由や前提を述べる文と、「〜してください」はそのまま残します。
  - 説明の文書で、書き手の側の予定や行動（「来月から担当を2人に増やします」）はそのまま残します。
  - 地の文の「です・ます」と「だ・である」が意図なく混在するときは、依頼と原文を手がかりにそろえます。常体を敬体にする指定があっても、助言・決まり・予定・説明の働きを変えません。
- 同じ立場の中の強さの違い（「〜しましょう」と「〜してください」、「〜が大切です」と「〜しましょう」）は変えません。強さを上げません（勧めを「〜しなければなりません」にしません）。ただし、相手との関係や書き手の希望が分かる依頼では、内容・条件・期限を保って語調を整えます。希望された「〜してもらえると助かります」などを依頼の表現として選ぶことと、元にない具体的な便益・感情・感謝を足すことは分けます。依頼の定型を一律に追加したり削ったりしません。期限を任意にせず、安全手順や決まりの必須の指示は弱めません。「ください」自体を一律に命令口調とはみなしません。
- 文末をそろえるためだけに主語は足しません。主述の対応を直すために補う場合は、「主語と目的語の明確化」に従い、原文や前後に根拠がある語だけを使います。
- 文末をそろえたときは、『変えたところ』に1行でまとめ、理由も短く書きます（例: 残しておきます・共有します → 残しておきましょう・共有しましょう）。
- 次のときは、「書き手に確かめたい点」に、もう一方の立場で書くときの文末を1行で示します（例: 「チームの決まりとして書く場合は、『〜しましょう』を『〜します』にそろえます」）。
  - 手がかりから立場を決めきれず、文末を変えると働きが変わり得るとき。
  - 依頼の分野や行き先と、本文の中身が食い違うとき（「業務仕様向け」なのに、本文は読み手への心得を並べているなど）。
  文末を1つも変えなかったときは、もう一方の立場の文末は書きません（ほかに確かめたい点があれば通常どおり提示します）。
- 文どうしをつなげて「〜しましょう」の数を減らすことはしません。項目どうしを1文にまとめると、主題や理由のかかる範囲と、項目どうしの比重が変わるためです。箇条書きを地の文にすると同じ文末が3つ以上続くときは、箇条書きのまま残します（domains/tech.md の「箇条書きは15%以下」より優先します）。地の文でもともと「〜しましょう」が続いている場合はそのままとし、働きの違う文末（「〜してください」など）に変えて散らしません。
- 今回の書き直しで新たに同じ呼びかけを増やした場合は、助言として扱った文・節の根拠と、文体を変える必要性を見直します。語尾の数だけを減らすために、義務・可能・評価へ置き換えません。
- 依頼か説明か決まらない場合は、原文を保ち、本文を確定するために必要な点だけ書き手に確認します。分からないことを理由に「〜してください」や「〜できます」へ決めません。言い切りの説明文を勝手に可能表現（〜できます）に変えません。

### 段落と文の論理構造（つながり）
AIが生成した文章は、文同士の接続関係が曖昧であったり、予告だけの空疎な文が挟まったり、段落内に複数の話題が混ざったりしがちです。以下の指針で論理の流れを整えます。
1. **文と文の接続関係の確認**: つなぎ言葉（ただし、しかし、また、そして、つまり、そのため等）、主題の「も」、文頭の指示語（これ、それ、こうした等）は、前後の文と「何と何をつないでいるか」を必ず確かめます。接続の根拠が前後から明確に分かる場合は適切な接続表現に直し、分からない場合は無理に直さず書き手に確認します。「自然に読めるか」という感覚だけで判断せず、論理的な接続先を特定します。
2. **予告だけの文の解消**: 中身を伴わない予告文（「注目すべき点があります」「次の点が挙げられます」等）は、予告が担っていた重み（注目すべき等）を述語に残しながら、続く中身の文と1文にまとめます。1文にまとめると意味が変わる場合は無理にまとめず残します。
3. **1段落1話題の徹底**: 段落は1つの話題で構成します。話題が異なる段落同士を安易にまとめません。逆に、1つの段落に異なる話題が混在している場合は、文の順序を崩さずに段落を適切に分けます。
4. **主述のかみ合わせ**: 主語と述語の対応が崩れている文は、元の文の意図が読み取れる範囲で自然に対応させます。
5. **修飾・条件・並列の関係**: 修飾語の掛かる先、条件・例外・否定・限定・数量が掛かる動作や判断を確かめます。並列した各項目が共通する述語につながるかも確認します。
6. **名詞の連続と長い節**: 名詞が続いたり、主語と述語の間に長い節が入ったりして、動作や判断の関係を追いにくくなっていないか確かめます。
7. **操作と結果の対応**: 注意事項で複数の操作と結果が並ぶときは、どの操作で何が残る・変わるかを読み手が区別できるか確かめます。対応を追いにくければ、必要な用語を残して、操作ごとに文や行を分けます。結果を表す語そのものの意味が確定しない場合は、配置だけで解決したことにせず、書き手に確認します。

読み違い、または関係を追う負担がある箇所を具体的に特定できた場合に、修飾語の移動、名詞を動作として書くこと、接続や読点の整理、文の分割を検討します。変更は問題箇所の近くに絞り、元から自然で関係が追える箇所は残します。原文と提供文脈から関係を確定できない場合は、その関係を勝手に決めて直さず、「書き手に確かめたい点」へ出します。文を切る・つなぐ・語順を変えるときも、条件・否定・因果・時系列・比重が掛かる範囲を保ちます。

接続を削る・変えるときは、必要な箇所だけ内部メモで「結論(比較, 方針)」「順序(A, B)」「条件(C, 動作)」のように関係を並べ、修正後も同じ対応を追えるか確かめます。不明な関係は「?」とし、因果や判断条件を作って埋めません。この表記は抜けを見つける補助であり、意味の等価性の証明ではありません。メモは出力に加えません。
構造を直す箇所では、原文を述語を中心とする短い語句に分け、主語・対象・扱いと、修飾語や指示語の係り先を対応づけます。書き直した文にも同じ点検を行い、語句が対応するだけでなく、関係が保たれるかを比べます。名詞に掛かる語を動作に掛かる語へ移す場合は、元と同じ意味と確認できる根拠が必要です。例えば「独立した展示」を「独立して担当する」へ変えると、展示の性質が担当者の行為へ移ります。文書の話題からそう読めそうというだけでは確定しません。不明な係り先は候補や「?」のまま残します。
助詞や修飾の位置を変えたり、名詞を動作として書いたり、述語を補ったりするときは、語が既出かだけでなく、対象と扱い、実行と待機の主体、修飾先が元と同じかを確かめます。原文が複数の読みを許す場合は、自然に言い換えるためだけに一つの読みへ決めません。関係が未確定なら本文で確定させず、何が不明かを書き手に確認します。

### 主語と目的語の明確化
単語の言い換えにとどまらず、「誰が・何を・どうした」を明確にします。ただし、省かれた目的語や対象を補うのは、前後の文にその語が明示されているときだけに限定します。文脈から分からない語を勝手に創作して足すことはしません。「これ」「片方」などの指示代名詞を名詞に戻すのも、指す先が文脈から分かるときだけに限定します。何を指すか追う必要がある名詞は、「もの」などへ不用意にぼかしません。助詞や使役を変えたときも、誰が何をどうするかの対応を確かめます。補った語がある場合は、出力の「変えたところ」に明記します。
複数の述語で動作主が変わる文は、述語ごとに「動作(主体, 対象)」を確かめます。使役は「誰が・何に・何をさせるか」を区別します。原文の語で対象が分かっていても、長い節を読み戻らないと追えない場合は、対象の再掲や節の分割を検討します。不明な主体や対象は作りません。
主述や使役の対応だけを直す場合は、まず原文の動詞を保ち、確定した主語・相手・対象を明記する案を検討します。動詞自体が不自然でなければ、対象を補うだけで伝わる文を別の長い構文へ組み替えません。比喩など動詞を直す理由がある場合も、元の動作と関係を保ちます。
処理や選別の対象を「もの」「それら」で省いている場合は、指す対象が原文や提供文脈から確定し、前の文から拾い直す必要があるときに、元にある名詞で明記します。近くにある名詞というだけで指す先を決めず、候補が複数ある場合は勝手に限定しません。確定した対象の再掲と、新しい対象を足すことを区別します。
動詞を言い換えた後も語順を確かめ、元の関係を保ったまま主語と述語を追いやすくする案を検討します。主述を近づけるために修飾先や条件の範囲を変えず、元から自然な語順は保ちます。

### 擬人化の解消
非生物主語を直すのは、道具や概念に感情や意志を持たせている擬人化表現（「コードが語る」「システムが願う」等）のときだけに限定します。道具や仕組みの働きを客観的に述べている文（「このツールはログを集めます」等）はそのまま残します。直す場合も、元にない条件（「〜を使えば」）や可能（「〜できます」）を足しません。

### 比喩動詞の具体化
「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません。
**比喩や言い回しが持っていた「含み（気持ちや評価の向き）」は必ず残します。**
- 含みの例: 「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔、「地味に」の目立たないけれど確かにある感じ。
- 比喩の語は言い換えて構いません。ただし、その語が伝えていた含みや理由は、別のふだんの言葉で補って言い表します。
- 比喩動詞だけでなく、副詞や前置きの言い回しも同じ扱いにします。
データやシステムに対して使われる「壊れる」は、「おかしくなる」「使えなくなる」のように、意味の広さが同じふだんの言葉に改めます。「データの整合性が失われる」「不整合が生じる」と書くのは、元の文や前後から、明らかに整合性の話だと分かるときだけに限定します。時計や機械など物理的な物体や、身体（お腹を壊す等）の文字どおりの「壊れる」はそのまま残します。また、「静かに」「黙って」のようなぼかしは、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。「エラーを出さずに」「通知なく」のように仕組みの話として書くのは、元の文や前後から、エラーや通知が出ないことがはっきり分かるときだけに限定します。
また、「骨が折れる」「手を焼く」「目から鱗が落ちる」「首を長くして待つ」のような、ふだんの日本語で定着した慣用句は、AIっぽい比喩として扱わずそのまま残します。業務仕様でも、意味を取り違えるおそれがなければ残します。迷ったときの目安は、その言い方を、AIが広まる前の人の文章でもふつうに見かけるかどうかであり、見かけるなら残します。

### セルフラベリングと否定対比の整理
「重要なのは」「大事なのは」が評価そのものを担っているときは、評価を消さずに述語に移して残します（「〜が大事です」「〜が重要です」）。前置きを削ってよいのは、削っても主張が変わらないときだけです。
前置きが理由・対比・結論や、説明から方針への切替を示す場合は、その関係を残します。「結論として」が比較結果と採用方針をつないでいる場合など、他の語から同じ関係が読めなければ削りません。
否定対比（AではなくB）は、否定を外しても主張が変わらないときだけ肯定文にします。Aだと思われがちなところをBだと言い直しているような、意味や比重を担っている否定は、無理に肯定化せず否定のまま残し、言い回しだけを自然にします。否定していたAを「Aに加えてB」と並べたり、「AよりB」と順位づけしたりしません。否定を残すときに、元にない理由の文は足しません。

### 情報の不増補（足さない）
元の文や前後から分からない動作主、名詞、行動、原因、条件、数値、例、専門用語は足しません。ぼかした語を、より狭い具体的な事実に勝手に置き換えることもしません。情報が足りず具体的に書けないときは、本文で勝手に補わず、出力の最後に「書き手に確かめたい点」として提示します。

### 内容に合わない大げさな名詞の整理
決まりや方針を「契約」、原文や比較の基準を「正本」と大げさに呼んでいる場合は、「ルール」「方針」「原文」「比較の基準」「参照するファイル」等、実際の役割に合う語へ直します。手段や書き方を曖昧に「仕組み」と呼んでいる場合も、原文から分かる内容に合う語で書きます。
取引や合意としての契約、正式な文書を区別する正本、処理の関係や動作を説明する仕組み、内容が定義されている専門用語は、その意味を保ちます。置換先で信頼性・唯一性・更新元という役割を新たに足しません。原文にある唯一性や評価の強さも落としません。詳しい用例は `references/slop-catalog.md` を参照します。

### 文長と読点の調整
文の平均の長さは30〜45字程度、1文あたりの読点は0〜2個を目安にします。読点は、不自然な位置や掛かり先を読みにくくする箇所で調整します。元から読みやすい文の読点を、数や見た目だけで削りません。文が長いことだけを理由に文を分けることはしません。長い文を分けるのは、前後のつながり（手段・理由・順序・対比）を、後ろの文のつなぎ言葉（そのため、こうすることで、一方で、反対に等）で残せるときだけに限定します。目的や理由が文末の結論にかかっている文（例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です／〜しますの形）は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。

読点の整理だけを理由に、元から読みやすい文の語順や述語を組み替えません。

### 装飾記号と不要な空白の排除
絵文字、文末コロン、ダッシュ記号（em dash）、情報量の増えない言い換えカッコ、和欧文間の不自然な半角空白を排除します。
ただし、「日時：10時」「対象：社内ポータル」のように、ラベルと値の対応を示すコロンは文末の装飾とは区別し、元の区切りを残します。URLやコード内のコロンも変更しません。
また、Markdownとして表示される文章（GitHubや技術記事など）で太字を残すときは、太字として正しく表示される書き方に整えます。GitHubなどでは、`**` のすぐ内側が記号（「」『』（）【】、。やバッククォート等）で、すぐ外側が文字（ひらがな・漢字・英数字）だと、太字にならず `**` がそのまま表示されてしまいます。太字を残すときは、次の優先順で直します。
1. かっこごと太字にしているときは、かっこの内側だけを太字にします（例: `次に**「文書の立場」**を決めます。` → `次に「**文書の立場**」を決めます。`）。
2. 太字の終わりが句点などのときは、句点を太字の外に出します（例: `これは**必須です。**詳しくは下に書きます。` → `これは**必須です**。詳しくは下に書きます。`）。
3. 1と2ができないとき（コードで始まる・終わる太字、かっこが2つ以上ある太字など）は、`**` の外側の、文字に接する側に半角スペースを1つ入れます（例: `立場は**「勧め」か「決まり」**で決めます。` → `立場は **「勧め」か「決まり」** で決めます。`）。
この半角スペースは表示のためのものであり、排除対象の不自然な半角空白には当たらないため消しません。
元の文で太字にならない書き方になっている箇所は、太字を残すなら、ほかに直す箇所がない文でも同様に直します（意味は変わらないため「変えたところ」には書きません）。これは太字を増やす決まりではなく、太字を減らす決まり（domains/tech.md の1,000文字あたり1〜2箇所など）はそのまま維持します。

---

## 2. 実行手順

### Step 1: 文脈と段落の把握

書き直す前に、文章全体と段落の流れを確認します。
1. **ドメインの判定**: 入力されたテキストや指示文からドメインを判定します。
   - `tech` (技術記事): 技術ブログや設計書。箇条書きを15%以下に抑え、元の文や資料にある情報の範囲で手順を整理します。
   - `business` (業務・仕様書): PR説明文や社内レポート。比喩の理由は残しつつ客観的な表現に改め、元の文から分かる範囲で境界条件や責任主体を明記します。
   - `essay` (エッセイ・個人発信): noteや個人雑記。大げさな教訓化を避け、素朴な感情と具体的な体験を残します。
2. **段落の話題と文の関係の把握**
   - 段落ごとに「何の話をしているか」を1行でつかみます。話題が異なる段落同士はまとめず、話題が混ざっている段落は分割を検討します。
   - 文ごとに、前の文とどのような関係にあるか（理由、例示、但し書き、言い換え、補足、まとめ等）を確かめます（このメモは出力には出しません）。
3. **意味の4点の確認**: 元の文の「主張」「比重」「言い切りの強さ」「文の働き」を確認します。
4. **文書の立場と文体の確認**: 「文書の立場と文末」に従って、文書の主たる目的と、各文・各節の働きの根拠を確かめます。常体・敬体の変更指定は別に確認します。立場を決めきれない箇所は、不確かなまま文末で確定しません（このメモは出力には出しません）。
5. **文の構造の点検**: 語を言い換える前に、主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけます。条件・例外・否定・並列の関係と、名詞の連続も確かめ、読み違いや関係を追う負担がある箇所を特定します。関係が確定しない箇所と、変更が不要な箇所も区別します（このメモは出力には出しません）。

### Step 2: 文章の書き直し

`references/gemini-syntax.md` およびドメイン別仕様に従い、以下の手順で変換します。

1. 元の文から分かる範囲で、動作主（主語）や対象を明確にします。省かれた目的語や対象を補うのは、前後の文にその語があるときだけに限定します（補った場合は「変えたところ」に出します）。
2. 文末は、Step 1で確かめた各文・各節の働きに合わせます。適切な文末と、変更指定のない常体・敬体は保ちます。指定に応じて文体を変える場合も、動作主や文の働きを変えません。
3. 指示代名詞（これ、片方など）は、指す先が文脈から分かる場合のみ具体的な名詞に戻します。
4. 比喩動詞や言い回しは、ふだん使う言葉や文脈に合った言葉に置き換えます。データやシステムの「壊れる」は「おかしくなる」「使えなくなる」のように同等の広さの言葉にし、整合性の文脈であることが明らかな場合のみ「整合性が失われる」等とします。「静かに」「黙って」は「気づかないうちに」「知らないうちに」のように気づけない幅のまま直します。定着した慣用句や含みは維持します。
5. 重複する補足カッコを削り、英単語前後の余計な半角空白を除去します（太字の表示のために ** の外側に入れる半角スペースは除きます）。
6. 「重要なのは」が評価を担っているときは述語に残し、否定対比（AではなくB）は意味や比重を担っているなら否定を残したまま表現を整えます。
7. 「装飾記号と不要な空白の排除」に従い、絵文字、文末の装飾としてのコロン、ダッシュ記号を排除します。ラベルと値の区切りは残します。ダッシュを外して前後を1文につなぐとき、前にある理由や条件（「〜ため」「〜なら」など）がつないだ後ろの部分までかかるようになるなら、2文に分けます。
8. 文末のリズム調整は、AIっぽさを直すついでに同一文末が3連続した場合にのみ行います。AIっぽさのない自然な文は文末だけを変えません。直す箇所がほとんどない場合は無理に書き換えません。文をつなげて「〜しましょう」の数を減らすことはせず、地の文でもともと続いている場合はそのままとします（働きの違う文末に変えて散らしません）。箇条書きを地の文にすると同じ文末が3つ以上続くときは、箇条書きのまま残します。
9. 箇条書きを地の文にするときも、各項目の働きと、変更指定のない常体・敬体を保ちます。「〜する」「〜しない」がそのまま文として使えるなら、語尾を足さずに残します。文書が勧めであることだけを理由に「〜しよう」「〜しましょう」へ変えません。評価や義務を足さず、単に並んでいるだけなら箇条書きのまま残してよい決まりも維持します。
10. つなぎ言葉（ただし、しかし、また、そして、つまり等）、主題の「も」、文頭の指示語は、前後の接続先を確かめ、正しく合致するものに整えます（直した場合は「変えたところ」に出します。判断がつかない場合は無理に直さず「書き手に確かめたい点」に出します）。
11. 中身を伴わない予告文は、予告の重みを述語に残して中身の文と1文に統合します（統合した場合は「変えたところ」に出します。統合すると意味が変わる場合は残して「残したAIっぽいところ」に出します）。
12. Step 1で特定した構造上の問題を、元の意図が分かる範囲で整えます。主述の対応、修飾語の位置、名詞の連続、接続や読点を問題箇所の近くで直し、条件・否定・並列・順序が掛かる範囲を保ちます。関係を確定できない箇所は勝手に決めず、「書き手に確かめたい点」へ出します（意味が動きやすい修正は「変えたところ」に出します）。
13. 文が長いことだけを理由に文を分けません。長い文を分けるのは、前後のつながり（手段・理由・順序・対比）を、後ろの文のつなぎ言葉（「そのため」「こうすることで」「一方で」「反対に」など）で残せるときだけに限定します。目的や理由が文末の結論にかかっている文（例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です／〜しますの形）は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。
14. 太字を残すときは、「装飾記号と不要な空白の排除」の書き方に従い、太字として表示される形にします。
15. 「内容に合わない大げさな名詞の整理」に従い、語の指す役割を確かめて直します。書き直した本文だけでなく、変更理由や確認事項でも、元にない約束・制約・信頼性を感じさせる語へ言い換えません。

### Step 3: 静的検査（リンター）

フルモード指定時やファイル保存時は、同梱のリンターを実行して静的検査を行います。

```bash
# スキル配置先（${CLAUDE_SKILL_DIR}等）を基準にスクリプトの絶対パスを解決して実行
python3 <スキル配置ディレクトリ>/scripts/yomiyasu_lint.py <対象ファイル>
```

検出結果は機械的な見直し候補の位置づけです。文脈上正当な専門用語や事実の記述であれば無理に言い換えず保持します。また、「大事です」のように評価を担う語や、主張上必要な否定（AではなくB）も、リンターの指摘があっても無理に消さず残します。ただし、bold_not_rendered（太字にならない書き方）が出た場合は、元の太字が正しく表示される書き方になっているかを確認します。すでに正しく表示される書き方であれば変更しません。修正が必要な場合も、案によって太字の範囲や前後の文が崩れないかを確認したうえで適用し、不確かな案はそのまま適用せず目視で整えます。修正試行は最大2回とし、警告を消すためだけの過剰な言い換えループを防止します。

### Step 4: 足したもの・削ったものの点検（Diff検査）

書き直した文ができたら、元の文と書き直した文を比較し、意図しない情報の増減やつながり、文末の乱れがないかを点検します。

```bash
# 元の文と書き直した文をファイルに保存して差分スクリプトを実行
python3 <スキル配置ディレクトリ>/scripts/yomiyasu_diff.py 元の文.txt 書き直した文.txt --stance=<勧め|決まり|説明>
```

※ `--stance` には Step 1で確かめた主たる立場（`勧め`、`決まり`、`説明` のいずれか）を指定します。決めきれない場合は省略します。出力される候補を理由に、働きの違う文まで同じ文末へそろえません。

スクリプトが出力した候補を1つずつ確認し、以下を判断します。
- 文末の種類と立場: 文末の種類が変わった文と、立場に合わない文末の候補を確認します。候補のうち、仕組みの説明ややり方の手順のように立場に合っているものは残します。
- 言い回しの種類（依頼・義務・評価・可能等）が増減している場合: 元の文の働きからずれていれば元の表現に戻し、正当な言い換えであれば残して「変えたところ」に記載します。
- 元にない語や消えた語: 勝手な情報の付け足しや、必要な前提の脱落がないか確認します。
- 箇条書きや段落の変化: 箇条書きを地の文にした際に余計な評価や義務が足されていないか、段落統合によって話題が混ざっていないかを確認します。
- つながりの確認箇所: つなぎ言葉や指示語が前後の文と論理的につながっているかを確認します。
- 構造の変更箇所: 誰が何をどの条件で行うか、修飾先、例外・否定・限定・数量、並列や出来事の順を、元と同じように追えるか確認します。関係を見失う箇所や、不要に読み戻る箇所が減ったかも確かめます。
- 名詞と説明文: 本文と「変えたところ」等の説明文で、語が指す役割に合っているか、元にない信頼性・唯一性・約束などが足されていないかを確認します。
- 太字の表示: 「太字にならない書き方」が出たら、元の太字の表示可否と案の範囲を確認し、適切であれば案に従って直します（すでに正しく表示される場合や不確かな案はそのまま適用せず、意味が変わらないため「変えたところ」には書きません）。

修正は1回のみ行い、スクリプトの再実行を繰り返す往復は行いません。Pythonが実行できない環境では、上記と同じ観点（文末が立場にそろっているか、言い回しの増減、元にない語、消えた語、段落・箇条書きの変化、接続関係、太字が表示される書き方か）を目視で点検します。

---

## 3. 出力フォーマット

対話リライト時には、以下のフォーマットで提示します。絵文字や不要なカッコは使用しません。

```markdown
### 書き直した本文

（自然な日本語に再構築された本文）

---

### 変えたところ
- （意味が動きやすい変更、つながりを直したところ、文末を立場に合わせてそろえたところ、補ったものだけを、最大5点まで記載。文末をそろえた箇所は1行にまとめて記載。該当がなければ「なし」と1行で記載）
- 元の表現 → 書き直し後の表現（変更理由）

### 残したAIっぽいところ（※意味や重みを担っているため消さずに残した前置きや結びがある場合のみ記載。なければこの見出しごと出さない）
- （残した表現と、意味や重みを保つために残した理由）

### 書き手に確かめたい点（※意味・条件・用途などが不明で、本文を確定するために確認が必要な場合のみ、最大2点まで記載。なければこの見出しごと出さない）
- （未確定の内容と、本文にどう影響するかを短く記載。提供済みの文脈は聞き直さず、意味を保って残せる表現を削るかどうかという好みの問いは出さない）
```

More agent context in nanaism/yomiyasu

One other file this repository gives its agents.