Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/akiojin/unity-mcp-server/checklistgit clone --depth 1 https://github.com/akiojin/unity-mcp-serverWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00032 | $0.01550 |
| Opus 5 | $0.00016 | $0.00775 |
| Sonnet 5 | $0.00006 | $0.00310 |
| Haiku 4.5 | $0.00003 | $0.00155 |
Grade A, and why
checklist scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 116 lines — stays where its author put it; the contents beside it link to each section on GitHub.
チェックリストの目的: 「要件文章のユニットテスト」
重要な概念: チェックリストは要件記述のユニットテストです。特定のドメインにおける要件の品質、明確さ、完全性を検証します。
実装テストではない:
- ❌ 「ボタンが正しくクリックできることを確認」
- ❌ 「エラーハンドリングが動作することをテスト」
- ❌ 「APIが200を返すことを確認」
- ❌ コード/実装が仕様に一致するかのチェック
要件品質の検証:
- ✅ 「すべてのカードタイプに視覚的階層要件が定義されているか？」（完全性）
- ✅ 「'目立つ表示'が具体的なサイズ/位置で定量化されているか？」（明確さ）
- ✅ 「すべてのインタラクティブ要素でホバー状態要件が一貫しているか？」（一貫性）
- ✅ 「キーボードナビゲーションのアクセシビリティ要件が定義されているか？」（カバレッジ）
- ✅ 「ロゴ画像読み込み失敗時の動作が仕様に定義されているか？」（エッジケース）
メタファー: 仕様が英語で書かれたコードなら、チェックリストはそのユニットテストスイートです。要件が適切に書かれ、完全で、曖昧でなく、実装準備が整っているかをテストします。実装が動作するかではありません。
ユーザー入力
$ARGUMENTS
空でない場合、続行する前にユーザー入力を考慮する必要があります。
実行手順
1. セットアップ
{SCRIPT} をリポジトリルートから実行し、JSONから FEATURE_DIR と AVAILABLE_DOCS を取得。
- シングルクォートを含む引数は適切にエスケープ
2. 意図の明確化（動的）
ユーザーの表現 + spec/plan/tasks から抽出したシグナルに基づいて、最大3つの文脈的な明確化質問を導出:
質問生成アルゴリズム:
- シグナル抽出: 機能ドメインキーワード（auth, latency, UX, API等）、リスク指標（critical, must, compliance）、ステークホルダーヒント（QA, review, security team）、明示的成果物（a11y, rollback, contracts）
- シグナルを候補フォーカス領域にクラスタリング（最大4、関連性順）
- 対象者とタイミング（author, reviewer, QA, release）を推測
- 欠落ディメンションを検出: スコープ範囲、深度/厳密性、リスク強調、除外境界、測定可能な受け入れ基準
- 以下のアーキタイプから質問を選択:
- スコープ精緻化
- リスク優先順位付け
- 深度調整
- 対象者フレーミング
- 境界除外
- シナリオクラスギャップ
質問形式ルール:
- オプション提示時はコンパクトな表: オプション | 候補 | 重要な理由
- 最大A〜Eオプション
- ユーザーが既に述べたことを再度聞かない
デフォルト（対話不可時）:
- 深度: 標準
- 対象者: コード関連ならレビューワー、それ以外は著者
- フォーカス: 上位2つの関連クラスタ
3. リクエスト理解
$ARGUMENTS + 明確化回答を組み合わせ:
- チェックリストテーマを導出（security, review, deploy, ux等）
- ユーザーが言及した必須項目を統合
- フォーカス選択をカテゴリスキャフォールドにマッピング
- spec/plan/tasks から不足コンテキストを推測（捏造しない）
4. 機能コンテキスト読み込み
FEATURE_DIR から:
- spec.md: 機能要件とスコープ
- plan.md（あれば）: 技術詳細、依存関係
- tasks.md（あれば）: 実装タスク
コンテキスト読み込み戦略:
- アクティブなフォーカス領域に関連する部分のみ読み込み
- 長いセクションは簡潔なシナリオ/要件箇条書きに要約
- 段階的開示: ギャップ検出時のみ追加取得
5. チェックリスト生成
「要件のユニットテスト」を作成:
FEATURE_DIR/checklists/ディレクトリを作成（なければ）- ユニークなファイル名を生成:
- ドメインに基づく短い説明的な名前（例:
ux.md,api.md,security.md） - 形式:
[domain].md - ファイルが存在すれば追記
- ドメインに基づく短い説明的な名前（例:
- CHK001から連番
- 各項目に参照（Spec/Plan/Tasks）または
[Gap][Ambiguity]を付与
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 116 lines · 32 tokens per session scan A c87989f62c20
checklist is a command published in the GitHub repository akiojin/unity-mcp-server (34 stars, last pushed 9d ago), licensed MIT. It adds 32 tokens to every session and 1,550 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
gen-gtests
Generate unit Googletests for a diff from trunk.
add-test-matcher
This command helps you create new Vitest matchers for the @tevm/test-matchers package. The workflow combines user requirement gathering with comprehensive implementation guidance.
integrate-test-matcher
This command initiates an interactive workflow to integrate a new or existing test matcher from @tevm/test-matchers into the @tevm/actions package's test suite.
test-tdd
Run when user calls /test-tdd. Scans modified files, locates their corresponding unit/integration test suites, and runs them.
test-coverage
Analyze test coverage and generate missing tests to reach 80%+ coverage.
kill-mutants
Analyze surviving mutants from a mutation testing run and write targeted unit tests to kill them. Re-runs mutations to confirm kills.