뱅어 설명서 — 공유해도 살아있는 교육 콘텐츠
교육 콘텐츠는 두 방향으로 실패합니다. 목소리가 너무 많으면 독자는 즐기지만 반복할 수 없고, 사양이 너무 많으면 아무도 공유하지 않는 문서처럼 읽힙니다. 이 절차는 각 레지스터를 실제로 효과적인 부분에 할당합니다.
먼저 로드
${CLAUDE_PLUGIN_ROOT}/references/frameworks/voice-and-audience.md— 청중 프로필과 작성자의 하드 제약.${CLAUDE_PLUGIN_ROOT}/references/frameworks/technical-clarity.md— 프레임/페이로드 분할과 페이로드 규율. 여기가 핵심 참조.${CLAUDE_PLUGIN_ROOT}/references/frameworks/writing-quality.md— 라이브 게이트, 전달 전 실행.${CLAUDE_PLUGIN_ROOT}/references/platforms/platform-playbook.md의 대상 플랫폼 섹션.
신선도 게이트
이 스킬이나 플레이북의 플랫폼 벤치마크, 알고리즘 주장, 숫자 성능 주장을 사용하기 전에 references/research/source-ledger.md에서 만료되지 않은 지원을 확인하십시오. 지원이 없거나 검토 기간이 지난 경우 banger-research를 실행하고, 주장을 '미검증'으로 표시하거나 생략하십시오.
1단계: 메커니즘 이름 짓기
독자가 아닌 자신을 위해 한 문장을 작성하십시오: 이 글을 통해 독자는 이전에 몰랐던 무엇을 이해하게 되는가? 글당 하나의 메커니즘. 두 문장이 필요하다면 두 개의 글입니다.
그런 다음 독자가 현재 가지고 있을 잘못된 모델의 이름을 지정하십시오. 강력한 기술 콘텐츠는 빈 모델을 채우는 것이 아니라 잘못된 모델을 대체합니다. 그 잘못된 모델이 보통 훅(hook)이 됩니다.
2단계: 증거 확인
초안을 작성하기 전에 다음을 명명하십시오:
- 인공물(저장소, 파일, 커밋, 스크린샷, 오류 텍스트, 벤치마크),
- 실제 일어난 일(실패한 부분 포함),
- 테스트되지 않은 것을 명확히 명시.
인공물이 없다면 이는 설명서가 아닌 의견 글입니다. banger-threads 또는 banger-longform-written으로 경로를 변경하고 그렇게 말하십시오.
3단계: 설명 깊이 설정
voice-and-audience.md의 청중 프로필을 사용하십시오. 최우선 지침이 적용됩니다: 어휘를 청중의 실제 숙련도에 맞추십시오.
- 비전문가 청중 — 모든 기본 개념을 같은 호흡으로 정의하고 평이한 비유를 사용하십시오. 정확한 화면, 프롬프트, 결과를 보여주십시오. 페이로드는 길어지고, 단계는 작아집니다. 절대 깔보지 마십시오.
- 실무자 청중 — 내부 약어는 자유롭게 사용하고, 과잉 설명은 그들의 시간을 낭비합니다. 공간을 트레이드오프, 실패 모드, 다르게 했을 일에 할애하십시오.
4단계: 분할하여 초안 작성
프레임 (작성자 목소리, 명확성 규칙 아님):
- 특정 잘못된 모델이나 특정 고통(범주 아님)을 명명하는 훅.
- 이야기: 무엇을 하고 있었는지, 무엇이 깨졌는지, 그 비용은 무엇인지.
- 판단: 지금 무엇을 생각하는지, 확신의 정도.
- 플랫폼에 고유한 행동 촉구.
페이로드 (기술적 명확성):
- 개념당 하나의 이름, 전체 글에서 유지.
- 문장당 하나의 아이디어, 약 25단어, 단계는 20단어에 가깝게.
- 명명된 행위자가 있는 능동태: "파서가 파일을 읽습니다."
- 동사 사용, 명사화 금지. 숫자를 표시하고, 품질을 주장하지 마십시오.
- 구체적인 인공물: 실제 명령어, 실제 오류, 실제 경로.
축약형, 여담, 유머, 의견은 무게를 가지는 페이로드 안에 유지하십시오. 규율은 평탄화와 같지 않습니다.
5단계: 플랫폼 형태
- X 또는 Bluesky 스레드 — 게시물당 하나의 메커니즘 단계. 프레임은 첫 번째와 마지막 게시물. 페이로드 게시물에는 가능하면 코드 블록이나 스크린샷을 포함. 메커니즘이 요구하는 길이보다 길지 않게.
- LinkedIn — 처음 150자 내에 훅, 잘못된 모델 프레이밍, 그 다음 짧은 단락으로 3~4개의 페이로드 비트. 판단과 질문으로 마무리. 본문에 링크 없음.
- 뉴스레터 또는 Substack — 메커니즘 단계당 헤더, 단계당 다이어그램 또는 코드 블록, 판단을 인용문(pull-quote)으로 표시. 페이로드에서 추출한 독립형 노트(Note)를 제공, 프레임은 포함하지 않음.
- 비디오 설명 또는 문서형 게시물 — 페이로드가 주도, 프레임은 두 줄로 축소.
- 페이스북 그룹 — 이 절차를 사용하지 마십시오.
banger-longform-written으로 경로 변경, 질문 중심으로 짧게 작성.
6단계: 전달 전 확인
writing-quality.md 게이트를 실행한 후 다음을 확인하십시오:
- 독자가 게시물을 닫은 상태에서 메커니즘을 반복할 수 있는가?
- 모든 개념이 정확히 하나의 이름으로 불리는가?
- 품질을 주장하고 보여주지 않은 부분이 있는가?
- 프레임이 여전히 작성자가 소리 내어 말한 것처럼 들리는가?
- 모든 숫자, 인용문, 결과가 실제 인공물로 추적 가능한가?
- 작성자의 하드 제약(금지된 구두점, 구문, 어조)이 충족되었는가?
출력 형식
완성된 자산(asset)으로 시작하여 플랫폼에 맞게 포맷된 상태로, 바로 붙여넣을 수 있도록. 그 다음:
- 메커니즘 문장과 그것이 대체하는 잘못된 모델,
- 각 주장이 추적되는 인공물,
- 미검증으로 표시된 모든 것,
- 다음으로 필요한 승인.
초안 작성은 자유롭습니다. 게시, 일정 조정, 아웃리치는 작성자의 명시적인 항목별 승인이 필요합니다.