| name | tier-matrix-review |
| description | 3 ヶ月周期で .agent-core/sprints/ と post-mortem の Tier Matrix Suggestion を集計し、tier 判定ルール (classify-tier.sh と tier-matrix.md) の改定案を提示する。構造層 Gotcha 学習の HITL ゲート。Trigger: /tier-matrix-review, 四半期レビュー, tier 判定見直し |
| disable-model-invocation | false |
Tier Matrix Review — 構造層 Gotcha の HITL 集約スキル
Usage
/tier-matrix-review [--since=YYYY-MM-DD]
--since: 集計開始日 (省略時は 3 ヶ月前)
設計原理
H-Consensus の Gotcha 2 層学習のうち、Layer 2 (構造層) を担当するスキル。
- Layer 1 (prompt層): post-mortem agent が sprint 終了後に随時 agent/skill MD 末尾に append
- Layer 2 (構造層): このスキルが 3 ヶ月周期で sprint ログと post-mortem の提案を集計 → tier 判定ルール改定案を HITL レビュー
構造層は agent の prompt 改善では直らない問題 (tier が誤判定された、fork 構成が適さなかった等) を扱う。頻繁に書き換えるべきではないため、3 ヶ月周期で HITL ゲートを必ず通す。
決定論ゲート (スキルローダー実行)
ゲート 1: Sprint ログ集計
3 ヶ月以内の sprint 件数: !find .agent-core/sprints -name 'S-*.json' -mtime -90 2>/dev/null | wc -l
3 ヶ月前の日付: !date -v-90d +%Y-%m-%d 2>/dev/null || date -d '90 days ago' +%Y-%m-%d
ゲート 2: Tier 別集計
T1 sprint 件数 (3ヶ月): !find .agent-core/sprints -name 'S-*.json' -mtime -90 2>/dev/null | xargs -I{} grep -l '"tier": "T1"' {} 2>/dev/null | wc -l
T2 sprint 件数 (3ヶ月): !find .agent-core/sprints -name 'S-*.json' -mtime -90 2>/dev/null | xargs -I{} grep -l '"tier": "T2"' {} 2>/dev/null | wc -l
T3 sprint 件数 (3ヶ月): !find .agent-core/sprints -name 'S-*.json' -mtime -90 2>/dev/null | xargs -I{} grep -l '"tier": "T3"' {} 2>/dev/null | wc -l
ゲート 3: エスカレーション件数
3 ヶ月の ESCALATED sprint: !find .agent-core/sprints -name 'S-*.json' -mtime -90 2>/dev/null | xargs -I{} grep -l '"verdict": "ESCALATED"' {} 2>/dev/null | wc -l
ゲート 4: 現行 tier-matrix.md
現行 tier-matrix 存在確認: !test -f .agent-core/tier-matrix.md && echo "exists" || echo "missing"
指示 (main Claude orchestrator 版)
あなたは /tier-matrix-review の orchestrator です。3 ヶ月間の sprint 運用実績から tier 判定ルールの改善点を抽出し、ユーザーに改定案を提示せよ。
Step 1: データ収集
Step 1-A: sprint JSON の読み込み
ゲート 1-3 で得られた件数を確認。sprint が 10 件未満なら早期終了:
⚠️ 集計対象 sprint が {N} 件しかありません (10 件未満)。
tier matrix 改定には統計的サンプルが不足しています。
次回 /tier-matrix-review は sprint が 10 件以上蓄積された後に実行してください。
10 件以上ある場合、以下を Read で収集:
find .agent-core/sprints -name 'S-*.json' -mtime -90 -type f
各 sprint JSON から以下を抽出:
sprint_id, ticket_id, tier, cold_start_override, manual_force, iterations, verdicttier_metadata (ticket JSON を join して参照)
Step 1-B: post-mortem の Tier Matrix Suggestion を収集
全 post-mortem レポートの ### Tier Matrix Suggestion セクションを grep で抽出:
grep -rA 5 "### Tier Matrix Suggestion" .agent-core/sprints/ 2>/dev/null
各提案を TIER_SUGGESTIONS リストに集約。
Step 2: パターン分析
以下の定量的パターンを機械的に検出する (LLM 的判断ではなく決定論集計):
Pattern A: Tier 判定の偏り
- T1 / T2 / T3 の実行比率
- 健全な分布: T1 15-30%, T2 50-70%, T3 10-25%
- 偏りが大きい場合、tier 判定ルールの閾値が不適切な可能性
Pattern B: Escalation 多発 tier
- tier 別の ESCALATED 件数を集計
- どの tier でエスカレーションが多発しているかを確認
- T2 で escalation 多発 → fork 構成が不十分 (T3 化を検討)
- T1 で escalation 多発 → 閾値が緩すぎて本来 T2 相当が T1 に落ちている
Pattern C: Iteration 過多
- 各 tier で iteration が 3 round 以上の sprint を抽出
- T2 で iteration 過多 → test-auditor 欠如が原因の可能性
- T1 で iteration 過多 → T1 判定ルールが甘い可能性
Pattern D: manual_force が発動した sprint
- ユーザーが
--force-tier で判定を上書きしたケース
- 発動回数が多い tier → 自動判定の信頼性が低い
Pattern E: post-mortem からの集約提案
TIER_SUGGESTIONS 内の重複提案を頻度順にソート- 3 件以上の独立 sprint から同じ提案が出ていれば採用候補
Step 3: 改定案の生成
Pattern A-E の結果を元に、以下の候補を生成する:
3-A: classify-tier.sh の閾値変更案
- 現行 surface threshold (10) を変更すべきか
- 現行 risk_layer のカテゴリ分けを変更すべきか (新規 layer を追加 or 既存を統合)
3-B: tier-matrix.md の記述更新案
- 各 tier の典型例を実データで更新
- post-mortem 提案を反映した判定ルール追記
3-C: cold-start-check.sh の閾値変更案
- 現行の sprint 20 / gotcha 10 の閾値が適切だったか
- 実績から最適値を逆算
Step 4: 改定案の HITL 提示
以下の Handoff Document でユーザーに提示:
## Tier Matrix Review Report (since {SINCE_DATE})
### Sprint Statistics
- Total: {N} sprints
- T1: {N1} ({P1}%)
- T2: {N2} ({P2}%)
- T3: {N3} ({P3}%)
- Escalated: {NE} ({PE}%)
- Cold-start override: {NC}
- Manual force: {NM}
### Pattern Findings
#### Pattern A (Distribution Balance)
- 実測分布: T1 {P1}%, T2 {P2}%, T3 {P3}%
- 健全範囲: T1 15-30%, T2 50-70%, T3 10-25%
- 判定: {within_range / too_low_T1 / too_high_T3 / etc.}
#### Pattern B (Escalation by Tier)
- T1 escalation: {n} / {total}
- T2 escalation: {n} / {total}
- T3 escalation: {n} / {total}
- 顕著な偏り: {yes/no, 詳細}
#### Pattern C (Iteration Excess)
- iteration >= 3 round が発生した sprint: {count}
- 最も iteration 過多だった tier: {tier}
#### Pattern D (Manual Force Frequency)
- --force-tier 発動: {count} 回
- 最多上書き先: {tier}
#### Pattern E (Post-Mortem Proposals)
- 収集した提案数: {count}
- 頻度 3 以上の共通提案 (採用候補):
1. {proposal 1} (頻度 {N1})
2. {proposal 2} (頻度 {N2})
3. {proposal 3} (頻度 {N3})
---
### 改定案
#### Proposal 1: classify-tier.sh の閾値変更
- 対象: [surface threshold / risk_layer mapping / etc.]
- 現行: [現在の値]
- 推奨: [新値]
- 理由: [Pattern A/B/C のどれに基づくか]
- 適用影響: 過去 3 ヶ月 {N} sprint のうち {M} sprint が再分類される見込み
#### Proposal 2: tier-matrix.md 記述更新
- 追記内容: [具体的な文言]
- 理由: [Pattern E の post-mortem 提案を反映]
#### Proposal 3: cold-start-check.sh 閾値調整
- 対象: [sprint / gotcha 閾値]
- 現行: 20 / 10
- 推奨: [新値]
- 理由: [実績データに基づく逆算]
---
### 選択肢
1. Proposal 1/2/3 を全て承認 → 自動適用 → git diff で確認
2. 一部のみ承認 → 個別選択
3. 全て却下 → 現状維持
4. 分析結果だけ見て、修正は後回し
5. 次回レビュー日を再設定 (早める / 遅らせる)
どれにしますか？
Step 5: 承認後の適用 (HITL 承認時のみ)
ユーザーが承認した Proposal のみ適用する。
5-A: classify-tier.sh の変更
plugins/agent-core/scripts/classify-tier.sh を Edit で変更- 変更後、テストケースで動作確認 (4 パターン smoke test)
5-B: tier-matrix.md の変更
.agent-core/tier-matrix.md が存在しなければ plugins/agent-core/scripts/tier-matrix-initial.md をコピーしてから Edit- 追記内容を Edit で反映
5-C: cold-start-check.sh の変更
plugins/agent-core/scripts/cold-start-check.sh を Edit で変更
5-D: Review 実施記録
.agent-core/tier-matrix-reviews/YYYY-QN.md に実施記録を残す:
# Tier Matrix Review YYYY-QN ({実施日})
## Sprints Analyzed
{集計結果}
## Proposals Applied
- Proposal 1: {採用 / 却下}
- Proposal 2: {採用 / 却下}
- Proposal 3: {採用 / 却下}
## Applied Diff
{git diff --stat}
## Next Review Due
{3ヶ月後の日付}
Rules
- このスキルは HITL 必須 (自動適用は禁止)
- 3 ヶ月周期の運用を推奨 (頻繁な変更は tier 判定の一貫性を損なう)
- 10 sprint 未満の集計では改定しない (統計的有意性不足)
- 改定後は必ず classify-tier.sh の smoke test を実行
- 却下された Proposal も記録に残す (将来の再検討のため)
Next
→ ユーザー承認後: 自動適用 → smoke test → 次回レビュー日予約
→ 却下時: 現状維持、記録だけ残す
→ 3 ヶ月後: 再度 /tier-matrix-review を実行
Gotchas
