asis-tobe-decision

name

asis-tobe-decision

description

Present a decision or confirmation request in the user's four-part format: 전후맥락 (context) → 추천 + 이유 (recommendation) → UI/UX 형태 (a scannable table/option-list) → ASIS→TOBE contrast, led by the recommendation so the user can say yes fast. Fire at genuine A-or-B / approval / explicit-ASIS-TOBE moments. Triggers on the user's verbatim phrases "ASIS TOBE로 설명", "ASIS-TOBE로 알려줘", "화면으로 ASIS TOBE로 설명", "의사결정 / 컨펌 요청", "이거 진행할까요?", and the softer "다음 진행할 것들 알려줘"; English equivalents: "present this as ASIS/TOBE", "give me the as-is to-be", "should I do A or B", "ask for my approval", "lay out the options". Do NOT fire for pure information with no decision, or trivial reversible actions you would just do.

ASIS→TOBE Decision Presentation

A presentation format, not a heavy process. It fires at the moment you would otherwise ask "should I do this?" or "A or B?" and turns that question into a one-screen artifact the user can approve, question, or push back on in a single pass.

This codifies the user's standing rule in .claude/CLAUDE.md:

의사결정 및 컨펌 요청 시

1. 이해가 쉽도록 전후 맥락과 함께 상세하게 설명
2. 추천하는 제안과 그 이유를 설명
3. UI/UX 형태로 이해할 수 있도록 설명
4. ASIS TOBE 형태로 설명

The rule exists but does not reliably self-trigger — the user has had to demand it mid-task ("구체적으로 화면으로 ASIS TOBE로 설명", "다음 진행할 것들 ASIS-TOBE로 알려줘"). This skill makes it an active default so the user never has to ask.

When to use

Fire whenever you are about to:

• ask for approval before doing something ("이거 이렇게 진행할까요?")
• offer the user a choice between two or more approaches
• propose a change to architecture, config, scope, or plan
• recommend one option over others

Softer/secondary trigger: reporting "next steps" the user must sign off on ("다음 진행할 것들"). Use judgment — render it in this format when a real yes/no is needed.

Do not fire for pure information with no decision in it, or for trivial reversible actions you'd just do. This is for moments where a human "yes / no / which one" is genuinely needed.

The four slots (= the four CLAUDE.md items)

The four slots map 1:1 to the user's rule. Cover all four, but lead with the recommendation — readers decide off the conclusion, so put it up top even though it is item 2 in the list. Everything after it is there to justify and let the user react to one specific cell.

추천 + 이유   (item 2)  ← lead here: the recommendation and the explicit ask
전후맥락       (item 1)  ← context: the forces that make this decision necessary now
UI/UX 형태     (item 3)  ← one scannable table / option-list, never prose
ASIS→TOBE     (item 4)  ← current → proposed contrast, gap made concrete

추천 + 이유 (item 2) — lead with this

State the recommendation as a concrete commitment in active voice: "I'll switch X to Y" — not "we could consider maybe looking at Y." Hedged language signals low confidence and pushes the user back into doing the analysis themselves. Give the short why (a line or two), then the explicit ask: "Approve A, or pick B?" A proposal with no actual ask leaves the loop open and guarantees another round.

전후맥락 (item 1) — context

The forces at play in plain language — the technical, product, or constraint pressure that makes this decision necessary now. Keep it to what the user needs to judge the call; without it a reader either blindly accepts or blindly rejects.

UI/UX 형태 (item 3) — show it, don't narrate it

Render the choice as one scannable table or option list, never a wall of prose — this is the "UI/UX 형태로 이해할 수 있도록" item. Aligned columns the user can scan vertically; pre-answer the obvious objection inline ("왜 B가 아닌가") so they don't have to ask. When it's "which of these?", an option-comparison table fits; when it's "move from current to proposed?", use the ASIS→TOBE shape below.

ASIS→TOBE (item 4) — make the gap concrete

Columns: 항목 / ASIS (현재) / TOBE (제안) / Gap. Quantify the gap with a metric or cost — an unquantified gap ("느림 → 빨라짐") is rhetoric, not a basis for deciding. List trade-offs honestly, including the downside of the recommended option; hidden downsides surface later as distrust (a no-false-ship violation). You can close with a one-line tail of what happens on approval ("승인 시 → …") — keep it to the ask, not a separate required slot.

Worked example

Input (what you're tempted to send): "The compat checker re-validates every asset on each run and it's gotten slow. I could cache results. Want me to?"

Output (the format):

추천 + 이유: gen-compatibility 의 검증 결과를 콘텐츠 해시 기준으로 캐싱하도록 바꾸겠습니다 — 변경분만 재검증해 시간을 가장 크게 줄이고 CI 코어 변동에도 안정적이라. 승인해 주세요 — 아니면 B(캐시 없이 병렬화만)도 가능합니다.

전후맥락: 자산이 52개로 늘면서 매 실행마다 전 자산 재검증 → CI gen-compat 스텝이 느려짐. 자산 내용은 거의 안 바뀌는데 매번 풀 재검증하는 게 병목.

항목	ASIS (현재)	TOBE (제안: 해시 캐싱)	Gap
전체 검증 시간	~140s (52자산 전수)	~12s (변경분만)	-128s / 실행
캐시 미스 시	—	풀 재검증 폴백	정확성 손실 0
추가 코드	없음	캐시 read/write + 무효화 (~40줄)	유지보수 +α
트레이드오프	—	해시 충돌 시 stale 위험	무효화 키 = 파일내용 해시로 차단

왜 B(병렬화만)가 아닌가: 병렬화는 시간을 ~3배만 줄이고(약 45s) 코어 수에 의존 — 캐싱이 변경분만 검증해 더 크게(11배) 줄이고 CI 코어 변동에도 안정적이라 A 추천.

승인 시 → feature 브랜치에서 캐시 레이어 + 무효화 테스트 추가 → 로컬 npm run ci 통과 → PR.

Notice: the user can say "go" after the first two lines, or push back on exactly one cell of the table. No essay, no buried recommendation, no hidden downside.

Common failure modes to avoid

• Hedged recommendation ("고려해볼 수 있습니다") — forces the user to do the analysis. State a commitment.
• Recommendation buried under option analysis — lead with the lead option.
• Context but no ask — leaves the loop open. Always end the 추천 with the ask.
• Prose instead of a table — skips the "UI/UX 형태" item. Show it scannable.
• Unquantified ASIS→TOBE gap — rhetoric, not a decision basis. Attach a metric or cost.
• Suppressed downsides to make the proposal look cleaner — surfaces later as distrust (and a no-false-ship violation). List trade-offs.

왜 통하나 (근거, 선택적)

Light support if you want to defend the format — not part of the body:

• Lead with the recommendation: BLUF (Bottom Line Up Front) — readers decide off the conclusion, so the ask goes first even though it's item 2.
• Keep supporting reasons few (~3), one scannable table: executive-decision-slide and working-memory (~7±2) guidance — more dilutes and pushes the reader back into analysis-mode.
• Quantify the gap, list all consequences: As-Is/To-Be gap analysis + ADR (Nygard) — an unquantified or one-sided gap isn't a basis for deciding.
• Pre-answer the objection inline: Amazon Working Backwards PR/FAQ — collapses the back-and-forth into one round.
• Contested call? score on explicit criteria: RICE (Intercom) — a small scoring table is more defensible than prose advocacy.

Related skills

A cross-cutting presentation discipline, not a workflow. Sibling skills that produce findings or choices should render them in this format:

• gap-analysis-e2e — its gap output maps directly onto the ASIS→TOBE table.
• ultracode-service-audit — present audit findings and remediation choices as ASIS→TOBE.