mcpField
R
ru-check

ru-check

github.com/talkstream生産性281339 回インストール3 日前に更新
リポジトリ

ru-check について

ru-checkは、付属のru-textリファレンスに基づいてロシア語を校正するスキルです。依頼された校正と範囲を限定した自主チェックに対応し、元ファイルを変更せず、修正文と分類別の指摘を返します。

主な機能

  1. 01参照ルールに沿った全体校正
  2. 02自主チェック向けの限定トリアージ
  3. 03組版と文体の確認
  4. 04任意の分野別チェック
  5. 05読み取り専用の修正文レポート

活用シーン

  1. 01依頼に応じたロシア語校正
  2. 02提出前のロシア語チェック
  3. 03UI文やビジネス文の確認
  4. 04ファイルを変更せず修正案を提示

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/talkstream/ru-text --skill ru-check

インストール後、Claude Code で/ru-checkを入力して読み込まれたか確認します。

詳細

ロシア語テキストの品質チェック

$ARGUMENTS 内のテキスト(引数がない場合は、直近に出力されたロシア語テキスト)を、ru-text スキルを使って確認します。

参照ファイルの場所

このスキルでは、同梱されている ru-text スキルのコーパスを読み込みます。まずそのフォルダーを見つけ、その中から指定されたファイルを読み込んでください。

  • 親ディレクトリの名前が ru-text で、info-style.md を含む references ディレクトリを探してください。以下に挙げるファイルはすべてそのフォルダーにあります。
  • シェルではなく、ファイルツールで検索してください。 **/ru-text/references/info-style.md のようなパターンを Glob で検索するか、ホストが提供するファイル検索機能を使い、その後 Read で読み込んでください。このコマンドではコマンドラインを使いません。Bash は disallowed-tools リストに含まれており、このフィールドに対応していないホストでも使用できません。2026年12月8日に Claude Cowork で確認したところ、検索でコーパスが見つかる前に、最初の ls が赤字で「Bash の使用許可が拒否されました」と表示されました。この呼び出しには何の利点もなく、読者を不安にさせただけでした。
  • Claude Code では、フォルダーは ${CLAUDE_SKILL_DIR}/../ru-text/references/ にあります。まずそこで info-style.md を Read し、検索は省略してください。このパスが展開されずに届いた場合や、読み込みに失敗した場合は、上記の検索に切り替えてください。
  • パスを推測してはいけません。 フォルダーが見つからない場合は、その旨を伝えて終了してください。コーパスではなく記憶しているルールに基づくチェックは、このコマンドではありません。それを別のものとして報告することこそ、この製品が防ごうとしている失敗です。

1 つのコマンドで 2 つの深さ

このチェックには 2 つの深さがあります。深さは選べず、以下のルールで決まります。

全件チェック — 以下の「チェックの順序」をすべて実施します。人からこのチェックを依頼された場合(「вычитай」、「прогони ru-text」、ru-text を指定するゲート、ゴールデンセットの実行)、またはトリアージでエスカレーションされた場合は、必ず実施してください。明示的な依頼にトリアージで答えてはいけません。

トリアージ — 自発的に実施する場合のみ:ru-text の指示がない状況で、自分が作成または目にしたロシア語テキストを、習慣として確認します。読み込むのは次の 3 項目だけです。それ以外は読み込まないでください。

  1. ru-text の SKILL.md — インラインのタイポグラフィ表と冒頭のストップワード。すでにコンテキストに含まれている場合は省略してください。常時接続のホストでは、通常すでに含まれています。
  2. addenda.md の「Neuroslop index」セクション:## Neuroslop index の見出しから次の ## まで。ファイルの残りは読み込まないでください。残りはその部分の 10 倍の量があります。
  3. info-style.md の「B. Каталог стоп-слов」セクション:## B. の見出しから次の ## まで。ファイルの残りは読み込まないでください。

そのうえで、テキストをチェックしてください。タイポグラフィは機械的に確認します(まっすぐな引用符、ダッシュの代わりに使われたハイフン、省略記号の ...、数値と % の間のスペース、в、к、с、о、у、и、а、я の後の通常のスペース。目視ではなくコードポイントで確認してください)。ストップワード一覧では、活用形も含めて、候補となる各行を自分で判断してください(名詞の「данные」はストップワードの「данный」ではありません)。インデックスの指摘は目視で確認してください。

トリアージで報告できるのは、単一の行だけで判断できるものに限ります。つまり、タイポグラフィと、一覧で確認できた該当語です。 ニューロスロップの兆候はトリアージの指摘事項にしてはいけません。 AD ルールにはすべて、全ファイルにしか記載されていない適用除外があります。また、実際に先行する内容がある「не X, а Y」は通常の文章です。インデックスだけを見て指摘するのは、このコマンドへの信頼を最も損なう誤検出です。トリアージで兆候を見つけた場合は、エスカレーションのきっかけにするだけにしてください。

次のいずれかに該当する場合は、全件チェックにエスカレーションしてください:ニューロスロップの候補が見つかった · 指摘が 5 件確認された · テキストが読者向けのものである(納品物、出版物、クライアント向け)。エスカレーションは何も伝えずに行い、依頼された場合と同じように全件チェックの手順を続けてください。

トリアージの報告では、トリアージを実施したことを明示します:「簡易チェック:タイポグラフィとストップワード。コーパスに基づく全文校正は実施していません。」トリアージを全件チェックとして報告することこそ、この製品が防ごうとしている失敗です。このホストに検索ツールがない場合はトリアージを行わず、全件チェックを実施してください。

チェック順

  1. タイポグラフィ — typography.md を読み、次の点を適用します。

    • 引用符:第一階層は«»、入れ子は„“
    • ダッシュ:文中では —(em ダッシュ)、範囲では –(en ダッシュ)、複合語では -(ハイフン)
    • スペース:1文字の単語の後、数字のグループ内、単位の前には NBSP を入れます。ただし、一般文および Web テキストでは % は数字に続けて書きます(R37:100% であり、100 % ではありません。GOST の技術文書では 100<NBSP>% を使う場合があります)。ルールに記載された理由を添えて報告します。通常のスペースは改行位置になり、次の行に % だけが残るためです
    • 三点リーダー、省略形、特殊文字
  2. アンチパターン — anti-patterns.md を読み、次の点を確認します。

    • 官僚的な言い回しや名詞化
    • 受動態の多用
    • 冗長な文
    • 同語反復と冗語
  3. 文章の品質 — info-style.md を読み、次の点を適用します。

    • ストップワードや埋め草
    • 具体性と事実
    • 構成と明瞭さ
  4. ドメイン固有 — テキストの種類を特定できる場合は、次のファイルを読み込みます。

    • UI/インターフェースのテキスト → ux-writing.md
    • メール/ビジネス文書 → business-writing.md
    • 文法の確認が必要な場合 → editorial-punctuation.md + editorial-grammar.md
  5. 経験に基づく表現/ニューロスロップ — addenda.md を読み、AI 生成文章に特有の兆候を確認します。

    • 人工的な対比(AD-6)— 先行する文脈がない「X ではなく Y」「単なる X ではなく Y」
    • 先回りの美徳アピール(AD-7)— 「余計な話は抜きに」「要点を明確に」
    • アシスタント調のメタコメント(AD-8)— 「素晴らしい質問です!」「お役に立てば幸いです」
    • 中身のない書き出し(AD-9)— 「詳しく見ていきましょう」「掘り下げてみましょう」「理解しておくことが重要です」
    • 誠実さの宣言(AD-10)— 「率直な分析」「正直に言いましょう」のように、文章そのものが誠実だと主張する表現です。単独の発言に付ける同様の言い回し(「正直に言うと、締め切りに間に合いませんでした」)は AD-7 です
    • 無理な三項並列(AD-11)— 「革新的で、変革をもたらし、画期的」
    • 中身の抜けた仕組みの説明(AD-12)— 「さまざまな要因によります」「それぞれに特徴があります」
    • 出典のない帰属(AD-13)— 「調査によると」「専門家は指摘しています」
    • 成果物をチャットの会話形式にする(AD-14)— 文書の骨格が対話になっている
    • 検索エンジンへの呼びかけ(AD-15)— 代名詞で済む箇所で検索クエリの語句を繰り返す
    • 加算的な見せかけの対句(AD-16)— Y が何も付け加えていないのに「X だけでなく Y も」とする表現
    • コンマとダッシュの連結(AD-17)— 1つの文の中で、同じ構文によって要求されるコンマと em ダッシュが隣り合っている状態です。「一晩でまとめられた報告書、 — 机の上にあります」のような例です。コードポイントで検索してください。2つの記号の間には通常、ダッシュの前に R16/R44 が要求する NBSP が入るため、通常のスペースを使った検索では、正しく組版されたテキストを見つけられません。直接話法(「納期がずれます」、 — とペトロワは警告しました)は2つの構文が接しているものであり、従属節を並列した後に主節が続く箇所で、コンマがダッシュと一体の記号を形成する場合も、根拠は異なりますが結果は同じです。いずれもこのルールには該当しません
    • 大文字の連続(AD-18)— 2文字以上のキリル文字の単語が3つ以上連続し、小文字の単語や改行を挟まない状態です。ニューロスロップの兆候ではなく、意図的に上記の一覧に含めていません。人は斜体キーがないときにキーボードで大文字を連打しますが、モデルはそうしません。これは全体を丁寧に確認する段階でのみ扱い、簡易チェックでは扱いません。大文字の単語が1つまたは2つだけの場合は意図的な強調なので、指摘しません。略語、機械生成テキスト、ステータス欄、見出しは連続数に含めません

    上記の一覧は、目を向けるためのヒントであり、ルールそのものではありません。このうち AD-14 と AD-15 は 文書 に対する指摘なので、個々の文ではなく文章全体について確認してください。各ルールには、該当の判定条件と同じくらい多くの例外があります。例外は addenda.md に記載されています。これらを確認せずに指摘すると、このコマンドで最も信頼を損なう誤検出になります

出力形式

読み取り専用 — ソースファイルを変更しないでください。 ru-check は チェック です。問題を報告し、ユーザーが適用できるよう修正済みテキストを返します。解析対象のファイルへの書き込み、編集、上書きは行いません。

この動作をどのように強制するかはホストによって異なるため、正確に把握しておくことが重要です。

Claude Code では、コマンドの実行中、disallowed-tools によって指定されたツールが利用可能なツール群から除外されます。2.1.220 では、Write、Bash のリダイレクト、Monitor、委任されたサブエージェントを通じた書き込みを試みて検証しました。すべての経路で拒否され、ファイルは作成されませんでした。allowed-tools だけでは同じ結果になりません。このフィールドはツールを事前承認するものであり、制限するものではありません。

このリストでは、直接ファイルを書き込むツール(Write、Edit、NotebookEdit)と、2.1.220 で特定してテストしたコマンド実行ツール(Bash、PowerShell、Monitor)を除外します。Monitor は見落としやすいツールです。これもコマンドを実行し、Bash の権限ルールに従うため、広範な Bash 許可ルールを設定すると、気付かないうちに事前承認されます。一方、disallowed-tools: Bash を指定しても、Monitor は除外されません。このリストに記載されているのは、無効化した経路であり、存在するすべての経路ではありません。

限界は4つあります。明確に述べておきます。接続された MCP サーバーが独自の書き込みツールを公開している場合、ツール単位の拒否リストではそれを把握できません。独自の定義で tools: Write が許可されている名前付きサブエージェントは、親コマンドの拒否リストではなく、その定義に従います。後続の Claude Code リリースで、このファイルに記載されていないツールが追加される可能性がありますが、手書きのリストは自動更新されません。また、disallowed-tools を実装していないホストでは、上記はすべてエージェントに従うよう求める指示であり、プラットフォームが強制する保証ではありません。

この仕組みが及ばない範囲でも、取り決めは変わりません。どのホストでも、利用可能なツールの構成にかかわらず、このコマンドはテキストを返し、ファイルには書き込みません。

修正済みテキストを書き込まずに出力として返すことで、コマンドの動作は決定的になり、副作用もなくなります。ソースファイルに NBSP を黙って挿入するのは、二重に有害です。NBSP をインポート時に除去する対象(例:Notion)では、読者に変更が見えません。また、同じ挿入によって、そのファイルを対象とする後続の完全一致文字列ツール(grep/replace)が機能しなくなります。

次を返してください。

  1. 修正済みテキスト
  2. カテゴリ別(タイポグラフィ/スタイル/文法/ドメイン)の変更一覧
  3. 変更ごとの重大度:critical/high/medium/low

コメント