taste

Taste

必読： ../pack-shared/standards.md。ルールは AGENTS.md の Taste セクションと Architecture セクションにあります。このスキルには監査手順と例が記載されています。このスキルが呼び出されていないからといって、ルールを省略しないでください。

質問のスタイル： ../pack-shared/asking.md

読むもの： AGENTS.md の Taste セクション · examples.md · UI の検証や変更を行う場合は reference.md · ../pack-shared/plain-language.md

引用キーは Taste セクションの見出しです。ユーザーに話すときは、原則を**平易な名前（正式名称）**で引用してください。例：keep this simple (KISS)。「正式名称なしの略語のみ」や「正式名称を含まない言い換え」は使わないでください。配置や taste:keep-jobs-apart の不備も、Taste の違反です。親ワークフロー（/task、/analyze、/grill-me、/implement、/design）は、計画やコードの記述に入る前に Taste と Architecture の各セクションを適用します。

これが単発の依頼（監査またはレーンの修正）の場合

コーディングスタイル、シンプルさの維持、重複の回避、原則についてユーザーから質問された場合や、「これはきれいな実装ですか？」と尋ねられた場合、完全な /task を実施せずにレーンをレビューする場合、または小規模な変更の前後に乱雑なファイルを整える場合に使用します。

1. 対象のレーン（パス／シンボル）と依頼内容を特定します。
2. Taste セクションと examples.md を適用します。引用キー（taste:keep-it-simple および名前付き原則）を使います。
3. パスを根拠として具体的な違反を報告し、最小限の修正を提示します（taste:leave-it-cleaner／taste:keep-it-simple：推測に基づく書き換えはしない）。
4. ユーザーが修正を依頼した場合は、そのレーン内で動作を維持する編集のみを適用します。より大きなプロダクト範囲の変更には、/analyze または /task を推奨します。
5. 親ワークフローを独自に作ったり、テストを書いたり、/create-test を開始したりしないでください。

引き継ぎ先：構造／フォルダー／サービス → /architecture。エンドツーエンドで構築 → /task。まず調査 → /analyze。

ビルドの中ですでにこのスキルが読み込まれている場合

1. グリルの締めくくり、プランのコントラクト作成、または実装ブリーフの作成に入る前に、Taste と Architecture の各セクションを適用します。
2. 関連する引用キーが動作に関わる場合は、Active Rules／受け入れ条件に引き継ぎます（例：境界で taste:fail-fast、Webhook で taste:safe-to-retry）。
3. 受け入れの根拠を集めて /code-review を行う前に、Taste セクションのチェックリストを実行します。
4. /code-review の Standards 軸では、リポジトリのドキュメントに反する記述がない限り、Taste と Architecture の違反をどちらも重大な違反として扱います。