AI студия Владимира Ломтева
УСЛУГИПРОЕКТЫСТАТЬИБАЗА ЗНАНИЙМаркетплейсОбучениеПолезные сервисы

Оставьте заявку,
чтобы обсудить проект

Напишите ваш вопрос, не забудьте указать телефон. Мы перезвоним и все расскажем.

Контакты

Москва

Работаем по всей России
и миру (онлайн)

+7 (999) 760-24-41

Ежедневно с 9:00 до 21:00

v.lomtev@airassvet.ru

По вопросам сотрудничества

TelegramWhatsApp

Есть предложение?

Напишите нам в мессенджеры

© 2025 AI студия Владимира Ломтева

Политика конфиденциальностиСогласие на обработку ПДн|ИНН 623412173261
    Yomiyasu — Скилл для ИИ-агентов | AI Рассвет

    Yomiyasu

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

    Скиллы для операций#GitHub#nanaism/yomiyasu#skills.sh
    Скачивания
    2
    В избранном
    0
    Комментарии
    0
    Просмотры
    8

    Установить скилл

    Добавьте инструмент одной командой или скачайте проверенный архив версии.

    npx skills add nanaism/yomiyasu --skill yomiyasu
    Скачать ZIP
    Версия
    1.0.0+986da6ffc893
    Автор
    Владимир Ломтев
    Репозиторий
    nanaism/yomiyasu
    GitHub: nanaism/yomiyasu

    Как установить

    1. 1Скопируйте команду из блока установки.
    2. 2Запустите её в терминале из каталога проекта.

    Документация

    yomiyasu

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

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


    1. 基本原則

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

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

    書き直す前に元の文の次の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個を目安にします。読点は、不自然な位置や掛かり先を読みにくくする箇所で調整します。元から読みやすい文の読点を、数や見た目だけで削りません。文が長いことだけを理由に文を分けることはしません。長い文を分けるのは、前後のつながり(手段・理由・順序・対比)を、後ろの文のつなぎ言葉(そのため、こうすることで、一方で、反対に等)で残せるときだけに限定します。目的や理由が文末の結論にかかっている文(例: 「設定を先に読み込んで、起動を速くするために使います」のような、〜するために〜です/〜しますの形)は、分けると「何のために何が必要か」の向きが変わりやすいため分けません。分けると向きが変わるなら分けずに残します。

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

    案内用スライドの見出し

    本文の話題や手順を案内する見出しは、その箇所で何を扱うかが分かる短い語句に整えます。記録先や場面が内容を見分ける手がかりになる場合は、本文にある具体的な語を残します。「記録」「引き継ぎ」だけに縮めず、「Issueに残す採用理由」「担当交代時の引き継ぎ」のように書きます。見出し自体が結論・条件付きの警告・評価を伝えている場合は、その内容を一般的な題名へ薄めずに保ちます。 発表の締めに置かれていることだけでは、見出しが結論を言い切る役割だとは決めません。本文の話題を案内する見出しなら、最後の見出しも同じ基準で整えます。

    コピー調の抑制

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

    装飾記号と不要な空白の排除

    絵文字、文末コロン、ダッシュ記号(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: 静的検査(リンター)

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

    ## スキル配置先(${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つずつ確認し、以下を判断します。

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

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


    3. 出力フォーマット

    対話リライト時には、以下のフォーマットで提示します。意味を確定できない箇所がある場合は「書き直した本文」を「暫定文」とし、本文内でも未確定箇所を示します。「変えたところ」には、その書き方を選んだ短い理由も含めます。本文のみなど出力の指定がある場合はその指定を優先し、本文内の未確定の表示は残します。絵文字や不要なカッコは使用しません。

    ### 書き直した本文
    
    (書き直した本文。意味が未確定の箇所は、その点が分かる暫定文)
    
    ---
    
    ### 変えたところ
    - (意味が動きやすい変更、つながりを直したところ、文末を立場に合わせてそろえたところ、補ったものだけを、最大5点まで記載。文末をそろえた箇所は1行にまとめて記載。該当がなければ「なし」と1行で記載)
    - 元の表現 → 書き直し後の表現(変更理由)
    
    ### 残したAIっぽいところ(※意味や重みを担っているため消さずに残した前置きや結びがある場合のみ記載。なければこの見出しごと出さない)
    - (残した表現と、意味や重みを保つために残した理由)
    
    ### 書き手に確かめたい点(※意味・条件・用途などが不明で、本文を確定するために確認が必要な場合のみ、最大2点まで記載。なければこの見出しごと出さない)
    - (未確定の内容と、本文にどう影響するかを短く記載。提供済みの文脈は聞き直さず、意味を保って残せる表現を削るかどうかという好みの問いは出さない)
    

    Требования и возможности

    Источник пакета
    https://github.com/nanaism/yomiyasu/tree/986da6ffc89316a90e509d007c1efe1fc59057e6/skills/yomiyasu

    Файлы версии

    ПутьРазмерSHA256
    .claude-plugin/marketplace.json68527a274555cdd4c63...
    .claude-plugin/plugin.json3299d0ef67c1bd44c3a...
    SKILL.md44533db6c6b6bd2d4e61f...
    references/domains/business.md4434145b97cec0a472f8...
    references/domains/essay.md2404cdb1e9ff907cb618...

    Частые вопросы

    Как установить Yomiyasu?
    Используйте команду npx skills add nanaism/yomiyasu --skill yomiyasu или скачайте ZIP-архив.
    Можно ли скачать Yomiyasu бесплатно?
    Да, опубликованную версию можно скачать из маркетплейса бесплатно.

    Похожие инструменты

    Смотреть все
    Ozon Seller и Performance APIСправочник Ozon Seller API и Performance API с локальными OpenAPI-спецификациями.Grill MeA relentless interview to sharpen a plan or design.Git CommitExecute git commit with conventional commit message analysis, intelligent staging, and message generation. Use when user asks to commit changes, create a git commit, or mentions "/commit". Supports: (1) Auto-detecting type and scope from changes, (2) Generating conventional commit messages from diff, (3) Interactive commit with optional type/scope/description overrides, (4) Intelligent file staging for logical grouping
    Комментарии

    Войдите, чтобы оставить комментарий.

    Комментариев пока нет.

    Установить скилл

    Добавьте инструмент одной командой или скачайте проверенный архив версии.

    npx skills add nanaism/yomiyasu --skill yomiyasu
    Скачать ZIP
    Версия
    1.0.0+986da6ffc893
    Автор
    Владимир Ломтев
    Репозиторий
    nanaism/yomiyasu
    GitHub: nanaism/yomiyasu
    Llm WikiThe foundational knowledge distillation pattern for building and maintaining an AI-powered Obsidian wiki. Based on Andrej Karpathy's LLM Wiki architecture. Use this skill whenever the user wants to understand the wiki pattern, set up a new knowledge base, or needs guidance on the three-layer architecture (raw sources → wiki → schema). Also use when discussing knowledge management strategy, wiki structure decisions, or how to organize distilled knowledge. This is the "theory" skill — other skills handle specific operations (ingesting, querying, linting).