grilling

This skill is adapted from mattpocock/skills grilling (MIT). The original 5-line essence:

Interview me relentlessly about every aspect of this plan until we reach a shared understanding.
Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
For each question, provide your recommended answer.
Ask the questions one at a time.
⚠️ cfh deviation from original: do NOT explore the codebase as a substitute for asking. The codebase represents current state, but grill is about user intent — they may differ. Always ask the user; codebase is reference material for recommendation rationale only.

Faithfully preserved:

• Relentless depth (unbounded, no auto round/time cap) — see Phase 3
• One question at a time — explicit TURN BOUNDARY in Phase 2
• Walk design tree, resolve dependencies — Phase 1 + 2
• Recommended answer for every question — required, never skipped

cfh additions (clearly marked, do not weaken original):

• Confidence markers [verified] / [inferred] / [guessed] for transparency
• Phase 0 context absorption — handles /cfh-plan → /cfh-grill delegation
• Phase 1 branch enumeration — user sees the tree before grilling starts
• Optional branch pruning (user "skip this branch") — remaining branches still relentless
• Anti-triggers — prevents collision with /cfh-plan·/cfh-debug·/cfh-make
• Retro mini-section at end — links to /cfh-retro for permanent record

Deliberate deviations from original (intentional, reasoned):

• ⚠️ "Explore the codebase instead of asking" REMOVED. Original says: "If a question can be answered by exploring the codebase, explore the codebase instead." We disagree — grill is about user intent, not current state. Code may have an answer (e.g., "current state uses zustand") but the user may intend something different for this plan. Asking the user is non-negotiable; code is reference material for recommendation rationale, never a substitute for the answer.
• No automatic depth/round cap — depth is unbounded by design (we strengthen original "relentlessly")

Deliberate non-changes (kept original even when tempted):

• Recommendation rationale is enhancement, not replacement — original just said "recommended answer", we added why; the recommendation itself is still core

트리거 조건 (1.0 컨벤션 — 본문 참고용, frontmatter description이 권위)

TRIGGER:  'grill me', 'stress-test this plan', '진짜 이거 맞아?', '더 깊이 봐줘',
          '결정 트리 파봐', '이 디자인 검증해줘' — 기존 plan·design을 깊이 인터뷰.
SKIP:     casual planning (use /cfh-plan), initial intent gathering (use /cfh-make),
          bug investigation (use /cfh-debug). 자동 trigger 약함 — 명시 호출(`/cfh-grill`) 우선.
EXAMPLES:
  - '/cfh-grill 쿠폰 검증 plan' → Phase 1 decision tree enumerate + 순차 인터뷰
  - '/cfh-plan' Phase 2 카드에서 (grill) 선택 → Context handoff 블록 + /cfh-grill 위임
  - '/cfh-grill 결제 쪽' → 광범위 topic 가드: 좁히는 질문 후 진입

Core principles:

• One question at a time. Never dump multiple questions. Wait for each answer before the next.
• Always recommend. Every question carries your recommended answer + rationale. Empty "what do you think?" is forbidden.
• User intent first. Always ask the user. Code is current state, not future intent — they may differ. Codebase is reference for recommendation rationale only, never substitute for the answer.
• Explicit answers required. "OK"/Enter/brief response/silence are ambiguous — do not interpret as consent or default-acceptance. Wait until the user expresses intent unambiguously. Applies everywhere (Phase 0, 1, 2, 3).
• Walk the tree. Resolve parent decisions before children. A decision blocks its dependents until answered.
• Depth is unbounded. End only when the tree is exhausted, the user explicitly says "enough"/"그만"/"시간 없어", or remaining branches are all [guessed] (information gap, no signal to push further). No automatic round/depth caps — mattpocock 원본의 "relentlessly" 정신.
• Confidence tagging. Mark each piece of reasoning with [verified] / [inferred] / [guessed] so the user knows what to push back on.
• Self-validation (slot ≠ purpose). Every node, option, and sub-decision must exist because it materially affects the user's plan — not because a template has a slot for it. Slot-filling = empty question = forbidden. Specific applications:
  • Phase 1 enumerate — explicit reason required: each candidate node carries a one-line "why this matters for THIS plan" reason next to it (visible in tree card). If the only reason is "it's a template standard" or "it's in the category," exclude. When in doubt, exclude by default.
  • Phase 1 — exclusions transparent: tree card shows an "Excluded candidates (self-validation)" section with each excluded node + reason. Self-validation must not be a black box. User can request inclusion ("actually do grill X") — re-inclusion is supported (decisions can be reversed).
  • Phase 2 question gate: if you cannot ground the recommendation with at least one [verified] or [inferred] (i.e., only [guessed]), do NOT ask. Move to Phase 3 "unresolved — insufficient signal" instead.
  • "Alternative B/C": only when real trade-offs exist. If recommendation is dominant, write "no real alternative — single clear choice" rather than fabricate plausible-sounding alternatives.
  • Sub-decision creation: only when the user's answer explicitly opens a new branch, or the new node blocks progress. Do NOT auto-derive "and now we need to decide X within A" from "I'll go with A".</s>

<when_to_trigger>

Trigger phrases (any of):

• "grill me", "grill the plan", "stress-test this plan"
• "진짜 이거 맞아?", "더 깊이 봐줘", "이 디자인 검증해줘"
• "결정 트리 walk", "decision tree review"
• Used after /cfh-plan Phase 2 with (grill) option

Anti-triggers (do NOT trigger):

• Casual or fresh planning → use /cfh-plan instead
• Initial intent gathering ("뭐 만들지 모르겠어") → use /cfh-make
• Bug investigation ("원인 모르겠어") → use /cfh-debug
• Test writing ("TDD 시작") → use /cfh-tdd / /cfh-tdd-gen

</when_to_trigger>

Phase 0 — Context absorption

Core principle: No automatic context absorption. Grill target comes only from explicit $ARGUMENTS or explicit user answer. Aligned with the ambiguous-response rule.

1. If invoked from /cfh-plan (grill) option → /cfh-plan outputs an explicit Context handoff block + explicit command line. The user invokes /cfh-grill <Q1> themselves; we then have the handoff block visible in the conversation as explicit reference. Do not re-ask the Q1~Q4 since the user already answered them — the handoff block carries them.

2. If standalone (/cfh-grill <topic-or-goal>) — $ARGUMENTS accepts plan / design / goal / topic in any form. Two sub-cases:

   2a. Existing-code target (e.g., src/legacy/foo refactor):

   • tiny pre-scan for tree enumeration only, NOT for finding answers
   • CLAUDE.md (relevant section only)
   • package.json deps
   • Topic-related: at most 3 files, 100 lines each
   • Forbidden: broad Glob, whole-directory Read
   • Pre-scan output → tree enumeration context + [verified] for rationale. Answer still from user.

   2b. Greenfield / abstract goal (e.g., 쿠폰 검증 추가, auth 재설계):

   • Skip pre-scan — no code to read
   • Enumerate via decision-tree.md FE/BE/refactor templates + topic keyword matching
   • Rationale uses [inferred] / [guessed] only (no [verified] without code)
   • User answers carry most of the signal — grill works harder here
3. If no $ARGUMENTS and no handoff block → ask one question: "What plan or design do you want grilled? One sentence." Wait for an explicit, unambiguous answer before proceeding to Phase 1. Brief responses ("OK", Enter, silence) are not answers — they are ambiguous and should keep the skill waiting.
4. If $ARGUMENTS or user answer is too broad (e.g., "결제 쪽", "auth 관련", "프론트 좀") — do NOT enumerate the category-template tree wholesale. Ask one narrowing question: "Specifically which decision or plan? (e.g., payment retry policy / card tokenization strategy / idempotency)". Only enter Phase 1 after the user narrows.

After Phase 0, enumerate as many decision points as the plan naturally contains. No minimum, no maximum — depth is unbounded by design. mattpocock 원본의 "relentlessly" 정신 유지.

• Tiny plan (e.g., 함수 한 개 rename) → 2~3 nodes is normal — signal "shallow plan, grill 가치 낮음"
• Medium plan → 5~10 nodes common
• Large architecture plan → 15+ nodes — group by category in Phase 1 for readability

If only 1~2 nodes can be extracted, surface that to user in Phase 1: "얕은 plan — grill 가치 낮음, /cfh-plan 또는 직접 실행 권장".

Phase 1 — Decision tree enumeration

List the decisions (in dependency order — parent before child):

🌳 Decision tree (grill order)

1. <root decision>   ← unresolved   reason: <one-line why this matters for THIS plan>
2. <child A>         ← blocked by #1  reason: <one-line>
3. <child B>         ← blocked by #1  reason: <one-line>
   ↳ <grandchild>    ← blocked by #3  reason: <one-line>
4. <independent decision>  ← unresolved  reason: <one-line>

Excluded candidates (self-validation):
  - <candidate node> — <reason it doesn't apply to THIS plan>
  - <candidate node> — <e.g., "Q3 out-of-scope explicitly excluded performance">

Each in-tree node carries a one-line reason explaining why this decision matters for THIS plan. If the only reason is "template standard," exclude it.

Excluded candidates appear in their own section — self-validation must be transparent, not a black box. User can request re-inclusion ("actually do grill X") since decisions can be reversed.

Mark each in-tree node:

• ← unresolved (default)
• ← already decided in <Q3 / handoff block> (skip Phase 2 question)
• ← codebase-answerable (resolve via fact-check, not asking)

Show this tree to the user.

Default = grill every branch — but default activates only after explicit user confirmation. LLM must not self-apply default on silence or ambiguous response.

Required user response before Phase 2:

• "전체 walk" / "다 가자" / "yes 진행" → start full walk
• "Skip #3" / "#3·#4 제외" → exclude specified branches, then walk
• "OK" / Enter / "응" / brief response / silence → WAIT. These are ambiguous — user may be reviewing the tree. Do not interpret as consent.
• Do not progress until the user gives an unambiguous direction.

Optional pruning (only on explicit user statement): "Skip #3" → branch omitted, recorded in Phase 3 termination report as "user-excluded — verify later". Remaining branches still relentless.

Phase 2 — Sequential interrogation

Core principle: grill is about user intent, not current code state. Even if the codebase has an answer, the user may want something different for this plan. Always ask the user. Codebase is reference for recommendation rationale, never a substitute for the answer.

For each unresolved node, in tree order:

1. Ask the question with this template (do NOT skip asking because code has an answer):

❓ Q<n>: <single question, focused, ~1~2 sentences>

📌 추천: <your recommended answer>
   이유:
     - 🟢 [verified] <fact from code/Q>
     - 🟡 [inferred] <reasonable deduction>
     - 🔴 [guessed] <weak signal, needs user confirmation>

다른 옵션:
   - <option B> — when <condition>
   - <option C> — when <condition>

답변: yes / B / C / 다른 의견 / pass (보류)

Terminology (don't confuse with Phase 1 skip):

• Phase 1 skip = exclude branch from tree entirely
• Phase 2 pass = defer this node's answer (node stays unresolved, can be revisited)

2. One question. Stop. Wait. (turn boundary)
3. Update the tree based on the answer (next turn, after user replies):
   • Resolved nodes get a check mark
   • New sub-questions may appear (children unlock)
   • User-provided answers override your recommendation (record both, note divergence)
4. Move to the next unresolved node.

Recommendation rationale rules

• Cite specific signals, not generalities. "Q3 said no API change" beats "TDD is good".
• Use confidence markers ([verified]/[inferred]/[guessed]). At least one [verified] preferred — if none, say so.
• Limit length — 2~3 bullets max per recommendation. Don't write an essay.

Code is context, never the answer

Code may inform the rationale of your recommendation, but never the decision itself. The user always answers.

❓ Q3: 쿠폰 검증의 state 위치는?

📌 추천: zustand 사용
   이유:
     - 🟢 [verified] src/features/coupon/CouponInput.tsx:5에 useCouponStore 이미 사용 — 일관성
     - 🟡 [inferred] 다른 페이지에서도 쿠폰 상태 접근 가능성 → shared store 적합
   ⚠ 다만 이 plan은 새 진입점이라 사용자가 다른 선택 가능 — local state·server state·URL state 옵션 열려 있음.

다른 옵션:
  - local state — 단일 페이지·페이지 진입 시 리셋 의도일 때
  - server state (react-query) — 검증 결과 캐싱·재요청 최적화 필요할 때
  - URL state — share-able 검증 결과 (드물지만 가능)

답변: zustand / local / server / URL / 다른 의견

❌ 금지: "코드에 zustand 있으니 결정 #3: zustand로 자동 resolve, 다음 노드로" — 사용자에게 안 묻고 자동 결정 금지

Phase 3 — Convergence check

When the tree has no unresolved nodes (or user says "enough"):

✅ Grill 종료

해결된 결정 (N개):
  ✓ #1: <decision> → <answer>
  ✓ #2: <decision> → <answer>
  ...

미해결 — 사용자 판단 필요:
  ⚠ #N: <decision>
    이유: 정보 부족 또는 사용자 응답 보류

다음 단계 추천:
  📌 추천: <next concrete action — usually a delegation to /cfh-tdd, /cfh-refactor, etc.>
     이유: 모든 결정 트리가 해결됐고, <delegation target>이 다음 작업의 자연스러운 위임 대상.

If unresolved nodes block progress, recommend either:

• 추가 정보 수집 (사용자가 알아내야 할 것)
• 가정으로 진행 + 가정을 PROGRESS.md에 기록

• One question per turn. Never list 3 questions. Wait for the answer.
• Always include 추천 + 이유. "What do you think?" 없이 끝내지 말 것.
• User intent first. 결정은 항상 사용자에게 묻기. 코드는 현재 상태이지 미래 의도가 아님. 코드는 추천 이유의 컨텍스트로만 (선택적).
• Tree before questions. Phase 1에서 트리 보여주고 사용자가 가지치기할 기회 제공.
• Confidence markers. [verified]/[inferred]/[guessed] 사용 — 사용자가 어디를 압박할지 알 수 있게.
• Stop conditions. 트리 소진 / 사용자 "enough" / 미해결이 추측 영역으로 들어감 → 종료.
• Out of scope. 새 결정 트리 만들기는 안 함. 기존 plan/design을 깊이 파는 것에 집중. 새 plan은 /cfh-plan.
• No silent override. 사용자가 추천과 다른 답을 줘도 침묵하지 않음 — "B를 선택하셨군요. #5 (B에 의존)으로 진행" 명시.

<output_format>

질문은 자연스럽게, 결과 설명은 4축(Why·What·How·What if) 권장 (refactoring-strategy/references/reasoning-format.md 참조).

추천 형식은 commands/references/recommendation-pattern.md 단일 출처.

</output_format>

• commands/references/recommendation-pattern.md — 추천+이유 컨벤션
• commands/references/confidence-tagging.md — [verified]·[inferred]·[guessed] 마커
• commands/cfh-grill.md — 명시 호출 커맨드
• /cfh-plan — 새 plan을 만들 때 (grill은 기존 plan을 깊이 파는 도구)
• skills/grilling/references/decision-tree.md — 트리 walk 알고리즘 상세