Communitygithub.com

뱅어 설명서

공유해도 살아있는 기술 콘텐츠를 작성하기 위한 절차입니다. 각 레지스터(화자 목소리와 기술적 명확성)를 실제로 효과적인 부분에 할당합니다.

뱅어 설명서란 무엇인가요?

이 스킬은 기술 콘텐츠가 공유된 후에도 유용하게 남아 있도록 설계된 콘텐츠 작성 절차를 제공합니다. 일반적인 기술 콘텐츠는 너무 많은 화자의 목소리(재미는 있지만 반복 불가) 또는 너무 많은 기술적 사양(공유되지 않는 문서)이라는 두 가지 실패 방향을 가집니다. 이 스킬은 각 레지스터를 실제로 효과적인 부분, 즉 프레임(화자 목소리, 청중 연결)과 페이로드(기술적 명확성, 재현 가능한 지식)로 분리합니다. X/Bluesky, LinkedIn, 뉴스레터/Substack, 비디오 설명 등 다양한 플랫폼에 맞게 조정 가능하며, 작성 전 검증(신선도 게이트, 증거 확인)과 작성 후 검증(라이팅 퀄리티 게이트)을 포함합니다. Claude Code 환경에서 참조 프레임워크를 로드하여 일관성과 정확성을 유지하도록 설계되었습니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Jeff-Kazzee/bangers/tree/main/skills/banger-explainer

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

뱅어 설명서 — 공유해도 살아있는 교육 콘텐츠

교육 콘텐츠는 두 방향으로 실패합니다. 목소리가 너무 많으면 독자는 즐기지만 반복할 수 없고, 사양이 너무 많으면 아무도 공유하지 않는 문서처럼 읽힙니다. 이 절차는 각 레지스터를 실제로 효과적인 부분에 할당합니다.

먼저 로드

  • ${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 게이트를 실행한 후 다음을 확인하십시오:

  1. 독자가 게시물을 닫은 상태에서 메커니즘을 반복할 수 있는가?
  2. 모든 개념이 정확히 하나의 이름으로 불리는가?
  3. 품질을 주장하고 보여주지 않은 부분이 있는가?
  4. 프레임이 여전히 작성자가 소리 내어 말한 것처럼 들리는가?
  5. 모든 숫자, 인용문, 결과가 실제 인공물로 추적 가능한가?
  6. 작성자의 하드 제약(금지된 구두점, 구문, 어조)이 충족되었는가?

출력 형식

완성된 자산(asset)으로 시작하여 플랫폼에 맞게 포맷된 상태로, 바로 붙여넣을 수 있도록. 그 다음:

  • 메커니즘 문장과 그것이 대체하는 잘못된 모델,
  • 각 주장이 추적되는 인공물,
  • 미검증으로 표시된 모든 것,
  • 다음으로 필요한 승인.

초안 작성은 자유롭습니다. 게시, 일정 조정, 아웃리치는 작성자의 명시적인 항목별 승인이 필요합니다.

Individual skills in this repo

This repo contains 11 individual skills — each has its own dedicated page.

관련 스킬