taste

センス

センスとは、何を作るか、どうすればうまく作れるか、どの選択が重要かについて、培われた判断力です。主観的な好みではなく、説明し、根拠を示せる理にかなった判断です。優れたセンスがあると、振り返ったときに、物事が必然だったように感じられます。

---

起動するタイミング

必ず起動する： ユーザーがエンジニアリングにおけるセンスに直接言及する場合：「センス」、「/taste」、「品質判断」など、コード、デザイン、またはエンジニアリングの品質に関する文脈での言及です。「味覚」のようなエンジニアリング以外の意味での「センス」（食べ物や、「デバッグする気になれない」といった口語的な用法）では起動しません。

起動する： ユーザーが具体的な修正箇所を指定せず、全体的な品質判断を求めている場合：

• 「これは良いですか」、「何かしっくりこない」、「何かおかしい」、「どこか変です」、「過剰に設計されている」、「素人っぽい」
• 判断の要点：ユーザーは何を修正すべきかを指定しておらず、全体的な品質について尋ねています

センスに関する明示的な言葉がある場合にのみ起動する： 機能に関する依頼に「センス」という言葉、または明確な品質判断の目的が伴う場合：「センスよく X を作って」、「Y のデザイン品質をレビューして」。機能に関する依頼で使われる「洗練された」、「すっきりした」、「より良い」といった一般的な修飾語（「もっと洗練させて」、「キャッシュにはどちらの方法がより良いか」）では起動しません。これらは好みを伴う通常の実装依頼であり、センスの判断を求める依頼ではありません。「どちらが良いか」だけの場合も、センスや品質に関する言葉がなければ、センスに関する依頼ではなく、機能上の比較です。

起動しない： ユーザーが品質に関するシグナルを示さず、具体的な機能上の目標を持っている場合：バグの修正、パフォーマンスの最適化、エラーハンドリングの追加、機能 X の実装、セキュリティレビュー。

---

回答の深さ

センスに関する依頼では、回答の深さを次のいずれかにします。通常は簡潔な判断を選びます。必要な場合にのみ、詳細なレビューに切り替えます。ユーザーが明示的に深さを指定した場合は、常にその指定を優先します。たとえば、5 ファイルについて「手短な意見」を求められた場合は、簡潔な判断を返してください。

簡潔な判断（デフォルト）

次の場合に使用します：単一ファイル、短いコード断片、シンプルな「これは良いですか」という質問、判断を目的とした比較、その他ほとんどのセンスに関する依頼。

自然な文章で回答します：

• 評価 — 優れている点、しっくりこない点、その理由
• 最も効果の大きい修正 — センスを最も高める一つの変更
• スコアは必須ではありません。スコアによって明確になる場合は含めてもかまいません。それ以外の場合は省略してください。

詳細なレビュー

次のいずれかに該当する場合に使用します：

• 対象が 3 ファイル以上に及ぶ、またはコードベースのまとまった範囲である
• 対象がアーキテクチャドキュメントまたは PRD である
• ユーザーが「詳細なレビュー」、「全体的なレビュー」、または「詳しいレビュー」を明示的に求めている

次の内容を含めて回答します：

• 各観点について、直接的な根拠を示した所見
• 観点ごとのスコア（1～5）— 文章による説明以上の情報が得られる場合に限り、任意で含めます
• 重要なトレードオフ — 複数の観点にまたがる実際のトレードオフ（ある判断が相反する効果をもたらすこと）がある場合に限ります。このセクションを無理に設けないでください。
• 推奨する次のアクション

必須のテンプレートはありません。根拠から導ける内容に合わせてレビューを構成してください。出力の推奨順序は、まず評価、次に根拠、必要な場合のみ構成です。

ガイド（センスを取り入れた生成またはリファクタリング）

ユーザーがセンスを意識したコードの生成またはリファクタリングを求めている場合（実装や変換を示す動詞と、品質目標が含まれている場合）は、生成時に参考原則を適用します。複雑な生成（新しいモジュール、サービス、ページ）の場合は、生成前のガイダンスを得るため、必要に応じてアドバイザーエージェントを起動します。

UI コードでは、「コード」と「コミュニケーション」のセンスだけで終わらせず、「プロダクト」のセンスも確認します。エラー状態、読み込み状態、空の状態、フォームのセマンティクス、アクセシビリティを確認してください。これらのエッジケースこそ、配慮された成果物とプロトタイプを分ける要素です（references/product-taste.md § 機能としてのエッジケースを参照）。

生成後、センスに関する判断が自明でない場合に限り、行った判断を説明する簡潔な主な選択を 2～4 行で追記します。

比較（アプローチの比較）

ユーザーが判断を伴う比較（「どちらのセンスが優れているか」「どちらのデザインのほうがよく検討されているか」など）を求めた場合は、各観点についてトレードオフを分析します。根底にある原則を参照します。センスによる判断と客観的な利点を区別して示します。本当に好みの問題である場合は、その旨を伝えます。大規模な比較（アプローチごとに多数のファイルがある場合）では、比較の中で Deep Review の観点別の構成を使用します。

明示的にセンスや品質について問われていない、通常の実装上のトレードオフに関する質問（キャッシュ戦略、DB の選択、フレームワークの選定など）は、このスキルの対象外です。

---

5 つのセンスの観点

各観点の詳細な参考ファイルは references/ にあります。レビューまたは生成の前に、関連するファイルを読みます。

観点	中核となる緊張関係	最終的な判断基準
コード	独創性より一貫性	深夜 2 時に疲れたエンジニアでも理解できますか？
アーキテクチャ	優雅さより回復力	次の 3 回の要件変更にも耐えられますか？
プロダクト	完全性より組み合わせやすさ	これを取り除くとプロダクトはよくなりますか、それとも単に作りやすくなるだけですか？
デザイン	装飾より意図	すべてのピクセルに存在意義がありますか？
コミュニケーション	説明より理解を促すこと	新規参加者は尋ねることなく意図を理解できますか？

観点の境界

• コードの対象：構造、抽象化、制御フロー、エラー処理、命名の仕組み（スコープに応じた長さ、名前の曖昧さ、ファイル名）
• コミュニケーションの対象：ドメイン言語としての命名、API サーフェスの設計、ドキュメント、コミットメッセージ、エラーメッセージ
• 重複に関するルール：純粋に仕組み上の命名の問題（曖昧な名前、大文字・小文字の不統一）は「コード」に分類します。ドメインモデリングに関する命名の問題（実装言語とドメイン言語の違い）は「コミュニケーション」に分類します。API サーフェス内で発生した仕組み上の問題（エンドポイントの大文字・小文字の不統一など）は「コミュニケーション」の領域である API サーフェスの問題として評価します。同じ問題を両方の観点で減点しないでください。
• コメントに関するルール：理由（ビジネス上の理由、明白でない制約）を説明するインラインコードコメントは、「コミュニケーション」（ドキュメントの品質）として評価します。認知負荷を高める、必要なコメントの不足は「コード」（認知負荷）として評価します。同じコメントの問題を両方の観点で減点しないでください。

スコア基準（1～5）

• 1 = 有害 — 混乱、技術的負債、ユーザーの不満を招きます
• 2 = 不注意 — 動作はしますが、トレードオフについて判断した形跡がありません
• 3 = 適切 — 妥当な選択で、特に問題は見当たりません
• 4 = よく検討されている — 意図的なトレードオフの明確な証拠があり、優れた判断が感じられます
• 5 = 卓越 — 当然そうあるべきだと感じられ、実例を通じて学べ、参考例として挙げたくなります

根拠に関するルール

• 提供された成果物に直接的な根拠がある観点のみ採点します
• 根拠がない観点は省略し、不足しているものを簡潔に記します：「デザインは未レビュー — UI 成果物が提供されていません」
• 根拠が乏しい場合（例：スクリーンショットが 1 枚のみで、インタラクション状態がない場合）は、スコアを 2～4 に限定し、不確実性を明示して、方向性を示す提案のみを行います
• 表面的な根拠だけで 1 または 5 を付けてはいけません

---

コードベースへの適応（生成）

生成する前に、コードベース内の既存パターンを抽出します。

1. 対象ディレクトリで同種の参考ファイルを最大 3 件見つけます
2. 命名規則、ファイル構成のパターン、ライブラリ／フレームワークのパターンを抽出します
3. 既存のパターンに合わせて生成します。既存のパターンが参考原則と衝突する場合は、明らかに有害でない限り、既存のパターンを優先します。

既存のパターンが見つからない場合は、次のように記します：「既存のコードパターンは検出されませんでした — 一般的なセンスの原則に基づいて提案します。」

---

知的な源流

これらの思想が、審美眼の原則に影響を与えています。判断を説明する際は、自然な形で参照してください。

• Unix 哲学（McIlroy）：一つのことをうまく行う。組み合わせる。
• Dieter Rams（10 原則）：優れたデザインとは、可能な限りデザインを少なくすることです。
• Paul Graham（Taste for Makers）：シンプルさ。時代を超えること。正しい問題を解決すること。
• 認知負荷理論（Sweller）：作業記憶の容量は約 4 項目です。不必要な概念はすべてコストになります。
• Christopher Alexander（パターン・ランゲージ）：特定の文脈において、繰り返し現れる問題に対する解決策。
• Steve Krug（Don't Make Me Think）：インターフェイスの審美眼とは、ためらいが一切ないことです。
• Rich Hickey（Simple Made Easy）：シンプルであることは、簡単であることとは違います。複雑に絡み合わせることが敵です。
• Sandi Metz（Practical OO Design）：間違った抽象化をするくらいなら、重複を選びます。
• Kent Beck：変更しやすくしてから、その簡単な変更を行います。
• Linus Torvalds（Good Taste）：特別扱いをなくします。上流のデータを信頼します。

---

アンチパターン（判断基準）

審美眼に欠ける状態とはどのようなものか、判断基準として活用してください。

• 宇宙飛行士アーキテクチャ — 抽象化のための抽象化。目的のないレイヤー
• 賢さの見せびらかし — 伝えるためではなく、目立つためのコード
• 早すぎる一貫性 — ドメインを理解する前に、統一を無理に押し付けること
• デザインのデフォルトの罠 — デフォルトの余白、ありきたりなカード、視覚的な階層の欠如、AI 生成物のような画一性
• 名前の霧 — handleData、processInput、utils.ts、helpers.js
• 完全性を装った機能肥大化 — 「ついでに」追加する機能
• 間違った抽象化 — 概念が実際には異なるところに DRY を適用すること
• カーゴ・カルト的なパターン — 理由を理解せず、「そうするものだから」とパターンを使うこと
• 過剰な作り込み — 重要でないものを磨き上げ、重要なものを無視すること

---

エージェントの振り分け

エージェントの利用は任意です。審美眼に関する依頼のほとんどで、エージェントは必要ありません。

Reviewer エージェント（agents/reviewer.md）— 次のいずれかに該当する場合に起動します。

• 詳細なレビュー対象が 5 ファイル以上にわたる
• ユーザーが 3 ファイル以上にわたる対象について、「deep review」または「full review」を明示的に依頼している

Advisor エージェント（agents/advisor.md）— 次の場合にのみ起動します。

• 新しいモジュール、サービス、またはページを生成する場合（大規模なグリーンフィールド開発）
• 小規模な生成タスク（コンポーネントの追加、審美眼を加味した修正など）では不要です

すべての判断はメインスキルが担います。エージェントは実行役であり、調査結果を返し、あなたがそれをまとめます。