mcpField
T
terminology-normalizer

terminology-normalizer

github.com/willoscarドキュメント51753 回インストール3 週間前に更新
リポジトリ

terminology-normalizer について

terminology-normalizer は、技術サーベイの草稿で意味や引用を変えずに用語を統一するスキルです。標準語を定め、本文、見出し、表で一貫して使います。

主な機能

  1. 01用語候補リストを作成
  2. 02標準語と同義語ルールを決定
  3. 03見出しと表の用語を統一
  4. 04引用と意味のある区別を維持
  5. 05用語集の付録を任意で作成

活用シーン

  1. 01草稿内の用語の揺れを解消
  2. 02見出しを分類体系に合わせる
  3. 03本文と表の用語を統一

インストール

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

$npx skills add https://github.com/willoscar/research-units-pipeline-skills --skill terminology-normalizer

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

詳細

用語の正規化

トリガーとルーティング

  • トリガー:用語、用語集、用語の統一、用語の一貫性、术语统一、统一叫法、术语表。
  • 使用する場面:草稿内で概念の表記に揺れがある(同じものが2~3通りの名前で呼ばれている)場合、または全体レビューで用語の不統一が指摘された場合。

目的:引用や意味を変えずに、一貫した命名(標準用語と同義語の方針)を徹底し、草稿全体を一人の著者が書いたように読めるようにします。

役割カード(明示的に使用)

分類担当(標準化)

ミッション:概念ごとに標準用語を1つ決め、簡潔な同義語の方針を定めます。

行うこと:

  • 利用可能な場合は、分類ノード名(outline/taxonomy.yml)を標準ラベルとして優先します。
  • 読者が同義語を想定する場合に限り、簡潔な同義語の方針を定めます(必要な場合のみ)。
  • 見出しと表の用語を標準用語に合わせます。

避けること:

  • 固有名詞(論文タイトル、ベンチマーク名、モデル名)の改名。
  • 意味のある区別を失わせる過剰な正規化(例:異なる2つのメカニズムを1つの用語にまとめる)。
統合担当(揺れのない適用)

ミッション:意味や引用を変えず、一貫して置換を適用します。

行うこと:

  • 置換は局所的かつ慎重に行い、曖昧さが生じた文は読み返します。
  • 引用の位置と小見出しの区切りを保ちます。

避けること:

  • 用語を書き換える際に、新たな主張を加えること。
  • 小見出し間で引用を移動すること。

役割プロンプト:用語編集者(一貫した文体)

You are normalizing terminology in a technical survey draft.

Your job is to make the draft read like one author wrote it by enforcing consistent naming.

Constraints:
- do not add/remove citation keys
- do not move citations across ### subsections
- do not introduce new claims while renaming

Method:
- pick a canonical term per concept
- define allowed synonyms (optional, minimal)
- apply consistently across headings, prose, and tables

入力

  • output/DRAFT.md
  • 任意(読み取り専用のコンテキスト):
    • outline/outline.yml(見出しの一貫性)
    • outline/taxonomy.yml(標準ラベル)

出力

  • output/DRAFT.md(その場で編集)
  • 任意:output/GLOSSARY.md(必要に応じて、短い付録/用語集の表)

ワークフロー

上記の役割カードを使用します。

手順:

  1. 草稿から用語集の候補リストを作成します(重要な用語を10~30個):
  • 中核となる対象(エージェント、ツール、環境、プロトコル)
  • 主要コンポーネント(プランナー/実行担当、メモリ、検証器)
  • 評価用語(ベンチマーク、指標、予算)
  1. 標準用語と同義語の方針を決定します:
  • 1つの概念につき標準用語は1つ
  • 読者が同義語を想定する場合に限り、許容する同義語を定めます(使用は必要な場合のみ)
  • outline/taxonomy.yml が存在する場合:分類ノード名を標準ラベルとして優先します(新しい名前を作らない)
  • outline/outline.yml が存在する場合:セクション見出しを同じ標準用語に合わせます
  1. 慎重に置換を適用します:
  • 論文名、モデル名、ベンチマーク名は変更しません
  • 見出し、本文、表のキャプション全体で用語を統一します
  1. 任意:簡潔な output/GLOSSARY.md を作成します:
  • term | canonical | allowed synonyms | notes

簡単な例(推奨事項と避けるべき事項)

  • 悪い例(用語の揺れ):ルールを定めずに、tool API、tool interface、action schema を同じ意味で使用する。

  • よい例(標準用語と簡潔な同義語の方針):標準用語を1つ選び(例:tool interface)、最初に導入するときに限り同義語を1つ認め(例:tool interface (API contract))、その後は標準用語を使い続ける。

  • 悪い例(過剰な正規化):区別されている用語を置き換え、対比を失わせる。

  • よい例:異なるメカニズムを表す用語は区別したままにし、表記と命名の一貫性のみを正規化する。

ガードレール(必ず守ること)

  • 引用キーを追加または削除しないでください。
  • ### の小見出しをまたいで引用を移動しないでください。
  • 用語の変更時に新たな主張を加えないでください。

トラブルシューティング

問題:正規化によって引用キーが変更された、または引用が移動した

修正:

  • 元に戻します。このスキルでは、キーの追加・削除や、小見出しをまたいだ引用の移動をしてはいけません。
問題:同義語の方針が不明確

修正:

  • 概念ごとに標準用語を1つ定め、許容する同義語を列挙します。見出し、表、本文全体で一貫して適用します。

コメント