memory-sanitize

name	memory-sanitize
description	エージェントの文脈に影響する永続層 (メモリ・CLAUDE.md・規約文書・指針文書・スキル文書等の日本語文章) の日本語品質を、`textlint-ja` と独自規則で再現可能に点検する。英単語混入等の文章規律違反を検出。ユーザーが「日本語品質チェック」「textlint かけて」「英語混入チェック」「メモリ点検」「`memory sanitize`」等を指示したら起動する。

memory-sanitize

エージェントの文脈に影響する永続層の日本語文章の品質を、textlint-ja の規則群と独自規則で再現可能に検証する。自動修正はしない、検出のみ。修正はエージェント自身が結果を見て判断する。

検査は二段構えで実施する。第一段は機械検出、第二段は散文品質レビュー。永続層への書き込みは両段を通過してから完了とする。

1. 機械検出: textlint による決定論的な検査。文法・形式・英単語混入など、規則で機械的に判定できる規律違反を検出する。scripts/check.sh がこれを担う。
2. 散文品質レビュー: tech-writing スキルを参照したエージェント主導の検査。論証・段落構成・冗長排除・演出の抑制・LLM っぽい表現の禁止など、機械では判定できない規律違反を検出する。

起動条件

• 「日本語品質チェック」「textlint かけて」「英語混入チェック」「メモリ点検」「memory sanitize」等の指示
• 永続層への新規書き込み後の自己確認

検査対象

スキルは「エージェントの文脈に影響する永続層の日本語散文」を対象とする。以下の機能的性質を満たすファイルが想定対象。

• 日本語の散文、すなわち文として読まれる本文を含む
• エージェントの文脈や応答に影響する。ランタイムが読み込むもの、応答指針として参照されるもの、などを指す
• 永続化されている。一時ファイルでなく、セッションをまたいで残るもの

検査対象に入れないもの:

• 構造化データ (JSON / YAML / lockfile / 設定ファイル等)。規則のデータファイル (data/*.json・$XDG_CONFIG_HOME/memory-sanitize/*.json) もここに含まれる。
• ソースコード (Markdown でない .ts・.js・.py 等)。

具体的な配置・命名・構造は環境ごとに異なるため、スキルは検査対象の経路を一切規定しない。対象はエージェントが起動文脈から判断し、引数で check.sh に渡す。

呼び出し方は以下のとおり。

• ユーザーが対象を指定した場合は字句通り使う
• ユーザーが指定しない場合はエージェントが上記の機能的性質に照らして自分の環境から候補を列挙する
• 判断に迷う場合はユーザーに確認する

対象が決まったら bash <SKILL_DIR>/scripts/check.sh <file...> の形で実行する。

検出項目

textlint の既存規則と独自規則を 1 回の実行で同時に適用する。

textlint-ja の既存規則による技術文書一般品質

• ですます・である調の混在
• 文末句点の混在
• 重複した助詞・接続詞
• 不適切な表現・冗長表現
• 全角半角混在
• 二重否定
• 全角文字どうしの間の半角スペース (ja-no-space-between-full-width。カタカナ複合語は除外される)

scripts/rules/ 配下の独自規則 (判断を要する)

判定は機械的でも、違反を 0 にするには編集判断が要る規則。許可一覧の整備や文の書き換えが伴うため、二値ゲートには向かない。

• no-english-word: 固有名詞 (data/proper-nouns.json)・略語 (data/acronyms.json)・バッククォート内コード以外の連続英字を検出
  • 検出範囲は「日本語と英語が混在した Str ノード」のみ。日本語文字すなわちひらがな・カタカナ・漢字を 1 文字も含まないテキストは「英単語混入」の対象外となる。純英語の見出し・引用・スラッグ単独行・コード片などがこれに当たる。ルール本来の目的、すなわち日本語文中の英単語混入検出だけを評価し、純英語パターンは無関係とする。
• no-paren-equals-gloss: 半角開き括弧 ( の直後に等号 = が続く (= 構文を完全禁止
  • 「X (= Y)」形式の括弧内同格挿入は本文の論述リズムを断ち切る注釈様式として全面的に避ける。同格挿入が必要なら別文に分け、「X とは Y である」と書き起こすか、「X すなわち Y」と読点でつなぐ。
  • 検出対象は半角形のみ。バッククォート内の文字列リテラル、すなわち Code ノードは対象外。
• no-em-dash-ja: 日本語の地の文・見出しでのダッシュ類使用を禁止
  • 検出対象は次の 3 種類。— (U+2014、em ダッシュ)、― (U+2015、横棒)、—— (em ダッシュ 2 連の 2倍ダッシュ)
  • 除外は次のとおり。– (U+2013、en ダッシュ) は範囲表記として許容する。日本語文字を含まない純英語の Str ノードは対象外 (例: Curry–Howard などの英語複合語)。バッククォート内コード・コードブロックは標準動作で自動除外される。
  • tech-writing 規範 18 行目を機械化したもの。同格・補足の挿入は括弧 () に降ろし、言い換えは句点で二文に分けるか読点で対応する。
• no-heading-separator: 見出しに区切り線 ─ (U+2500、罫線) を含めるのを禁止
  • 検出対象は Header ノード内の ─ 単独および ── の連続。
  • 除外は次のとおり。Header ノード以外の本文中での ─ 出現は対象外。バッククォート内コード・コードブロックは標準動作で自動除外される。
  • tech-writing 規範 20 行目を機械化したもの。二要素を罫線で連結した見出し (例: 種別──主題) を遮断する。見出しは単一の自然な句にし、要素を一つに絞るか助詞・読点でつなぐ。

scripts/rules-gate/ 配下の独自規則 (ゲート化できる)

違反を 0 にするのに編集判断が要らない規則。空白を削る、文字を差し替える、で機械的に解消できる。CI からは scripts/check-gate.sh がこのディレクトリだけを --rulesdir に渡し、二値ゲートとして使う。

• no-space-after-ja-punctuation: 読点 、 または句点 。 の直後に半角スペースを入れるのを禁止
  • 検出対象は句読点直後の半角スペース。後続が全角でも ASCII でも検出する。
  • 除外は次のとおり。日本語と ASCII の間の空白 (import と関数・PR 作成) は正しい日本語組版なので検出しない。全角スペース U+3000 は別の論点として扱わない。バッククォート内コード・コードブロックは標準動作で自動除外される。
  • 範囲を句読点だけに絞っている。全角語どうしの間は公開 rule ja-no-space-between-full-width が担い、あちらはカタカナどうしを複合語として除外する言語的判断を含むため自前で書き直すと劣化する。かっこ類を見る公開 rule ja-no-space-around-parentheses は採用しない。オプションが無く、**Issue**: [Description] のような英語テンプレートの半角 [] を括弧として拾うため、日英混在ファイルで誤検知が避けられない (作者の環境で 15 件中 10 件が誤検知だった)。結果、公開 rule で埋まらないのは句読点直後だけになる。ja-space-after-exclamation と ja-space-after-question は存在するのに句読点版が無い、という穴を埋める。
  • 英文の「ピリオドの後は 1 スペース」を日本語に持ち込んだ書式である。一度混ざると以後の書き手が隣接様式として模倣し増殖するため、永続層に効く規則として機械化した。2026-07-26 に本スキル自身の SKILL.md から 188 箇所、作者のグローバル規範から 149 箇所を除去した際に追加。うち句読点直後が 132 箇所だった。
• no-confusable-cyrillic: キリル文字 (U+0400-U+04FF) の同形文字混入を禁止
  • 検出範囲は Str に加えて Code・CodeBlock。他の規則と違いコードも見る。バッククォート内に混ざったキリル文字は実行して初めて気づくため、散文より危険である。
  • ギリシャ文字は対象外。技術文書では λ・μ・π・Ω などが正当に使われるため、混ぜると誤検知になる。日本語・英語の技術文書にキリル文字が正当に現れることは事実上ない。
  • 生成時の同形文字滑りで混入する。2026-07-19 に作者のグローバル規範へ混入した実績がある。当時はリポジトリ側のシェルスクリプトが検査していたが、同じ規則を repository ごとに書くのをやめてここへ移した。

使い方

機械検出

bash <SKILL_DIR>/scripts/check.sh <target-file> [<target-file> ...]

エージェントは検査結果に基づき次の手順を取る。

• 検出された違反を 1 件ずつ確認・修正する。例えば英単語混入なら日本語化する。
• 修正後 check.sh を再実行して残違反 0 を確認する。

散文品質レビュー

機械検出で残違反 0 を確認した後、各対象ファイルに対して tech-writing スキルを参照したレビューを実施する。機械検出では拾えない規律違反、例えば段落構成、論証の厳密さ、冗長、演出過多、LLM っぽい空句などを検出することが目的。

手順は以下のとおり。

1. tech-writing スキル本文を読み、各規範節を文脈に置く。
2. 対象ファイルの本文を、各節に照らして点検する。違反候補を列挙する。
3. 違反候補のうち、ファイルの目的と矛盾しないものはエージェントが書き直す。ファイルの目的上やむを得ず規範の例外と判断する箇所は、判断理由を 1 行コメントで残すか、ユーザーに確認する。
4. 書き直しが本文を変えた場合は機械検出の check.sh を再実行し、textlint 違反が再発していないことを確認する。機械検出と散文品質レビューは相互に影響し得るため、散文品質レビューの修正後に機械検出を再評価する。

散文品質レビューは決定論的なスクリプトを持たない。エージェントが規範文書を読んで判定する責任を負う。規範を読まずに「問題なし」と宣言してはならない。

英語語句の取り扱い指針

辞書を持たない。「英単語 → 日本語訳」の対応表をスキル文書側に書かない。翻訳テーブルはエージェントから文脈読解の責務を奪い、機械置換の道具にする。文脈で意味を読み取り、日本人読者にとって最も自然な日本語へ置き換えるのがエージェントの仕事。

第一選択は日本語化。バッククォート化、すなわち textlint の Code ノードへの退避は最終手段。検出回避目的のバッククォート化は禁止する。検出された英単語をそのままバッククォートで囲んで判定を通すのは思考停止のエスケープであり、ユーザー指示「概念語は日本語に置き換える」の趣旨に反するからである。

バッククォートで囲むのは真の正式名称のみ

バッククォートは「コード識別子としての引用」という意味的機能を持つ。そのため次の場合のみ正当化される。

• ファイルパス・ディレクトリ名を文中で固有識別子として参照する
• コマンド名・サブコマンド名・オプションを引用する
• 関数名・API オプション名・属性名を引用する
• git ブランチ名を引用する
• 設定キー名を引用する
• スキル名・エージェント名・フック名すなわちランタイムに登録された識別子を引用する
• スキル文書で公式定義された節名・構造名を引用する
• retrospective ファイルのスラッグを引用する
• 「これは概念用語ラベルである」と明示的に引用する。「<ラベル> などの中間カテゴリのラベル」の用法がこれに当たる

これらに該当しない英単語、すなわち概念語・一般語・技術用語は、文脈から意味を読み取って日本語に置き換える。

業界横断で確立した固有名詞

製品名・サービス名・組織名・言語名・ライブラリ名などで、ls や find や公式ドキュメント参照などによる実在確認を経たもののみ追記してよい。追記先はスキル同梱 data/proper-nouns.json か、ワークスペース固有の ~/.config/memory-sanitize/proper-nouns.json のいずれか。前者は普遍的な語、後者はワークスペース固有の語を置く。

判定が曖昧な場合は AskUserQuestion で認可を取る。

許可一覧の編集規律

許可一覧の中身はスキルの判定基準そのものを書き換える行為。エージェントの自己判断で語を「固有名詞扱い」として通すと、本来日本語化すべき英単語を素通りさせる失敗が発生する。

追加してはいけない語

• 概念語・一般語・技術用語。これらは日本語化が正解で、許可一覧に入れて素通りさせるのは判断ぶれ。
• 検出回避目的で許可一覧に追加する語。「修正が面倒だから登録する」という動機での追加はここに含まれる。

配布対象のスキル同梱 data/*.txt への追記

スキル同梱の data/proper-nouns.json / data/acronyms.json は他の利用者にも出荷される配布物。「分野横断で普遍的に確立した」が要求基準で、「エージェントが知っているか」は理由にならない。

必ず AskUserQuestion で認可を取る。自動追加してよいパスは存在しない。エージェントは「これは普遍的だ」と独断確定するな (例: 自分が見たプロジェクトで使われている → 普遍的、は失敗パターン)。

• 質問形式: 「<同梱ファイル名> に追加してよい語を選択してください」
• multiSelect: true で各候補語を選択肢として並べる。最大 4 件まで、超える場合は質問分割または優先度上位のみとする
• 「どれも追加しない」の選択肢を必ず含める
• 各候補の description は実在確認した事実のみを書き、未確認の権威語を付与しない
• 選択肢を 1 つに絞った独断確定や、オープンクエスチョンでテキスト回答を強いる形は禁止

ユーザーが選択した語のみを末尾に追記し、check.sh を再実行して反映確認する。

ローカル専用のユーザー上書き許可一覧への追記

$XDG_CONFIG_HOME/memory-sanitize/*.txt のユーザー上書き許可一覧は配布されない。ユーザー固有の語、例えばワークスペース・プロジェクト・人物・組織などの語を置く場所。ここへの追記は、ユーザー文脈で ls や find や公式ドキュメント参照などによる実在確認を経た固有名詞に限り、エージェントが自動追加してよい。

固有名詞か概念語・一般語かの境界が曖昧な場合は、ユーザー側でも AskUserQuestion で認可を取る。

構成

• scripts/check.sh: 入口。npx で textlint を起動する。
• scripts/test.sh: 独自規則の自動テスト。textlint-tester と node --test を使い、一時ディレクトリへ npm install 後に NODE_PATH 経由で起動する。永続インストールはなし。
• scripts/rules/*.js: 判断を要する独自規則。--rulesdir 経由で textlint に読み込ませる。
• scripts/rules-gate/*.js: ゲート化できる独自規則。check.sh は両ディレクトリを渡すが、CI は rules-gate だけを渡して二値ゲートにする。--rulesdir はディレクトリ内の全規則を無条件に有効化し、設定ファイルの false では抑止できないため、選択はディレクトリ分割で行う。
• tests/*.test.js: 独自規則の振る舞い固定。valid と invalid を textlint-tester で宣言する。
• data/proper-nouns.json: 固有名詞許可一覧。スキル同梱の既定で、普遍的に確立した語のみを置く。
• data/acronyms.json: 略語許可一覧。スキル同梱の既定で、確立した頭字語のみを置く。

textlint 既存規則の選定は scripts/check.sh 本体に --rule フラグで列挙されている。独自規則は scripts/rules/ に 1 ファイル 1 規則で配置、ファイル名がそのまま規則名になる。

ユーザー固有の許可一覧の重ね合わせ

スキル同梱の data/ 配下は関心ごとに 2 ファイルへ分かれる。すべて普遍的な語のみを含み、ワークスペース・プロジェクト・人物・組織などのユーザー固有の語は含めない。

• data/proper-nouns.json: 固有名詞。製品名・サービス名・組織名・ライブラリ名などを置く。
• data/acronyms.json: 業界横断の頭字語。HTML・API・GCP・DOM などの、複数語の頭文字を取った語を置く。

ユーザー固有の語は以下の経路に書く。

• $XDG_CONFIG_HOME/memory-sanitize/proper-nouns.json。既定では ~/.config/memory-sanitize/proper-nouns.json を指す
• $XDG_CONFIG_HOME/memory-sanitize/acronyms.json。既定では ~/.config/memory-sanitize/acronyms.json を指す

no-english-word 規則はスキル同梱の 2 ファイルとユーザー側の上書き許可一覧の和集合を許可一覧として読む。配布時はスキル同梱が普遍的な範囲に閉じているため、他ユーザーがスキルを受け取ってもワークスペース固有の語が漏れない。

許可一覧に入れない語:

言語/シェル/フレームワークの構文要素は 許可一覧に入れない。例えば Dockerfile の COPY、SQL の JOIN、HTTP メソッドの POST、シェル論理演算子の AND、ファイル名慣習の README、環境変数名の PATH などが該当する。これらは「コード識別子としての引用」が正規の表記で、文中で言及するときは バッククォート引用が常に正解。「念のため」で許可一覧に詰め込むのは検出回避目的の事前ストックという規律違反であり、維持・棚卸し・配布時のスコープ判断を崩す。

関心別の使い分け規律:

• 「これは頭字語すなわち複数語の頭文字か?」 → acronyms.json
• 「これは固有名詞すなわち具体的な製品・サービス・組織・人物か?」 → proper-nouns.json
• 「これは予約語・構文要素か?」 → 許可一覧に入れず、本文側でバッククォート引用

依存

スキル自体に永続的なインストール物を持たない。scripts/check.sh 実行時に npx が以下のパッケージを取得する。グローバル汚染はなく、~/.npm/_npx/ のキャッシュは共有する。

• textlint (^15)
• textlint-rule-no-mix-dearu-desumasu
• textlint-rule-ja-no-mixed-period
• textlint-rule-ja-no-redundant-expression
• textlint-rule-ja-no-successive-word
• textlint-rule-ja-no-abusage
• textlint-rule-no-doubled-conjunctive-particle-ga
• textlint-rule-no-doubled-joshi
• textlint-rule-no-doubled-conjunction
• textlint-rule-no-double-negative-ja
• textlint-rule-no-dropping-the-ra
• textlint-rule-no-hankaku-kana
• textlint-rule-no-mixed-zenkaku-and-hankaku-alphabet

Node.js は環境に既存のものを使う。初回実行で npx がパッケージを取得するため遅延が生じる。以降は npx のキャッシュ経由のため 1〜2 秒程度で完走する。

設計判断

• 検査対象の経路を持たない: スキルの可搬性を確保するため。エージェントが自分の環境から判断する責務を負う。
• 自動修正しない: 内容を壊す危険を避けるため。修正はエージェントの判断に残す。
• 既存規則と独自規則を 1 系統で運用: 独自検出も textlint 規則として scripts/rules/ に実装する。出力形式・行列番号・Code および CodeBlock ノードの除外処理を textlint 側に統一する。
• 個別規則の直接指定 + --no-textlintrc: textlint v15 で preset の .textlintrc.json 経由解決が不安定なため、--rule フラグで規則を直接列挙する。同じ入力で同じ出力を返す再現可能性を確保する。
• 永続インストールなし: npx で都度取得し、スキル配下に node_modules を持たない。環境依存を最小化する。