AGENT SKILL

yomiyasu

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

License 许可
MIT
所属仓库
upamune/skills
最近更新
2026-11-15
Stars
★ 1
Forks
0

01 前言 Front Matter

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

02 资源文件 41

03 SKILL.md 正文

yomiyasu

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

用途と表記の扱い

  • 原文があれば推敲、資料(依頼文だけのときは依頼文)から書くなら新規作成です。新規作成では依頼の読み手と目的に合わせて書き、主張・条件・担当・数値・未確認の事項が資料どおりかを読み比べます。原文と資料の両方があれば推敲として進めます。
  • 補助動詞と形式名詞の「事」「為」の漢字はひらがなにします(して下さい → してください、出来ます → できます、して頂く → していただく、して見る → してみる、する事 → すること、する為 → するため)。「事の経緯」のような中身のある名詞は残します。
  • ほかの表記の揺れ(外来語の長音、送り仮名、かなと漢字、全角と半角)は原文のままにします。

1. 基本原則

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

書き直す前に元の文の4点を確かめ、書き直したあとも同じに保ちます。ほかの決まりは、この4点を変えない範囲でだけ当てます。

  1. 主張: 要点と論理関係を保ちます。論点を別の概念にすり替えたり、動詞を足して論点を変えたりしません。
  2. 比重: 否定していたものを並列(Aに加えてB)にしたり、順位を変えたりしません。比較は何と何を比べているかを、差を述べる文は何と何の差かを示す語句を残します。重要度の評価を頻度の評価に変えません。
  3. 言い切りの強さ: 断定は断定のまま、推量・可能性はその強さのまま書きます。許可(〜してよい)、能力(〜できる)、義務(〜しなければならない)、保証(必ず〜する)もこの強さに入ります。「含めてよい」を「含められる」や「含める」に、「〜場合がある」を言い切りにせず、「必ず」「保証する」を足しません(「〜することができる」を「〜できる」にする程度は構いません)。
  4. 文の働き: 評価・説明・依頼・予定・感想の働きと時制を保ちます。評価の文を目標や予定の文にせず、完了した変更を予定の「〜します」にしません。

書き直す前に、各文の種類(事実、意見・評価、依頼・決まり、例え・比喩、皮肉・冗談・反語、仮定・予測、引用・伝聞)を内部メモに記録し、書き直したあとで変わっていないかを読み比べます(比喩動詞を含む文は事実の文)。伝聞や意見を断定に、依頼を説明に、例えを言い切りに、反語を疑問に、仮定を予定に変えません。文を分けたりつないだりしても元の種類をどこかで保ち、決めきれない種類は候補のまま扱います。種類が変わったら元に戻し、戻せなければ原文を残して「書き手に確かめたい点」に出します。わざと複数の読みを残した箇所は一つに決めません。決意や抱負の結びは内容を残して大げさな語だけを直し、評価や実感を述べる「〜ことができました」も残します。メモは出力に出しません。

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

根拠にするのは、原文、依頼、資料、文脈(この会話の利用者の発言、開いたファイル、コマンドの出力)に書いてあることだけです。自分やほかのAIの発言と一般の知識は使いません。原文から分からない動作主、原因、条件、数値、例、専門用語を推測で足さず、ぼかした語をより狭い事実に替えず、前後の文の限定をその限定のない文に持ち込みません。要約の指定がなければ情報を省きません。この決まりは本文のあとの欄にも当てます。提供された定義、識別子、値と状態の対応は説明に活かします。出典のない「〜という声もあります」は本文に残し、出典が受け取り方を左右するときだけ尋ねます。「昨日」のような相対の日付は、書いた日が確かに分かるときだけ括弧で日付を添え(昨日(3月4日))、essay と promo、すでに日付があるとき、ほかの日付と食い違うときは添えず、曜日は足さず、添えたら「変えたところ」に何から数えたかを書き、検査に出ても戻しません。

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

本文には、原文が読者に伝えている「未定」「調査中」も含め、主張・否定・条件・強さ・動作主をそのまま残します。読み取れないことの注記、質問、「要確認」のような編集表示は本文に入れず、理由は「変えたところ」、確かめることは「書き手に確かめたい点」に置きます。主張を確認の欄に移したり「〜と述べている」と伝聞にしたりしても、本文で保ったことになりません。意味を確定できなくても結びつく動作が分かる表現は、対象や仕組みを足さずに本文に残します。質問は元から未定のことと読み取れないことを分けて尋ね、些細な不足を並べません。

文書の立場と文末

文末を選ぶ前に、誰が、誰に、何のために、いつのこととして書く文書かを確かめ、主な用件と各段落で伝えることを決めます。立場は、勧め(読み手に勧める・頼む文書。動くのは読み手)、決まり(運用ルール、手順書、お知らせ、仕様)、説明(技術の説明、報告、体験)の3つです。 立場は、依頼の行き先と読み手、次に本文の手がかり(主語、宛名、署名、見出し)で決めます。分野の名前(技術記事向け)だけでは決めず、決めきれなければ文末で決めません。 文末を直すのは、動作主・時制・働きが意図とずれて読めるとき、文体を指定されたとき、行き先と立場が合わないとき、「です・ます」と「だ・である」が意図なく混ざるときだけです。合わない文末だけを直し、働きと強さ(勧めを義務にするなど)は変えません。決まりの文書で決まりそのものを書いた「〜しましょう」は「〜します」にそろえ、理由の文と「〜してください」は残します。語尾を散らすために働きを変えたり、文をつないで「〜しましょう」を減らしたりしません。システムの動作(返します)、機能(できます)、依頼、予定、現在の方針(〜する方針です)は、それぞれの形を保ちます。変更の報告は、どの指針・設定・実装をどう改めたかを述語まで書き、改定前が分からなければ比較を作らず、現在の動作や方針を今回変えたことにしません。常体・敬体は指定がなければ原文のままにします。並列が明確な箇条書きは地の文に戻さず(論理を分断するなら地の文にします)、地の文の項目を新しく箇条書きにもしません。立場を決めきれずに文末を変えたときは、もう一方の立場の文末を「書き手に確かめたい点」に1行で示します。

主語と目的語の明確化

「誰が、何を、どうした」は、原文・依頼・資料・文脈に書いてある語だけで補います。元にない担当者や動作主を作らず、システムの動作を人の行為に変えず、近くにある名詞というだけで対象を選びません。指示語を名詞に戻すのは指す先が決まるときだけです。何の期限か、何を頼むかが抜けて読み違えるときは、同じ文書の前後の語で補います。2つ以上に読めれば尋ねます。目的語を書かない他動詞の前に句が挟まり、前の別の名詞が目的語に読める文は、書いてある対象を目的語に書くか、動作を名詞にして主語に立てます。主題が部品の名前で後半に別の名前の動作が続き、その主題の話か決まらない文は、主体を足さずに尋ねます。動作主が切り替わる所は主体を書き、使役の述語は変えずに主語の側を「〜には」に直します。書き手の一人称(私は)を足すのは、依頼で書き手を言われたときだけです。

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

つなぎ言葉、主題の「も」、文頭の指示語は、何と何をつなぐかを確かめ、根拠が前後にあれば正しい語に直し、なければ尋ねます。予告だけの文は、予告の重みを述語に残して続く文と1文にします。「重要なポイントは3つです」のような数の予告は、数と項目が合うときだけまとめ、合わなければ数も項目も変えずに尋ねます。1段落1話題にします。主述のかみ合わせを直し、動作を名詞にした主題に要ることが続く文は「ログを一括で削除するには、」の形にし、修飾・条件・否定・因果・時系列の掛かる範囲を保ち、見聞きした日時を出来事の日時にしません。2通りに読める所は一つの読みに決めず尋ねます。文が長いことだけでは分けず、分けるのは手段・理由・順序・対比を後ろの文のつなぎ言葉で残せるときだけにし、目的や理由が文末に掛かる文も分けません。原文の1文から「〜ためです。」の短い文を切り出さず、「〜ます。」の短い文を続けすぎず、同じ対象や場面は意味のまとまりで1文にします。改行は話題や段階が変わり分けると読みやすい所に1つ入れ、元の段落分けと書式の区切りは保ちます。 本文で言い終えたことを同じ強さで言い直すだけの締めの文や「まとめ」は削ります。新しい情報や絞り込みがあるもの、長い文書の要約、依頼で指定されたまとめ、報告やお知らせの最後で次にすることや予定を述べる文は残します。削る前に、そこにしかない数値・条件・例外がないかを確かめ、あれば残すか本文へ移します。

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

否定対比(AではなくB)は、Aを外しても主張が変わらないときだけ肯定文にします。誤解を正す否定(「原因はキャッシュではなくDNSの設定でした」)は残し、Aを並列や順位づけに変えません。「弱みではなく視点の違いでもある」は一つの文のまま残します。直前に挙げた二つをどちらも打ち消すだけの文は「どちらでもない。」と受けて構いません。用語の説明が「〜ではありません」だけで薄いときは、原文や資料から何であるかを先に書き、否定はあとに残します。「重要なのは」が評価を担っていれば述語に移して残し、理由・対比・結論を示す前置きは残します。

内容に合わない大げさな名詞の整理、専門用語と名称の扱い

決まりを「契約」、原文を「正本」、確認を「ゲート」、一覧を「台帳」のように大げさに呼ぶ語は、実際の役割の語に直し、元にない信頼性や唯一性を足さず、元の強さも落としません。正式な名称や専門用語としての用法(品質ゲート、行政の台帳)は残します。「分離」「保証」「管理」のような漢語の名詞や「〜を行う」だけで動作を済ませた文は、原文や資料に動作と条件があるときだけその文に書き直し、なければ残して尋ねます。専門的な意味の語はその分野で定着した用語で書き、文字どおりの日常語は専門用語に変えず、識別子、画面の項目名、API の名称・型・値、引用した原文は変えません。意味の決まらない語を近い印象の語に替えません。

比喩動詞の具体化と擬人化の解消

「倒す」「効く」「溶かす」「潰す」のような比喩動詞は、何がどう変わったかを書くか、ふだんの言い方にします。効き目だけをぼんやり言う形(「助けになっている」)にしません。「うっかり」「ようやく」「〜てしまった」「地味に」のような含みは別の語で残し、原文より強い確度の語(確実に、必ず)は足しません。データやシステムの「壊れる」は「おかしくなる」「使えなくなる」のように同じ広さの語にし、整合性の話だと分かるときだけ「整合性が失われる」にします。システムやデータの不具合や変化について、知らせが出ないことを「静かに」「黙って」とぼかしているとき(「静かに壊れる」「黙って失敗する」)は、「気づかないうちに」「知らないうちに」のように気づけないという幅のまま書きます。それ以外の「静かに」(人や物の様子、「議事録が会議の迷いを静かに語っていた」のような擬人化)は、この言い換えに当てません。比喩なら比喩と擬人化の決まりのとおりに直し、原文にない「気づかなかった」という含みを足しません。「骨が折れる」のような慣用句は残します。エッセイと小説では、何を何に例えたか読める比喩は残し(エッセイの比喩動詞は直します)、主語と述語を取り出すと成り立たず連想もできない比喩(「午後が膝を抱える」)は直し、あとの文で例えた理由を述べた比喩は残します(references/slop-catalog.md 8章)。 道具や概念に感情や意志を持たせた擬人化(「コードが語る」)は直し、働きを客観的に述べる文(「このツールはログを集めます」)、働きが一読で分かる擬人化(「センサーが異常に気づく」)、開発者向けの文書で識別子が主語の文は残します。人の判断を抽象名詞の作用のように書いた文(「見積もりの甘さが判断を遅らせた」)は、誰の行動か分かるときだけ書き直します。コードを人の知識や役目にたとえた言い方(「呼び出し元の事情を知っている」)は、コードや資料に実際の動作が書いてあるときだけ、何を受け取り、何を返し、何を呼ぶかの文に直し、分からなければ残して尋ねます。設計の用語(責務を持つ、依存する)と、原文や資料がその用語で書いたオブジェクト指向の「〜はデータを知っている」は残します。

次の直しは、lint に出なくても当てます。

文長と読点の調整

短い主題(は、も、には、では、とは)、短い主語の「が」、短い目的語の「を」のすぐあとで間を作るだけの読点は外し、新しく足しません。誤読を防ぐ所(「店長は、慌てて逃げた客を追いかけた」)、主題のあとに別の動作主が続く所(「会議では、担当者が説明しました」)、長い主語や節のあと、挟み込みの句の前、並べた語句の間、条件・逆接・理由の切れ目、文頭の接続語のあと(まず、また)の読点は残し、ほかは何か所あっても外します。区切りがどれも短い文では副詞(毎日)のあとの読点も外します。「1つ目は、」のような項目の先頭の主題のあと、「AではなくB」の「なく」のあと、見出しの中の読点も外します(文書の題は変えません)。外すのは読点だけで、語順と述語は変えません。小説や随筆で書き手が間として置いた読点は残してかまいません。

太字とラベル

箇条書きの先頭のラベルとコロン(- **期限**: 11月末。太字でなくても同じ)は、コロンのあとが値か説明の文かで分けます。日時・場所・担当・数値・状態のような値と、物や方式、引数、設定項目、作業の名前に説明が続く項目と、値の項目が並ぶ中の1項目は、ラベルとコロンを残します。ラベルが説明の文をまとめただけの語(「特徴」のような分類の語、出来事を名詞にした語、短い述語)なら、太字とラベルとコロンを外し、ラベルの意味を説明の最初の文に入れて1文にします(1. **応答速度の低下**:ピーク時に3秒を超えた。 → 1. 応答が遅くなり、ピーク時に3秒を超えた。)。ラベルを文に入れたら、入れる前とラベルの働きが同じかを確かめます。勧める動作のラベル(**手順書を読む**:)は、「読むときは」のような条件にしません。ラベルの場面と説明の文の条件が別のもの(**停電時の対応**:電源が使えない場合は)なら、2つを1つの条件にまとめず、ラベルとコロンを残して太字だけを外します。ラベルを外すだけにして語を足さないのは、ラベルの語がすべて説明の文にあるときだけです。説明の文にないラベルの語は落とさずに文へ入れ、1文にします(- **鍵と名札の返却**:帰る前に受付に返却する。 → - 帰る前に鍵と名札を受付に返却する。)。入れたあとで、条件や否定、「〜し、」で続けた節の掛かる範囲が変わったら、ラベルとコロンの形に戻します。番号と項目の数と順は保ちます。

太字のラベルとコロンで始まる項目が2つ以上重なるときは、残すラベルの太字も多用として外します。議事録とスライドのラベルと値、紹介記事・宣伝文の見出しの太字の行はこの扱いの外です。

2文の否定対比と「もちろん、」

否定と肯定を2文に分けた形(「必要だったのは新しい道具ではない。使い方をそろえることだった。」)は、否定を残して1文にまとめ、「なく」のあとに読点を足しません。エッセイでも同じです。小説の語りと会話、紹介記事・宣伝文で短い文を重ねた所、後ろの文が別の主張を足しているときは除きます。文頭の「もちろん、」に数語だけが続く短い文(「もちろん、失敗もする。」)は随筆でも「もちろん、」を外し、別の語で補いません。会話や引用、答えの「もちろんです。」、後ろに具体的な内容が続く文は対象外です。

案内用の見出し

見出しは、その節で何を扱うかが分かる短い項目名(「保存期間」「材料を量る」)にし、語り出し、理由、警告・条件・結論を文のまま詰め込みません。節を見分ける手がかりの語(「Issueに残す採用理由」)は残します。見出しは「AではなくB」の形にせず、Bの側だけを書きます。後ろの括弧と結びの「〜について」は外し、管理番号、社内の呼び名、画面の項目名の括弧(「(REQ-118)」)は残します。「jqとは:使い方」は「jqの使い方」にします。本文に出てこない一語の比喩の見出しは、本文の語で項目名にします。 見出しから外した警告・条件・結論、範囲・順序・手段、書き手の評価や態度は省かず、本文になければ本文へ移して同じ意味で残します。本文へ移すときは、見出しの語を落とさずに使います(見出しの「独自の設定ファイルを増やさず」を本文で「独自のファイルを増やさない」とすると、増やさないものの範囲が広がります)。節の役割を示す語(「まとめ」「はじめに」)は、見出しを短くするときも外しません。依頼で指定された見出しの形とまとめの節、文書の題、議事録の見出し、紹介記事・宣伝文のキャッチコピーは直しません。見出しと節の数と順は変えません。

装飾記号の排除と太字の表示、コピー調の抑制

絵文字、文末の装飾のコロン、ダッシュ(em dash、「─」「──」)、情報の増えない言い換えの括弧は外します。ラベルと値のコロン(「日時:10時」)、URLやコード、罫線の区切り線、出典の記号は残します。ダッシュを外して1文につなぐと前の理由や条件が後ろまで掛かるなら、2文にします。手順や先に済ませる作業を括弧に入れた文は、括弧から出して行う順に並べます。原文の「■」「・」は Markdown に置き換えず、英数字の前後の空白は一律に足したり消したりしません。 「資料を、全員へ。」のように短い句で切るコピー調、「速い。軽い。安い。」のように評価の語だけを並べる型は、対象と動作が原文から決まるときだけ述語まで書きます。評価の語を足したり強めたりせず、対象が決まらなければ残します。「〜したのは、A、B、C。」は、前提が前の文や見出しにないときだけ「〜では、A、B、Cが変わった」にします。

promo では勢いを残し、根拠のない誇張は本文を変えずに尋ねます。

直訳語、漢語の詰まり、連用形名詞

直訳語(機械やシステムが人の動作をする言い方、実物の代わりの場所のたとえ、英語を一語ずつ写した句、英語の短い術語に当てた漢字1字の名詞、英語の術語に当てた2字以上の名詞)は、その分野の人が自分で書くときに使う呼び名か、英語に戻すと一語ずつ対応するか、の2つを問います。直すときは、何が何をどうするかを前後の文から確かめて文として書き直し、語を差し替えるだけで済ませません(術語に当てた名詞を定着した呼び名に替えるのは差し替えに入りません)。名前と動作が原文や資料になければ残して尋ねます(型と例は references/calques.md)。 助詞を落として漢語を詰めた句(「書類不備発見時は」)は、語を残して助詞と動詞を補ってほどきます。ほどくと「とき」が近くで続くなら、「時」「際」を残すか、ほどきません。定着した複合語(ログイン画面)と正式な語は詰まりとして扱いません。 漢語と和語の選び方は原文のままにします。その文書でふつうに使う漢語(確認する、使用する、停止する、動作する、現在、現時点)は和語の言い方に替えず、報告書の「発生」も残します。和語に替えてよいのは、中身のない硬い漢語(多角的、包括的、活用する。references/slop-catalog.md 7章)、決まり文句、比喩、名詞化の言い回し(〜を実施する、〜することが可能です)のように、ほかの決まりで直す所だけです。そこでも文書の硬さに合う語にし、和語の動詞に替えるのは目的語が文の中で追え、意味の幅が同じときだけにします(「確認する」は「見る」にしません)。書き直した所に、原文にない漢語や名詞化の言い回し(担保、〜の実施)を足しません。ペルソナで敬語を上げる言い換え(同じこと → 同様のこと)と、読み手を general に指定されたときの言い換え(references/audience.md 8章)は、この決まりの外です。新規作成でも、資料の漢語を和語の言い方に替えません。 他動詞の連用形を1語だけ名詞にして「の」で受ける形(「結果の確かめ」)は、「結果を確かめる」か定着した漢語(結果の確認)にします。「資金集め」「見直し」のような定着した語は残し、漢語を和語にひらくときもこの形を作りません。

2. 実行手順

Step 1: 種類と読み手

  • 種類と読み手は、依頼と本文の手がかりだけで決めます。種類は pr、article、incident(障害報告)、proposal、minutes、manual、slides、essay(エッセイ・小説)、formal(公用文、規程、契約書、仕様書)、promo(紹介記事・宣伝文)、mail(メール・チャット)、paper、script(台詞・脚本)の13種類で、当たらなければ決めません。種類を決めたら、書き直す前に必ず references/doc-types/<種類>.md を読み、そこで当てないとした規則を当てません(書き方に迷うときは references/domains/ の該当するファイルを読みます)。
  • 読み手は expert、informed、general の3段階です。指定に従い、分からなければ決めません。informed か general を指定されたら references/audience.md を読みます。その読み手に説明の要る用語で原文と資料に説明がなければ、語を残して「ここに説明が必要です: 語(場所)」と書きます。
  • 決め方で直し方が変わり、問い返せるときだけ、書き直す前に1回だけ確かめます。本文だけの指定、一回きりの実行、ほかのスキルの途中、「質問しないで」のときは決めずに進みます。
  • 書き手の立場と読み手との関係(上司、取引先など)は、依頼で言われたときだけ使い、references/persona.md を読んでから直します。上司と社外の読み手への依頼と読み手の行為は尊敬語に、社外に向かう書き手の行為は謙譲語に上げ、「お・ご」を付けるだけでなく、その関係で人がふつう書く言い回しにします。言われないときはペルソナを理由に敬語も書き手の主語も変えず、ペルソナや敬語について、変えなかったこととその理由を返答のどこにも書きません。
  • 作業フォルダの git の最上位(git の外では作業フォルダ)に .yomiyasu-words/ があれば、allow.txt(直さない語)、flag.txt(見直す語。直訳語と同じく文として書き直す)、flag-patterns.txt(見直す語の名前と正規表現。flag.txt と同じ扱い)を読みます。

Step 2: 上から読み、1か所ずつ直す

  1. 原文に lint をかけます(python3 ${CLAUDE_SKILL_DIR}/scripts/yomiyasu_lint.py 元の文.md。コマンドは「実行するコマンド」の節のとおりです。種類を決めたら --doc-type 値 を足します)。候補は手がかりの一部で、直す合図ではありません。候補が0件でも1章の型を探し、それだけを理由に原文のまま返しません。直訳語の指摘が出た文は「直訳語」の2つの問いで読み直します。指摘ごとの見方は references/review-points.md、ai_phrase の問いは references/slop-catalog.md 10章にあります。
  2. 型を探す前に、原文を上から1回、初めて読む読み手として読み、読み手が止まる所を書き出します。前に戻らないと誰が何をするか、何を指すかが分からない所、動作をする人が文の中にあるのに受け身で書いた所(「担当者から案が示された」)、助詞を落として名詞を詰めた所、掛かり方を読み違える所、同じ語や言い回しが近くで続く所などです。書き出した所は、1章の型に当たらなくてもこのあとで直す案を作り、言い直しテストの6点で確かめます。読み手にとって何が読みやすくなったかを言えない案は採らず、原文を残します(このメモは出力には出しません)。1章は本文のすべての文に当てますが、単調さを直すためだけに自然な文の語尾を変えません。
  3. 直す前に案を1つ書き、原文と6点を比べます(言い直しテスト)。何について述べるか、何を認め何を否定するか、誰が誰にするか、範囲と条件、断定・推量・伝聞の強さ、数値・固有名詞・時期。1つでも変わる案は捨てて原文を残し、「残したAIっぽいところ」に書きます。案を作り直して通るまで試しません。直す所を減らすためのテストではありません。確定した主語や対象を補うこと、補助動詞と「事」「為」の表記、2文の否定対比を1文にすることは6点を変えません(例は references/rephrase-test.md)。自分が書いた原稿では、読み手が動く値と主張を資料と文脈で確かめます。比喩や誇張で見えない中身、抜けた主語・数値・条件、食い違う値、出典のない値があるとき、会話や資料の値を本文に入れる前、原稿だけを渡されて読み手が動けない値が抜けているときは、references/fact-recovery.md を読み、補った値と直した値は「事実の確かめ」に出典の文を引いて書きます。本文だけを返す指定では、注記も食い違いの知らせも付けません。
  4. 本文は1か所ずつ、前後の文を読んで直します。sed、perl、python などの置換で本文をまとめて直しません(正規表現で同じ形の行をまとめて変える、置換の組を一度に流す、など)。太字のラベルや「〜は、」の読点のように同じ形の箇所が続くときも、1か所ずつ直すかを決めます。最終稿は、直した全文をファイルに書くか、1か所ずつ直します。

実行するコマンド

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

Step 3: 検査

最終稿を原文とは別のファイルに保存し、run --final の CLI(「実行するコマンド」の節)で lint と diff をまとめて実行します。ファイルを書けないとき(ファイルに保存しないよう頼まれたときを含みます)だけ run --stdin を使い、返す直前に同じ本文で verify --final - を1回実行します(Step 5)。lint と diff を別々に呼んだり、スクリプトを import したりせず、Bash から CLI を直接呼びます。--no-record は、記録を残さないよう、またはファイルに保存しないよう頼まれたときだけ付けます。

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

--stance は1章の立場で、決めきれなければ省きます。資料があれば --material 資料 を足し、新規作成では --source の代わりに --material を渡します。種類を決めたら --doc-type 値、読み手を決めたら --reader 値 を足します。標準入力では次のように渡します(資料は <<<yomiyasu:material>>> の行のあと)。返答の本文は、渡した最終稿と同じにします。

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

出力の1行目に従います。

Step 4: 読み手として読み、候補を確かめる

  • 最終稿を読み手として上から通読し、用件と誰が何をするかが伝わるかを確かめます。
  • diff の候補を一つずつ見ます。書き直す前の記録と比べて意味が変わっていれば元に戻し、同じ働きと確かめられたときだけ残して「変えたところ」に書きます。候補に出なかった文も記録と読み比べ、戻せない恐れは報告に書きます。
  • 修正は1回のみ行い、直したら Step 3 の run をもう一度実行します。そのあとは本文を変えません。

Step 5: 提出の前の照合

最終稿の lint に残った info の指摘に残す理由があるかを確かめます。run と verify の出力の「残した指摘の語」があれば、その文を Step 2 の問いで読み直し、「書き手に確かめたい点」で尋ねるか、残す理由を「残したAIっぽいところ」に書きます(理由だけで済ませるのは、定着した言い方と文字どおりの意味のときだけ)。原文と最終稿で地の文の読点の数を比べ、増えた読点が「文長と読点の調整」の残す読点に当たらなければ外します。種類を決めずに lint に pause_comma が出ないときも、最終稿の文頭の「〜は、」「〜を、」などと見出しの読点を同じように見ます。直したら run をやり直します。原文のファイルを更新する依頼なら、最終稿をそのまま原文の場所に写します。提出の直前に、本文を変えずに1回、最終稿が検査したものと同じかを確かめます(「実行するコマンド」の節)。verify のあとに本文を1字でも変えたら、run と verify をやり直してから提出します。

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

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

3. 出力フォーマット

本文だけを返す指定なら、変更理由・質問・注記・確認の記録を付けません(検査は同じように行います)。納品物がファイルで返答が別にあるときは返答に欄を付けます。指定がなければ次の形にします。

### 書き直した本文

(推敲済みの本文。見出しや箇条書きを保ち、コードの囲みに入れない)

---

### 変えたところ
- 元の表現 → 書き直し後の表現(変更理由)
- (意味が動きやすい変更、つながりの直し、文末をそろえた所(1行にまとめる)、補ったものを最大5点。なければ「なし」と1行)

### 残したAIっぽいところ(意味や重みのために残した表現があるときだけ。なければ見出しごと出さない)
- (残した表現と、残した理由)

### 書き手に確かめたい点(本文を決めるのに確認が要るときだけ、最大3点。なければ見出しごと出さない)
- (多いときは、意味や誰が何をするかが変わる所、読み手が動く値や手順、指す先、出典の順に選び、残りは「- ほかに N か所」。答えで本文が変わらない問いは入れない。「ここに説明が必要です」とペルソナの知らせは3点とは別に数える)

### 事実の確かめ
(補った・直した事実の出典と、確かめられなかった点。見出しはこの形のまま。なければ出さない)

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

エッセイ・小説、紹介記事・宣伝文と判断して表現を残したときは、確認の記録の下に1行だけ書きます(「エッセイと判断したので、文の個性を残しました」など)。直した箇所があっても書き、ペルソナについては書きません。check の言う「完了報告」は本文のあとの欄のことで、その見出しは雛形の字のまま、同じ ### か #### を付けて書きます(太字やコロンや地の文に替えません)。

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

04 同仓库更多 Skills

upamune
upamune/skills

stageshow

Build faux product UI that looks like a real product, as a still illustration or an animated demo with a cursor. Browser and app windows, dashboards, phones, notifications, terminals, bento grids and cursor walkthroughs, framed, masked and cropped the way a marketing page, feature card or docs hero needs them. Use whenever someone wants a fake or mocked UI, a product demo or walkthrough animation, a hero or feature-card illustration of an app, a product shot in the style of a polished marketing site, or an animated cursor doing things in an interface, even if they never say "faux UI". React and plain CSS.

前端开发
★ 1
upamune
upamune/skills

i-have-adhd

Shape output for a reader with ADHD: lead with the next action, number multi-step work, restate state across turns, suppress tangents, give specific time estimates, make wins visible. Invoke with /i-have-adhd; stays on until "stop adhd mode".

★ 1
upamune
upamune/skills

archify

Create validated architecture, workflow, sequence, data-flow, lifecycle/state, ERD, class, tree, timeline, and waterfall diagrams as explorable standalone HTML with dark/light themes, motion and image/SVG/WebM export. Accept requirements or Mermaid; inspect repository evidence for code-backed diagrams. Use when visualizing systems, API calls, pipelines, schemas, histories, timings, or everyday steps, parts, relationships and states. Also turn an answer into a one-page explainer, with the conclusion first, structured panels, native diagrams and charts, when the user asks for a page, an explainer or an answer to share (做成一页, 用页面讲), or proactively when the user's rules opt in with an [archify explainer: ...] line. Not for dashboards.

图像与多媒体
★ 1