yomiyasu
AIが生成した日本語を推敲するスキル。利用者が yomiyasu の名前を出して頼んだとき(「/yomiyasu」、「$yomiyasu:yomiyasu」、「yomiyasu で推敲して」など)と、スキルを使った日本語の推敲をはっきり頼んだときだけ使う。CLAUDE.md、AGENTS.md、カスタム指示などで…
Skill by mr04vv
Install
Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.
npx agentmarket install skill/mr04vv-yomiyasu
Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.
Get the weekly diff
The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.
About
Reviews
Write a reviewNo reviews yet. Installed it? Reviews come from verified installers only. How reviews work
Permissions
What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.
- Tools
- No tools found
- Secrets
- None asked for
- Install scripts
- None found
- Runs as
- Python package
Network hosts it talks to 1
codeload.github.com· found in install command
Files it touches
~/.claude/skills/yomiyasu
What's inside
- Skill name
yomiyasu- Description
- AIが生成した日本語を推敲するスキル。利用者が yomiyasu の名前を出して頼んだとき(「/yomiyasu」、「$yomiyasu:yomiyasu」、「yomiyasu で推敲して」など)と、スキルを使った日本語の推敲をはっきり頼んだときだけ使う。CLAUDE.md、AGENTS.md、カスタム指示などで yomiyasu を使うよう求められているときも、名前を出して頼まれたものとして扱う。名前を出さずに日本語の文章を書かせる依頼や、コード、設定、ドキュメントの更新では使わない。意味と条件を保ち、不自然な比喩、曖昧な主述関係、不要な装飾やコピー調を整える。
- License
- MIT
- Metadata
- version: 2.1.0
- Instructions
- 361 lines in SKILL.md · view on GitHub
Before installing
- Ships executable scripts
Files (37)
- LICENSE
- SKILL.md
- UNICODE-LICENSE.txt
- algo-artis.png · assets/
- audience.md · references/
- article.md · references/doc-types/
- essay.md · references/doc-types/
- formal.md · references/doc-types/
- incident.md · references/doc-types/
- mail.md · references/doc-types/
- manual.md · references/doc-types/
- minutes.md · references/doc-types/
- paper.md · references/doc-types/
- pr.md · references/doc-types/
- promo.md · references/doc-types/
- proposal.md · references/doc-types/
- slides.md · references/doc-types/
- business.md · references/domains/
- essay.md · references/domains/
- tech.md · references/domains/
- fact-recovery-details.md · references/
- fact-recovery.md · references/
- gemini-syntax.md · references/
- fact-gaps.txt · references/lists/
- feelings.txt · references/lists/
- hedges.txt · references/lists/
- intensifiers.txt · references/lists/
- nominalization.txt · references/lists/
- persona.md · references/
- rephrase-test.md · references/
- review-points.md · references/
- slop-catalog.md · references/
- markdown_visibility.py · scripts/
- yomiyasu_check.py · scripts/
- yomiyasu_diff.py · scripts/
- yomiyasu_hook.py · scripts/
- yomiyasu_lint.py · scripts/
SKILL.md (first lines)
# 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を代入する」と変えるような、実際の条件や動作の改変は避けます。 処理や選別の対象を「もの」「それら」で省いている場合は、指す対象が原文や提供文脈から確定し、前の文から拾い直す必要があるときに、元にある名詞で明記します。近くにある名詞というだけで指す先を決めず、候補が複数ある場合は勝手に限定しません。確定した対象の再掲と、新しい対象を足すことを区別します。 動詞を言い換えた後も語順を確かめ、元の関係を保ったまま主語と述語を追いやすくする案を検討します。主述を近づけるために修飾先や条件の範囲を変えず、元から自然な語順は保ちます。 ### 擬人化の解消 非生物主語を直すのは、道具や概念に感情や意志を持たせている擬人化表現(「コードが語る」「システムが願う」等)のときを基本とします。道具や仕組みの働きを客観的に述べている文(「このツールはログを集めます」等)はそのまま残します。人が自分でした行動や判断を、抽象名詞が作用したように書いている文(「見積もりの甘さが判断を遅らせた」等)は、原文や前後から誰の行動か分かる場合だけ、その人の行動として書きます(gemini-syntax.md 原則3)。直す場合も、元にない条件(「〜を使えば」)や可能(「〜できます」)を足しません。 ### 比喩動詞の具体化 「倒す」「効く」「溶かす」「潰す」といった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文にまとめます。エッセイでも同じです(小説の語りと会話、紹介記事・宣伝文で短い文を重ねた箇所は除きます)。後ろの文が別の主張を足しているときはまとめません。 直前で問いなどとして挙げた二つを、続く文が「〜ではない」「〜でもない」のような否定の形で両方とも打ち消すだけの場合は、「どちら」が何と何を指すかが直前の文脈から一通りに決まるときに限り、挙げた語を繰り返さずに「どちらでもない。」(敬体なら「どちらでもありません。」)と短く受けて構いません。「どちら」が直前の二つを指すので、打ち消す内容は保たれます。打ち消すほかに問いにない内容(「決して」のような強めの語、限定、なぜ違うかの説明など)を含む否定は、短くせずに書きます。
From mr04vv/agent-config, MIT.
More from mr04vv/agent-config
- 0.567score
visual-explainer
nicobailon
Generate self-contained HTML visual explanations for systems, code changes, plans, data, and technical concepts.
SkillAFreshness: AClaude Code +9 - 0.565score
paper-details
mr04vv
Produce a detailed Markdown explainer of an academic paper.
SkillAFreshness: AClaude Code +9 - 0.565score
animated-arch-diagram
mr04vv
構成図・アーキテクチャ図・エージェント構成・処理の流れを「動く画像」にして、X(Twitter)などに貼れる MP4 と GIF で書き出すスキル。ノードが順に現れ、線が引かれ、光の粒がエッジを流れ、いま動いている部分だけが光り、下に字幕がタイプされ、最後に全体が同時に動いてループする。箇条書きのツリー(「>…
SkillAFreshness: AClaude Code +9 - 0.559score
writing-quotation
mr04vv
Formatting rules for quoting external sources (papers, articles, web pages, prompt templates) inside a Markdown document.
SkillAFreshness: AClaude Code +9 - 0.559score
explain
mr04vv
Conventions for writing a Markdown explainer that walks the reader through a concept or system.
SkillAFreshness: AClaude Code +9 - 0.559score
documenting-with-sources
mr04vv
Common conventions for writing Markdown documents that cite external sources (survey reports, paper explainers, and any deliverable that surfaces facts from…
SkillAFreshness: AClaude Code +9 - 0.553score
mo
mr04vv
moを使ってMarkdownファイルをターミナル上でレンダリングして表示する。「moで開いて」「プレビューして」「moで見せて」などと指示された場合に実行される。
SkillAFreshness: AClaude Code +9 - 0.550score
html
mr04vv
概念・仕組み・調査内容を、HTML による視覚的な説明ドキュメントとして作成・編集する。
SkillAFreshness: AClaude Code +9
Signals
- Stars
- 0
- Forks
- 0
- Open issues
- 0
- Last commit (this folder)
- Oct 20, 2026 (8 days ago)
From GitHub (fetched Oct 24, 2026).
Details
- Version
- 2.1.0
- License
- MIT
- Repository
- github.com/mr04vv/agent-config
- First seen
- Oct 24, 2026
- Last checked
- Oct 24, 2026
- Source
- GitHubgithub-graphql
More from mr04vv
- 0.565score
animated-arch-diagram
mr04vv
構成図・アーキテクチャ図・エージェント構成・処理の流れを「動く画像」にして、X(Twitter)などに貼れる MP4 と GIF で書き出すスキル。ノードが順に現れ、線が引かれ、光の粒がエッジを流れ、いま動いている部分だけが光り、下に字幕がタイプされ、最後に全体が同時に動いてループする。箇条書きのツリー(「>…
SkillAFreshness: AClaude Code +9 - 0.565score
paper-details
mr04vv
Produce a detailed Markdown explainer of an academic paper.
SkillAFreshness: AClaude Code +9 - 0.559score
explain
mr04vv
Conventions for writing a Markdown explainer that walks the reader through a concept or system.
SkillAFreshness: AClaude Code +9 - 0.559score
documenting-with-sources
mr04vv
Common conventions for writing Markdown documents that cite external sources (survey reports, paper explainers, and any deliverable that surfaces facts from…
SkillAFreshness: AClaude Code +9 - 0.559score
writing-quotation
mr04vv
Formatting rules for quoting external sources (papers, articles, web pages, prompt templates) inside a Markdown document.
SkillAFreshness: AClaude Code +9 - 0.553score
mo
mr04vv
moを使ってMarkdownファイルをターミナル上でレンダリングして表示する。「moで開いて」「プレビューして」「moで見せて」などと指示された場合に実行される。
SkillAFreshness: AClaude Code +9
Cite this page
yomiyasu skill. Agent Mart. https://agentmart.dev/skills/mr04vv-yomiyasu (last updated 2026-10-24)