yomiyasu

---
name: yomiyasu
description: AIが生成した日本語を推敲するスキル。利用者が yomiyasu の名前を出して頼んだとき（「/yomiyasu」、「$yomiyasu:yomiyasu」、「yomiyasu で推敲して」など）と、スキルを使った日本語の推敲をはっきり頼んだときだけ使う。CLAUDE.md、AGENTS.md、カスタム指示などで yomiyasu を使うよう求められているときも、名前を出して頼まれたものとして扱う。名前を出さずに日本語の文章を書かせる依頼や、コード、設定、ドキュメントの更新では使わない。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。
license: MIT
allowed-tools: Bash(python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_lint.py *) Bash(python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py *) Bash(python ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_lint.py *) Bash(python ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py *) Bash(py -3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_lint.py *) Bash(py -3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py *)
metadata:
  version: "2.5.0"
---

# yomiyasu

「/yomiyasu」や「$yomiyasu」と名前だけで呼ばれ、推敲する文章を渡されなかったときは、直前の自分の返答に依頼を受けて書いた本文があればそれを推敲します。作業の報告や変更の説明は、ここでいう本文に入りません。そうした本文がなければ作業フォルダの直下の `.md` と `.txt` を一覧し、`AGENTS.md` や `CLAUDE.md` のような指示のファイルと、yomiyasu が作った抜き書き（最終稿の名前.material.txt）を除いて1つならそれを推敲し、2つ以上ならどれかを聞き、どちらもなければ文章を貼るように頼みます。こうしてファイルを選んで推敲したときは、最終稿を原文と同じフォルダにまだない名前で保存し、原文のファイルは書き換えません。「適用します」「有効にしました」とだけ返して終えません。

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

他の日本語校正スキルと併用すると、指示が食い違う場合があります。出力が乱れる場合は、類似スキルを無効にして使うことを検討してください。

### 用途と表記の扱い
- 原文があれば推敲として、資料（依頼文だけのときは依頼文）から書くなら新規作成として進めます。新規作成では資料の書き方をそのまま写さず、依頼にある読み手と目的に合わせて書き、書いたあとで主張・条件・担当・数値・未確認の事項が資料どおりかを読み比べます。原文と資料の両方があれば推敲として進め、資料も検査に渡します。
- 補助動詞と、形式名詞の「事」「為」を漢字で書いた形は、ひらがなに直します（実行して下さい → 実行してください、指定出来ます → 指定できます、確認して頂く → 確認していただく、試して見る → 試してみる、する事が → することが、する為に → するために）。「事の経緯」のような中身のある名詞の漢字は残します。
- それ以外の表記の揺れは直しません。外来語の長音（サーバとサーバー、ユーザとユーザー）、送り仮名、上の補助動詞と「事」「為」以外の漢字とかなの使い分け（掛かる、全て）、数字や英字の全角と半角は、見出しと本文や同じ文書の中で書き方がそろっていなくても、原文のままにします。表記の統一は、表記の校正のスキルに任せます。

---

## 1. 基本原則

「**意味の保持（主張・比重・言い切りの強さ・文の働きを変えないこと）**」と「**情報の不増補（勝手に足さないこと）**」を最優先にします。
元の文章が伝える内容は変えず、不自然な比喩、余計な装飾、主述の不一致、文のつながり、立場に合わない文末を直します。

### 最優先ルール: 意味の保持
書き直す前に元の文の次の4点を確かめ、書き直したあとも必ず同じに保ちます。他の原則は、この4点を変えない範囲でのみ適用します。
1. **主張（何を言っているか）**: 伝えたい要点や論理関係を維持します。「本質」「核」などの論点を「目的」など別の概念にすり替えたり、勝手に動詞を足して論点を変えたりしません。
2. **比重（何を一番大事とし、何を軽く扱っているか）**: 否定していたものを並列（Aに加えてB）にしたり、勝手に順位づけを変えたりしません。比較や最上級は、何を比べているかも保ちます。差や食い違いを述べる文では、何と何の差かを示す語句を、短くするために削りません。重要度の評価を、頻度や見落としやすさの評価に変えません。何の比較か分からなければ原表現を残します。
3. **言い切りの強さ（断定・推量・可能性、許可・能力・保証）**: 元の文が言い切っていることは言い切ったまま、推量や可能性で書いていることはその強さのまま書きます（「おそれがあります」と弱めたり、「〜と言えるでしょう」を断定に強めたりしません）。許可（〜してよい）、能力・権限（〜できる）、義務（〜しなければならない）、保証（必ず〜する、〜を保証する）の言い方も、この強さに入ります。仕様書や設計文書では、これらの違いがそのまま仕様の違いになるので、「含めてよい」を「含められる」や「含める」にしたり、「〜場合がある」を消して言い切ったり、説明に「必ず」「保証する」を足したりしません（「〜することができる」を「〜できる」にするような、同じ言い方の中での言い換えは構いません）。
4. **文の働き（評価・説明・依頼・予定・感想）**: 評価の文は評価のまま、説明は説明のまま保ちます（「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文に変えません）。実施済みの変更、現在の動作・方針、今後の予定を時制と役割に合わせて書き分け、完了した変更を予定のような表現にしません。文末は、文書の目的を手がかりに、各文・各節の動作主と働きに合う形を選びます。常体・敬体の選択とは分けて判断します（詳細は「文書の立場と文末」を参照してください）。

「文の働き」は、文の種類として確かめます。書き直す前に、各文が「事実」「意見・評価」「依頼・決まり」「例え・比喩」「皮肉・冗談・反語」「仮定・予測」「引用・伝聞」のどれにあたるかを内部メモに記録し、書き直したあとで種類が変わっていないかを読み比べます。伝聞（「〜とされる」「〜らしい」）を断定にする、意見（「〜と思う」）を事実として言い切る、依頼を説明に変える、例え（「まるで戦場のようだ」）を「戦場だ」と言い切る、反語をただの疑問にする、仮定を予定にする、といった書き換えはしません。種類は、その文が何を述べているかで決めます。「休日を溶かした」のように比喩動詞を含む文は、事実の文として扱います。皮肉や反語は、文脈から確定できるときだけその種類とします。
文を分けたりつないだりするときは、元の各文の種類を、書き直した文のどこかで保ちます。種類を決めきれない文は、無理に一つに決めず、候補を残したまま扱います。種類が変わった文は元の種類に戻し、元の種類のままでは直せない場合は、元の文を残して「書き手に確かめたい点」に出します。小説や人文系の文章で、書き手がわざと複数の読みを残している箇所は、一つの読みに決めて直しません。書き手の決意や抱負を述べる結びも、書き手の意思を伝える文として内容を残し、大げさな語だけを直します。書き手の評価や実感を述べる「〜ことができました」（「今月も、計画どおりに作業を進めることができました」）は、「進められました」「進めました」のように外枠を外して短くせず、そのまま残します。種類の記録は内部メモであり、出力には出しません。

### 文書の立場と文末
日本語は主語を省くことが多く、文末の形が「誰が動くのか」「決まりなのか、勧めなのか、説明なのか」を伝えます。文末を選ぶ前に、「誰が、誰に、何のために、いつのこととして書くか」を手がかりとして、まず文書全体で読み手に知らせる主たる用件を確かめ、その用件を果たすために各段落で伝える内容を決めます。これらを機械的に本文へ明記するのではなく、文末や語調を選ぶ基準とします。文書や段落の目的をそろえることと、すべての文末を同じ種類にすることは別です。助言を含む文書でも、事実や道具の動作を説明する文は説明のまま残します。
変更内容の報告を求められた場合は、提供された事実をもとに「どの指針・設定・実装を、どう改めたか」を、書き手の改定行為として述語まで書きます。「指針を改定しました」と一般的に宣言した後に方針宣言を並べただけでは、報告できたとはみなしません。変更したと分かる内容だけを改定として報告し、現在の動作・仕様・方針しか分からない記述を今回導入・変更・維持した事実へ勝手に変えません。改定前の内容が未提供なら前後比較や追加、改善幅を作らず、現在の動作や方針を補足する場合も、何の現在の状態を説明しているか、既知の改定とどういう関係なのかが読み手に伝わるように書き分けます。
現在の推敲方針や設定済みの指示を補足するときは、書き手の作業予定に見える「〜します」ではなく、誰の現行方針かを確かめた上で「〜するようにしています」「〜する方針です」「〜するよう指示しています」など、主体と状態が読める形にします。ただし「ようにしています」を万能語尾にせず、システムの実動作（「返します」）、利用可能な機能（「できます」）、手順書、読み手への依頼（「してください」）、将来計画（「予定です」）はそれぞれ適切な表現を保ちます。現在の方針を今回新設・変更・維持したという履歴や確実な実行性能、未知の原因・主体は作りません。関係が不明なら因果を作らず、完了した変更を予定のような「〜します」にしたり、現在の実動作や仕様説明をすべて過去形に揃えたりもしません。
常体・敬体は、変更の指定がない限り原文を保ちます。技術記事という分野だけを理由に敬体へ変えません。混在を直す場合も、文の働きとは別に文体を選びます。
文脈が明確でない場合は余計な内容を書き足さず、明確な場合は読み手が理解できるように説明します。読者の理解に必要な定義、識別子、値と状態の対応が依頼や文脈で提供されている場合は、説明に活かします。何の文章かが分かりにくいときは、提供された用途や読み手を、短い見出しや冒頭の説明で示します。分からない主体・意図・条件は推測で補いません。
- 立場は次の3つのどれかです。
  - **勧め**: 読み手に勧める・頼む文書（心得、助言、呼びかけ）。動作をするのは読み手です。
  - **決まり**: 決まり・手順を伝える文書（運用ルール、手順書、お知らせ、仕様）。動作をするのは手順に従う読み手、または方針を決めた書き手です。
  - **説明**: 事実・結果・考えを伝える文書（技術の説明、報告、体験）。
- 立場は、上の手がかりほど優先して決めます。
  1. 依頼にある行き先と読み手（「社内ブログ向け」「上長への報告」「チームの運用ルールとして」など）。「技術記事向け」「業務仕様向け」「エッセイ向け」のような分野の名前だけでは、立場を決めません。同じ分野の中に、決まり・報告・勧めの文書があるためです。
  2. 本文の手がかり（「私は」「当チームでは」などの主語、宛名・署名・日付、見出し）。
  3. 決まりと読む手がかりがないことだけでは、勧めとも決めません。助言・決まり・予定・説明のどれかを確定できないときは、文末で勝手に決めず、「情報が足りない場合の暫定文」に従います。
- 文末や語尾を見直すのは、次のときです。
  - 文末によって動作主、時制、文の働きが意図とずれて読めるとき（助言が予定の表現になっている、完了した変更報告が予定の「〜します」になっている等）。
  - 指定された文体へ変えるときや、箇条書きを地の文に書き直すとき（文末の形を選び直しても、各文の働きは保ちます）。
  - 依頼にある行き先や読み手と、文末の立場が合わないとき。
  - 地の文の「です・ます」と「だ・である」が意図なく混在するとき。
  - 立場や時制が適切でも、類似した変更動詞や同じ文末が続いて単調で読みにくいとき（この場合は立場・働き・時制を保ったまま、語順や文のまとめ方を工夫して言い回しを整えます。語尾を散らす目的で文の働きや時制を変えたり、自然な文末を無理に変えたりはしません）。
  文末が文書の中でそろい、動作をする人と文の働きが依頼や本文の手がかりに合っているときは、文末を変えません。文末がそろっていることだけでは、立場が適切だとは判断しません。実際の処理や操作を「〜します」で説明し、最後の1文だけを「〜しましょう」で結ぶ形は、混ざっているとみなしません。原則や大事な点を述べる文と、行動を示す文も、それぞれの働きに合っていれば残します。
- 立場・働き・時制を直すときは、合わない文末だけを直します。
  - 読み手への助言を、書き手の予定のような「〜します」「〜しておきます」で書いているときは、動作主と助言の働きが伝わる形に直します。敬体への指定がなければ、助言を表す自然な常体も保ちます。「まず」「次に」「最後に」は順序を示す語であり、動作主や文の働きを決める語ではありません。設計上の助言と、構成された道具の実際の動作が一文にある場合も、節ごとに区別します。
  - 決まりの文書で、「〜しましょう」「〜ことが重要です」が決まりそのものを書いているときは、「〜します」にそろえます。決まりの理由や前提を述べる文と、「〜してください」はそのまま残します。
  - 説明の文書で、書き手の側の予定や行動（「来月から担当を2人に増やします」）や、実施済みの変更（「方針を変更しました」）はそのまま残します。完了した変更を予定のような文にしません。
  - 地の文の「です・ます」と「だ・である」が意図なく混在するときは、依頼と原文を手がかりにそろえます。常体を敬体にする指定があっても、助言・決まり・予定・説明の働きを変えません。
- 同じ立場の中の強さの違い（「〜しましょう」と「〜してください」、「〜が大切です」と「〜しましょう」）は変えません。強さを引き上げません（勧めを「〜しなければなりません」に変えないなど）。ただし、相手との関係や書き手の希望が分かる依頼では、内容・条件・期限を保って語調を整えます。希望された「〜してもらえると助かります」などを依頼の表現として選ぶことと、元にない具体的な便益・感情・感謝を足すことは分けます。依頼の定型を一律に追加したり削ったりしません。期限を任意にせず、安全手順や決まりの必須の指示は弱めません。「ください」自体を一律に命令口調とはみなしません。
- 文末をそろえるためだけに主語は足しません。主述の対応を直すために補う場合は、「主語と目的語の明確化」に従い、原文や前後に根拠がある語だけを使います。
- 文末をそろえたときは、『変えたところ』に1行でまとめ、理由も短く書きます（例: 残しておきます・共有します → 残しておきましょう・共有しましょう）。
- 次のときは、「書き手に確かめたい点」に、もう一方の立場で書くときの文末を1行で示します（確かめたい点の3点の中に数えます。例: 「チームの決まりとして書く場合は、『〜しましょう』を『〜します』にそろえます」）。
  - 手がかりから立場を決めきれず、文末を変えると働きが変わり得るとき。
  - 依頼の分野や行き先と、本文の中身が食い違うとき（「業務仕様向け」なのに、本文は読み手への心得を並べているなど）。
  文末を1つも変えなかったときは、もう一方の立場の文末は書きません（ほかに確かめたい点があれば通常どおり提示します）。
- 文同士をつなげて「〜しましょう」の数を減らすことはしません。項目同士を1文にまとめると、主題や理由の掛かる範囲と、項目同士の比重が変わるためです。地の文でもともと「〜しましょう」が続いている場合はそのままとし、働きの違う文末（「〜してください」など）に変えて散らしません。
- 独立した変更点、手順、担当と結果の対応など、並列関係が明確で読みやすい箇条書きは、AI調に見えるという印象や比率の数値だけで無理に地の文へ戻さず残します。箇条書きを地の文にすると同じ文末が単調に続くような場合も、箇条書きのまま残します。
- 書き直しで新たに同じ呼びかけを増やした場合は、助言として扱った文・節の根拠と、文体を変える必要性を見直します。語尾の数だけを減らすために、義務・可能・評価へ置き換えません。
- 依頼か説明か決まらない場合は、その働きを未確定のまま扱い、「情報が足りない場合の暫定文」に従います。分からないことを理由に「〜してください」や「〜できます」へ決めません。言い切りの説明文を勝手に可能表現（〜できます）に変えません。

### 段落と文の論理構造（つながり）
AIが生成した文章は、文同士の接続関係が曖昧であったり、予告だけの空疎な文が挟まったり、段落内に複数の話題が混ざったりしがちです。以下の指針で論理の流れを整えます。
1. **文と文の接続関係の確認**: つなぎ言葉（ただし、しかし、また、そして、つまり、そのため等）、主題の「も」、文頭の指示語（これ、それ、こうした等）は、前後の文と「何と何をつないでいるか」を必ず確かめます。接続の根拠が前後から明確に分かる場合は適切な接続表現に直し、分からない場合は無理に直さず書き手に確認します。「自然に読めるか」という感覚だけで判断せず、論理的な接続先を特定します。
2. **予告だけの文の解消**: 中身を伴わない予告文（「注目すべき点があります」「次の点が挙げられます」等）は、予告が担っていた重み（注目すべき等）を述語に残しながら、続く中身の文と1文にまとめます。1文にまとめると意味が変わる場合は無理にまとめず残します。「重要なポイントは3つです」「以下の3つの観点から説明します」のような数の宣言も、宣言した数と続く項目の数が合っている場合に限り、同じ基準で続く中身の文と1文にまとめます。ただし、長い説明で項目数の予告が読み手の案内になっている場合は残します。数が合わない場合は、宣言の数も項目も変えずに「書き手に確かめたい点」に出します。宣言の数にそろえるために項目を足したり削ったりしません。
3. **1段落1話題の徹底**: 段落は1つの話題で構成します。話題が異なる段落同士を安易にまとめません。逆に、1つの段落に異なる話題が混在している場合は、文の順序を崩さずに段落を適切に分けます。
4. **主述のかみ合わせ**: 主語と述語の対応が崩れている文は、元の文の意図が読み取れる範囲で自然に対応させます。動作を名詞にした主題に、その動作のために要ることを述べる述語が続く文は、主題を「〜を〜するには、」の形にして、何をするための話かが分かるようにします（「ログの一括削除は、保存先の権限も変える必要がある」→「ログを一括で削除するには、保存先の権限も変える必要がある」）。
5. **修飾・条件・並列の関係**: 修飾語の掛かる先、条件・例外・否定・限定・数量が掛かる動作や判断を確かめます。並列した各項目が共通する述語につながるかも確認します。
6. **名詞の連続と長い節**: 名詞が続いたり、主語と述語の間に長い節が入ったりして、動作や判断の関係を追いにくくなっていないか確かめます。漢語の名詞を、助詞を落として詰めた句（「書類不備発見時は」「設定変更後に」）は、語を残したまま助詞と動詞を補ってほどきます（「書類の不備を発見したときは」「設定を変更したあとに」）。漢語を和語に替えることは、この直し方に入りません。ほどくと「とき」のような同じ語が近くで続くなら（〜したときや〜したとき）、「時」「際」を残すか、その句をほどかずに残して、同じ表現を続けて使いません。その分野で定着した複合語（ログイン画面、文字コード）と、報告書・公用文・論文の正式な語は、詰まりとして扱いません。
7. **操作と結果の対応**: 注意事項で複数の操作と結果が並ぶときは、どの操作で何が残る・変わるかを読み手が区別できるか確かめます。対応を追いにくければ、必要な用語を残して、操作ごとに文や行を分けます。結果を表す語そのものの意味が確定しない場合は、配置だけで解決したことにせず、書き手に確認します。

同じ段落で一つの問題を説明した後、その対策を述べる文でも同じ問題を長く言い直している場合は、「この問題を防げます」のように、明確な指示語で受けます。原文にある反復だけでなく、書き直しで新たに重複した説明も整理します。複数の問題や条件の切替で、どの対象かを追うために必要な再掲は保ちます。
本文で言い終えた内容を「まとめると」「結局のところ」「要するに」などで同じ強さのまま言い直すだけの締めの文や段落は削ります。短い文書の最後で本文を繰り返すだけの「まとめ」見出しと段落も同じです（依頼でまとめの節やページを指定されているときは残します。「案内用の見出し」）。新しい情報や条件、結論の絞り込みを加えている場合と、長い文書や発表で要約の役割を担う場合は残します。報告やお知らせの最後で次にすることや予定を述べる文（「来月は、残りの移行と権限の見直しを進めます」）は、本文の予定と重なっていても、読み手が次の動きを確かめる文なので残します。削る前に、その箇所にしかない数値・条件・例外がないかを確かめ、あれば削らずに残すか、同じ意味で本文へ移します。削った場合は「変えたところ」に出します。
改行は、話題や説明の段階が切り替わり、分けると読みやすくなる箇所で、意味のまとまりごとに使います。出来事、現在の状態、今後の予定のように、報告の説明段階が切り替わる箇所でも、分けると読みやすければ改行を使います。新たに本文の行を分けるときは改行1つを基本とし、読みやすさを理由に空行を一律に増やしません。時制が変わるたびに機械的に改行したり、常に三段構成にしたりせず、条件と結果、理由と結論、操作の順序を読み違える位置では分けません。元からある意図的な段落分けや、見出し・箇条書き・コードなどの書式上の区切りは保ちます。Markdownの改行指定と通常の行分けを取り違えず、句点ごとに機械的に改行せず、元から自然な短い段落や改行は保ちます。

読み違い、または関係を追う負担がある箇所を具体的に特定できた場合に、修飾語の移動、名詞を動作として書くこと、接続や読点の整理、文の分割を検討します。変更は問題箇所の近くに絞り、元から自然で関係が追える箇所は残します。原文と提供文脈から関係を確定できない場合は、その関係を勝手に決めて直さず、「書き手に確かめたい点」へ出します。文を切る・つなぐ・語順を変えるときも、条件・否定・因果・時系列・比重が掛かる範囲を保ちます。筆者が情報を見聞きした日時と、出来事そのものが起きた日時は区別します。述語ごとに誰の動作や報告かを対応づけ、見聞きした日時を出来事の日時へ移したり、現在の報告や伝聞を過去の発言へ勝手に変えたりしません。引用や予定、日時が指定されていない出来事も、意味や時制を保って書き分けます。原文の各主張の動作主・述語・対象、時、条件、文の働きは本文で追えるように保ちます。提供文脈にある別の事実（聞き取った経験など）を書いたことだけで元の主張を保ったとみなさず、既知の関係を別の観察・経験・予定へ置き換えて消さないようにします。

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

### 主語と目的語の明確化
単語の言い換えにとどまらず、「誰が・何を・どうした」を明確にします。原文や提供文脈から分かる主体を必要な位置で示し、誰の行為かを確かめます。ただし、元にない担当者を創作したり、自然なシステム動作まで人間の行為へ変えたりはしません。省かれた目的語や対象を補うのは、原文・依頼・提供資料・文脈に対象と関係が明示されているときだけに限定します。推測で創作したり、近くにある名詞というだけで対象を選んだりはしません。「これ」「片方」などの指示代名詞を名詞に戻すのも、指す先が文脈から分かるときだけに限定します。何を指すか追う必要がある名詞は、「もの」などへ不用意にぼかしません。助詞や使役を変えたときも、誰が何をどうするかの対応を確かめます。補った語がある場合は、報告に明記します。何の期限か、何を頼むかがその文で抜けていて、間にほかの話が入るなどして、読み違えるか前に戻らないと分からないときは、同じ文書の前後に書いてある語で補います（段落の冒頭で見積書の提出を頼み、注意書きが続いたあとに「金曜までにお願いします」とある → 「見積書の提出は金曜までにお願いします」）。直前から同じ対象の話が続いて読み違えない文、前後に書いていない対象、2つ以上に読める対象は補いません（2つ以上に読めるときは「書き手に確かめたい点」に出します）。
目的語を書かない他動詞の前に比較や条件などの句が挟まると、前のほうにある別の名詞（「〜を渡して」の〜など）が目的語に読めてしまいます。この形の文は、文として自然に読めても、上の「直前から同じ対象の話が続いて読み違えない文」に入れません（「設定の一覧を渡して比べさせると、Aは残りの2つの案より多く削った。」は、何を削ったかが書いてなく、「設定の一覧」を削ったとも読めます）。対象が原文・依頼・資料・文脈に書いてあれば、その語を目的語に書きます。書いていなければ、動作を名詞にして主語に立てます（「〜の修正は、ほかより多かった」のような形。「〜を行う」にはしません）。名詞にしても何の話か決まらないときは、原文を残して「書き手に確かめたい点」に出します。漢語や名詞の形を和語の動詞に替えるときも、替えたあとで目的語が文の中で追え、意味の幅が同じときだけにします（「確認する」を「見る」にするような、幅の広がる言い換えはしません）。例は `references/gemini-syntax.md` 原則1にあります。主語も目的語も書かずに他動詞を読点で並べて止める文も、この段落と同じ直し方をします。
複数の述語で動作主が変わる文は、述語ごとに「動作(主体, 対象)」を確かめます。原文や提供文脈で分かる動作主が切り替わる箇所は、その主体を明記します。例えば「上長が差し戻した場合、システムが通知します」と書き、差し戻す人と通知する主体を区別します。使役は「誰が・何に・何をさせるか」を区別します。長い節を読み戻らないと対象を追えない場合は、対象の再掲や節の分割を検討します。不明な主体や対象は作りません。書き手の一人称（私が、私は）を主語として新しく足すのは、依頼で書き手を言われたときだけです（`references/persona.md` 5章）。言われないときは、冒頭に書き手の受け持ちが書いてあっても足さず、原文のままにします。
主題の「〜は」「〜では」は文末まで掛かって読まれます。主題のあとに「〜ため、」「〜て、」などで節が続く文は、後半の節も主題の話として読めるかを確かめます。とくに、主題が部品や処理の名前（クラス、関数、画面など）で、後半に主題とは別の名前（設定、マクロ、ファイル、ライブラリなど）を扱う動作が出てくる文は、後半もその主題の中の話かを、原文・資料・前後の文で確かめます。主題の中の話だと確かめられなければ（「ParserではJSONの深さを10までに抑えるため、MAX_DEPTHを定義して再帰を打ち切ります。」の後半は、Parser の中の処理か、ビルドの設定の話かが文だけでは決まりません）、主体や場所を足さずに文を残し、後半がどの主題の話かを「書き手に確かめたい点」に出します（前後の文にある場所や手段を後半に移しても、どの主題の話かは決まりません）。後半が主題とは別のもの（部品、処理、人）の話だと原文から言えるときは、後半の冒頭にその主体を書きます。後半に主体が書いてある文と、主題の性質や状態の続きを述べる文は残します（例は `references/gemini-syntax.md` 原則1）。
主述や使役の対応だけを直す場合は、まず原文の動詞を保ち、確定した主語・相手・対象を明記する案を検討します。使役の述語（〜させる）は変えません。主語と使役の述語がかみ合わないときは主語の側を「〜には」に直し、並ぶ述語も使役にそろえます（「バッチは設定を読み込み、集計だけを担当させます」→「バッチには設定を読み込ませ、集計だけを担当させます」）。「担当するようにします」「担当する形にします」と述語を変えると、誰が誰にさせるかが変わります。動詞自体が不自然でなければ、対象を補うだけで伝わる文を別の長い構文へ組み替えません。比喩など動詞を直す理由がある場合も、元の動作と関係を保ちます。
動作を名詞にして「〜を行う」と書くより、対象と動詞を直接つなぐ方が自然な箇所は、「値を代入する」「変更内容を共有する」のように書きます。何を扱うかが分かる対象を落としたり、動作を別の動作へ変えたりしません。失敗時に値を代入しない処理を「falseを代入する」と変えるような、実際の条件や動作の改変は避けます。
他動詞の連用形を1語だけ名詞にした語（確かめる→確かめ、比べる→比べ）を「の」で目的語につなぐ形（「結果の確かめ」「二つの案の比べ」）は、日本語では使いにくく、漢語を避けて和語で書くと出やすい形です。目的語と動詞の文に戻すか（結果を確かめる）、定着した漢語の名詞にします（結果の確認）。名詞とくっつけて定着した語（資金集め）、複合動詞から来た語（見直し、組み合わせ）、「お」を付けた形（お選び）、別の意味で定着した語（住民票の写し、詰めが甘い）は残します。漢語を和語にひらくときも、この形を作りません。lint の renyo_noun はこの形の候補です（語の一覧は `references/lists/renyo-nouns.txt`）。漢語の名詞にするのは、Step 2 の「別の語に差し替えるだけ」に入りません。diff の文体の硬化の候補に出ても、この形に戻しません。
処理や選別の対象を「もの」「それら」で省いている場合は、指す対象が原文や提供文脈から確定し、前の文から拾い直す必要があるときに、元にある名詞で明記します。近くにある名詞というだけで指す先を決めず、候補が複数ある場合は勝手に限定しません。確定した対象の再掲と、新しい対象を足すことを区別します。
動詞を言い換えた後も語順を確かめ、元の関係を保ったまま主語と述語を追いやすくする案を検討します。主述を近づけるために修飾先や条件の範囲を変えず、元から自然な語順は保ちます。

### 擬人化の解消
非生物主語を直すのは、道具や概念に感情や意志を持たせている擬人化表現（「コードが語る」「システムが願う」等）のときを基本とします。道具や仕組みの働きを客観的に述べている文（「このツールはログを集めます」等）はそのまま残します。人が自分でした行動や判断を、抽象名詞が作用したように書いている文（「見積もりの甘さが判断を遅らせた」等）は、原文や前後から誰の行動か分かる場合だけ、その人の行動として書きます（gemini-syntax.md 原則3）。直す場合も、元にない条件（「〜を使えば」）や可能（「〜できます」）を足しません。
コード、関数、クラス、サービスの働きを説明する文書では、何を受け取り、何を返し、何を呼ぶかで書きます。人の知識や会話、人の役目にたとえた言い方（「この関数は呼び出し元の事情を知っている」「コードが語る」「DB と対話する」「認証の責任を引き受ける」「リクエストの門番」「交通整理の役」）は、コードや資料から実際の動作が分かるときだけ、その動作の文に書き直します。分からなければ原文を残し、何をするのかを「書き手に確かめたい点」で尋ねます。動作を足さなくても意味が1つに決まる言い換え（「この資料は仕様を語っている」→「この資料に仕様が書かれている」）は、今までどおり直します（gemini-syntax.md 原則3）。設計の用語として定着した言い方（責務を持つ、依存する、呼び出す、委譲する、返す、受け取る）は残します。オブジェクト指向の説明で使う「〜はデータを知っている」も、資料や原文がその用語で書かれていれば残します。働きが一読で分かる擬人化（「センサーが異常に気づく」）と、開発者向けの文書で識別子が主語の文は、今までどおり残します（`references/slop-catalog.md` 8章、`references/audience.md`）。

### 比喩動詞の具体化
「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません。ただし報告書では「障害が発生した朝」のように文書の種類に合う語を残し、ふだんの言葉に開きすぎません。意味を保った自然な言い換えができない場合は無理に変えず、元の動詞を残します。
**比喩や言い回しが持っていた「含み（気持ちや評価の向き）」は必ず残します。**
- 含みの例: 「うっかり」の不注意、「ようやく」の待ちくたびれた感じ、「〜てしまった」の後悔、「地味に」の目立たないけれど確かにある感じ。
- 比喩の語は言い換えて構いません。ただし、その語が伝えていた含みや理由は、別のふだんの言葉で補って言い表します。
- 言い換えるときは、「良いほうに働いている」「助けになっている」のように、効き目や評価だけをぼんやり述べる言い方にしません。何がどう変わったのかを書くか、ふだんの文章で使われる言い方を選びます。
- 含みを補うときも、誇張語を言い換えるときも、原文より強い確度や程度の語（確実に、必ず、劇的に）は足さず、言い切りも強めません。上の例の「地味に」の「確かにある感じ」は、「目立たないながらも」のような言い方で表し、確度の語にはしません。
- 比喩動詞だけでなく、副詞や前置きの言い回しも同じ扱いにします。
データやシステムに対して使われる「壊れる」は、「おかしくなる」「使えなくなる」のように、意味の広さが同じふだんの言葉に改めます。「データの整合性が失われる」「不整合が生じる」と書くのは、元の文や前後から、明らかに整合性の話だと分かるときだけに限定します。時計や機械などの物体や、身体（お腹を壊す等）の文字どおりの「壊れる」はそのまま残します。また、「静かに」「黙って」のようなぼかしは、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。「エラーを出さずに」「通知なく」のように仕組みの話として書くのは、元の文や前後から、エラーや通知が出ないことがはっきり分かるときだけに限定します。
また、「骨が折れる」「手を焼く」「目から鱗が落ちる」「首を長くして待つ」のような、ふだんの日本語で定着した慣用句は、AIっぽい比喩として扱わずそのまま残します。業務仕様でも、意味を取り違えるおそれがなければ残します。迷ったときの目安は、その言い方を、AIが広まる前の人の文章でもふつうに見かけるかどうかであり、見かけるなら残します。
エッセイと小説では、何を何に例えたかが読み取れる比喩は、字義どおりでなくても書き手の個性として残します（エッセイの比喩動詞は上のとおり直します）。一方、主語と述語だけを取り出すと成り立たず、何を言いたいかを連想もできない比喩（「午後が膝を抱える」）や、動作と主語が釣り合わない比喩は、小説でも直します。比喩は前後の文と合わせて見て、あとの文で例えた理由を述べている比喩は残します。直す案が物や場所の「黙って〜している」の形になるなら、原文を残します。目印と例は `references/slop-catalog.md` 8章と `references/doc-types/essay.md` にあります。

### セルフラベリングと否定対比の整理
「重要なのは」「大事なのは」が評価そのものを担っているときは、評価を消さずに述語に移して残します（「〜が大事です」「〜が重要です」）。前置きを削ってよいのは、削っても主張が変わらないときだけです。
前置きが理由・対比・結論や、説明から方針への切替を示す場合は、その関係を残します。「結論として」が比較結果と採用方針をつないでいる場合など、他の語から同じ関係が読めなければ削りません。ただし、文頭の「もちろん、」のあとに数語だけが続いて終わる短い文（「もちろん、失敗もする。」）で、読み手が思いそうなことを先回りして認めているものは、AIの文章らしく見えやすいため、随筆でも「もちろん、」を外します。当然のこととして認める含みがあることだけを理由に残さず、その含みを「当然、」「言うまでもなく、」などの別の語で補うこともしません。認めている内容とその程度は残し、元にない理由や因果やつなぎの語は足しません。会話や引用の中の「もちろん」、問いや依頼への答え（「もちろんです。」）、条件や前提を確かめる文、「もちろん、」の後に同じ文の中で具体的な内容が続く文、文の途中の「もちろん」（「AはもちろんB」など）は、この扱いの対象にしません。
否定対比（AではなくB）は、否定を外しても主張が変わらないときだけ肯定文にします。Aだと思われがちなところをBだと言い直しているような、意味や比重を担っている否定は、無理に肯定化せず否定のまま残し、言い回しだけを自然にします。否定していたAを「Aに加えてB」と並べたり、「AよりB」と順位づけしたりしません。「弱みではなく、視点の違いでもある」のように否定のあとに「でもある」と続ける文は、否定と「も」をどちらも保ち、一つの文のまま残します。「弱みではない。視点の違いでもある。」と2文に分けたり、「でもある」の意味を書き手に尋ねたりしません。「弱みであると同時に、視点の違いでもある」のように、否定していたAを認める形にも変えません。否定を残すときに、元にない理由の文は足しません。否定と肯定を2文に分けた形（「必要だったのは新しい道具ではない。使い方をそろえることだった。」）は、否定を残したまま「必要だったのは新しい道具ではなく、使い方をそろえることだった。」の1文にまとめます。エッセイでも同じです（小説の語りと会話、紹介記事・宣伝文で短い文を重ねた箇所は除きます）。後ろの文が別の主張を足しているときはまとめません。
直前で問いなどとして挙げた二つを、続く文が「〜ではない」「〜でもない」のような否定の形で両方とも打ち消すだけの場合は、「どちら」が何と何を指すかが直前の文脈から一通りに決まるときに限り、挙げた語を繰り返さずに「どちらでもない。」（敬体なら「どちらでもありません。」）と短く受けて構いません。「どちら」が直前の二つを指すので、打ち消す内容は保たれます。打ち消すほかに問いにない内容（「決して」のような強めの語、限定、なぜ違うかの説明など）を含む否定は、短くせずに書きます。
用語や状態を説明する文が「〜ではありません」「〜を意味するわけではありません」で終わり、それが何であるかの説明が薄いときは、何であるか、いつそうなるかを先に書きます（「下書きはまだ公開していない記事の状態です。中身が仕上がっていないという意味ではありません。」のように、何であるかを先に置き、否定はそのあとに残します）。説明の中身は原文の前後の文、資料、文脈から取ります。否定の文が読み手の誤解を防ぐ条件を伝えているときは消さずに後ろに残し、上の否定対比の決まり（否定が意味や比重を担うときは残す）は変えません。何であるかを書く材料がなければ、本文を残して尋ねます。言い直しテスト（`references/rephrase-test.md`）の6点は変えません。

### 情報の不増補（足さない）
「勝手に足さない」は、原文、依頼、提供資料、文脈（この会話の利用者の発言、開いたファイル、コマンドの出力）に明示された内容だけを根拠にします。自分やほかのAIの発言、会話のまとめ、一般の知識は使いません。この原則は本文だけでなく、「変えたところ」「残したAIっぽいところ」「書き手に確かめたい点」「事実の確かめ」のすべての出力欄に適用します。読者の理解に必要な定義、識別子、値と状態の対応が提供されている場合は、説明に活かします。提供済みの文脈を無視して必要な情報を減らすことはしません。
一方で、読み手に不要な説明を毎回足す決まりにはせず、原文や文脈から分からない動作主、名詞、行動、原因、条件、数値、例、専門用語を推測で創作して足すことはしません。ぼかした語を、より狭い具体的な事実に勝手に置き換えることもしません。対象の一部や比べる項目、期間などの限定が前後の文にあっても、その限定がない文へ持ち込んで主張の範囲を狭めません。指示語や「同じ」、用語の定義などで同じ限定が掛かると原文・依頼・提供資料から確定できる場合は、その限定を補っても構いません。本文で元の表現を残した場合でも、説明欄で重大さなど示されていない比較の基準を勝手に決めたり、より狭い具体的な意味を決めつけて書いたりしません。確認の問いでも、文脈に根拠がない未確定の語や動作について、状態や行き先などを勝手に限定せず、何が分からないかを中立に尋ねます。出典の示されていない「〜という声もあります」のような書き方は、声の主や数を推測で補ったり言い切りの強さを変えたりせず、本文に残します。出典の有無が主張の受け取り方を左右する場合は、「書き手に確かめたい点」で出典があるかを尋ねます。情報が足りず具体的に書けないときは、次の「情報が足りない場合の暫定文」に従います。
「昨日」「先週」のような相対の日付は、書いた日が確かに分かるときだけ、括弧で日付を添えます（昨日（3月4日））。書いた日が分かるのは、原稿に書いた日の行があるときと、依頼や会話から原稿を今日書いたと分かるとき（利用者が同じ出来事を今日から数えて言っているときなど。今日の日付はホストが知らせる日付を使います）です。推測では添えません。その日付がすでに書いてあるとき、ほかの日付と食い違うとき、essay と promo のときも添えません。曜日は足しません。添えた日付は同じ日を言い直したもので、言い直しテストの時期を変えず、検査の「資料にない数値・名前」に出ても戻しません。添えたときは「変えたところ」に、何から数えたかを1行で書きます。
書き手がAIに出した指示や除外の判断が、読者向けの本文に言い換えて残っている文（「今回は一般論ではなく、自分の体験に絞って紹介します」「ここでは専門用語を使わず、やさしいトーンで振り返ります」）は、読者に向けた中身の部分だけを残し、指示や方針を述べる部分を削ります。読者のために扱う範囲・対象読者・前提を示す文（「この手順書では、退職の手続きは扱いません」）は残します。決められなければ残します（`references/slop-catalog.md` 6章）。

### 情報が足りない場合の暫定文
読み手に渡す本文には、原文が「未定」「調査中」と読者に伝えている状態も含め、主張・動作主・条件をそのまま残します。推敲側が元の意味を読み取れないことについての注記や説明、書き手への質問は本文に含めず、独立した項目に置きます（本文のみの指定では注記を加えずに本文だけを返します）。文の途中や末尾に「要確認」などの編集表示は挟みません。見出しや箇条書きなどの書式は規則どおり保ちます。詳しい理由は「変えたところ」、確認すべき内容は「書き手に確かめたい点」に自然な言葉で置きます。文の意味や関係がどうしても読み取れず説明が重要な場合は、何が読み取れず何を確かめたいかを短く述べてから尋ねます。ただし同じ説明を各欄で繰り返さず、元の主張を批評や伝聞に変えることも避けます。質問は最大3点（「書き手に確かめたい点」の上限と同じ）とし、元から未定や調査中であることと提供情報から読み取れないこととを区別して尋ね、些細な不足を機械的に並べることは避けます。
原文の主張、否定、条件、言い切りの強さ、適用範囲、文が何のために書かれているかは本文に残します。主張を確認の項目で引用したり、「〜と述べている」のように伝聞や批評に変えたりするだけでは、本文で主張を保ったことになりません。意味を確定できない表現でも、結びつく動作が分かるなら、元にない対象や仕組みを推測で書き足さずに本文に残します（すべての表現を一字一句そのまま残す必要はありません）。意味の幅を変えずに自然な文へ整え、不明な点の確認は報告で行います。本文のみの指定では注記を加えずに本文だけを返します。
意味を読み取れないことと、仕様や予定が実際に未決定なことは分けます。原文や提供文脈にある「未定」「調査中」は、その時点の状態として保ちます。未知の主体・動作・手段は補わず、未読の外部資料を調べたかのような説明もしません。作者の氏名などが分からなくても本文の意味や働きに影響しない場合は、それだけで本文全体を暫定扱いにしません。

### 内容に合わない大げさな名詞の整理
決まりや方針を「契約」、原文や比較の基準を「正本」、確認手順を「ゲート」、記録や一覧を「台帳」と大げさに呼んでいる場合は、「ルール」「方針」「原文」「比較の基準」「参照するファイル」「確認」「チェック」「記録」「一覧」等、実際の役割に合う語へ直します。手段や書き方を曖昧に「仕組み」と呼んでいる場合も、原文から分かる内容に合う語で書きます。
「境界」が何を区別しているかが曖昧な場合は、文脈から分かる対象や条件、順序で書きます。「この境界を守れば問題を防げる」のように語の指す対象が曖昧でも、「守れば問題を防げる」という動作や関係は分かります。語の対象を勝手に決めることと、条件付きの主張を本文に残すことは別です。元にない仕組みを推測で書き足さず、元の条件付き主張と言い切りの強さをそのまま本文に残します（「防げるとされている」のような批評や伝聞には変えません）。語が何を指すかは特定の役割（時点・責務・範囲・判断条件など）を決めつけず、「書き手に確かめたい点」で自然に尋ねます。
意味が確定できない語は、近い印象の別語へ安易に置き換えて状態の種類・強さ・対象範囲を変えません（「破綻した」を単に「壊れた」「問題のある」と同義と決めない等）。元の語で伝わるなら残し、既知の隔離・対象・処置・順序は本文で保ちます。
取引や合意としての契約、正式な文書を区別する正本、処理の関係や動作を説明する仕組み、数学や区域の境界、テストの境界値、CIなどの製品や仕組みの正式名称としての品質ゲート、会計や行政の台帳、内容が定義されている専門用語や実際の名称は、その意味を保ちます。置換先で信頼性・唯一性・更新元という役割を新たに足しません。原文にある唯一性や評価の強さも落としません。詳しい用例は `references/slop-catalog.md` を参照してください。
「分離」「保証」「管理」「対応」「担保」などの漢語の名詞だけで、誰が何をするか、どんな条件かを済ませている文は、原文や資料から動作と条件が分かるときだけ、その動作の文に書き直します（資料に「申請はその場で受け付け、承認は担当者が翌営業日にまとめて行う」とあれば、「申請と承認を分離する」をその文にします）。分からなければ残して尋ねます。語を同じ意味の別の漢語に替えるだけでは済ませません。「保証」のような約束の語を、資料にない強さの動作に書き直したり、消したりもしません（基本原則の言い切りの強さ）。言い直しテストの6点は変えません。

### 専門用語と名称の扱い
専門的な意味で使う語は、その分野で日本語として定着した用語で書きます。原文や提供文脈から対象と意味が確定した場合は、不自然な直訳をその用語へ直します。日常の言葉として文意が通る場合でも、文脈から専門的な対象だと分かるときは、その分野で定着した言葉（産業用ロボットの「アーム」など）を使います。ただし、身体の部位や日常的な物、資料の名称、画面の項目名、部品ラベル、コードの識別子は保ちます。表の短い項目名やラベルは無理に文へ展開せず、説明欄の文は必要な範囲で整えます。API表やスキーマの名称・キー・型・enum値・null許容・必須性・数量・単位は保ち、未確定の仕様を埋めません。推測で型や仕組み、名称を作ったり、何でもカタカナ語にしたりはしません。
処理の判断に必要な識別子や、値と状態の対応が提供されている場合は、判定条件を読み手が追えるように明記します。専門用語へ直すだけで説明を済ませません。型や値の意味が不明な語から、真偽値や「真になる」という意味を推測で補いません。
文字どおりの日常語は専門用語へ変えず、不明な語の分野や意味は推測で決めません。書き直した本文だけでなく、自分で書く見出し・変更理由・確認事項にも同じ基準を使います。原文を比較のために引用する箇所は改変しません。

### 文長と読点の調整
文の平均の長さは30〜45字程度、1文あたりの読点は0〜2個を目安にします。この長さは文章全体の平均の目安であり、一つひとつの文をこの範囲にそろえるために分けたりつないだりはしません。読点は、不自然な位置や掛かり先を読みにくくする箇所で調整します。元から読みやすい文の読点を、数や見た目だけで削りません。文が長いことだけを理由に文を分けません。長い文を分けるのは、前後のつながり（手段・理由・順序・対比）を、後ろの文のつなぎ言葉（そのため、こうすることで、一方で、反対に等）で残せるときだけに限定します。目的や理由が文末の結論にかかっている文（例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です／〜しますの形）は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。
短い主題句から述語まで続けて読め、読み分けの役割がない読点は、元の文にあっても外します。「操作画面の『旗』はまだオンにしません」のように書き、実際の項目名は保ちます。条件・逆接や長い句を読み分ける読点は残します。「会議では、担当者が説明しました」のように、主題とその後の動作主を読み分ける読点は、句が短くても残します。
主語の「が」、短い目的語の「を」、主題の「は」「も」「には」「では」「とは」のすぐあとに置いて間を作るだけの読点（「古いキャッシュが、重複して読み込まれる」「応答は、〜」「バッチには、設定を読み込ませ」「点検を、〜」「営業部とは、〜」）は、人が読むとAIの文章らしく見えるので、新たに付けず、元の文にあれば外します。主題のあとに別の動作主が続く所（上の「会議では、」）、長い主語や節の主語、長い目的語や節の目的語のあと、挟み込みの句の前、並んだ語句を区切る所、外すと掛かり先が変わる所（「店長は、慌てて逃げた客を追いかけた」）の読点は、この理由で外しません。1つの文書に何か所あっても、これらに当たらないものはすべて外し（小説や随筆で書き手が間として置いた読点は残してかまいません）、外すのは読点だけにします。lint の pause_comma の候補は手がかりで（6字以内の短い目的語の「を、」も候補に出ます。並べと長い目的語には出ません）、候補でも上の残す読点に当たるもの（長い主語や節の主語のあとなど）は外しません。読み分けの役目のない読点は、ほかの位置にも新しく足しません。並んだ語句を区切る所とは、並んだ語や句のあいだの読点のことで、「1つ目は、」「次の点は、」のような、並んだ項目の先頭の主題のあとの読点は、短い主題として外します。「AではなくB」「Aだけでなく」の「なく」のあとで間を作るだけの読点と、見出しの中の読点も外します（依頼で見出しの形を指定されたときは外しません。「案内用の見出し」）。見出しは「AではなくB」の形にせず、Bの側だけを書きます。文書の種類を決めずに lint の候補が出ないときも、提出の前に、最終稿の文頭の「〜は、」「〜には、」「〜では、」「〜とは、」「〜を、」と見出しの読点を一つずつ見て、残す読点に当たらなければ外します。
文を分けるときは、「〜ます。」で終わる短い文が続きすぎないようにし、同じ対象や場面についての内容は、意味のまとまりで1文に保ちます（「申請の受付時と承認時は、このチャンネルでお知らせします」）。原文で1文に書いた目的や理由を後ろへ切り出して、「〜ためです。」「〜からです。」の短い文を新しく作りません（「ディスクがあふれないよう、一時ファイルは毎晩消します。」を「一時ファイルは毎晩消します。ディスクがあふれないようにするためです。」にしない）。原文にもとからある「〜ためです。」の文は、この理由では直しません。
推敲で文をつないだり言い換えたりして新しく読点を置くときは、残す読点（誤読を防ぐ所、長い修飾や節の切れ目、並べ、条件・逆接・理由の切れ目、主題のあとに別の動作主が続く所）に当たる所だけにします。1文の中で、短い主題、短い主語、短い目的語、副詞（順番に、毎日、少しずつ）のあとに読点が続き、区切りがどれも短い文（「担当者は、申請を、毎朝、確かめます」）は、残す読点に当たらない読点をすべて外します（小説や随筆で書き手が間として置いた読点は残してかまいません）。外すのは読点だけで、語順と述語は変えません。地の文の文頭の接続語のあとの読点（まず、また、なお）は、`references/slop-catalog.md` 9章のとおり残します。接続語が3文以上続く段落では、接続語そのものが要るかを「段落と文の論理構造」の決まりで見て、読点だけを外すことはしません（スライドの見出しと箇条は `references/doc-types/slides.md` のとおりです）。

読点の整理だけを理由に、元から読みやすい文の語順や述語を組み替えません。
読点だけを整えるときは、原文の動作主・対象・述語を残します。誰かが操作を行わないという記述を、対象の状態が変わらないという保証へ変えません。
進捗報告で別々の作業の完了・未完了を伝える場合は、状態ごとに文を分けて書きます。逆接や留保そのものが結論の解釈を左右する文は、その関係を残します。

### 案内用の見出し
記事・文書・スライドの見出しは、新しく書く場合も推敲する場合も、その箇所で何を扱うかが分かる短い項目名にします。「保存期間」「削除後の復元」「共有できる期間」のような名詞句や、「材料を量る」のような短い動作を基本とし、語り出しや理由、操作の細部、警告・条件・結論を文のまま見出しに詰め込みません。記録先や場面が内容を見分ける手がかりになる場合は、本文にある具体的な語を見出しに残します。「記録」「引き継ぎ」だけに縮めず、「Issueに残す採用理由」「担当交代時の引き継ぎ」のように書きます。見出しから外した警告・条件・結論や、「先に」「全部」「ぬるま湯で」のような範囲・順序・手段、「思い切って」「意外と効いた」のような書き手の評価や態度は省かず、本文になければ本文へ移して同じ意味で残します。タイトルや導入が「3つの工夫」のように数を示し、見出しの番号がその対応を示している場合は、番号を残します。見出しの後ろに括弧で補った語句と、結びの「〜について」は外し、短い項目名にします（「参加費の集金（前日まで）」→「参加費の集金」、「懇親会の会場について」→「懇親会の会場」）。括弧の中の条件や期限が本文になければ、本文へ移します。節がその括弧の中身だけを扱うときは、括弧の語を項目名にしてよい（「会場の準備（机と椅子の配置）」→「机と椅子の配置」）。管理番号、社内の呼び名、画面の項目名の括弧（「（REQ-118）」）は残します。短い動作の見出し（「設定を見直す」）は、名詞句に言い換えません。文書の題（いちばん上の題名）は、この節で直すときに限らず変えません（「の」の連続を詰める、語を足す、読点を外す直しも当てません）。
見出しだけで警告や結論を伝えることが依頼で明示された場合に限り、その内容を見出しに保ちます。依頼で見出しの形（長さ、言い切り、番号、記号）や、まとめの節・ページを指定されているときは、その形と節を保ち、直しません（ほかの節の見出しとまとめの決まりより先にします）。警告や条件を含むことだけを理由に長い文の見出しを残さず、すべての見出しを名詞句にそろえることもしません。
発表の締めに置かれていることだけでは、見出しが結論を言い切る役割だとは決めません。本文の話題を案内する見出しなら、最後の見出しも同じ基準で整えます。
見出しや文書の1行目が、本文に出てこない一語の比喩（「〜の横」「〜係」など）のときは、その節の本文が何を扱うかを読んでから、本文の語で項目名を作ります。比喩の語を別の一語に替えるだけでは済ませません。本文から話題が決まらなければ残します。文書の題は変えず、題が本文から何を指すか読めないときは「書き手に確かめたい点」で尋ねます。
紹介記事・宣伝文の見出しのキャッチコピーには、この節を当てません（「紹介記事・宣伝文の勢い」）。
「uvとは：仕組みと使い方」のように、「〜とは」とコロンで扱う話題をつないだ見出しは、コロンの後の語句を落とさずに「uvの仕組みと使い方」のような名詞句にします。「議事録：10月定例会」のように、文書の種類と対象を区切るラベルのコロンは残します。
議事録を推敲するときは、見出しを短い項目名に直さず、原文の見出しのまま残します（`references/domains/business.md` 3章）。

### コピー調の抑制
原文をこの節で整える対象は、不要な読点で間を作る表現や、助詞句・副詞句で切るコピー調、評価の語だけの短い文を並べる型です。その型がない自然な文は、この節のために言い換えません。
コピー調になっている実務文の本文は、文脈から確定した動作・判断・評価を、その文の働きに合う述語まで書きます。自分で書く変更理由や補足説明にも、この型を持ち込みません。型を整えるときも、原文と提供文脈で確定している対象の範囲・動作主・条件・手段を省きません。コピー調の見出しやスライドの見出しは、「保存先の指定」のように、その箇所の話題や手順が分かる短い語句にします。本文にある複数の担当者の動作を、一つの担当者の動作にまとめません。
「資料を、全員へ。」「作業を、もっと確かに。」のように、短い句の後で間を置き、助詞句や副詞句で切るコピー調は使いません。原文にある同じ型も、意味・比重・文の働きを保った表現に整えます。読点だけを消して同じコピー調を残したり、語尾を散らすためにこの型へ変えたりしません。
意味を取り違えるおそれがなく、主語・目的語から述語へ続けて読める箇所は、助詞の後で区切らず一続きに書きます。「資料を確認します」「担当者が更新しました」のような文に、間を作る読点を新たに足しません。条件・逆接や長い句を読み分ける読点は、助詞の後にあるという位置だけで削りません。
「速い。軽い。安い。」のように、評価の語だけの短い文を並べてリズムを作る型は、何を評価しているかが原文や前後の文から確定する場合に、対象と評価を述語までつないで書きます（前の文で紹介したツールの評価なら「このツールは速く、軽く、安い。」）。評価の語を足したり減らしたり強めたりせず、元にない理由・逆接・比較も足しません。評価の対象が確定しない場合は、対象を作らずに原文を残します。小説や随筆の語りや会話で、書き手が文体として短い文を重ねている箇所と、紹介記事・宣伝文で評価の語を短く重ねている箇所は残します。
「〜したのは、A、B、C。」のように、「〜のは、」のあとに名詞を並べて文を終える強調の形は、「変わったものがある」のような前提を読み手と共有しているときの書き方です。前の文や見出しにその前提がなければ、「〜では、A、B、Cが変わった」のように、「のは」の前の動詞を述語に戻して書きます（語は足しません）。前提が直前の文にあるとき、見出し、結び、スライドの箇条で強調として選んでいるときは残します。lint の cleft_list_ending はこの形の候補です。
「丁寧な、人。」のように、修飾語と名詞のあいだに読点を打って短い名詞で止める型は、読点を外し、文脈から決まる述語まで書きます。述語が決まらなければ読点だけを外します。広告や見出しで一度だけ使うものは残します。
その物ならふつう備わっている性質を目立たせる一句（傘の案内の「雨をはじきます」）は、その性質がふつう備わっているものかを問います。そうであれば、原文にあるより具体的な事実に寄せ（事実の文の条件や範囲は変えません）、なければ残します。
動作や意図を原文・提供文脈から確定できない場合は、型を消すために具体的な述語や効果を作らず、「情報が足りない場合の暫定文」に従います。原文の引用、確認項目の名称などの用途上十分な省略は保ちます。

### 装飾記号の排除と太字の表示
絵文字、文末コロン、ダッシュ記号（em dashや罫線文字「─」「━」「──」）、情報量の増えない言い換えカッコを排除します。罫線だけの区切り線や、木構造・図の罫線、引用の出典表記の記号は、文中の装飾ではないので残します。英単語や数値の前後に空白があることだけを理由に一律に削除したり、逆に一律に空白を入れたりせず、元の書式や指定されたスタイルを保ちます。太字を表示させるための空白や、太字の内側にある不要な空白を直す作業は、英単語前後の削除とは別に維持します。コマンド・コード・URLに含まれる必要な空白も勝手に消しません。
ただし、「日時：10時」「対象：社内ポータル」のように、ラベルと値の対応を示すコロンは文末の装飾とは区別し、元の区切りを残します。URLやコード内のコロンも変更しません。紹介記事・宣伝文で書き手が気持ちや勢いを表すために使った絵文字と「！」も残します。
箇条書きの項目の先頭のラベルとコロン（`- **期限**: 11月末`。太字でなくても同じです）は、コロンのあとが値か説明の文かで分けます。日時・場所・担当・数値・状態のような短い値の項目（`- 状態: 対応中`）と、物や方式、引数、設定項目、作業の名前に説明が続く項目（用語や引数の説明の並び）は、ラベルとコロン（：か :）を残します。値の項目が並ぶ中の1項目なら、説明が文でも残します。その太字は、原文が太字のラベルとコロンで始まる箇条書きを2つ以上重ねているときに多用として外し、1つだけなら残します。ラベルが説明の文をまとめただけの語（「特徴」「改善点」のような分類の語、「〜の低下」「〜の肥大化」のように出来事を名詞にまとめた語、「返信が遅れる」のような短い述語）なら、ラベルとコロンで説明につなぐ形はAIの文章らしく見えるので、多用に当たらなくても太字とラベルとコロンを外し、ラベルの意味を説明の文（2文以上なら最初の文）に入れて1文にします（`1. **応答速度の低下**：ピーク時に3秒を超えた。` → `1. 応答が遅くなり、ピーク時に3秒を超えた。`）。ラベルが示していた意味と項目の区別は文の中に残し、原文にない事実や程度は足さず、箇条書きのまま番号と項目の数と順を保ちます（`references/doc-types/pr.md`）。lint の bold_label_list の候補は手がかりで、ラベルとコロンと太字はこの段落で決めます。議事録とスライドのラベルと値、紹介記事・宣伝文の見出しの太字の行は、この扱いの外です（`references/doc-types/`）。
原文が「■」「・」などの記号で見出しや項目を示している場合は、依頼で指定がなければ、Markdownの「##」や「- 」に置き換えず原文の記号を保ちます。Slackやメールなどに貼る文章では、Markdownの見出しが記号のまま表示されることがあります。
また、Markdownとして表示される文章（GitHubや技術記事など）で太字を残すときは、太字として正しく表示される書き方に整えます。`**` のすぐ内側が記号（「」『』（）【】、。やバッククォート等）で、すぐ外側が文字（ひらがな・漢字・英数字）のとき、表示環境によっては太字にならず、`**` がそのまま表示されます（gemini-syntax.md 原則14）。太字を残すときは、次の優先順で直します。
1. かっこごと太字にしているときは、かっこの内側だけを太字にします（例: `次に**「文書の立場」**を決めます。` → `次に「**文書の立場**」を決めます。`）。
2. 太字の終わりが句点などのときは、句点を太字の外に出します（例: `これは**必須です。**詳しくは下に書きます。` → `これは**必須です**。詳しくは下に書きます。`）。
3. 1と2ができないとき（コードで始まる・終わる太字、かっこが2つ以上ある太字など）は、`**` の外側の、文字に接する側に半角スペースを1つ入れます（例: `立場は**「勧め」か「決まり」**で決めます。` → `立場は **「勧め」か「決まり」** で決めます。`）。
この半角スペースは消さずに維持します。
元の文で太字にならない書き方になっている箇所は、太字を残すなら、ほかに直す箇所がない文でも同様に直します（意味は変わらないため「変えたところ」には書きません）。これは太字を増やす決まりではありません。太字を減らす決まり（domains/tech.md の1,000文字あたり1〜2箇所など）はそのまま維持します。

### 紹介記事・宣伝文の勢い
商品、お店、場所、サービス、作品を勧める紹介記事・宣伝文（promo）では、書き手の勢いが記事の魅力そのものです。次は勢いとして残します。
- 見出しのキャッチコピーと、その言い回し。
- 「！」。同じ段落に3つ以上並んでも減らさず、読点にも変えません。
- 評価の語を短く重ねる型（安い。うまい。早い。）と、同じ褒め言葉の繰り返し（麺は抜群、スープも抜群）。まとめたり、回数を減らしたり、ほかの語に置き換えたりしません。
- 勢いのある語（パンチ、大活躍、最強、イチオシ）と強める語（本当に、ぜひ）。落ち着いた言い方に置き換えたり、削ったりしません。
- 書き手が気持ちや勢いを表すために使った絵文字。

それでも、誤字と脱字、主語と述語のずれは直します。根拠のない誇張が事実のように書かれている所（県内でいちばん売れている）は書き換えず、「書き手に確かめたい点」で根拠を尋ねます。元にない褒め言葉は足しません。細部と例は `references/doc-types/promo.md` にあります。

---

## 2. 実行手順

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

書き直す前に、文章全体と段落の流れを確認します。
1. **文書の種類と読者、ドメインの判定**
   - 文書の種類は下の表の13種類です。指定に従い、なければ依頼の行き先と本文の形から推定します。当たらなければ決めません。種類を決めたら `references/doc-types/<値>.md` を読み、表の「当てない規則」を、その範囲で当てません。
   - 読者は、expert（同じ分野の専門家）、informed（分野は違うが技術や業務に詳しい人）、general（専門知識のない人）の3段階です。指定に従い、読者像を渡されたら近い段階にします。依頼や宛先から分からなければ決めません。
   - 自信がなく、決め方で直し方が変わり、問い返せるときだけ、書き直す前に1回だけ確かめます。確かめられないとき（本文だけの指定、一回きりの実行、ほかのスキルの途中、質問しないでと頼まれたとき）は決めずに進み、この SKILL.md の規則どおりに直します。推定で決めたときに使う調整は、本文を変えないか、変える箇所を減らす向きのものだけです（細部は `references/audience.md`。informed か general を指定されたときは読みます）。
   - expert には、用語を残して説明を足しません。informed（分野の外で通じにくい語）と general（説明のない用語）では、指定されたときだけ、原文と資料にある説明で言い換えるか添えます。推定のときと、原文と資料に説明がないときは、語を残して「書き手に確かめたい点」に「ここに説明が必要です: 語（場所）」と書きます（確かめたい点の3点とは別に3点まで）。識別子が主語の文は、expert と informed には直しません。見出しと節の数と順は、どの種類と読者でも変えません。
   - 書き手の立場と、読み手との関係（上司、取引先など）は、依頼で言われたときだけ使います。言われずに推定しただけなら、本文も知らせも変えず、敬語の揺れや度合いについて、知らせも直す案の申し出も書きません。推定した読み手や関係を、変えなかった理由として書くこと（「社外あての文書なので、丁寧な言い方を残しました」）もしません。言われたら、直す前に `references/persona.md` を読み、その範囲で本文を直します。上司と社外の読み手には、読み手への依頼と読み手の行為を尊敬語（ご確認ください）に、社外の読み手に向かう書き手の行為を謙譲語（ご連絡いたします）に上げます。形は persona.md 7章に従い（同じ動詞に「お・ご」を付けた形か、その関係で人がふつう書く言い回し。頼む中身は変えない）、二重敬語と、原文にない「させていただく」は作りません。書き手が自分でした行為で、主語がなくほかの人の行為と読み違えうる所は、原文にある書き手の一人称を主語に補います（チームや会社の決定とも読める文、手順の操作、決まった事柄の文には補わず、3か所まで）。担当者、説明、挨拶、お詫びは足さず、一人称と謙遜は残します。読み手に合わせて語の難しさを上げ下げしたり語句を削ったりせず、人の名前と敬称も変えません。敬語を下げるのは利用者が頼んだときだけで、essay と promo ではペルソナで本文を変えません。ペルソナから出す知らせは、知りえない事情、立場に合わない断定、関係に合わない言い方（一人称、宛先の食い違い、常体）の3つだけで、本文は書き換えず、persona.md 9章の形で「書き手に確かめたい点」に書きます。ペルソナや敬語について、問題がなかったこと、変えなかったこと、変えなかった理由は、返答の冒頭のまとめ、「変えたところ」（「なし」の後ろの括弧を含む）、確認の記録を含め、返答のどこにも書きません。主語を補わなかった所と、敬語を上げなかった所（同じ動詞の形がない依頼、引用や画面の文言、自分の側の作業）の理由、検査の候補への答えの中で読み手や関係を理由に残した所も、同じく書きません。

   | 種類 | 当てない規則（範囲） |
   |---|---|
   | pr（PR説明） | 箇条書きを地の文に戻す直し（変更点、確認したこと） |
   | article（技術記事） | なし |
   | incident（障害報告） | 箇条書きを地の文に戻す直し（時系列）、硬い漢語の言い換え（発生、復旧などの報告の語） |
   | proposal（提案書） | なし |
   | minutes（議事録） | 箇条書きを地の文に戻す直し（太字のラベルを含む） |
   | manual（マニュアル） | 箇条書きを地の文に戻す直し（番号つきの手順） |
   | slides（スライド） | 箇条書きを地の文に戻す直し（太字のラベルを含む）、数の宣言と繰り返すだけの「まとめ」の整理、体言止めの項目での主語の抜けと文末の修正、箇条の「〜のは、A、B、C」の修正、他動詞を読点で並べる形の修正 |
   | essay（エッセイ・小説） | 読み取れる比喩の言い換え（エッセイの比喩動詞は直す）、小説の本文のコピー調とダッシュの修正、見出しの比喩と他動詞を読点で並べる形の修正 |
   | formal（公用文、規程、契約書、仕様書） | 硬い漢語の言い換え（正式な語）、「〜を行う」「〜することができる」の言い換え |
   | promo（紹介記事・宣伝文） | 見出しのキャッチコピー、「！」と絵文字、勢いのある語と強める語、評価の語を短く重ねる型と他動詞を読点で並べる形の修正（「紹介記事・宣伝文の勢い」）、見出しの比喩の修正 |
   | mail（メール・チャット） | 宛名、挨拶、結び、署名、クッション言葉の削除、敬語の度合いと口語の書き換え、絵文字の削除 |
   | paper（論文・研究レポート） | ぼかした語の具体化（慎重な言い方）、専門用語と論文調（本研究では）の言い換え、長い文の分割、名詞化の言い換え |
   | script（台詞・脚本） | 台詞の口調、言い回し、短い文を重ねる形の修正（台詞の最後の「。」だけを外す。句点の指定があれば外さない） |

   種類とは別に、入力されたテキストや指示文からドメインを判定し、`references/domains/` の該当するファイルを読みます。
   - `tech` (技術記事): 技術ブログや設計書。箇条書きは15%以下を目安としつつ、並列関係が明確なものは無理に崩さず、元の文や資料にある情報の範囲で手順を整理します。
   - `business` (業務・仕様書): PR説明文や社内レポート。比喩の理由は残しつつ客観的な表現に改め、元の文から分かる範囲で境界条件や責任主体を明記します。
   - `essay` (エッセイ・個人発信): noteや個人雑記。大げさな教訓化を避け、素朴な感情と具体的な体験を残します。
   - 作業フォルダの git の最上位（git の外では作業フォルダ）に `.yomiyasu-words/` があれば、`allow.txt` と `flag.txt` を読みます（1行に1語）。allow.txt の語は、その分野で定着した言い方として直しません。flag.txt の語は、そのプロジェクトで見直すと決めた語です。定着した言い方であることを理由に残さず、Step 2 の直訳語と同じく、指すものと動作を前後の文から確かめて文として書き直します。名前が分からなければ本文を残して尋ねます。
2. **段落の話題と文の関係の把握**
   - 本文・要約・見出し・表やスキーマを区別して読みます。要約の指定がなければ情報を省かず、指定があれば、要約に含める主張の条件・例外・確度も保ちます。見出しは「案内用の見出し」、表やスキーマの名称は「専門用語と名称の扱い」に従います。
   - 段落ごとに「何の話をしているか」を1行でつかみます。話題が異なる段落同士はまとめず、話題が混ざっている段落は分割を検討します。
   - 文ごとに、前の文とどのような関係にあるか（理由、例示、但し書き、言い換え、補足、まとめ等）を確かめます（このメモは出力には出しません）。
   - 説明文や論考では、見出し・問い・列挙の導入が何の関係を説明すると述べているかを、全文で一度確かめます。個々の文が読めても、前段と列挙の対応や、結びの指示先が分かるとは限りません。列挙の前に「そこで」などがある場合は、何への対応なのかも確かめます。明確な対応は読み手が追えるように整え、分からない対応は推測で書き足さず、「情報が足りない場合の暫定文」に従って本文の主張を保ち、確認が必要なら「書き手に確かめたい点」で尋ねます。独立した報告や項目を無理につなげず、仕組みの詳細が省かれているだけで意味不明とは判断しません。
3. **意味の4点の確認**: 元の文の「主張」「比重」「言い切りの強さ」「文の働き」を確認します。「文の働き」は、最優先ルールの7つの文の種類で文ごとに記録します（このメモは出力には出しません）。
4. **文書の主たる用件と段落の目的の確認**: 「文書の立場と文末」に従い、文末を選ぶ前に、まず文書全体で読み手に知らせる主たる用件を確かめ、その用件を果たすために各段落で何を伝えるかを決めます。変更報告であれば、提供情報から書き手がどの対象をどう改めたかを把握し、内部でその段落が読み手のどの問いに答えるかを短く確かめます。推敲では原文の事実、主体、文の働き、不確実性を守り、創作文書や手順書を改定報告へ変えません。作文では元資料のマニュアル調をそのまま真似ず、明示された読み手や目的に合わせます。提供された目的は無視せず、不明な目的や主体は推測で補いません。常体・敬体の変更指定は別に確認し、立場や用件を決めきれない箇所は不確かなまま文末で確定しません（このメモは出力には出しません）。
5. **文の構造の点検**: 語を言い換える前に、主語と述語、修飾語と掛かる先、指示語と指す対象を対応づけます。条件・例外・否定・並列の関係と、名詞の連続も確かめ、読み違いや関係を追う負担がある箇所を特定します。主題（〜は、〜では）が後半の節まで掛かるか、挟まった句のあとの他動詞の目的語が追えるかも確かめます。関係が確定しない箇所と、変更が不要な箇所も区別します（このメモは出力には出しません）。

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

書き直す前に、原文に lint をかけて候補を見ます（`python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_lint.py 元の文.md`。コマンドは「実行するコマンド」の節のとおりです。種類を決めたら `--doc-type 値` を足します）。lint の候補は手がかりの一部です。候補が0件でも原文を読み、1章の型（主述のずれ、ぼかした語、説明の文の前のラベルとコロン、2文の否定対比、括弧に入れた手順、まとまりで並べられる文など）を探し、当たった箇所と候補を一つずつ確かめてから直すか残すかを決めます。lint の候補がないことだけを理由に原文のまま返しません。

直訳語、見出しの比喩ラベル、意味の薄いカタカナ語などの lint の指摘は、直す合図ではなく、文脈を読み直すための候補です。指摘の出た文では、何が、何を、どうするかを原文と前後の文から確かめ、その関係が読める文に書き直します。指摘の出た語を別の語に差し替えるだけでは済ませません。書き直しに使う名前と動作が原文や資料にないときは、本文を残し、「書き手に確かめたい点」に出します。その分野で定着した使い方（flag.txt の語は除きます）と、語の一覧の allow.txt の語は残します。直訳語（機械やシステムが人の動作をする言い方、実物の代わりの場所のたとえ、英語を一語ずつ写した句、英語の短い術語に当てた漢字1字の名詞）は、その分野の人が自分で書くときに使う呼び名か、英語に戻すと一語ずつ英語の言い方に対応するか、の2つを問います。英語の短い術語に当てた漢字1字の名詞を、その分野で定着した呼び名に替えるのは、上の「別の語に差し替えるだけ」に入りません。型と書き直しの例は `references/calques.md`、指摘ごとの見方は `references/review-points.md` にあります。AI の文章によく出る言い回し（ai_phrase）の指摘は、`references/slop-catalog.md` 10章の問いで、判断した人や潜むものの中身のように、何が足りない文かを確かめます。

1章の型に当たった箇所は、直す前に案を1つ書き、原文と次の6点を比べます（言い直しテスト）。何について述べるか、何を認め何を否定するか、誰が誰にするか、範囲と条件、断定・推量・伝聞の強さ、数値・固有名詞・時期。1つでも変わるなら案を捨てて原文を残し、「残したAIっぽいところ」に書きます。案を作り直して通るまで試すことはしません。否定対比（AではなくB）のAを消すのは、Aを消しても主張が変わらないときだけです（「原因はキャッシュではなく、DNSの設定でした」は残します）。2文に分けた否定対比を、Aを残して1文にまとめる直し（「セルフラベリングと否定対比の整理」）は、6点を変えないので進めます。原文と前後から確定した主語や対象を補うことと、補助動詞と「事」「為」の表記を直すことは、6点を変える直しではありません。言い直しテストは型に当たった箇所で意味を守るための確認で、直す箇所を減らすための規則ではありません。主語と述語がかみ合わない文に確定した主語や対象を補う直し（「キャッシュは古くなったら捨て」→「キャッシュのデータが古くなったら捨て」。ほかの例は rephrase-test.md）と、同じ対象や場面の文を意味のまとまりで並べ直す直しは、6点が変わらなければ進めます。主語と使役の述語がかみ合わないときは、述語を変えず主語の側を直します（「主語と目的語の明確化」）。例は `references/rephrase-test.md` にあります。

自分が書いた原稿では、読み手が動く値と主張を資料と文脈で確かめます。比喩や誇張で見えない中身、抜けた主語・数値・条件、根拠と食い違う値か出典のない値があるときと、会話や資料の値を本文に入れる前は、`references/fact-recovery.md` を読みます。原稿だけを渡され、読み手が動けない値の抜けがあるときも読みます。根拠の文があれば確度を変えずに補い、値を直すのは references の条件のときだけにします。なければ1章のとおりに書き、読み手が動けない所だけ報告で問います。資料と文脈から補った値と直した値は、雛形の「事実の確かめ」の「補った」「直した」の行に、出典の文を引いて書きます。本文だけを返す指定では、返答は本文だけにし、区切りの線のあとの注記も、食い違いの知らせや資料と会話の値も、1点だけでも付けません。

`references/gemini-syntax.md` およびドメイン別仕様に従い、以下の手順で変換します。手順の1〜15は、1章の型に当たった箇所だけでなく、本文のすべての文に当てます。型に当たらない文を直すときも、案を書いたら上の言い直しテストの6点で確かめてから採ります。

1. 原文や提供文脈から分かる範囲で、動作主（主語）や対象を明確にします（書き手の一人称を主語に足すのは、書き手を言われたときだけです）。元にない担当者を創作したり、自然なシステム動作を人間の行為へ変えたりはしません。省かれた目的語や対象を補うのは、原文・依頼・提供資料・文脈に対象と関係が明示されているときだけに限定します。推測で創作したり、近くにある名詞というだけで対象を選んだりはしません（補った語がある場合は報告に出します）。読者の理解に必要な定義、識別子、値と状態の対応が依頼や文脈で提供されている場合は、説明に活かします。
2. 文末は、Step 1で確かめた文書の用件と各段落の目的、文・節の働き・時制に合わせて整えます。変更報告の段落では、「どの指針・設定・実装を、どう改めたか」を書き手の改定行為として述語まで書き、一般的な改定宣言の後に方針宣言を並べるだけで済ませません。変更したと分かる内容だけを改定として報告し、改定前の内容が未提供なら比較や追加を作らず、現在の動作・仕様・方針しか分からない記述を今回の改定や維持の方針へ勝手に変えません。現在の動作や方針を補足する場合も、既知の改定との関係や主体の切り替えが読者に伝わるように書き分けます。現在の推敲方針や設定済みの指示を説明するときは、書き手の作業予定に見える「〜します」ではなく、誰の方針かを確かめて「〜するようにしています」「〜する方針です」など主体と状態が読める形で表します。システムの実動作（返します）、利用可能な機能（できます）、手順、依頼、将来計画とは区別し、「ようにしています」を一律の語尾にしません。現在の方針を今回新設・変更・維持した履歴や確実な性能、未知の主体は作らず、関係が不明なら因果でつなげず、完了した変更を予定の表現にしたり、現在の実動作や仕様説明をすべて過去形に揃えたりもしません。自然にまとまっている時制の混在はそのまま保ちます。適切な文末と、変更指定のない常体・敬体は維持し、指定に応じて文体を変える場合も動作主や文の働きを変えません。
3. 指示代名詞（これ、片方など）は、指す先が文脈から分かる場合のみ具体的な名詞に戻します。
4. 比喩動詞や言い回しは、ふだん使う言葉や文脈に合った言葉に置き換えます。データやシステムの「壊れる」は「おかしくなる」「使えなくなる」のように同等の広さの言葉にし、整合性の文脈であることが明らかな場合のみ「整合性が失われる」等とします。「静かに」「黙って」は「気づかないうちに」「知らないうちに」のように気づけない幅のまま直します。定着した慣用句や含みは維持します。
5. 重複する補足カッコを削ります。手順、依頼、先に済ませる作業を括弧に入れた文は、括弧から出して行う順に文で並べます（「設定ファイルを編集します（先にバックアップを取ってください）。」→「先にバックアップを取ってください。そのあと、設定ファイルを編集します。」）。順序を示す語のほかは足しません。英単語や数値の前後に空白があることだけで不自然と扱わず、一律の削除や挿入は行いません（太字の表示や内側の調整に必要な作業、コマンド・コード・URLの必要な空白は維持します）。
6. 「重要なのは」が評価を担っているときは述語に残し、否定対比（AではなくB）は意味や比重を担っているなら否定を残したまま表現を整えます。
7. 「装飾記号の排除と太字の表示」に従い、絵文字、文末の装飾としてのコロン、ダッシュ記号（罫線文字「─」「━」「──」を含む）を排除します。ラベルと値の区切りや、小説・随筆で書き手が文体として使うダッシュ、引用は残します。ダッシュを外して前後を1文につなぐとき、前にある理由や条件（「〜ため」「〜なら」など）がつないだ後ろの部分までかかるようになるなら、2文に分けます。
8. 文末のリズム調整は、AIっぽさを直すついでに単調な繰り返しが生じて読みにくい場合に行います。類似した変更動詞が隣り合う場合も語順や文のまとめ方を工夫しますが、語尾を散らす目的で文の働きや時制を変えません。AIっぽさのない自然な文は文末だけを変えません。直す箇所がほとんどない場合は無理に書き換えません。文をつなげて「〜しましょう」の数を減らすことはせず、地の文でもともと続いている場合はそのままとします（働きの違う文末に変えて散らしません）。箇条書きを地の文にすると同じ文末が単調に続くときは、箇条書きのまま残します。
9. 独立した変更点、手順、担当と結果の対応など、並列関係が明確で読みやすい箇条書きは、AI調に見えるという印象や割合の数値だけで無理に地の文へ戻さず維持します。論理関係を分断しているなど具体的な理由がある場合に地の文へ統合します。地の文にするときも、各項目の働きと、変更指定のない常体・敬体を保ちます。「〜する」「〜しない」がそのまま文として使えるなら、語尾を足さずに残します。文書が勧めであることだけを理由に「〜しよう」「〜しましょう」へ変えません。評価や義務を足さず、単に並んでいるだけなら箇条書きのまま残してよい決まりも維持します。地の文で並べた対策や作業を、依頼がないのに新しく箇条書きにはしません。
10. つなぎ言葉（ただし、しかし、また、そして、つまり等）、主題の「も」、文頭の指示語は、前後の接続先を確かめ、正しく合致するものに整えます（直した場合は「変えたところ」に出します。判断がつかない場合は無理に直さず「書き手に確かめたい点」に出します）。
11. 中身を伴わない予告文は、予告の重みを述語に残して中身の文と1文に統合します（統合した場合は「変えたところ」に出します。統合すると意味が変わる場合は残して「残したAIっぽいところ」に出します）。
12. Step 1で特定した構造上の問題を、元の意図が分かる範囲で整えます。主述の対応、修飾語の位置、名詞の連続、接続や読点を問題箇所の近くで直し、条件・否定・並列・順序が掛かる範囲を保ちます。関係を確定できない箇所は勝手に決めず、「書き手に確かめたい点」へ出します（意味が動きやすい修正は「変えたところ」に出します）。
13. 文が長いことだけを理由に文を分けません。長い文を分けるのは、前後のつながり（手段・理由・順序・対比）を、後ろの文のつなぎ言葉（「そのため」「こうすることで」「一方で」「反対に」など）で残せるときだけに限定します。目的や理由が文末の結論にかかっている文（例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です／〜しますの形）は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。
14. 太字を残すときは、「装飾記号の排除と太字の表示」の書き方に従い、太字として表示される形にします。
15. 「内容に合わない大げさな名詞の整理」に従い、語の指す役割を確かめて直します。意味が確定できない語は、安易な言い換えで状態の種類・強さ・対象範囲を変えず、元の語で伝わるなら残します。語の対象が曖昧でも結びつく動作が分かるなら、推測で仕組みを書き足さず、元の条件付き主張と言い切りの強さをそのまま本文に残します（伝聞や批評に変えたり、説明の項目へ移したりしません）。本文だけでなく変更理由や確認事項でも、不明な語そのものを判断条件など特定の役割だと決めつけず、元にない約束・制約・信頼性を感じさせる語へ言い換えません。不明な語の確認が必要なら「書き手に確かめたい点」で自然に尋ねます。

### 実行するコマンド

検査のスクリプトは `python3`、`python`、`py -3` の順に試して実行します。command not found か「Python was not found」で終わったら、同じ引数で次のコマンドを試します。どれも動かなければ、Step 4 の終わりのとおり目視で点検し、確認の記録に `yomiyasu-check: not_run reason=no_python` と書きます。この SKILL.md の例は `python3` で書いています。コマンドの中の `${CLAUDE_SKILL_DIR}` はこのスキルを置いたフォルダです。Claude Code ではそのフォルダの絶対パスに置き換わります。置き換わらずに残っているときは、SKILL.md のあるフォルダの絶対パスに書き換えて実行します。手順のコマンドには `cd`、`&&`、出力のリダイレクト（`>`、`2>&1`）を付けません。

### Step 3: 検査（リンターと Diff 検査をまとめて実行）

書き直した最終稿を原文とは別のファイルに保存し、同梱の検査スクリプトで、最終稿のリンター（lint）と、原文と最終稿の差分の検査（diff）をまとめて実行します。

検査は最終稿をファイルに保存して `run --final` の CLI で動かし、記録を残します（コマンドは「実行するコマンド」の節のとおりです）。ファイルを書けないとき（ファイルに保存しないよう頼まれたときを含みます）だけ `run --stdin` を使い、返す直前に同じ本文で `verify --final -` を1回実行します（Step 5）。最終稿の lint と diff を別々に呼んだり、スクリプトの関数を import したり python のコードの中から呼んだりせず、check は Bash から CLI を直接呼びます。`--no-record` は、利用者が記録を残さないよう頼んだときだけ付けます。記録には原文と最終稿の全文が入るので、ファイルに保存しないよう頼まれたときも付けます。

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py run --source 元の文.md --final 書き直した文.md --stance=<勧め|決まり|説明> --fact-gaps
```

※ `--stance` には Step 1で確かめた主たる立場（`勧め`、`決まり`、`説明` のいずれか）を指定します。決めきれない場合は省略します。出力される候補を理由に、働きの違う文まで同じ文末へそろえません。依頼や提供された資料があれば `--material 資料` を足します（何個でも）。新規作成では `--source` の代わりに `--material` を渡します。Step 1で種類を決めたら `--doc-type 値` を、読者を決めたら `--reader 値` を足します。

ファイルを書けないとき（ファイルに保存しないよう頼まれたときを含みます）だけ、次のように原文と最終稿を標準入力から渡します（資料は `<<<yomiyasu:material>>>` の行のあとに置きます。コマンドは「実行するコマンド」の節のとおりです）。返答の本文は、渡した最終稿と同じにします。

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py run --stdin --fact-gaps <<'YOMIYASU_EOF'
<<<yomiyasu:original>>>
（原文）
<<<yomiyasu:final>>>
（最終稿）
YOMIYASU_EOF
```

出力の1行目に従います。出力の節ごとの見方は `references/review-points.md` にあります。検出結果は、文章を見直すための候補です。文脈に合う専門用語や事実の記述は、無理に言い換えません。「大事です」のような評価を担う語や、主張に必要な否定（AではなくB）も残します。
bold_not_rendered（太字にならない書き方）が出た場合は、元の太字が正しく表示されるか確認します。すでに表示される書き方なら変更しません。修正が必要な場合も、太字の範囲や前後の文が崩れないかを確認します。不確かな案はそのまま適用せず、目視で整えます。修正は Step 4 の1回にまとめ、警告を消すためだけに言い換えを繰り返しません。

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

Step 3 の出力にある diff の候補と全文差分で、元の文と書き直した文を比較し、意図しない情報の増減やつながり、文末の乱れがないかを点検します。

スクリプトが出力した候補を1つずつ確認し、以下を判断します。
- 文書の用件と段落の確認: 単に個々の文の時制を分類したり語尾の種類を数えたりするのではなく、読み手の立場で段落全体を通読します。文書全体の用件を果たしているか、誰が何をするのかが自然に伝わるかを確認します（語尾の種類の数やばらつきは合否基準ではありません）。変更報告を求めた文章では、この段落のどの文から書き手が何をどう改めたと読み取れるかまで確かめ、一般的な宣言の後に方針宣言が並ぶだけの状態を防ぎます。仕組みの説明や現在の方針・動作仕様が用件である場合はその内容を残し、段落の目的に合っている文末や正当な時制の混在は維持します。
- 言い回しの種類（依頼・義務・評価・可能等）が増減している場合: 元の文の働きからずれていれば元の表現に戻し、正当な言い換えであれば残して「変えたところ」に記載します。
- 文の種類が変わった文: スクリプトが「文の種類を表す語が変わった文」に挙げた文（伝聞・推量・意見・例え・依頼や決まりを示す表現が消えた、または増えた文）は、Step 1の記録と読み比べ、種類が変わっていれば元の種類に戻します。事実・皮肉・仮定のように表現だけでは拾えない種類もあるので、スクリプトの候補に出なかった文も記録と読み比べます。
- 許可・能力・保証の言い方が変わった文: スクリプトが意味が変わる恐れに挙げた許可・能力の言い方の変化、確度の強まり（「場合がある」の言い切り、「必ず」の追加）、約束・保証の追加は、Step 1の記録と読み比べ、元の言い方に戻します。同じ働きと確かめられたときだけ残し、「変えたところ」に書きます。
- 元にない語や消えた語: 勝手な情報の付け足しや、必要な前提の脱落がないか確認します。
- 箇条書きや段落の変化: 箇条書きを地の文にした際に余計な評価や義務が足されていないか、段落統合で話題が混ざっていないかを確認します。意図的な改行整理と区別し、Markdown上必要な改行指定や空白が見落としによって消えていないかも差分から確かめます。
- つながりの確認箇所: つなぎ言葉や指示語が前後の文と論理的につながっているかを確認します。「これ」「それ」などの指す先が一読で分かるかも確かめ、分からなければ推測で名詞を補わずに「書き手に確かめたい点」に出します。
- 構造の変更箇所: 誰が何をどの条件で行うか、修飾先、例外・否定・限定・数量、並列や出来事の順を元と読み比べ、関係を見失う箇所や不要に読み戻る箇所が減ったか確かめます。助詞や語順を変えた箇所では、対象となる人や場面、条件がそろえば行うこととその条件のときだけ行うことの区別が保たれているかも確認します。
- 本文内の反復: 同じ段落で一つの問題や結果を長く言い直していないか確認します。指示語で明確に受けられる重複は整理し、複数の対象を区別するための再掲は残します。
- 名詞と説明文: 本文と「変えたところ」等の説明文で、語が指す役割に合っているか、元にない信頼性・唯一性・約束などが足されていないかを確認します。
- 太字の表示: 「太字にならない書き方」が出たら、元の太字の表示可否と案の範囲を確認し、適切であれば案に従って直します（すでに正しく表示される場合や不確かな案はそのまま適用せず、意味が変わらないため「変えたところ」には書きません）。

修正は1回のみ行い、直したら Step 3 の run をもう一度実行します。そのあとは本文を変えません。Pythonが実行できない環境では、Step 3、Step 4、Step 5 の verify の代わりに、上記と同じ観点（文書全体の用件と段落の目的が果たされているか、変更報告で改定内容が読み取れるか、文末が立場に合っているか、言い回しの増減、文の種類、元にない語、消えた語、段落・箇条書きの変化、接続関係、太字が表示される書き方か）を目視で点検します。この目視の点検は、検査を実行したことにはなりません。

### Step 5: 提出の前の照合

照合の前に、最終稿の lint に残った info の指摘（意味の薄いカタカナ語のように、残しても毎回同じ語に出る指摘）を一つずつ見て、残す理由があるかを確かめます。直訳語（calque）と語の一覧（project_term）の指摘が残っていれば（run と verify の出力の「残した指摘の語」）、その文を Step 2 の問いで読み直し、節に書いたとおり、本文を残して「書き手に確かめたい点」で尋ねるか、残す理由を「残したAIっぽいところ」に書きます。理由を書くだけで尋ねずに済ませるのは、直訳語の定着した言い方と文字どおりの意味のときだけです。原文と最終稿で地の文の読点の数を比べ、増えた読点が「文長と読点の調整」の残す読点に当たるかを1つずつ確かめ、当たらない読点は外します（diff の「読点が増えた」の候補は、その手がかりです）。直したら run をやり直します。原文のファイルを更新する依頼なら、最終稿をそのまま原文の場所に写します（中身は変えません）。提出（ファイルの保存、PR本文への貼り付け、返答）の直前に、本文を変えずに1回、最終稿が検査したものと同じかを確かめます（コマンドは「実行するコマンド」の節のとおりです）。verify のあとに本文を1字でも変えたら（行を足すときも含めます）、run と verify をやり直してから提出します。

```bash
python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_check.py verify --final 提出するファイル
```

ファイルを書けずに標準入力で run したときは、返す直前に、同じ本文（最終稿だけ）を標準入力から `verify --final -` に渡して1回実行します。`--no-record` を付けた run には照らす記録がないので、verify は実行せず、最終稿の照合を実行しなかった検査（記録を残していないため）として報告します。1行目が「ハッシュが記録と合いました」を含まなければ、本文を変えずに Step 3 の run とこの verify を1回だけやり直します。それでも合わなければ、最終稿の照合を実行しなかった検査として報告します。すでに自然で本文を変えなかったときも、run と verify は実行します。

---

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

対話リライト時には、以下のフォーマットで提示します。最終出力の前に、依頼にある出力形式の指定を確認します。本文のみの指定がある場合は、変更理由・残した点・質問・編集者向け注記を別欄に出さず内部確認にとどめ、本文だけを返します（環境の指定で構造化された形式が必要な場合も、編集者向け欄を空にできる形式なら空欄にして本文のみの指定を守ります）。区切りの線のあとの注記や、原稿と資料・会話の食い違いの知らせも付けません。出力形式の指定がない通常の対話では、以下のフォーマットに従って本文後に必要な説明や質問を添えます。文の確定に必要な条件や主張の意味が読み取れず、確定的な本文が書けない場合は「書き直した本文」を暫定文とし、分かる範囲で本文の主張を保って書きます。原文が読者に伝えている未定や調査中の状態は本文に残し、推敲側が意味を読み取れないことについての説明や質問は本文に入れず、「変えたところ」や「書き手に確かめたい点」に置きます。意味や働きに影響しない実装詳細の不足まで機械的に列挙したり、本文全体を不必要に未確定扱いにしたりはしません。「変えたところ」には、その書き方を選んだ短い理由も含めます。絵文字や不要なカッコは使用しません。

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

（読み手に渡す推敲済みの本文。原文にある未定・調査中の状態や主張を残し、見出しや箇条書きなどの書式は保つ。本文全体をコードの囲み（```text など）に入れない。推敲側が意味を読み取れないことについての注記や説明、質問は本文に入れず別欄に置く）

---

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

### 残したAIっぽいところ（※意味や重みを担っているため消さずに残した前置きや結び、内面の説明などがある場合のみ記載。なければこの見出しごと出さない）
- （残した表現と、意味や重みを保つために残した理由。原文に根拠のない重大さなどの比較の基準を勝手に決めたり、残した表現の説明でより狭い具体的な意味を決めつけて書いたりしない）

### 書き手に確かめたい点（※意味・条件・用途などが不明で、本文を確定するために確認が必要な場合のみ、最大3点まで記載。3点を埋めるために問いを足さない。なければこの見出しごと出さない）
- （多いときは、次の順に選ぶ。読み違えると主張、誰が何をするか、主題の掛かる範囲、条件や否定、許可・義務・確度などの文の働きが変わる所。読み手が動く値や手順や頼みごとが決まらない所。語や指示語の指す先。出典、誇張の根拠、用途や立場。答えで本文の語句が変わらない問い（書き足しや、言い方をそろえることの提案）は入れない。同じ順なら、見出しと最初の段落、何度も出る所を先にする。選ばなかった所があれば、最後に「- ほかに N か所」と1行添える。「ここに説明が必要です」とペルソナの知らせはこの3点とは別に数え、それぞれの組のすぐあとに置く）
- （未確定の内容と、本文にどう影響するかを短く記載。説明が重要な場合は何が読み取れず何を確かめたいかを短く述べてから尋ね、同じ説明を他の欄で重複させない。確認の問いでも、不明な語が何を指すかを推測で前提にせず、判断条件や特定の責務など語の種類・役割を勝手に限定して尋ねない。文脈に根拠のない未確定の動作についても、状態や行き先などを勝手に決めつけず、何が分からないかを中立に尋ねる。説明すると述べた関係が読み取れない場合は、どの内容とどの内容の対応が不明かも含める。用語の指す対象だけを尋ねて、その関係を省かない。提供済みの文脈は聞き直さず、意味を保って残せる表現を削るかどうかという好みの問いは出さない）

### 事実の確かめ
（補った・直した事実の出典と、確かめられなかった点。見出しはこの形のまま書く。なければ出さない。曜日や祝日、暦の計算を一般の知識で確かめた結果は書かない）

### 確認の記録
- 書き手・読み手・場面: （「書き手: …／読み手: …／場面: …」の形。値ごとに（指定）か（推定）を付け、決めない値は「決めていない」。この形の外の説明（指定がなかったこと、敬語をどうしたか）は書かない。例「書き手: 決めていない／読み手: 決めていない／場面: incident（推定）」「書き手: 新人エンジニア（指定）／読み手: 上司、上司・目上（指定）、informed（推定。関係から）／場面: 決めていない（週報）」）
- 実行した検査: （lint、diff、資料との照合、最終稿の照合 のうち、実行したものだけ。なければ「なし」）
- 実行しなかった検査: （なければ「なし」。あれば「検査名（理由）」。資料を渡されなかったときは、資料との照合をどちらの行にも書かない）
- 硬化の検査: （run の出力の「硬化の検査:」の値を写す。なければ書かない）
- 勢いの検査: （同じ形）
- 見直し候補: （最後の run の出力の「見直し候補:」の行から「原文 N件 → 最終稿 M件」を写し、「（件数は点数ではない。増減は読みやすさの良し悪しを示さない）」を添える。新規作成では「最終稿 M件」。件数の増減を、読みやすくなった根拠として書かない）
- （verify の出力の2行目をそのまま写す。実行できなかったときは `yomiyasu-check: not_run reason=no_python` のように書き、理由は no_python、not_allowed、check_error から選ぶ）

（エッセイ・小説、紹介記事・宣伝文と判断して表現を残したときだけ、判断を1行で書く。ペルソナについては書かない）
```

エッセイと判断して比喩や語りを書き手の個性として残したときは「エッセイと判断したので、文の個性を残しました」（小説なら「小説と判断したので、読み取れる比喩と語りを残しました」）、紹介記事・宣伝文と判断して勢いのある書き方を残したときは「紹介記事・宣伝文と判断したので、勢いのある書き方を残しました」と、本文とは別に、確認の記録の下に1行書きます。利用者が、yomiyasu が働かなかったと思わないための補足です。直した箇所があっても書きます。本文だけを返す指定のときは書きません。

返答そのものが納品物で本文だけを返す指定があるときは、確認の記録も説明の欄も付けません（検査は同じように行います）。納品物がファイルで、返答が別にあるときは返答に付けます。check の出力が「完了報告」と書くのは、この出力フォーマットの本文のあとの欄（確認の記録を含む）のことです。完了報告の見出しは雛形の字のまま、雛形と同じ ### か #### を付けて書きます（太字やコロンの形、地の文に替えません）。

- 原文を渡された依頼では、状態の行が `mode=rewrite` になります。`mode=compose` なら原文を `--source` に渡していないので、Step 3 からやり直します。
- 「yomiyasu で整えた」のように手順全体を終えたと読める書き方は、実行しなかった検査が「なし」のときだけにします。検査を実行したことは、意味が保たれたことや読みやすさの合格を示しません。