Menú
エージェントの文脈に影響する永続層 (メモリ・CLAUDE.md・規約文書・指針文書・スキル文書等の日本語文章) の日本語品質を、`textlint-ja` と独自規則で再現可能に点検する。英単語混入等の文章規律違反を検出。ユーザーが「日本語品質チェック」「textlint かけて」「英語混入チェック」「メモリ点検」「`memory sanitize`」等を指示したら起動する。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Write or update your handover document so the next holder of this job seat can take over your responsibilities. The seat you hold is identified by (project, role) in the document's frontmatter; the document is a handoff report, not a personal diary. Use this skill whenever the user mentions 'handover', 'hand over', 'pass it on', or '/handover'. NEVER invoke this skill proactively, autonomously, or as part of completing a task — finishing work, wrapping up, ending a session, or saving progress are NOT triggers for this skill unless the user explicitly asks for a handover.
Take over a job seat left by a previous holder — adopt responsibility for the work going forward, audit the predecessor's claims before relying on them, and continue under your own name. Every referenced artifact becomes a mandatory read task, drained before any work starts. The predecessor's report is yours to audit, not yours to inherit unexamined. Use this skill whenever the user mentions 'takeover', 'take over', 'pick up where we left off', or '/takeover'. NEVER invoke this skill proactively or autonomously — resuming or continuing work is NOT a trigger for this skill unless the user explicitly asks for a takeover.
Retrospective grounded in the garbage-in-garbage-out principle: traces problems from Output back to their upstream origin across six stages, then fixes at the stage where the cause lives — knowledge deficiencies get knowledge fixes, not downstream rule patches. Implements fixes in the current session. Use after finishing a task, before creating a PR, or whenever the user says 'retrospective', 'wrap up learnings', or similar.
Edited a project's manifest, lockfile, or config? Added or deleted a whole project? Then its `.knowledge/` wiki page is now stale — use this skill to ingest (regenerate the page) or deingest (remove it). Assume the user won't mention the wiki or KB; trigger from the file touched or the action alone. Fire when: - a project's stack/dependency/build/deploy/structure-defining file changes — package.json, any lockfile (pnpm-lock, uv.lock, gleam.lock), pyproject.toml, gleam.toml, tsup.config, angular.json, wrangler.toml, Dockerfile/Cloud Run, pnpm-workspace.yaml, new workspace packages — or its CLAUDE.md; - a project is cloned, forked, or placed under a KB anchor (`~/works/`, `~/.claude/`), or a project directory is removed from one; - **AI-generated intermediate-artifact files appear, change, or are discovered** anywhere under a KB-covered repo — design docs (`docs/designs/*.md`), review records (`docs/reviews/*.md`), plans (`docs/plans/*.md`), acceptance-test records, retrospectives, conversation logs — **regard
Lint the knowledge base at `~/.knowledge/` (LLM Wiki). Deterministic checks are delegated to a script; contradictions, broken links, and staleness are reported as proposals only (no auto-fix). Use for KB health checks, contradiction detection, right after a batch ingest, or before relying on the KB as evidence.
Use this skill whenever the user is trying to recall, verify, enumerate, or reconcile facts about their own collection of projects — especially "which of my projects do X" questions. X can be a library, package, framework, version, service, cloud platform, deploy target, architectural pattern, or "what even is this project." Trigger on memory-checking and inventory intent: enumerating consumers/users of something, confirming a remembered list ("…だっけ", "…で正しい？", "…以外もあったよな", "…の気がする"), mapping relationships or dependency chains between projects, or sorting projects by which tech/version they use. Trigger even when phrased casually, even when one specific project or package is named, and even though the user never mentions a KB, wiki, or `.knowledge/`. The skill answers from the knowledge base at `~/.knowledge/` with citations. Do NOT trigger for: writing/debugging code inside a single named project, learning a technology in general, or adding/removing/maintaining KB pages.
| name | memory-sanitize |
| description | エージェントの文脈に影響する永続層 (メモリ・CLAUDE.md・規約文書・指針文書・スキル文書等の日本語文章) の日本語品質を、`textlint-ja` と独自規則で再現可能に点検する。英単語混入等の文章規律違反を検出。ユーザーが「日本語品質チェック」「textlint かけて」「英語混入チェック」「メモリ点検」「`memory sanitize`」等を指示したら起動する。 |
エージェントの文脈に影響する永続層の日本語文章の品質を、textlint-ja の規則群と独自規則で再現可能に検証する。自動修正はしない、検出のみ。修正はエージェント自身が結果を見て判断する。
検査は二段構えで実施する。第一段は機械検出、第二段は散文品質レビュー。永続層への書き込みは両段を通過してから完了とする。
textlint による決定論的な検査。文法・形式・英単語混入など、規則で機械的に判定できる規律違反を検出する。scripts/check.sh がこれを担う。tech-writing スキルを参照したエージェント主導の検査。論証・段落構成・冗長排除・演出の抑制・LLM っぽい表現の禁止など、機械では判定できない規律違反を検出する。textlint かけて」「英語混入チェック」「メモリ点検」「memory sanitize」等の指示スキルは「エージェントの文脈に影響する永続層の日本語散文」を対象とする。以下の機能的性質を満たすファイルが想定対象。
検査対象に入れないもの:
data/*.json・$XDG_CONFIG_HOME/memory-sanitize/*.json) もここに含まれる。.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: 半角開き括弧 ( の直後に等号 = が続く (= 構文を完全禁止
(= Y)」形式の括弧内同格挿入は本文の論述リズムを断ち切る注釈様式として全面的に避ける。同格挿入が必要なら別文に分け、「X とは Y である」と書き起こすか、「X すなわち Y」と読点でつなぐ。Code ノードは対象外。no-em-dash-ja: 日本語の地の文・見出しでのダッシュ類使用を禁止
— (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: 読点 、 または句点 。 の直後に半角スペースを入れるのを禁止
import と関数・PR 作成) は正しい日本語組版なので検出しない。全角スペース U+3000 は別の論点として扱わない。バッククォート内コード・コードブロックは標準動作で自動除外される。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 は存在するのに句読点版が無い、という穴を埋める。no-confusable-cyrillic: キリル文字 (U+0400-U+04FF) の同形文字混入を禁止
Str に加えて Code・CodeBlock。他の規則と違いコードも見る。バッククォート内に混ざったキリル文字は実行して初めて気づくため、散文より危険である。bash <SKILL_DIR>/scripts/check.sh <target-file> [<target-file> ...]
エージェントは検査結果に基づき次の手順を取る。
check.sh を再実行して残違反 0 を確認する。機械検出で残違反 0 を確認した後、各対象ファイルに対して tech-writing スキルを参照したレビューを実施する。機械検出では拾えない規律違反、例えば段落構成、論証の厳密さ、冗長、演出過多、LLM っぽい空句などを検出することが目的。
手順は以下のとおり。
tech-writing スキル本文を読み、各規範節を文脈に置く。check.sh を再実行し、textlint 違反が再発していないことを確認する。機械検出と散文品質レビューは相互に影響し得るため、散文品質レビューの修正後に機械検出を再評価する。散文品質レビューは決定論的なスクリプトを持たない。エージェントが規範文書を読んで判定する責任を負う。規範を読まずに「問題なし」と宣言してはならない。
辞書を持たない。「英単語 → 日本語訳」の対応表をスキル文書側に書かない。翻訳テーブルはエージェントから文脈読解の責務を奪い、機械置換の道具にする。文脈で意味を読み取り、日本人読者にとって最も自然な日本語へ置き換えるのがエージェントの仕事。
第一選択は日本語化。バッククォート化、すなわち textlint の Code ノードへの退避は最終手段。検出回避目的のバッククォート化は禁止する。検出された英単語をそのままバッククォートで囲んで判定を通すのは思考停止のエスケープであり、ユーザー指示「概念語は日本語に置き換える」の趣旨に反するからである。
バッククォートは「コード識別子としての引用」という意味的機能を持つ。そのため次の場合のみ正当化される。
<ラベル> などの中間カテゴリのラベル」の用法がこれに当たるこれらに該当しない英単語、すなわち概念語・一般語・技術用語は、文脈から意味を読み取って日本語に置き換える。
製品名・サービス名・組織名・言語名・ライブラリ名などで、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 は実在確認した事実のみを書き、未確認の権威語を付与しないユーザーが選択した語のみを末尾に追記し、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.jsonproper-nouns.jsonスキル自体に永続的なインストール物を持たない。scripts/check.sh 実行時に npx が以下のパッケージを取得する。グローバル汚染はなく、~/.npm/_npx/ のキャッシュは共有する。
textlint (^15)textlint-rule-no-mix-dearu-desumasutextlint-rule-ja-no-mixed-periodtextlint-rule-ja-no-redundant-expressiontextlint-rule-ja-no-successive-wordtextlint-rule-ja-no-abusagetextlint-rule-no-doubled-conjunctive-particle-gatextlint-rule-no-doubled-joshitextlint-rule-no-doubled-conjunctiontextlint-rule-no-double-negative-jatextlint-rule-no-dropping-the-ratextlint-rule-no-hankaku-kanatextlint-rule-no-mixed-zenkaku-and-hankaku-alphabetNode.js は環境に既存のものを使う。初回実行で npx がパッケージを取得するため遅延が生じる。以降は npx のキャッシュ経由のため 1〜2 秒程度で完走する。
textlint 規則として scripts/rules/ に実装する。出力形式・行列番号・Code および CodeBlock ノードの除外処理を textlint 側に統一する。--no-textlintrc: textlint v15 で preset の .textlintrc.json 経由解決が不安定なため、--rule フラグで規則を直接列挙する。同じ入力で同じ出力を返す再現可能性を確保する。npx で都度取得し、スキル配下に node_modules を持たない。環境依存を最小化する。