菜单
プロジェクトの用語一貫性チェック。diff・PR・実装計画に登場する用語(識別子・コメント・テストタイトル)を、リポジトリ別の用語集(glossary)と既存コードの語彙(inventory)に照らしてチェックし、新出概念の命名を確定して glossary を育てる。用語チェック・命名の相談・表記揺れの確認で発動。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
nix-darwin の flake update + switch を実行。キャッシュミスで重いソースビルドが発生するパッケージは自動で pin し、過去の pin はキャッシュが追いつけば自動解除する。
Control herdr from inside it. Manage workspaces and tabs, split panes, spawn agents, read output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1).
Create, list, switch, or delete git worktrees for parallel branch work. Use when the user wants to work on multiple branches simultaneously.
GitHub に画像をアップロードし Markdown 画像リンクを返す。PR 作成や Issue 作成時に画像を添付したい場合に使用。
Commit changes by splitting into logical units. Defaults to Conventional Commits but adapts to the repo's existing format if consistently different. Auto-detects commit message language from git history.
Create a pull request. Follows PR templates if present. Validates checklist items via sub-agents before submitting.
| name | term-check |
| description | プロジェクトの用語一貫性チェック。diff・PR・実装計画に登場する用語(識別子・コメント・テストタイトル)を、リポジトリ別の用語集(glossary)と既存コードの語彙(inventory)に照らしてチェックし、新出概念の命名を確定して glossary を育てる。用語チェック・命名の相談・表記揺れの確認で発動。 |
| argument-hint | [<PR番号> | plan <計画の説明・ファイル>] |
ユーザー指示: $ARGUMENTS
リポジトリの用語(ドメイン用語・同義語・表記)の揺れを防ぐ。単一の 「term check」操作を、計画(実装前)と diff(実装後)のどちらにも適用する。
スクリプト: python3 <このスキルの base directory>/scripts/term_check.py <subcommand>
(以下 term_check.py と表記)
データ(リポジトリごと。worktree 間で共有される):
glossary.json — キュレーションされた用語集。全件 Read してよいinventory.json — 機械生成の全語彙。Read しない(大きい。スクリプト専用)日本語の用語抽出は janome(形態素解析)がインストールされていれば自動で使い、
無ければ正規表現の近似にフォールバックする(python3 -m pip install janome で精度向上)。
チェック対象: 識別子(変数・関数・ファイル名)、コメント、テストタイトル。 チェック対象外: UI 文言、テストデータ内の文字列(スクリプトが文字列リテラルを 除外することで実現している)。
term_check.py paths で repo-id とデータの場所を確認(出力の dir: 行のディレクトリに glossary.json / inventory.json が置かれる。Read / Edit はこのパスで行う)--ref <base> を付ける
(例: term_check.py inventory --ref origin/main)。--ref を省略すると
作業ツリーから抽出されるため、現在ブランチで追加した語彙が既存扱いになり
新出ワード判定から漏れる。base は「モード判定」で決めるデフォルトブランチを
そのまま使う。計画チェックや単独利用では --ref 省略でよい(作業ツリー全体)。
大きいリポジトリでは数十秒。gh pr diff <番号>)git diff <デフォルトブランチ>...HEAD)
git symbolic-ref refs/remotes/origin/HEAD --short
(origin/main 形式で返る)で特定する。失敗したら main / master の存在を
確認し、それでも不明ならユーザーに聞くplan ...、または会話の文脈が実装前の計画・設計 → 計画チェックterm_check.py lookup <語> で頻度と近い語を確認するglossary.json のスキーマ(term / ja は片方だけでもよい。note は任意):
{
"terms": [
{
"term": "fetch",
"ja": "取得",
"avoid": ["retrieve", "obtain"],
"avoid_ja": [],
"note": "外部 API からの取得。DB は find/get"
}
]
}
git diff <デフォルトブランチ>...HEAD | python3 .../term_check.py checkgh pr diff <番号> | python3 .../term_check.py checkterm_check.py lookup <語> [<語>...] で既存語彙と突き合わせるスクリプト出力を以下の 3 セクションに整理して報告する(抽出サマリは分析の 入力なので報告に含めない。決定的違反はスクリプトの結果をそのまま使ってよい):
## 用語チェック結果
### 1. 決定的違反 (N件)
- `path:line` `retrieveUser` の retrieve → **fetch**(外部 API からの取得)
### 2. 概念揺れ (M件)
- 同一概念に「実長」「生テキスト」と `rawLength` が混在
→ **実効文字数 / EffectiveMessageLength** への統一を提案
- 該当: path:line, path:line
### 3. 一般的でない新出語 (K件)
- 「壁時計」(×6) — wall clock time の直訳、エンジニア界でも使用率が低い
→ 推奨: 「現地時刻」「JST 表示時刻」「指定タイムゾーンの時刻」
- 「UTC エポック」(×1) — 造語、技術文書で未定着
→ 推奨: 「Unix エポック」(POSIX 由来の確立した技術用語)
### 4. 新出概念の登録提案
| term | ja | avoid | note |
| --- | --- | --- | --- |
| effective_message_length | 実効文字数 | raw_length | URL を固定長換算した文字数 |
問題がなければ「揺れなし」と簡潔に報告する。コードの修正は提案止まりとし、 ユーザーの指示があってから適用する。