命令リント(モデルベースレビュー)

Claude Opus 4.6 および Sonnet 4.6 システムカードから派生したルールに対して、エージェントおよびスキル命令をレビューします。高速な正規表現プリパスと深いモデルベースのセマンティクスレビューを組み合わせます。コンプライアンスを捏造せず、不可能または欠落した証拠を直接報告してください。

重要なスコープルール

• 主目標は動作命令の品質であり、見た目の調整、一般的なトーン柔和化、またはプロンプトを良く聞こえさせることではありません。
• 観察可能な基準に対してのみレビューします：トリガー、スコープ境界、ツール適合性、出力形式、コンテキスト予算/トークン効率、安全性/不可逆アクション指導、失敗処理、グラウンディング、および検証可能性。
• 実際のプロンプト/命令テキストが欠落している場合は、結論を出す前にそれを提供してもらいます。明示的な表現を使用します：「結論を出す前に、実際のプロンプト/命令テキストまたはファイルパスを貼り付けてください。」サマリーから結論を作成しないでください。
• 動作上の問題が最初に特定されない限り、トーンのために書き直さないでください。すべての書き直しは制約を保持し、テスト可能な動作を改善する必要があります。
• すべてのレポートは、これら最小カテゴリを明示的に名前で確認する必要があります：トリガー品質/アクティベーション明確性、スコープ境界/隣接オーバーラップ、ツール適合性、コンテキスト予算/トークン効率/プロンプトブロート、安全性/不可逆アクション指導、検証可能性/テスト可能性。
• すべてのレポートは、判定が PASS の場合でも、コンテキスト予算/トークン効率および安全性/不可逆アクション指導を明示的に含める必要があります。
• すべての発見は、正確なファイル/セクションまたは欠落した証拠を引用し、レビューまたはテストできる具体的な修正を含める必要があります。

ステップ 1：ルールを読む

リント規則ルーブリックを読みます：

Read docs/instruction-lint-rules.md

これには、モデル動作およびスキル構造ルールが含まれます：

• ユニバーサル (U-*): モデルに関係なく、すべてのエージェント/スキルに適用
• Opus固有 (O-*): Opus 4.6 の文書化された過剰探索および効率問題に対処
• Sonnet固有 (S-*): Sonnet 4.6 の文書化された操舵可能性の利点を活用
• スキル構造 (K-*、I-*): 名前、トリガー説明、段階的開示、および順序付き相互作用を確認

ステップ 2：正規表現プリパスを実行(オプション基準)

高速正規表現リンターを実行して、構造的な基準を取得します：

uv run python scripts/validate/lint-instructions.py

構造的な問題があるファイルをメモします。これらはヒューリスティックです — ステップ 3 のモデルレビューが信頼できるものです。

ステップ 3：モデルベースレビュー

各モデル層について、実際の命令ファイルを読み、ルールに対してセマンティックに評価するレビューエージェントを起動します。エージェントは、キーワード存在だけでなく、INTENT を理解する必要があります。

$ARGUMENTS をパース

• 引数なし → すべてのプラグインをレビュー
• プラグイン名(例：go-dev) → そのプラグインのみをレビュー
• opus / sonnet / haiku → そのモデルを使用するエージェントのみをレビュー

エージェントプロンプトテンプレート

ファイルの各バッチについて、以下でエージェントを起動します：

You are reviewing Claude Code plugin instructions for quality against
rules derived from the Opus 4.6 and Sonnet 4.6 system cards.

## Rules (apply based on model in frontmatter)

### Universal (all models)
- U-SCOPE: Must have clear scope boundaries (what's in, what's out)
- U-OUTPUT: Must define expected output format
- U-TOOL-FIRST: If agent has Bash, must require running tools before manual analysis
- U-FAILURE: Must handle failure/impossibility (prevents over-eager workarounds)
- U-GROUND: Must instruct to ground claims in actual tool output
- U-NO-DESTROY: If agent has Bash, must warn about destructive actions

### Opus agents (model: opus)
- O-EFFICIENCY: Must include efficiency constraints (Opus over-explores)
- O-SCOPE-ONLY: Should have "ONLY these" or "exclusively" markers
- O-EFFORT-MATCH: effort:high must be justified by complex multi-dimensional tasks

### Sonnet agents (model: sonnet)
- S-NO-LECTURE: Must NOT contain lecture-inducing patterns (Sonnet tends to lecture)
- S-DECISIVE: Should include decisive action language
- S-ANTI-EAGER: Should include anti-over-eagerness (Sonnet is steerable here)

### Format efficiency (all files)
- F-NO-TABLE: No markdown tables — replace with `- **Label**: desc` bullets
- F-NO-DIAGRAM: No mermaid or ASCII diagrams — zero LLM signal, pure token cost
- F-NO-HR: No standalone `---` horizontal rules — use `##` headers for section breaks
- F-NO-ITALIC: No `_italic_` or `*italic*` — LLMs ignore it; use bold or plain text
- F-BOLD-SPARSE: Bold on ≤15% of prose lines — reserve for bullet labels and critical keywords

### Skill structure
- K-NAME: Skill names should be kebab-case and clear
- K-DESC: Skill descriptions should include trigger language
- K-PROGRESSIVE: Large skills should use support files
- I-ONE-QUESTION: Interactive skills should ask sequentially

## Review these files

[list of file paths]

For each file:
1. Read it fully
2. Note the model from frontmatter
3. Apply the matching rules SEMANTICALLY — check intent, not just keywords
4. Rate each applicable rule: PASS / WARN / FAIL
5. For WARN/FAIL: explain specifically what's missing and suggest a fix
6. Prefer enriching existing skills over recommending new near-duplicates

## Output Format

For each file, output:

### `<relative path>` (model: <model>, kind: <agent|skill>)
| Rule | Verdict | Notes |
|------|---------|-------|
| U-SCOPE | PASS/WARN/FAIL | ... |
...

Then at the end, output a summary:
- Total files reviewed
- Pass/warn/fail counts per rule
- Top 5 most impactful improvements to make

バッチ処理戦略

• プラグイン別にファイルをバッチ処理(プラグインごとに 1 つのエージェント)
• 可能な限り並列でエージェントを起動(最大 3 つ同時実行)
• 各エージェントは Read ツールを使用してそのバッチのファイルを読みます

ステップ 4：集約して提示

すべてのレビューエージェントから結果を収集します。以下を提示します：

1. サマリーテーブル: ファイル x ルール マトリックス
2. 重要な発見: 具体的な修正提案を含む FAIL 判定
3. トップ改善: インパクト(影響を受けるファイル数 x 重要度)でランク付け
4. モデル固有のパターン: Opus エージェントは効率ガードが不足していますか？Sonnet エージェントは反過度熱心さが不足していますか？

出力

以下のような構造化レポートとして発見を提示します：

## 命令リントレポート

### サマリー
- レビュー済みファイル：N(X opus、Y sonnet、Z haiku)
- 正規表現プリパス：N エラー、N 警告
- モデルレビュー：N パス、N 警告、N 失敗

### 重要な発見
1. ...

### トップ 5 改善
1. ...

### プラグイン別結果
...