@uzysjung/agent-harness 26.152.0 → 26.153.0

package/templates/skills/audit-harness-fit/references/verification.md

@@ -1,123 +1,154 @@
-# User Journeys, Verification, and Model Delegation
+# User Journeys, Verification, and Execution Routes
 
 ## Contents
 
 - [Start from the usage scene](#start-from-the-usage-scene)
 - [Choose sufficient evidence](#choose-sufficient-evidence)
-- [Bundle verification by completed scene](#bundle-verification-by-completed-scene)
+- [Choose timing and change boundaries](#choose-timing-and-change-boundaries)
 - [Reuse evidence with explicit invalidation](#reuse-evidence-with-explicit-invalidation)
-- [Delegate only when the judgment warrants it](#delegate-only-when-the-judgment-warrants-it)
+- [Choose a suitable execution route](#choose-a-suitable-execution-route)
 - [Demonstrate improvement honestly](#demonstrate-improvement-honestly)
 
 ## Start from the usage scene
 
 Use confirmed requirements and accessible product evidence to identify **actor,
-precondition, action/input, observable outcome, and consequential failure/recovery**.
-Actors can be end users, operators, API consumers, or scheduled jobs. An assumption
-about a persona or goal remains an assumption, not a requirement inferred from code.
-
-Propose the smallest working end-to-end implementation slice for the requested
-outcome. A visible screen is not complete when its required persistence, retrieval,
-authorization, or error recovery is absent. Extend only with requested capabilities.
-This skill proposes how to implement and verify; it does not change product code.
+precondition, action/input, observable outcome, and consequential failure/recovery**
+where relevant to the change. Actors include end users, operators, API consumers,
+and scheduled jobs. Reuse established context; keep assumed goals distinct from
+accepted requirements. An isolated contract change can use its existing contract
+without reopening the whole product brief.
+
+Propose the smallest coherent implementation slice that delivers the requested
+outcome. Required persistence, retrieval, authorization, and recovery belong in
+that slice even when the visible screen already works. Choose boundaries that
+support useful feedback and manageable risk; extend only with requested capabilities.
+This skill proposes implementation and verification guidance, not product-code edits.
 
 ## Choose sufficient evidence
 
-Map each affected scene or critical contract to a check and an observable pass
-condition. Reuse existing coverage. A compact form is:
+Map each affected scene or critical contract to an observable pass condition and
+sufficient evidence. Reuse existing coverage. A compact form, when useful, is:
 
-| Scene / contract | Observable pass condition | Existing check or proposed check | Required or optional; execution / review owner |
+| Scene / contract | Observable pass condition | Existing or proposed evidence | Required gate / optional check; owner where relevant |
 |---|---|---|---|
 
-Choose the narrowest reliable level: unit for isolated logic, integration for real
-boundaries, and E2E for journeys requiring whole-path evidence. A slice being end-to-end
-does not mean every test must be E2E. Avoid testing every private function, arbitrary
-coverage targets, duplicate layers that prove nothing new, and running the entire
-suite after each edit solely because a prompt demands it.
-
-For example, saving a record and later retrieving it may need persistence integration
-coverage and one representative UI journey; validation edge cases can stay at unit
-level. This is an example, not a fixed test prescription for every product.
-
-Scale optional checks with impact, affected dependencies, uncertainty, and reversibility.
-Include credible negative/recovery paths and non-visible contracts such as authorization,
-data integrity, payments, concurrency, migration, and interoperability when affected.
-Happy-path screenshots do not establish those contracts. Avoid expanding to every
-hypothetical edge case unrelated to the change.
-
-Required tests and independent-review gates remain binding. Identify their policy /
-CI source: an explicit project test policy can be mandatory even without CI enforcement.
-Distinguish those gates from generic requests to "think again"; if their status is
-unclear, retain them pending a policy decision. When a required gate seems
-disproportionate, propose a separate policy decision;
-do not disable it, lower its threshold, or relabel it to make cleanup succeed.
-Document checks are sufficient for document-only effects unless applicable policy
-or actual dependencies require broader checks. State checks not run and why.
-
-## Bundle verification by completed scene
-
-Implementation and verification follow the scene, not the edit. While a scene is being
-built, run only the quick checks for the parts being changed — except when a scene first
-crosses an unproven external boundary, which is checked then. When the scene's changes are
-complete, bundle them and verify once from usage: the scene's observable outcome, its
-integration boundaries, the non-visible contracts it touches, and one representative
-journey. Re-verify the parts a later change affects, plus anything the reuse rules below
-require a new run for; when the affected scope cannot be established confidently, widen the
-bundle check instead of narrowing it. Treat instructions that force a
-full run or an independent review after every edit as a finding under the audit area on
-user-journey implementation and proportionate testing — they cost development speed without
-adding evidence — unless a required gate names that cadence explicitly.
-
-Bundling is not deferral. A scene is one actor reaching one observable outcome; when its
-changes outgrow what one review can hold, split it into smaller scenes rather than
-verifying later, and do not start the next scene on top of an unverified one. Keep each
-change committed on its own so a failed bundle bisects to the change that broke it, and
-keep merge and deployment gates where they are — a scene is verified before it crosses
-either. The non-visible contracts listed above — money and payments, permissions, data and
-its migrations, and any irreversible operation among them — are **separate verification
-targets**: they get their own independent check before merge regardless of how the scene is
-bundled, and a representative journey passing does not stand in for them.
+Choose the reliable level or combination with the lowest reasonable total burden:
+unit checks for isolated logic, integration for real boundaries, and E2E when a
+whole-path claim needs evidence. Include setup, selection, execution, diagnosis,
+and maintenance effort. A fast, reliable full suite can be simpler than elaborate
+selection. A user-facing slice does not require every assertion to be E2E.
+
+For example, saving and retrieving a record may use persistence integration coverage
+and a representative UI journey, with input validation at unit level. This is an
+illustration, not a universal test prescription. Target changed behavior, credible
+failure/recovery paths, and affected dependencies rather than every private function,
+a coverage quota, or unrelated hypothetical edge case.
+
+Treat consequential contracts such as authorization, payments, integrity, concurrency,
+migration, and interoperability as explicit verification targets when affected.
+Each needs evidence adequate to its claim; a happy-path screenshot alone cannot
+establish these properties. One test or execution can cover several contracts when
+its assertions and conditions actually support each. Separate targets do not by
+themselves require separate runs or separate reviewers. Add checks for evidence gaps,
+credible risk, or applicable policy; required review independence is a separate issue.
+
+Identify binding tests and independent-review gates from their policy / CI source.
+Explicit project policy can bind even without CI enforcement. Preserve those gates;
+route disproportionate mandatory requirements to a separate policy decision. Retain
+an unclear gate pending clarification while continuing work independent of it.
+Generic requests to "think again" are assessed for evidence value, not presumed gates.
+Document-only effects normally need document checks unless policy or dependencies
+require more. State checks not run and the resulting limits.
+
+## Choose timing and change boundaries
+
+Choose verification timing and batch size for useful feedback, uncertainty, impact,
+and recoverability. Resolve costly assumptions and unproven boundaries early enough
+to avoid building substantial work on an unsupported contract. Run quick local checks,
+incremental tests, or a broader bundle when they offer the best feedback for the task.
+Use existing tools and evidence before introducing new process overhead.
+
+Work may proceed in parallel when it is isolated or relies on sufficiently established
+contracts. Make consequential unverified assumptions visible and contain their impact.
+As a change grows beyond reliable review or recovery, split it or verify the uncertain
+boundary sooner. Complete the evidence required for acceptance and applicable merge /
+release gates before crossing those boundaries.
+
+Organize edits into coherent, reviewable, recoverable units. Follow the project's
+commit policy and actual authorization; logical change boundaries are not a command
+to commit each edit. Existing diffs, checkpoints, or version history can support
+recovery where appropriate. Commit and push actions remain outside this cleanup.
+
+Assess a prescribed cadence by the evidence it adds and its total cost. Checking a
+changed state can be useful even after a small edit; repeating a check with unchanged
+relevant conditions may add nothing. Per-edit full suites, continuous checks, batched
+verification, and targeted runs can each be suitable. Retain explicitly required
+cadence and propose policy changes separately. Choose a method instead of replacing
+one universal schedule with another.
 
 ## Reuse evidence with explicit invalidation
 
-Use existing logs or results to identify what was checked, the affected source state,
-inputs/dependencies, relevant environment, and result. Add only missing material
-provenance; do not require a new fingerprinting or evidence-management framework.
-A result is reusable when those relevant conditions and its coverage still hold.
-
-Recheck the affected scope when code, configuration, dependencies, meaningful inputs,
-environment, or acceptance criteria change; when evidence does not cover the contract;
-when a failure or credible nondeterminism remains; or when policy requires a new run.
-Do not rerun unaffected optional checks merely because time passed, another reviewer
-arrived, or a response is about to be sent. A stale result cannot certify a new diff.
-Stop optional verification when acceptance conditions have sufficient evidence and
-there is no relevant unresolved failure or risk. Do not claim all work safe forever.
-
-## Delegate only when the judgment warrants it
-
-Propose or use a more capable available model for a difficult design trade-off,
-a blocked diagnosis, or high-impact journey review when likely to improve the answer.
-Prefer the existing routing policy and actual environment. Routine implementation /
-checks stay with the current agent; a model's label, price, or recency is not evidence
-that it is better at the task. Do not prescribe an unverified model name or CLI flag.
-
-Before actually delegating, confirm the tool/model exists and the data sharing,
-permission, and cost boundaries permit it. A read-only audit may propose delegation
-without making a new external call. Send a bounded question with the scene, constraints,
-diff / necessary evidence, acceptance criteria, uncertainty, and requested review output.
-Ask for the specific decision or missing test, not a repeated open-ended "check everything".
-
-Model judgment complements executable evidence, never substitutes for it. Keep author
-and reviewer independent where required; changing a model label in the author's own
-self-review is not independent review. Do not introduce a new universal review gate.
-If no suitable model/reviewer is available, disclose that fact, use a permitted human
-or other route where available, and leave required review pending. Continue work that
-does not depend on the unmet gate. Never claim delegation happened when it did not.
+Use existing results to establish what was checked, relevant source state, inputs /
+dependencies, environment, and result. Add missing material provenance only. Existing
+records are sufficient when they support that determination; a new evidence-management
+or fingerprinting framework is not a prerequisite.
+
+Reuse a result when its coverage and relevant conditions still hold. Reassess and
+recheck affected scope when code, configuration, dependencies, meaningful inputs,
+environment, or acceptance criteria change; coverage is insufficient; a failure or
+credible nondeterminism remains; or policy requires a new run. A changed dependency
+can invalidate evidence beyond the edited file. When impact is uncertain, widen the
+check enough to address that uncertainty.
+
+Reuse unaffected optional results when another reviewer arrives, a response is due,
+or time passes without a relevant validity limit. Time-sensitive credentials, data,
+or environment guarantees may themselves expire. Finish optional verification when
+acceptance conditions have sufficient evidence and remaining uncertainty is within
+accepted risk boundaries. Report residual uncertainty; a past pass does not certify
+a new state.
+
+## Choose a suitable execution route
+
+Reuse the established routing policy and current route by default. Change routes
+when task-specific evidence supports a better quality / effort trade-off. Options
+can include an existing deterministic tool, the current agent, a specialist, a
+lower-cost capable model, a more capable model, or an authorized human reviewer.
+Routine tasks need no repeated model comparison.
+
+Consider expected answer quality, reliability, latency, total cost, context-transfer
+and review effort, data boundaries, and required independence. Delegate when the
+likely benefit justifies the handoff. A model's name, price, or recency alone does
+not establish task fitness; use configured capabilities and relevant observations.
+
+Before an actual call, establish that the tool / model exists and applicable data,
+permission, and cost boundaries permit it. Reuse valid configuration and approvals.
+A read-only audit can propose a route without invoking it. Send a bounded question
+with the scene or contract, constraints, necessary evidence, uncertainty, acceptance
+criteria, and requested decision. Minimize sensitive context and unnecessary repetition.
+
+Model judgment complements executable evidence. Do not present an opinion as a test
+result, self-review as required independent review, or a proposed handoff as executed.
+Where independence is required, use a genuinely separate permitted reviewer/process;
+a different model label alone does not supply it. Keep required review pending when
+no suitable route is available, identify an allowed alternative, and continue work
+that does not depend on the unmet gate. This guidance adds no universal review gate.
 
 ## Demonstrate improvement honestly
 
-For an uncertain simplification, propose a small representative comparison only if
-needed: did the agent complete the same scene with fewer avoidable questions/checks
-while retaining acceptance evidence and safeguards? Reuse existing observations.
-Label expected benefits as hypotheses until observed; byte counts and model agreement
-are not behavioral validation. Do not make every guidance edit wait for an experiment.
+Distinguish a well-supported guidance proposal from observed improvement in delivery.
+Structural validity, fewer words, fewer tool calls, and model agreement do not by
+themselves prove better outcomes. Use existing observations first; select a small
+representative comparison only when it can resolve a material uncertainty.
+
+For an authorized comparison, hold the accepted outcome, quality criteria, and
+safeguards constant. Compare completion and relevant regressions first, then useful
+available measures of elapsed work, cost, avoidable questions, and rework. A method
+can improve efficiency at retained quality or improve quality within the permitted
+budget. Evidence lost from an affected critical contract is not an efficiency gain.
+
+Account for task difficulty, model/tool configuration, and repeated-task familiarity
+when interpreting a result. Report what was observed and its limits; a successful
+case supports its tested scope, not universal superiority. Restore or revise a trial
+that misses acceptance criteria, increases material risk, or loses its expected value.
+[Apply](apply.md) governs authorization and adoption. Clear supported edits can proceed
+without an experiment; comparisons stay bounded to decisions that need them.

package/templates/skills/clear-korean-communication/SKILL.md

@@ -1,251 +1,118 @@
 ---
 name: clear-korean-communication
 description: >-
-  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 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) → 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") — and whenever you are about to ask "should I do
-  this?" ("ASIS TOBE로 설명", "이거 진행할까요?", "should I do A or B"). Do NOT fire
-  for pure information with no decision in it, for trivial reversible actions you
-  would just do, or for context-free word/sentence translation — that is ordinary
-  translation.
+  기술 설명과 선택·승인 요청을 사용자 관점의 한국어로 정리한다.
+  맥락, 문제와 발생 원인, 해결방안과 이유, 추천방안과 이유를 표로 제시한다.
+  사용자가 "뭔 소리야", "쉽게 설명해줘", "왜 문제야",
+  "선택지와 추천을 정리해줘"라고 하거나 중요한 선택·승인이 필요할 때 사용한다.
+  /clear-korean-communication만 호출하면 현재 대화의 미해결 문제나
+  직전 선택 요청을 기본 표로 정리한다.
 ---
 
 # 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.
-4. **아직 검증할 수 없는 항목** — model internals, unmeasured effects, long-session
-   claims you have no operating log for.
+직접 호출하면 사용자가 별도 형식을 지정하지 않는 한 아래 기본 표로 답한다.
 
-One case is not a general cause. Mark an unverified cause as a hypothesis and say
-how it could be checked. Do not present a guess as evidence.
+중요한 선택이나 승인을 사용자에게 요청할 때도 이 형식을 사용한다. 직접 호출하지 않은 단순 정보 전달이나 완료 보고에는 불필요하게 적용하지 않는다.
 
----
+사용자가 별도 형식을 지정하면 그 형식을 따르되, 판단에 필요한 **맥락·원인·대안·추천 이유**는 유지한다.
 
-# Part 1 — Explain
+## 설명 원칙
 
-## Step 1 — Fix the referent (do this before anything else)
+### 1. 사용자 관점에서 설명한다
 
-Ask: *does any name in my explanation point at more than one thing?*
+파일·함수·오류명보다 먼저 다음을 연결한다.
 
-This is the dominant failure. Codebases are full of names that legitimately
-denote two different objects — and the writer, who holds both in their head,
-never notices the collision:
+**사용자가 하려는 일 → 현재 상태 → 문제 또는 제약 → 발생 원인 → 실제 영향**
 
-| Collision shape | Example |
-|---|---|
-| Same path, two locations | `.claude/` in *this* repo vs `.claude/` in an *installed user's* project |
-| Same word, two layers | "config" = the file on disk vs the parsed object |
-| Same name, two lifecycles | "the build" = CI job vs local artifact |
-| Same entity, two roles | "user" = the human here vs a row in the DB |
+버그가 아니라 설계 선택, 요구사항 충돌, 환경 제약이라면 그대로 설명한다.
 
-If you find one: **separate and name them before explaining anything else**, and
-prefer a small diagram over prose — prose forces the reader to hold the split in
-working memory while you keep talking.
+같은 이름이 서로 다른 대상·위치·단계를 가리키면 먼저 구분하고, 실제 영향을 받는 사람을 기준으로 설명한다.
 
-```
-① this repo (where we develop)     ② the user's project (where it gets installed)
-   templates/skills/  ──npm──▶        .claude/skills/
-```
+기술 정보는 판단에 필요한 만큼만 사용하고, 낯선 용어는 해당 맥락에서 이해할 수 있게 풀어 쓴다.
 
-If nothing collides, say so to yourself and move on — do not manufacture a
-diagram you don't need.
+### 2. 사실·가설·판단을 구분한다
 
-## Step 2 — Lead with one sentence: who, and what changes
+확인된 사실과 원인, 아직 확인되지 않은 가설, 추천 판단을 섞지 않는다.
 
-Before any table, write **one sentence** naming the affected party and the
-concrete change:
+원인이 확인되지 않았다면 원인을 단정하지 말고 다음을 구분한다.
 
-> "Skills installed in someone's project never update, no matter how many times
-> they run update."
+- 확인된 현상과 영향
+- 가능한 원인 또는 가설
+- 방향을 결정하기 위해 추가로 확인할 사항
 
-Test it: could the reader repeat that sentence back after reading it once? If it
-needs a second clause to make sense, it is not the lead sentence yet.
+수치·비용·일정·효과는 근거가 있을 때만 사용한다. 추정치는 가정을 밝히고, 표를 채우기 위해 수치나 대안을 만들지 않는다.
 
-Bad leads, all real patterns:
-- opens with a coordinate — *"`update-mode.ts:53-78` の targets array…"*
-- opens with mechanism — *"the render loop iterates `updated` keys, so…"*
-- opens with what **you** did rather than what **changed** — *"I added a sha256
-  baseline to the install log."*
+### 3. 실제 선택 차이를 설명한다
 
-Coordinates and mechanism are **evidence**. They belong after the claim, never
-in front of it — to a reader who has not opened the file, `foo.ts:53` carries no
-meaning at all.
+선택지는 개수를 맞추지 말고 실제 선택할 가치가 있는 것만 제시한다. 현상 유지나 보류도 의미 있는 선택이면 포함한다.
 
-Name the role that is actually affected (최종 사용자 / 운영자 / 개발자 / 리뷰어 /
-보안 담당자 / 의사결정자). If the end user's screen does not change, do not invent
-an end-user benefit — say who really benefits instead.
+각 방안은 다음 차이가 드러나게 설명한다.
 
-## Step 3 — Then escalate, in this order
+**무엇을 하는가 → 왜 해결되는가 → 무엇이 달라지는가 → 어떤 부담이나 위험이 있는가**
 
-Each rung only if the previous one left a real gap:
+비용, 일정, 품질, 사용성, 안전성, 운영 부담 등 실제 결정을 바꾸는 기준에 집중한다.
 
-1. **One sentence** — who is affected, what changes.
-2. **Contrast** — before vs after, or expected vs actual. A table if there are
-   ≥3 dimensions; a two-line before/after if fewer. (If this is an approval
-   moment, switch to Part 2 — that is where the decision format lives.)
-3. **Evidence** — `file:line`, test output, measured numbers. This is where
-   precision lives, and where it stops costing comprehension.
+### 4. 추천은 명확하게 한다
 
-Stop as soon as the reader has what they need. Rungs 2 and 3 are not obligations.
+사용자의 목적과 현재 제약을 기준으로 가장 적합한 방안을 추천한다.
 
-Separate 이득 / 손실 / 위험, and separate 측정값 from 추정값. If it was not
-measured, write "미측정" or "감소가 예상되지만 확인되지 않음" — never a number
-invented to fill a cell.
+추천에는 다음을 포함한다.
 
-## Step 4 — When they say they don't follow: diagnose, don't rewrite
+- 추천하는 이유
+- 다른 방안보다 적합한 이유
+- 감수해야 할 주요 단점
+- 추천을 바꿀 수 있는 중요한 미확인 조건
 
-The instinct is to rewrite the same content in a softer voice. That reproduces
-the same defect with different words — the second failure in the observed case.
-Instead, ask which of these is missing, in order:
+추천은 판단이지 확인된 사실처럼 표현하지 않는다.
 
-| Symptom in their reply | Likely cause | Fix |
-|---|---|---|
-| "is this X or Y?" | **referent collision** | Step 1 — separate and name |
-| "so what?" / "and?" | no stated consequence | Step 2 — who is affected |
-| "why does that happen?" | jumped to fix, skipped cause | one causal sentence |
-| repeats your term back with a "?" | unexplained jargon | define once, in their words |
+## 기본 출력
 
-Their question is the diagnostic. **Read what they actually asked** rather than
-assuming the explanation was merely too long. In the observed case the reader's
-question — *"is this about installing, or about the project directory?"* — named
-the defect exactly, and the fix took three lines.
+표 앞에서 핵심 문제 또는 지금 필요한 판단을 한 문장으로 정리한다.
 
----
+| 항목 | 내용 |
+|---|---|
+| **맥락** | 사용자가 하려는 일, 기대 결과, 현재 상태와 이 문제가 나온 배경 |
+| **문제점** | 무엇이 문제인지, 왜 발생했는지, 누구에게 어떤 영향이 있는지 |
+| **해결방안** | 실제 가능한 방안과 각각의 해결 원리, 장점·부담 |
+| **추천방안** | 추천안과 이유, 주요 단점, 필요한 다음 행동 |
+
+선택지 비교가 복잡하면 **해결방안만 별도 비교표로 분리**한다.
+
+ASIS → TOBE는 변경 전후 비교가 판단에 도움이 될 때만 추가한다. 기본 네 항목을 대신하지 않는다.
+
+문제가 없거나 조치가 필요 없다면 억지로 해결책을 만들지 말고 그 사실과 이유를 설명한다.
+
+## 질문과 승인
+
+질문·승인 여부는 기존 프로젝트 정책과 사용자 위임 범위를 따른다. 그 안에서 사용자 결정이 필요한 미해결 사항만 질문한다.
+
+이미 위임받은 판단은 합리적인 방안을 선택해 처리하고 이유를 설명한다.
+
+질문이 필요하다면 단순히 "어떻게 할까요?"라고 묻지 말고 다음이 드러나게 한다.
+
+**무엇을 결정해야 하는지, 선택지의 차이가 무엇인지, 무엇을 추천하는지**
+
+설명이나 재정리 요청에 `진행할까요?` 같은 불필요한 실행 승인을 덧붙이지 않는다.
+
+## 품질 기준
+
+최종 답변만 읽어도 사용자가 다음을 설명할 수 있어야 한다.
+
+**맥락 → 문제와 원인 → 선택지의 차이 → 추천과 그 이유**
 
-# Part 2 — Decide
-
-Fire this half 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 ("다음
-진행할 것들"). Do **not** fire for pure information with no decision in it, or for
-trivial reversible actions you'd just do.
-
-## The four slots
-
-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 user's rule.
-
-```
-추천 + 이유   (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
-```
-
-- **추천 + 이유** — state it as a **concrete commitment in active voice** ("I'll
-  switch X to Y"), not "we could consider maybe looking at Y". 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.
-- **전후맥락** — the forces at play in plain language: the technical, product, or
-  constraint pressure that makes this decision necessary *now*. Without it a
-  reader either blindly accepts or blindly rejects.
-- **UI/UX 형태** — one scannable table or option list, **never a wall of prose**.
-  Aligned columns the reader can scan vertically; pre-answer the obvious
-  objection inline ("왜 B가 아닌가") so they don't have to ask.
-- **ASIS→TOBE** — 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. Close with
-  a one-line tail of what happens on approval ("승인 시 → …").
-
-## Don't over-fire the table
-
-ASIS→TOBE or a comparison table earns its space only when at least one holds:
-
-- 현재 상태와 변경 후 상태를 비교해야 한다.
-- 실제 선택이나 승인이 필요하다.
-- 비용·일정·범위·위험 또는 동작 차이가 있다.
-- 항목을 정렬하면 판단이 실제로 쉬워진다.
-
-단순한 버그 원인, 간단한 테스트 결과, 완료 여부, 선택지가 없는 작업 보고, 한두
-문장으로 충분한 답변에는 쓰지 마라. A table around a one-sentence answer is noise,
-and it is the most common way this skill gets misused.
-
-## Common failure modes to avoid
-
-- **Reaching for a nicer format first.** Format is rung 2; referent is rung 0.
-- **"Let me redo it from the user's perspective"** as a reflex. Perspective does
-  not fix referent ambiguity — it just re-narrates the same confusion.
-- **Leading with a coordinate.** `file:line` is proof, not an opening.
-- **Explaining your work instead of their change.** "I added X" is a changelog
-  entry; "your Y now does Z" is an explanation.
-- **Over-simplifying into vagueness.** Plain ≠ imprecise. Keep the exact numbers
-  and paths — just put them after the claim.
-- **Manufacturing a diagram when nothing collides.** Cost with no benefit.
-- **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** at a real decision — skips the "UI/UX 형태" item.
-- **Unquantified ASIS→TOBE gap** — rhetoric, not a decision basis.
-- **Suppressed downsides** to make the proposal look cleaner — surfaces later as
-  distrust. List trade-offs.
-
-## Before you send
-
-Run the pre-send checklist in
-[references/pre-send-checklist.md](references/pre-send-checklist.md) — 14 checks,
-one pass, fix and re-check. Never append "검수했습니다" to the answer itself.
-
-## References (read on demand, not by default)
-
-- [references/worked-examples.md](references/worked-examples.md) — the two full
-  before→after walkthroughs: a failing explanation repaired by the Step 1–4
-  diagnostic, and a complete four-slot decision with a quantified ASIS→TOBE table.
-- [references/pre-send-checklist.md](references/pre-send-checklist.md) — the 14
-  self-checks to run before sending.
-- [references/why-it-works.md](references/why-it-works.md) — the named frameworks
-  behind each rule (BLUF, RICE, Working Backwards PR/FAQ, ADR, working-memory
-  limits). Optional: read it when you have to defend the format, not to apply it.
-
-## Related skills
-
-A cross-cutting **communication discipline**, not a workflow. Sibling skills that
-produce findings or choices should render them through this one:
-
-- `audit-service-gaps` — its gap output maps directly onto the ASIS→TOBE table.
-- `recurrence-prevention` — when a *misexplanation* keeps recurring, that ladder
-  decides whether it becomes a note, a rule, or a gate.
-- `multi-persona-review` — panel findings are input to Part 2, not a substitute
-  for the recommendation you owe the user.
-
-This skill stops at understanding and the ask. Executing the approved change is
-someone else's job.
+같은 내용을 도입·표·결론에서 반복하지 않는다.