@uzysjung/agent-harness 26.154.0 → 26.156.0

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

@@ -1,118 +0,0 @@
----
-name: clear-korean-communication
-description: >-
-  기술 설명과 선택·승인 요청을 사용자 관점의 한국어로 정리한다.
-  맥락, 문제와 발생 원인, 해결방안과 이유, 추천방안과 이유를 표로 제시한다.
-  사용자가 "뭔 소리야", "쉽게 설명해줘", "왜 문제야",
-  "선택지와 추천을 정리해줘"라고 하거나 중요한 선택·승인이 필요할 때 사용한다.
-  /clear-korean-communication만 호출하면 현재 대화의 미해결 문제나
-  직전 선택 요청을 기본 표로 정리한다.
----
-
-# Clear Korean Communication
-
-사용자가 앞선 대화나 코드를 다시 읽지 않아도 다음을 판단할 수 있게 설명한다.
-
-**무슨 상황인지 → 무엇이 왜 문제인지 → 어떤 선택지가 있는지 → 무엇을 추천하며 왜 그런지**
-
-설명과 의사결정을 돕는 스킬이며 작업 범위나 승인 정책 자체를 변경하지 않는다.
-
-## 적용
-
-직접 호출되면 현재 대화에서 다음 순서로 대상을 찾는다.
-
-**사용자가 지정한 주제 → 미해결 문제·직전 선택 요청 → 직전 설명**
-
-대화에서 대상을 알 수 있으면 다시 묻지 않는다. 설명할 대상 자체가 없을 때만 원문이나 주제를 요청한다.
-
-직접 호출하면 사용자가 별도 형식을 지정하지 않는 한 아래 기본 표로 답한다.
-
-중요한 선택이나 승인을 사용자에게 요청할 때도 이 형식을 사용한다. 직접 호출하지 않은 단순 정보 전달이나 완료 보고에는 불필요하게 적용하지 않는다.
-
-사용자가 별도 형식을 지정하면 그 형식을 따르되, 판단에 필요한 **맥락·원인·대안·추천 이유**는 유지한다.
-
-## 설명 원칙
-
-### 1. 사용자 관점에서 설명한다
-
-파일·함수·오류명보다 먼저 다음을 연결한다.
-
-**사용자가 하려는 일 → 현재 상태 → 문제 또는 제약 → 발생 원인 → 실제 영향**
-
-버그가 아니라 설계 선택, 요구사항 충돌, 환경 제약이라면 그대로 설명한다.
-
-같은 이름이 서로 다른 대상·위치·단계를 가리키면 먼저 구분하고, 실제 영향을 받는 사람을 기준으로 설명한다.
-
-기술 정보는 판단에 필요한 만큼만 사용하고, 낯선 용어는 해당 맥락에서 이해할 수 있게 풀어 쓴다.
-
-### 2. 사실·가설·판단을 구분한다
-
-확인된 사실과 원인, 아직 확인되지 않은 가설, 추천 판단을 섞지 않는다.
-
-원인이 확인되지 않았다면 원인을 단정하지 말고 다음을 구분한다.
-
-- 확인된 현상과 영향
-- 가능한 원인 또는 가설
-- 방향을 결정하기 위해 추가로 확인할 사항
-
-수치·비용·일정·효과는 근거가 있을 때만 사용한다. 추정치는 가정을 밝히고, 표를 채우기 위해 수치나 대안을 만들지 않는다.
-
-### 3. 실제 선택 차이를 설명한다
-
-선택지는 개수를 맞추지 말고 실제 선택할 가치가 있는 것만 제시한다. 현상 유지나 보류도 의미 있는 선택이면 포함한다.
-
-각 방안은 다음 차이가 드러나게 설명한다.
-
-**무엇을 하는가 → 왜 해결되는가 → 무엇이 달라지는가 → 어떤 부담이나 위험이 있는가**
-
-비용, 일정, 품질, 사용성, 안전성, 운영 부담 등 실제 결정을 바꾸는 기준에 집중한다.
-
-### 4. 추천은 명확하게 한다
-
-사용자의 목적과 현재 제약을 기준으로 가장 적합한 방안을 추천한다.
-
-추천에는 다음을 포함한다.
-
-- 추천하는 이유
-- 다른 방안보다 적합한 이유
-- 감수해야 할 주요 단점
-- 추천을 바꿀 수 있는 중요한 미확인 조건
-
-추천은 판단이지 확인된 사실처럼 표현하지 않는다.
-
-## 기본 출력
-
-표 앞에서 핵심 문제 또는 지금 필요한 판단을 한 문장으로 정리한다.
-
-| 항목 | 내용 |
-|---|---|
-| **맥락** | 사용자가 하려는 일, 기대 결과, 현재 상태와 이 문제가 나온 배경 |
-| **문제점** | 무엇이 문제인지, 왜 발생했는지, 누구에게 어떤 영향이 있는지 |
-| **해결방안** | 실제 가능한 방안과 각각의 해결 원리, 장점·부담 |
-| **추천방안** | 추천안과 이유, 주요 단점, 필요한 다음 행동 |
-
-선택지 비교가 복잡하면 **해결방안만 별도 비교표로 분리**한다.
-
-ASIS → TOBE는 변경 전후 비교가 판단에 도움이 될 때만 추가한다. 기본 네 항목을 대신하지 않는다.
-
-문제가 없거나 조치가 필요 없다면 억지로 해결책을 만들지 말고 그 사실과 이유를 설명한다.
-
-## 질문과 승인
-
-질문·승인 여부는 기존 프로젝트 정책과 사용자 위임 범위를 따른다. 그 안에서 사용자 결정이 필요한 미해결 사항만 질문한다.
-
-이미 위임받은 판단은 합리적인 방안을 선택해 처리하고 이유를 설명한다.
-
-질문이 필요하다면 단순히 "어떻게 할까요?"라고 묻지 말고 다음이 드러나게 한다.
-
-**무엇을 결정해야 하는지, 선택지의 차이가 무엇인지, 무엇을 추천하는지**
-
-설명이나 재정리 요청에 `진행할까요?` 같은 불필요한 실행 승인을 덧붙이지 않는다.
-
-## 품질 기준
-
-최종 답변만 읽어도 사용자가 다음을 설명할 수 있어야 한다.
-
-**맥락 → 문제와 원인 → 선택지의 차이 → 추천과 그 이유**
-
-같은 내용을 도입·표·결론에서 반복하지 않는다.