temper

必須の事前準備

/agent-workflow を実行してください。このスキルには、ワークフローの原則、アンチパターン、コンテキスト収集プロトコルが含まれています。先に進む前にプロトコルに従ってください。ワークフローのコンテキストがまだない場合は、必ず最初に /teach-maestro を実行してください。 トポロジーパターンと、マルチエージェントが妥当となる条件について、agent-workflow スキルの agent-architecture リファレンスを参照してください。

---

過剰なエンジニアリングを避けてください。最もよくある間違いは、作り込みが足りないことではなく、作り込みすぎることです。

過剰なエンジニアリングの見極め方

過剰に作り込んでいる兆候：

• 単一エージェントで解決できる問題にマルチエージェントを使う
• パフォーマンスデータがない段階で時期尚早な最適化を行う
• 実装が1つしかない抽象化レイヤー
• 変更されないもののための設定
• 重要度の低い出力に対する評価ループ
• 機能より先にフレームワークを用意する

複雑さのテスト

各コンポーネントについて、次を確認します。

1. これは実際に発生している問題を解決していますか？（「発生するかもしれない」ではなく）
2. これは機能する最もシンプルな解決策ですか？
3. これを削除すると何かが壊れますか？（壊れないなら削除してください）
4. 初めての人でも5分で理解できますか？（できないなら、簡素化してください）

適正化の戦略

不要なエージェントを統合する

OVER-ENGINEERED: User → Classifier → Router → Specialist → Formatter → Checker (6 components)
TEMPERED: User → Single Agent with good prompt (1 component, same quality)

時期尚早な抽象化を取り除く

OVER-ENGINEERED: class AgentOrchestrator with 5 strategy interfaces
TEMPERED: async function runWorkflow(input) — direct, readable

設定を簡素化する

OVER-ENGINEERED: config.yaml (200 lines, 47 params, 3 inheritance levels)
TEMPERED: config.yaml (20 lines, essential params only, sensible defaults)

適正化してはいけないもの

• エラー処理 — 不可欠であり、余分なものではありません
• ロギング — 問題が起きたときに役立ちます
• 入力検証 — 連鎖的な障害を防ぎます
• コアのガードレール — 安全性は譲れません
• ゴールデンテストセット — 正常に動作していることを確認する手段です

推奨する次のステップ

適正化した後、品質が保たれていることを確認するために /evaluate を実行するか、健全性を全面的にチェックするために /diagnose を実行してください。

絶対にしないでください：

• 適正化の前後で出力品質を測定せずに適正化する
• シンプルさを理由にエラー処理を取り除く
• 正確性を損なうほど簡素化する
• ユーザーが実際に頼りにしている機能を取り除く