clear-korean-communicationlisted

Make a technical explanation land, and turn the decision at the end of it into something the reader can approve in one pass. Two halves of one job: (1) EXPLAIN — fix the referent first (one name often points at two things), lead with who is affected and what changes, put file paths and symbols after the claim as evidence; (2) DECIDE — present approval/choice moments 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. Run it whenever you explain a bug, a cause, or what your change did — especially the moment the reader says they don't follow ("뭔 소리야", "쉽게 설명해줘", "이해가 안 돼", "I don't follow", "in plain terms"), or when your draft opens with a file path or symbol name — and whenever you are about to ask "should I do this?". Triggers on the user's verbatim phrases "ASIS TOBE로 설명", "ASIS-TOBE로 알려줘", "화면으로 ASIS TOBE로 설명", "의사결정 / 컨펌 요청", "이거 진행할까요?", the softer "다음 진행할 것들 알려줘"
uzysjung/uzys-agent-harness · ★ 3 · Code & Development · score 67

Install: claude install-skill uzysjung/uzys-agent-harness

# Clear Korean Communication A **repair-and-prevent discipline** for the moment your explanation does not land, plus the **presentation format** for the decision it usually ends in. Not a style guide — a short diagnostic you run before (and after) explaining something technical to someone who has not read the code. Part 1 (Explain) gets the reader to *understand*. Part 2 (Decide) gets them to *choose*. Most real messages need Part 1; only genuine approval moments need Part 2. ## Why this exists (and why format alone won't save you) A correct, well-formatted explanation can still fail completely. Observed case: an agent explained a bug in the required ASIS→TOBE decision format — tables, before/after, quantified gap — and the reader replied **"뭔 소린지 모르겠다"**. The second attempt was explicitly rewritten "from the user's perspective" and failed *again*. What actually fixed it was one drawing that separated two things that shared a name. The lesson: **when an explanation fails, the usual suspect is not tone, length, or format. It is that the reader cannot tell what you are talking about.** Reaching for a nicer format first is why the second attempt fails too. ## Sort the facts before you write Split the input into these four buckets and never mix them in one sentence: 1. **관찰된 출력 문제** — what you actually saw in a response, log, screen, or test run. 2. **반복되는 실패 패턴** — the same shape confirmed across several cases. 3. **원인 가설** — explains the symptom but is not yet verified.