Explain 스킬 워크플로우 — 병목 시점에 "제안"

설계·구현을 검토할 때 병목은 사람이다. 이 체인은 인지부채와 검토 시간을 줄이려고 있고, 필요한 시점에 에이전트가 먼저 제안하는 방식으로 쓴다. 자동 실행하지 않는다.

워크플로우 전체 그림

설계 논의 ──▶ /explain-design-html ──▶ ledger decide ──▶ /impl-pipeline ──▶ /review-desk
             (구현 전 설계 리뷰)        (결정 확정)      (무중단 슬라이스 구현)  (사후 슬라이스 검수)
                                                              │                    │
                                                    러닝 중 tier A 슬라이스는       └─ 이해 안 될 때
                                                    /explain-diff-html 을 미리 생성 ──▶ 즉석 생성

다이어그램

손으로 그린 Mermaid·HTML이 기본이다. 그림은 노드가 많고 경로가 교차해서 독자가 따라가 봐야 이해되는 경우에만 넣는다 — 산출물 하나당 1~2장.

전용 다이어그램 도구를 쓴다면 그 도구의 검증을 통과한 것만 싣는다. 검증 안 된 그림이 검증된 것처럼 읽히는 게 이 층의 최악의 실패다.

Playground — 퀴즈로는 안 잡히는 층

두 explain 스킬 모두 퀴즈 앞에 Playground 섹션을 갖는다. 퀴즈는 인출 연습이라 선언적 사실에는 강하지만 반사실적 이해로는 잘 전이되지 않고, 객관식을 맞히면 유창성 착각(이해 없이 확신만 오르는 상태)이 생긴다. Playground는 사용자가 직접 값을 바꾸고 결과를 관측해 그 층을 메운다. 순서가 중요하다 — Playground가 모델을 만들고, 퀴즈가 그 모델을 인출한다.

• 각 Playground는 충실도 배지(실제 로직 이식 / 실측 트레이스 / 근사 모델 / 구조 모델)를 상단에 달아야 한다. 근사 모델을 실제처럼 보이게 하는 것이 이 산출물이 만들 수 있는 최악의 결과다 — 틀린 확신을 제조하기 때문. 배지 없는 Playground는 만들지 않는다.
• 첫 상호작용 1회는 예측 게이트를 통과해야 한다(예측 → 관측 → 해설). 예측이 틀리는 지점이 인지부채가 있던 정확한 위치이므로, 뻔한 값이 아니라 판단이 갈릴 지점을 묻는다.
• 조작해도 결론이 안 바뀌는 위젯은 장식이다. 넣지 않는다. 인터랙티브가 최선일 때만 인터랙티브.
• 사용자가 익숙한 영역(본인이 설계했고 자주 건드린 모듈)이면 Playground를 생략하고 패턴 이탈점만 delta로 제시한다(숙련자 역전 효과).

적용 규칙 (How to apply)

• 자동 실행 금지, 제안만. 위 시점이 감지되면 "이 설계/변경은 복잡하니 /explain-* 로 이해 자료를 만들까요?"처럼 한 줄 제안하고 사용자 결정을 기다린다. 몰래 스킬을 돌리지 않는다.
• aid이지 gate가 아니다. 제안을 거절하거나 실패해도 원래 흐름(결정 원장/raw diff)으로 리뷰는 그대로 진행한다.
• 사소한 것엔 nag 금지. 보일러플레이트·한 줄 수정·단순 변경엔 제안하지 않는다. "리뷰가 버거울 만한" 복잡도일 때만.
• 같은 개념을 두 번 이상 되물으면 그 기술 자체를 따로 파보자고 제안한다. 그때가 "아직 모른다"의 신호다. 단발성 궁금증엔 제안하지 않는다.
• impl-pipeline은 Step 1(설계 로드)에서 explain-design-html을, Step 6(리뷰)에서 explain-diff-html을 이미 옵션으로 물고 있다 — 파이프라인 밖에서 개별 작업할 때 이 제안을 내가 챙긴다.

Why: 사용자가 스스로 병목이라 느끼는 지점이 바로 "설계 확정 판단"과 "큰 변경 검토"다. 그 순간에 이해 자료를 먼저 제안하면 검토 시간과 인지부채가 줄어든다. 단, 결정권은 사용자에게 있으니 제안에 그친다.