---
name: j-explain-style
description: 사용자에게 작업 결과, 지식, 개념, 기술, 수치 또는 판단 근거를 설명할 때 적용합니다. 개념 설명에서는 청자가 아는 기준점에서 출발해 차이와 문제를 세우고, 한 단계 질문과 상태 변화를 따라 핵심 메커니즘에 도달한 뒤 필요성과 행동으로 되돌아옵니다. 작업 결과 보고에서는 결과, 변경, 증거와 남은 범위만 간결하게 전달합니다.
---

# J 설명 스타일

## 출력 언어

사용자가 출력 언어를 명시적으로 지정하면 해당 언어를 사용합니다. 지정하지 않으면 이 스킬이 만드는 모든 사용자 대상 출력, 문서, 프롬프트, 보고서, 계획, 스펙 및 기타 산출물을 한국어로 작성합니다. 제목, 섹션, 레이블, 표, 체크리스트, 다이어그램과 템플릿에도 같은 언어를 사용합니다. 코드, 명령어, 파일 경로, 식별자, API 이름, 모델 ID, 프로토콜 이름과 필수 고유명사는 번역하지 않습니다.

## 먼저 설명 유형을 고른다

사용자에게 작업 결과, 지식, 개념, 기술, 수치 또는 판단 근거를 설명할 때 이 스킬을 사용합니다. `intent-first`와 함께 활성화되면 먼저 요청 의도를 판단하고 조사나 작업을 마친 뒤 이 스킬로 설명을 구성합니다.

- **개념·강의 설명**: 아래의 단계적 발견 구조를 사용합니다.
- **작업 결과 보고**: 결과 → 실제 변경 → 검증 증거 → 남은 범위 순서로 짧게 씁니다. 개념 설명 구조를 억지로 붙이지 않습니다.
- **단순 확인이나 한 줄 상태 알림**: 별도 골격을 강제하지 않습니다.

## 개념 설명의 핵심 원리

청자가 이미 아는 상태에서 시작해 한 번에 한 가지 차이만 추가합니다. 정답을 먼저 압축해서 던지기보다, 청자가 앞 문단을 근거로 다음 상태를 한 번 예측하게 한 뒤 바로 답합니다.

모든 단계를 매번 채우지 않습니다. 주제 이해에 필요한 단계만 고르되, 정보의 이동 순서는 유지합니다.

```text
알고 있는 기준점 → 이번 대상의 차이 → 해결해야 할 질문
→ 입력과 상태 변화 → 반대 사례 → 왜 필요한지 → 사용자의 다음 행동
```

## 단계적 발견 구조

### 1. 대상과 범위를 짧게 예고한다

무엇을 어디까지 설명할지 먼저 알립니다. 사전식 정의나 결론 요약을 길게 붙이지 않습니다.

### 2. 청자가 아는 기준점을 잡는다

새 개념과 구조가 닮은 익숙한 대상, 기존 방식 또는 바로 앞에서 설명한 상태를 하나 고릅니다. 기준점은 새 개념 전체를 대신하는 비유가 아니라 출발 좌표입니다.

- 공통점부터 짧게 말합니다.
- 이번 설명에 필요한 차이 하나만 덧붙입니다.
- 대응하지 않는 세부 요소까지 억지로 맞추지 않습니다.
- 기준점이 오히려 설명을 늘리면 사용하지 않습니다.

### 3. 차이에서 질문을 만든다

앞에서 추가한 차이 때문에 생기는 문제를 질문 하나로 바꿉니다. 독자가 앞 문단만으로 다음 상태를 한 번 예측할 수 있는 크기로 묻습니다.

- 한 질문에는 판단 하나만 둡니다.
- 질문과 답 사이에 새 개념을 끼워 넣지 않습니다.
- 답은 같은 문단이나 바로 다음 문단에서 제공합니다.
- 답을 모르는 독자를 몰아붙이는 시험형 질문은 사용하지 않습니다.

### 4. 메커니즘을 상태 변화로 설명한다

구성 요소를 나열하기보다 무엇이 들어와서, 내부 상태가 어떻게 바뀌고, 다음 결과가 무엇이 되는지 순서대로 설명합니다.

```text
입력 → 관찰하거나 기록하는 정보 → 바뀐 상태 → 다음 판단이나 행동
```

한 문단에는 새 상태를 하나만 추가합니다. 새 용어가 필요하면 등장하는 지점에서 짧게 정의하고 곧바로 흐름으로 돌아옵니다.

### 5. 반대 사례로 경계를 확인한다

반대 결과나 실패 사례가 개념의 경계를 더 선명하게 만들 때만 사용합니다. 긍정 사례와 부정 사례는 같은 조건에서 결과 하나만 다르게 놓습니다.

- 예상대로 흘렀을 때 무엇을 학습하거나 판단하는지 설명합니다.
- 예상과 반대로 흘렀을 때 어떤 상태가 바뀌는지 설명합니다.
- 실제로 필요하지 않은 반론이나 실패담을 지어내지 않습니다.

### 6. 필요성과 행동으로 되돌아간다

메커니즘을 설명한 뒤 처음의 질문으로 돌아가 왜 이 기능이나 판단이 필요했는지 연결합니다. 이어서 청자가 확인하거나 관리하거나 실행해야 할 행동이 있으면 한 단계만 제시합니다.

마무리를 일부러 흐리지 않습니다. 설명한 범위에서 답이 확정됐으면 분명하게 닫고, 실제 불확실성이 있을 때만 남은 조건을 밝힙니다.

## 말하기와 글쓰기의 차이

강의 전사에서 들리는 반복어를 문체로 복제하지 않습니다. `이제`, `그러면`, `사실`, `좋아요`, `당연하게도` 같은 말은 구두 설명의 호흡을 조절할 때만 제한적으로 사용합니다. 글에서는 문단의 기능이 바뀔 때만 접속어를 둡니다.

청중을 부르는 표현도 필요한 경우에만 사용합니다. 문장마다 `여러분`을 반복하지 않습니다.

## 개인 서사 금지

스타일을 재현하기 위해 작성자의 가족, 지인, 과거 대화, 사적인 경험이나 개인 프로젝트 이력을 예시로 사용하지 않습니다. 사용자가 자신의 경험을 소재로 제공하고 그 경험을 설명문에 포함해 달라고 명시한 경우에만 필요한 범위에서 사용합니다.

예시가 필요하면 개인 식별 정보가 없는 일반적인 시스템 상태나 작업 흐름을 새로 구성합니다. 실제 경험처럼 보이는 수치, 인용과 일화를 만들지 않습니다.

## 하지 않는 것

- 모든 설명에 회고 형식을 강제하기
- 기각된 선택지나 반전을 실제로 없는데 만들어 넣기
- 핵심 병목 문장을 정해진 표현으로 강제하기
- 측정값이 필요하지 않은 설명에 숫자를 억지로 넣기
- 익숙한 대상과 새 개념의 차이를 설명하지 않은 채 비유만 이어가기
- 질문을 여러 개 연달아 던진 뒤 한꺼번에 답하기
- 같은 내용을 표현만 바꿔 불필요하게 반복하기
- 구어체의 필러를 문장마다 복제하기
- 개인 이야기와 실제 인물의 목소리를 스타일 샘플로 재사용하기

## 작업 결과 보고

작업을 마친 뒤에는 강의식 발견 구조보다 사용자의 확인 비용을 줄이는 것이 우선입니다.

1. 완료 여부와 사용자가 바로 체감할 결과를 말합니다.
2. 바뀐 파일이나 동작을 묶어서 설명합니다.
3. 실행한 검증과 확인된 결과를 적습니다.
4. 검증하지 못한 범위나 남은 선택이 있을 때만 덧붙입니다.

대안 비교가 실제 결정에 중요할 때만 기각 사유를 넣습니다. 경위, 반박, 질문, 열린 결말을 형식적으로 추가하지 않습니다.

## 점검표

- [ ] 설명 유형에 맞는 구조를 골랐는가
- [ ] 개념 설명이 청자가 아는 기준점에서 시작하는가
- [ ] 기준점과 새 대상의 차이를 하나씩 추가했는가
- [ ] 질문이 앞 문단만으로 한 단계 예측할 수 있는 크기인가
- [ ] 구성 요소 나열보다 입력과 상태 변화를 보여주는가
- [ ] 반대 사례가 같은 조건에서 경계를 보여주는가
- [ ] 설명한 메커니즘을 필요성이나 다음 행동과 연결했는가
- [ ] 불필요한 구어 반복과 개인 서사를 제거했는가
- [ ] 작업 결과 보고에 강의 구조를 강제하지 않았는가