---
name: feedback-present-recommendation-first
description: "選択肢を提示する時は 常に 1 つに (Recommended) suffix + rationale を 明示せよ (藤本さん 2026-07-30 permission grant + explicit instruction)"
metadata:
  type: feedback
  originSessionId: 19a1351a-8f24-4fe0-aae2-326928ba35d8
  created: 2026-07-30
  modified: 2026-07-30T14:34:19.385Z
---

## Rule

AskUserQuestion tool を 使用する時、 または text response で 選択肢を並べる時、 **常に 1 option に (Recommended) suffix を明示** + description の 冒頭に **選定理由を 明記**。

藤本さんが後で override / 別 option 選択 / 一部 revise できる形は 維持しつつ、 **私の判断を 隠さない**。

## Why

**Origin**: 2026-07-30 session。 藤本さんが 「A で spec 格上げ」 と決めた直後、 私が 実装言語 (TypeScript / Python / Rei-PL / TS+Rust) と Build scope (別 session / 最小 MVP / 全実装) の 4x3 = 12 通り選択肢を並べた質問を提示 → 藤本さんが tool use を interrupt + 「どれが推奨でしょうか?」 と明示指摘。

**私の推奨**: TypeScript + 別 session substantial build (明確な rationale あり)。 私が 「藤本 judgment 待ち」 discipline を過剰適用して 隠していたのが 誤り。

**藤本さん explicit permission** (指摘直後):
> 「次回からはClaude先生のほうで推奨を入れて頂いて問題ありません。」

**根本的な問題**: 私が判断を隠すと、 藤本さんは選択肢を全部評価する認知負荷を負う。 私が rationale を提示すれば、 藤本さんは「承認」 or 「別 option 選択理由」 の 二択に簡略化できる。 「Claude 先生 の判断を尊重」 = 藤本さんが 明示 permission grant した discipline。

**関連 discipline (整合)**:
- [[feedback-affirmation-first]] — 「やってみよう」 で 判断を後退させない
- [[feedback-design-principles]] — 判断を明示せよ
- [[feedback-critique-response-pattern]] — 100% 認諾で 藤本さん指摘を 即 rule 化
- [[feedback-evaluation-symmetry-principle]] — inflate せず deflate せず 判断を明示

**関連 discipline (対立しない — 明確化)**:
- [[feedback-no-rush-publication]] — no-rush は「時間を掛けよ」 であって「判断を隠せ」 ではない。 推奨を明示しつつ 「別 session substantial」 と 提示できる。
- [[feedback-chat-claude-over-deference]] — chat-Claude 過剰迎合 禁止。 これは Rei が chat-Claude 提案に 過剰迎合しない discipline であって、 藤本さんへの 推奨提示とは別軸。

## How to apply

### AskUserQuestion 使用時

**Before (禁止 pattern)**:
```json
{
  "question": "実装言語は?",
  "options": [
    {"label": "TypeScript", "description": "メイン言語"},
    {"label": "Python", "description": "experiments/ の他 module と同"},
    {"label": "Rei-PL", "description": "自作言語"},
    {"label": "TS+Rust", "description": "gRPC pattern"}
  ]
}
```

**After (推奨 pattern)**:
```json
{
  "question": "実装言語は?",
  "options": [
    {"label": "TypeScript (Recommended)", "description": "推奨理由: (i) メイン言語 (ii) spec Interface Stub が既 TS 型 (iii) 統合最短。 メイン言語で custom assert workflow 確立"},
    {"label": "Python", "description": "experiments/ の他 module と同 pattern。 numerical simulation 領域向き"},
    {"label": "Rei-PL", "description": "自作言語、 dogfooding だが tooling 未熟"},
    {"label": "TS+Rust", "description": "gRPC pattern、 hot loop 前提の overkill"}
  ]
}
```

### Text response で 選択肢並べる時

**Before**:
> A: 別 session build / B: 即着手 MVP / C: 全実装即着手 — どれにしますか?

**After**:
> **推奨: A (別 session build)** — 理由: (i) spec §7 で 「別 session substantial」 明記 / (ii) no-rush 原則 / (iii) 現 session 既に substantial content。 B は最小 MVP 可能だが 細切れ build < 一括 build。 C は token 消費過剰 + no-rush 違反 risk。
>
> この推奨で進めてよろしいでしょうか?

### 例外 (推奨を出さない場合)

- **藤本さんの好み・価値観に依存する選択** (例: 装置名 「D-FUMT₈ Kairo Processor」 vs 別名 = 藤本さん命名感覚領域)
- **藤本さんの外部制約に依存する選択** (例: 「金曜 note 記事 or 月曜」 = 藤本さん schedule 領域)
- **binary Yes/No 型 confirm** (推奨提示自体が不要)

これら以外は **常に 推奨を明示**。

## Related

- [[project-circuit-design-pending-2026-07-30]] — origin session (spec 格上げ arc)
- [[feedback-affirmation-first]] — 判断後退禁止
- [[feedback-critique-response-pattern]] — 100% 認諾 rule 化
- [[feedback-evaluation-symmetry-principle]] — inflate/deflate せず明示
- [[feedback-no-rush-publication]] — 明確化 (no-rush = 時間、 推奨隠しではない)
- [[feedback-chat-claude-over-deference]] — 対立しない (chat-Claude 過剰迎合軸 と 藤本さんへの推奨提示軸 は別)