All skills

AIが生成した日本語の推敲に使うスキル。「この文章を読みやすくして」「AIっぽさをなくして」「自然な日本語にして」「文章を脱臭して」といった依頼や、技術記事、仕様書、PR説明文、社内レポート、エッセイ・noteの文章を見直すときに使用する。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。

Use this Skill: https://skilld.dev/gh/nanaism/yomiyasu/yomiyasu

Nothing lands on disk. Nothing to clean up.

Fork this Skill

Edit a local copy. It keeps the author and licence.

SKILL.md

≈117 tokens for metadata: the name and description. ≈17k when used: this file. ≈20k more on demand in 7 files.

Description uses 2.1% of example budget

Before choosing a Skill, your Agent reads its name and description. All available Skills share that space.

  • A shorter description leaves more room for other Skills. This entry exceeds our 1% size suggestion.

In our Claude Code example, all Skill names and descriptions share 8,000 characters. This Skill uses ≈170 characters, or 2.1%.

The 1% threshold is a size suggestion. Longer descriptions can still fit.

Your model, settings, and other Skills decide how much text your Agent can read.

Example settings and source

The example uses a 200k-token context and default Claude Code settings. The count includes the name, description, separators, and when_to_use when present. Codex also counts local file paths.

Skit's source and limits: Codex 0.160.1, Claude Code 2.1.292.

yomiyasu

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

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


1. 基本原則

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

最優先ルール: 意味の保持

書き直す前に元の文の次の4点を確かめ、書き直したあとも必ず同じに保ちます。他の原則は、この4点を変えない範囲でのみ適用します。

  1. 主張(何を言っているか): 伝えたい要点や論理関係を維持します。「本質」「核」などの論点を「目的」など別の概念にすり替えたり、勝手に動詞を足して論点を変えたりしません。
  2. 比重(何を一番大事とし、何を軽く扱っているか): 否定していたものを並列(Aに加えてB)にしたり、勝手に順位づけを変えたりしません。比較や最上級は、何を比べているかも保ちます。重要度の評価を、頻度や見落としやすさの評価に変えません。何の比較か分からなければ原表現を残します。
  3. 言い切りの強さ(断定・推量・可能性): 元の文が言い切っていることは言い切ったまま、推量や可能性で書いていることはその強さのまま書きます(「おそれがあります」と弱めたり、「〜と言えるでしょう」を断定に強めたりしません)。
  4. 文の働き(評価・説明・依頼・予定・感想): 評価の文は評価のまま、説明は説明のまま保ちます(「〜が大事」「〜の本質は」という評価・性質の文を「〜を目的とする」「〜を高める」という目標・予定の文に変えません)。実施済みの変更、現在の動作・方針、今後の予定を時制と役割に合わせて書き分け、完了した変更を予定のような表現にしません。文末は、文書の目的を手がかりに、各文・各節の動作主と働きに合う形を選びます。常体・敬体の選択とは分けて判断します(詳細は「文書の立場と文末」を参照してください)。

文書の立場と文末

日本語は主語を省くことが多く、文末の形が「誰が動くのか」「決まりなのか、勧めなのか、説明なのか」を伝えます。文末を選ぶ前に、「誰が、誰に、何のために、いつのこととして書くか」を手がかりとして、まず文書全体で読み手に知らせる主たる用件を確かめ、その用件を果たすために各段落で伝える内容を決めます。これらを機械的に本文へ明記するのではなく、文末や語調を選ぶ基準とします。文書や段落の目的をそろえることと、すべての文末を同じ種類にすることは別です。助言を含む文書でも、事実や道具の動作を説明する文は説明のまま残します。 変更内容の報告を求められた場合は、提供された事実をもとに「どの指針・設定・実装を、どう改めたか」を、書き手の改定行為として述語まで書きます。「指針を改定しました」と一般的に宣言した後に方針宣言を並べただけでは、報告できたとはみなしません。変更したと分かる内容だけを改定として報告し、現在の動作・仕様・方針しか分からない記述を今回導入・変更・維持した事実へ勝手に変えません。改定前の内容が未提供なら前後比較や追加、改善幅を作らず、現在の動作や方針を補足する場合も、何の現在の状態を説明しているか、既知の改定とどういう関係なのかが読み手に伝わるように書き分けます。 現在の推敲方針や設定済みの指示を補足するときは、書き手の作業予定に見える「〜します」ではなく、誰の現行方針かを確かめた上で「〜するようにしています」「〜する方針です」「〜するよう指示しています」など、主体と状態が読める形にします。ただし「ようにしています」を万能語尾にせず、システムの実動作(「返します」)、利用可能な機能(「できます」)、手順書、読み手への依頼(「してください」)、将来計画(「予定です」)はそれぞれ適切な表現を保ちます。現在の方針を今回新設・変更・維持したという履歴や確実な実行性能、未知の原因・主体は作りません。関係が不明なら因果を作らず、完了した変更を予定のような「〜します」にしたり、現在の実動作や仕様説明をすべて過去形に揃えたりもしません。 常体・敬体は、変更の指定がない限り原文を保ちます。技術記事という分野だけを理由に敬体へ変えません。混在を直す場合も、文の働きとは別に文体を選びます。 文脈が明確でない場合は余計な内容を書き足さず、明確な場合は読み手が理解できるように説明します。読者の理解に必要な定義、識別子、値と状態の対応が依頼や文脈で提供されている場合は、説明に活かします。何の文章かが分かりにくいときは、提供された用途や読み手を、短い見出しや冒頭の説明で示します。分からない主体・意図・条件は推測で補いません。

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

段落と文の論理構造(つながり)

AIが生成した文章は、文同士の接続関係が曖昧であったり、予告だけの空疎な文が挟まったり、段落内に複数の話題が混ざったりしがちです。以下の指針で論理の流れを整えます。

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

同じ段落で一つの問題を説明した後、その対策を述べる文でも同じ問題を長く言い直している場合は、「この問題を防げます」のように、明確な指示語で受けます。原文にある反復だけでなく、書き直しで新たに重複した説明も整理します。複数の問題や条件の切替で、どの対象かを追うために必要な再掲は保ちます。 改行は、話題や説明の段階が切り替わり、分けると読みやすくなる箇所で、意味のまとまりごとに使います。出来事、現在の状態、今後の予定のように、報告の説明段階が切り替わる箇所でも、分けると読みやすければ改行を使います。新たに本文の行を分けるときは改行1つを基本とし、読みやすさを理由に空行を一律に増やしません。時制が変わるたびに機械的に改行したり、常に三段構成にしたりせず、条件と結果、理由と結論、操作の順序を読み違える位置では分けません。元からある意図的な段落分けや、見出し・箇条書き・コードなどの書式上の区切りは保ちます。Markdownの改行指定と通常の行分けを取り違えず、句点ごとに機械的に改行せず、元から自然な短い段落や改行は保ちます。

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

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

主語と目的語の明確化

単語の言い換えにとどまらず、「誰が・何を・どうした」を明確にします。原文や提供文脈から分かる主体を必要な位置で示し、誰の行為かを確かめます。ただし、元にない担当者を創作したり、自然なシステム動作まで人間の行為へ変えたりはしません。省かれた目的語や対象を補うのは、原文・依頼・提供資料に対象と関係が明示されているときだけに限定します。推測で創作したり、近くにある名詞というだけで対象を選んだりはしません。「これ」「片方」などの指示代名詞を名詞に戻すのも、指す先が文脈から分かるときだけに限定します。何を指すか追う必要がある名詞は、「もの」などへ不用意にぼかしません。助詞や使役を変えたときも、誰が何をどうするかの対応を確かめます。補った語がある場合は、出力の「変えたところ」に明記します。 複数の述語で動作主が変わる文は、述語ごとに「動作(主体, 対象)」を確かめます。原文や提供文脈で分かる動作主が切り替わる箇所は、その主体を明記します。例えば「上長が差し戻した場合、システムが通知します」と書き、差し戻す人と通知する主体を区別します。使役は「誰が・何に・何をさせるか」を区別します。長い節を読み戻らないと対象を追えない場合は、対象の再掲や節の分割を検討します。不明な主体や対象は作りません。 主述や使役の対応だけを直す場合は、まず原文の動詞を保ち、確定した主語・相手・対象を明記する案を検討します。動詞自体が不自然でなければ、対象を補うだけで伝わる文を別の長い構文へ組み替えません。比喩など動詞を直す理由がある場合も、元の動作と関係を保ちます。 動作を名詞にして「〜を行う」と書くより、対象と動詞を直接つなぐ方が自然な箇所は、「値を代入する」「変更内容を共有する」のように書きます。何を扱うかが分かる対象を落としたり、動作を別の動作へ変えたりしません。失敗時に値を代入しない処理を「falseを代入する」と変えるような、実際の条件や動作の改変は避けます。 処理や選別の対象を「もの」「それら」で省いている場合は、指す対象が原文や提供文脈から確定し、前の文から拾い直す必要があるときに、元にある名詞で明記します。近くにある名詞というだけで指す先を決めず、候補が複数ある場合は勝手に限定しません。確定した対象の再掲と、新しい対象を足すことを区別します。 動詞を言い換えた後も語順を確かめ、元の関係を保ったまま主語と述語を追いやすくする案を検討します。主述を近づけるために修飾先や条件の範囲を変えず、元から自然な語順は保ちます。

擬人化の解消

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

比喩動詞の具体化

「倒す」「効く」「溶かす」「潰す」といったAI特有の比喩表現を、ふだん使う言葉や文脈に合った言葉に書き換えます。「発生」「担保」など過度に硬い2字漢語を不要な場面で連発しません。意味を保った自然な言い換えができない場合は無理に変えず、元の動詞を残します。 比喩や言い回しが持っていた「含み(気持ちや評価の向き)」は必ず残します。

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

セルフラベリングと否定対比の整理

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

情報の不増補(足さない)

「勝手に足さない」は、原文だけでなく、依頼や提供資料に明示された内容を根拠にします。この原則は本文だけでなく、「変えたところ」「残したAIっぽいところ」「書き手に確かめたい点」のすべての出力欄に適用します。読者の理解に必要な定義、識別子、値と状態の対応が提供されている場合は、説明に活かします。提供済みの文脈を無視して必要な情報を減らすことはしません。 一方で、読み手に不要な説明を毎回足す決まりにはせず、原文や文脈から分からない動作主、名詞、行動、原因、条件、数値、例、専門用語を推測で創作して足すことはしません。ぼかした語を、より狭い具体的な事実に勝手に置き換えることもしません。対象の一部や比べる項目、期間などの限定が前後の文にあっても、その限定がない文へ持ち込んで主張の範囲を狭めません。指示語や「同じ」、用語の定義などで同じ限定が掛かると原文・依頼・提供資料から確定できる場合は、その限定を補っても構いません。本文で元の表現を残した場合でも、説明欄で重大さなど示されていない比較の基準を勝手に決めたり、より狭い具体的な意味を決めつけて書いたりしません。確認の問いでも、文脈に根拠がない未確定の語や動作について、状態や行き先などを勝手に限定せず、何が分からないかを中立に尋ねます。情報が足りず具体的に書けないときは、次の「情報が足りない場合の暫定文」に従います。

情報が足りない場合の暫定文

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

内容に合わない大げさな名詞の整理

決まりや方針を「契約」、原文や比較の基準を「正本」と大げさに呼んでいる場合は、「ルール」「方針」「原文」「比較の基準」「参照するファイル」等、実際の役割に合う語へ直します。手段や書き方を曖昧に「仕組み」と呼んでいる場合も、原文から分かる内容に合う語で書きます。 「境界」が何を区別しているかが曖昧な場合は、文脈から分かる対象や条件、順序で書きます。「この境界を守れば問題を防げる」のように語の指す対象が曖昧でも、「守れば問題を防げる」という動作や関係は分かります。語の対象を勝手に決めることと、条件付きの主張を本文に残すことは別です。元にない仕組みを推測で書き足さず、元の条件付き主張と言い切りの強さをそのまま本文に残します(「防げるとされている」のような批評や伝聞には変えません)。語が何を指すかは特定の役割(時点・責務・範囲・判断条件など)を決めつけず、「書き手に確かめたい点」で自然に尋ねます。 意味が確定できない語は、近い印象の別語へ安易に置き換えて状態の種類・強さ・対象範囲を変えません(「破綻した」を単に「壊れた」「問題のある」と同義と決めない等)。元の語で伝わるなら残し、既知の隔離・対象・処置・順序は本文で保ちます。 取引や合意としての契約、正式な文書を区別する正本、処理の関係や動作を説明する仕組み、数学や区域の境界、テストの境界値、内容が定義されている専門用語や実際の名称は、その意味を保ちます。置換先で信頼性・唯一性・更新元という役割を新たに足しません。原文にある唯一性や評価の強さも落としません。詳しい用例は references/slop-catalog.md を参照してください。

専門用語と名称の扱い

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

文長と読点の調整

文の平均の長さは30〜45字程度、1文あたりの読点は0〜2個を目安にします。読点は、不自然な位置や掛かり先を読みにくくする箇所で調整します。元から読みやすい文の読点を、数や見た目だけで削りません。文が長いことだけを理由に文を分けません。長い文を分けるのは、前後のつながり(手段・理由・順序・対比)を、後ろの文のつなぎ言葉(そのため、こうすることで、一方で、反対に等)で残せるときだけに限定します。目的や理由が文末の結論にかかっている文(例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です/〜しますの形)は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。 短い主題句から述語まで続けて読め、読み分けの役割がない読点は、元の文にあっても外します。「操作画面の『旗』はまだオンにしません」のように書き、実際の項目名は保ちます。条件・逆接や長い句を読み分ける読点は残します。

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

案内用の見出し

記事・文書・スライドの見出しは、新しく書く場合も推敲する場合も、その箇所で何を扱うかが分かる短い項目名にします。「保存期間」「削除後の復元」「共有できる期間」のような名詞句や、「材料を量る」のような短い動作を基本とし、語り出しや理由、操作の細部、警告・条件・結論を文のまま見出しに詰め込みません。記録先や場面が内容を見分ける手がかりになる場合は、本文にある具体的な語を見出しに残します。「記録」「引き継ぎ」だけに縮めず、「Issueに残す採用理由」「担当交代時の引き継ぎ」のように書きます。見出しから外した警告・条件・結論や、「先に」「全部」「ぬるま湯で」のような範囲・順序・手段は省かず、本文になければ本文へ移して同じ意味で残します。 見出しだけで警告や結論を伝えることが依頼で明示された場合に限り、その内容を見出しに保ちます。警告や条件を含むことだけを理由に長い文の見出しを残さず、すべての見出しを名詞句にそろえることもしません。 発表の締めに置かれていることだけでは、見出しが結論を言い切る役割だとは決めません。本文の話題を案内する見出しなら、最後の見出しも同じ基準で整えます。

コピー調の抑制

原文をこの節で整える対象は、不要な読点で間を作る表現や、助詞句・副詞句で切るコピー調です。その型がない自然な文は、この節のために言い換えません。 コピー調になっている実務文の本文は、文脈から確定した動作・判断・評価を、その文の働きに合う述語まで書きます。自分で書く変更理由や補足説明にも、この型を持ち込みません。型を整えるときも、原文と提供文脈で確定している対象の範囲・動作主・条件・手段を省きません。コピー調の見出しやスライドの見出しは、「保存先の指定」のように、その箇所の話題や手順が分かる短い語句にします。本文にある複数の担当者の動作を、一つの担当者の動作にまとめません。 「資料を、全員へ。」「作業を、もっと確かに。」のように、短い句の後で間を置き、助詞句や副詞句で切るコピー調は使いません。原文にある同じ型も、意味・比重・文の働きを保った表現に整えます。読点だけを消して同じコピー調を残したり、語尾を散らすためにこの型へ変えたりしません。 意味を取り違えるおそれがなく、主語・目的語から述語へ続けて読める箇所は、助詞の後で区切らず一続きに書きます。「資料を確認します」「担当者が更新しました」のような文に、間を作る読点を新たに足しません。条件・逆接や長い句を読み分ける読点は、助詞の後にあるという位置だけで削りません。 動作や意図を原文・提供文脈から確定できない場合は、型を消すために具体的な述語や効果を作らず、「情報が足りない場合の暫定文」に従います。原文の引用、確認項目の名称などの用途上十分な省略は保ちます。

装飾記号の排除と太字の表示

絵文字、文末コロン、ダッシュ記号(em dash)、情報量の増えない言い換えカッコを排除します。英単語や数値の前後に空白があることだけを理由に一律に削除したり、逆に一律に空白を入れたりせず、元の書式や指定されたスタイルを保ちます。太字を表示させるための空白や、太字の内側にある不要な空白を直す作業は、英単語前後の削除とは別に維持します。コマンド・コード・URLに含まれる必要な空白も勝手に消しません。 ただし、「日時:10時」「対象:社内ポータル」のように、ラベルと値の対応を示すコロンは文末の装飾とは区別し、元の区切りを残します。URLやコード内のコロンも変更しません。 また、Markdownとして表示される文章(GitHubや技術記事など)で太字を残すときは、太字として正しく表示される書き方に整えます。Markdownの構文規則では、** のすぐ内側が記号(「」『』()【】、。やバッククォート等)で、すぐ外側が文字(ひらがな・漢字・英数字)である場合、処理系や表示環境によっては太字として解釈されず、** がそのまま表示されることがあります(仕様や表示先により実際の表示は異なります)。太字を残すときは、次の優先順で直します。

  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. 重複する補足カッコを削ります。英単語や数値の前後に空白があることだけで不自然と扱わず、一律の削除や挿入は行いません(太字の表示や内側の調整に必要な作業、コマンド・コード・URLの必要な空白は維持します)。
  6. 「重要なのは」が評価を担っているときは述語に残し、否定対比(AではなくB)は意味や比重を担っているなら否定を残したまま表現を整えます。
  7. 「装飾記号の排除と太字の表示」に従い、絵文字、文末の装飾としてのコロン、ダッシュ記号を排除します。ラベルと値の区切りは残します。ダッシュを外して前後を1文につなぐとき、前にある理由や条件(「〜ため」「〜なら」など)がつないだ後ろの部分までかかるようになるなら、2文に分けます。
  8. 文末のリズム調整は、AIっぽさを直すついでに単調な繰り返しが生じて読みにくい場合に行います。類似した変更動詞が隣り合う場合も語順や文のまとめ方を工夫しますが、語尾を散らす目的で文の働きや時制を変えません。AIっぽさのない自然な文は文末だけを変えません。直す箇所がほとんどない場合は無理に書き換えません。文をつなげて「〜しましょう」の数を減らすことはせず、地の文でもともと続いている場合はそのままとします(働きの違う文末に変えて散らしません)。箇条書きを地の文にすると同じ文末が単調に続くときは、箇条書きのまま残します。
  9. 独立した変更点、手順、担当と結果の対応など、並列関係が明確で読みやすい箇条書きは、AI調に見えるという印象や割合の数値だけで無理に地の文へ戻さず維持します。論理関係を分断しているなど具体的な理由がある場合に地の文へ統合します。地の文にするときも、各項目の働きと、変更指定のない常体・敬体を保ちます。「〜する」「〜しない」がそのまま文として使えるなら、語尾を足さずに残します。文書が勧めであることだけを理由に「〜しよう」「〜しましょう」へ変えません。評価や義務を足さず、単に並んでいるだけなら箇条書きのまま残してよい決まりも維持します。
  10. つなぎ言葉(ただし、しかし、また、そして、つまり等)、主題の「も」、文頭の指示語は、前後の接続先を確かめ、正しく合致するものに整えます(直した場合は「変えたところ」に出します。判断がつかない場合は無理に直さず「書き手に確かめたい点」に出します)。
  11. 中身を伴わない予告文は、予告の重みを述語に残して中身の文と1文に統合します(統合した場合は「変えたところ」に出します。統合すると意味が変わる場合は残して「残したAIっぽいところ」に出します)。
  12. Step 1で特定した構造上の問題を、元の意図が分かる範囲で整えます。主述の対応、修飾語の位置、名詞の連続、接続や読点を問題箇所の近くで直し、条件・否定・並列・順序が掛かる範囲を保ちます。関係を確定できない箇所は勝手に決めず、「書き手に確かめたい点」へ出します(意味が動きやすい修正は「変えたところ」に出します)。
  13. 文が長いことだけを理由に文を分けません。長い文を分けるのは、前後のつながり(手段・理由・順序・対比)を、後ろの文のつなぎ言葉(「そのため」「こうすることで」「一方で」「反対に」など)で残せるときだけに限定します。目的や理由が文末の結論にかかっている文(例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です/〜しますの形)は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。
  14. 太字を残すときは、「装飾記号の排除と太字の表示」の書き方に従い、太字として表示される形にします。
  15. 「内容に合わない大げさな名詞の整理」に従い、語の指す役割を確かめて直します。意味が確定できない語は、安易な言い換えで状態の種類・強さ・対象範囲を変えず、元の語で伝わるなら残します。語の対象が曖昧でも結びつく動作が分かるなら、推測で仕組みを書き足さず、元の条件付き主張と言い切りの強さをそのまま本文に残します(伝聞や批評に変えたり、説明の項目へ移したりしません)。本文だけでなく変更理由や確認事項でも、不明な語そのものを判断条件など特定の役割だと決めつけず、元にない約束・制約・信頼性を感じさせる語へ言い換えません。不明な語の確認が必要なら「書き手に確かめたい点」で自然に尋ねます。

Step 3: 静的検査(リンター)

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

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

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

Step 4: 足したもの・削ったものの点検(Diff検査)

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

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

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

スクリプトが出力した候補を1つずつ確認し、以下を判断します。

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

修正は1回のみ行い、スクリプトの再実行を繰り返す往復は行いません。Pythonが実行できない環境では、上記と同じ観点(文書全体の用件と段落の目的が果たされているか、変更報告で改定内容が読み取れるか、文末が立場に合っているか、言い回しの増減、元にない語、消えた語、段落・箇条書きの変化、接続関係、太字が表示される書き方か)を目視で点検します。


3. 出力フォーマット

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

### 書き直した本文

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

---

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

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

### 書き手に確かめたい点(※意味・条件・用途などが不明で、本文を確定するために確認が必要な場合のみ、最大2点まで記載。なければこの見出しごと出さない)
- (未確定の内容と、本文にどう影響するかを短く記載。説明が重要な場合は何が読み取れず何を確かめたいかを短く述べてから尋ね、同じ説明を他の欄で重複させない。確認の問いでも、不明な語が何を指すかを推測で前提にせず、判断条件や特定の責務など語の種類・役割を勝手に限定して尋ねない。文脈に根拠のない未確定の動作についても、状態や行き先などを勝手に決めつけず、何が分からないかを中立に尋ねる。説明すると述べた関係が読み取れない場合は、どの内容とどの内容の対応が不明かも含める。用語の指す対象だけを尋ねて、その関係を省かない。提供済みの文脈は聞き直さず、意味を保って残せる表現を削るかどうかという好みの問いは出さない)

Source: SKILL.md on GitHub

skilld matched fixed text patterns in SKILL.md and file names. Patterns miss obfuscated code.

skilld run checks every file with the same patterns. It asks for approval before it loads a Skill with a behavior marked Needs approval.

No alertstoday3 checks · Risk SAFE
  • Gen Agent Trust Hubtoday

    The skill 'yomiyasu' is a Japanese text refactoring tool designed to normalize AI-generated writing. It uses local Python scripts for linting and style verification. The analysis found no evidence of malicious behavior, data exfiltration, or dangerous commands. The primary security surface is the ingestion of untrusted user text, which is handled analytically through regex-based linting and structural comparison.

  • Sockettoday

    No alerts

  • Snyktoday

    Risk: LOW · No issues

Signed by skilld. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub 18 hours ago.

updated 20 hours ago

README badge

README badge for nanaism/yomiyasu