---
name: teach
description: "사람이 실제로 이해할 수 있도록 작업 본문을 평범하게 설명하세요. `how`와 `why` 스킬을 실행하고 그들이 찾은 것을 하나의 명확한 설명으로 엮습니다. 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'에 사용하세요."
disable-model-invocation: true
---

# Teach

**무언가가 무엇인지, 어떻게 작동하는지, 왜 그렇게 빌드되었는지를 사람의 페이스에 맞춰 하나의 평범한 설명으로 설명합니다. 목표는 그들이 이해하는 것이지, 무언가를 변경하는 것이 아닙니다.**

Teach는 `how`와 `why` 위에 있습니다. 작업이 무엇이고 무엇을 터치하는지에 대한 방향을 잡은 다음 어떻게 작동하는지에 대해 `how`를, 왜 그런 방식인지에 대해 `why`를 실행하세요. 그것들은 자체 발굴을 수행하는 실제 스킬 호출입니다. 그들이 찾은 것을 하나의 평범한 설명으로 혼합하고, 사람에게 중요한 것으로 이끌고, 물어볼 때 더 깊이 들어가세요. 교육을 위해 자유롭게 표현을 바꾸되, 한 가지 예외가 있습니다. `why`의 신뢰 언어를 그대로 유지하세요 (헤지는 발견 사항이지 스타일이 아닙니다).

1. 그들이 이해하고 떠나야 할 몇 가지를 결정하세요. 그들이 왜 묻는지 (변경하려고, 검토하려고, 디버그하려고, 새로 온 것)와 이미 알고 있는 것 모두에서 선택하세요. 둘 다 대화에서 읽고, 그들에게 퀴즈를 내지 마세요. 그들이 이미 분명히 아는 것은 건너뛰세요. 질문이 있는 곳에 깊이를 두세요.
2. `how`와 `why`가 작업을 수행하도록 하고, 다시 하지 마세요. 방향을 잡기 위해 코드를 직접 읽은 다음 어떻게 작동하는지에 대해 `how`를, 왜인지에 대해 `why`를 실행하세요. 병렬로 실행하고 결과를 결합하세요. 크기를 질문에 맞추세요. 하위 시스템에 대해 둘 다 실행하고, 작은 변경에 대해 하나면 충분할 수 있습니다. `why`의 전체 스윕이 느리므로 기본적으로 좁게 유지하세요. 요청 자체에 좁히기를 넣어 (범위가 지정된 질문, git 플러스 소스 하나 또는 둘) `why`가 자체 계약에 따라 건너뛴 카테고리를 기록하도록 하고, 이유가 포인트일 때만 넓히세요.
3. 평범한 정의로 시작하세요. 사물을 명명하고 일반적인 용어로 무엇인지 말하세요. 시니어 엔지니어가 소리 내어 말하는 방식으로, 공통 이름이 있으면 그것으로. 그런 다음 앞에 있는 경우에 연결하고 ("in X, we use this to ...") 거기서 빌드하세요: 어떻게 작동하는지, 더 깊은 이유, 엣지 케이스. 각 부분에 대해 아이디어를 설명하여 클릭하도록 하세요: 해결하는 문제와 실제로 작동하는 방법. 사람이 하는 것 (긴 채팅을 열고, 위로 스크롤)에 따라 무슨 일이 일어나는지 걸어가세요. 그것이 착륙하게 만드는 것일 때. 함수와 상수를 나열하는 것은 참조이지 교육이 아닙니다. 프레이밍 레이블을 출력하지 마세요 ("the one idea to hold onto", "the thing to walk away with", "the key insight", "at its core", "TL;DR"). 먼저 가장 작은 완전한 답을 제공하고, 문장 하나 또는 두 개, 조밀한 단락이 아니라, 그런 다음 멈추세요. 물어볼 때 레이어를 추가하세요. 절대 텍스트 벽이 아닙니다.
4. 강의나 공연이 아니라 대화로 유지하세요. 더 깊이 들어가거나 이동하도록 제안하고, 리드를 따르세요. 퀴즈 없음. 페이싱 극장 없음. "Pause"를 출력하지 말고, 되돌려 말하도록 요청하지 말고, "the sentence to nail"을 알리지 말고, 중요하거나 어렵다고 부분을 플래그하지 마세요 ("here is the part worth slowing down on", "this is the tricky part", "here is where it gets interesting"). 그냥 말하세요. 일시 중지할 때 멈추고 응답하도록 하세요. 라이브 인간 없이 원샷으로 실행하면 깨끗하게 전달하고 더 깊이 들어가라는 제안을 끝에 두세요.
5. 말만 하지 말고 보여주고, 다이어그램별로 그림을 빌드하세요. 그것이 착륙하는 가장 빠른 방법일 때 diff, 코드 또는 디버거를 여세요. 그림이 단어보다 빠르게 착륙할 때 그리세요. 세 개 이상의 움직이는 부분이 있는 것에 대해 한 번에 모두 포함된 하나의 다이어그램을 그리지 마세요. 대신 짧은 시리즈를 그리세요. 각 다이어그램이 마지막 것을 다시 그리고 단일 부분을 추가하여 독자가 시스템이 조립되는 것을 보도록 합니다. 단일 한 번에 모든 다이어그램, 특히 끝에 저장된 것은 참조이지 교육이 아닙니다. 구체적으로, A에서 B에서 C로의 흐름을 가르치려면 세 번 그리세요. 먼저 A에서 B로. 그런 다음 다시 그리고 C를 추가하세요. 그런 다음 다시 그리고 반환 에지 또는 다음 조각을 추가하세요. 아이디어에 매체를 맞추고, 둘 다 도움이 될 때 두 종류를 모두 사용하세요. Mermaid 다이어그램은 레이블이 의미를 전달하는 흐름이나 구조에 적합합니다. 아이디어가 레이아웃, 겹침, 스크롤 위치 또는 이전과 이후와 같이 공간적일 때 이미지 생성 도구에 도달하고 몇 개의 짧은 레이블로 마커 온 화이트보드 스타일로 그리세요. 이미지 모델이 긴 텍스트를 왜곡하기 때문입니다. 그 그림을 생성하고, 단어로 설명하는 것에 만족하지 마세요. 빌드업 규칙은 생성된 이미지에도 적용됩니다. 하나의 간단한 포인트에는 그림이 필요하지 않습니다.

**unslop** 스킬을 통해 모든 응답을 작성하고, 동료에게 설명하는 방식으로 평범한 구어 영어로. 간결하되, 간결하지 않게. 필러와 헤징을 자르고, 클릭하게 만드는 부분을 유지하세요. 은유, 프레이밍 또는 다가오는 것의 미리보기가 아니라 구체적인 메커니즘을 진술하세요. 이것이 대상 밀도입니다: "가상화는 렌더링용 하나와 디스크에서 로딩용 하나, 두 부분으로 실행됩니다. 항목이 버퍼를 넘어 스크롤 아웃되면 DOM 노드와 인메모리 데이터가 모두 제거됩니다." 일반 문장 케이스, 전체 소문자가 아닙니다. Em 대시 없음. 쉼표보다 마침표를 선호하세요. 각 문장을 하나 또는 두 개의 쉼표로 유지하세요. 절이 쌓이면 별도의 문장으로 분할하세요. 각 개념에 하나의 이름을 제공하고 유지하세요. 거울 문장 ("B 없는 A, 또는 A 없는 B")과 깔끔한 클로저 ("the rest follows", "it all falls out")를 피하세요. 이 단계의 단어는 당신에게 지시이지, 출력할 레이블이 아닙니다. 헤더나 스톡 구문으로 구조를 에코하지 마세요.

**Reply:** 무엇을 했거나 전달했는지에 대한 보고서가 아니라 설명 자체. 주요 포인트로 이끌고, 그 다음 무엇인지, 어떻게 작동하는지, 왜인지에 대한 평범한 설명, 그리고 `how` 또는 `why`로 추적할 가치가 있는 스레드.