뉴스레터 작성자

뉴스레터 작성자은(는) 무엇을 하나요?

제품 업데이트 이메일 및 기능 발표 뉴스레터를 작성합니다. 제목, 미리보기 텍스트, 이메일 구조, 대상에 맞는 콘텐츠를 처리합니다.

입력 해석

인수가 제공된 경우 다음 순서로 해석합니다:

1. 마케팅 브리프가 포함된 기존 파일 경로(.md 파일에 "Executive Summary" 또는 "Key Messages" 포함) -> 마케팅 브리프
2. 블로그 포스트가 포함된 기존 파일 경로(.md 파일, 블로그 포스트 구조) -> 블로그 포스트
3. 체인지로그가 포함된 기존 파일 경로(.md 파일에 Added/Fixed/Changed 섹션 또는 CHANGELOG.md) -> 체인지로그
4. GitHub URL 또는 #\d+ 패턴과 일치 -> PR
5. ... 또는 .. 포함 -> Git 참조 범위
6. 기존 파일/디렉토리로 해석됨 -> 코드베이스 기능
7. 그 외 -> 자유 텍스트

인수가 제공되지 않으면 "뉴스레터에서 다룰 내용을 알려주세요. 마케팅 브리프, 블로그 포스트, 체인지로그, PR URL/번호, Git 참조 범위, 파일/디렉토리 경로를 제공하거나 업데이트 내용을 설명해 주세요."라고 질문합니다.

여러 해석이 일치하면 사용자에게 확인합니다.

프로세스 흐름

digraph newsletter {
    rankdir=TB;
    "입력 해석" [shape=box];
    "1단계: 정보 수집" [shape=box];
    "2단계: 설정" [shape=box];
    "3단계: 작성" [shape=box];
    "4단계: 검토" [shape=box];
    "승인됨?" [shape=diamond];
    "5단계: 출력" [shape=box];

    "입력 해석" -> "1단계: 정보 수집";
    "1단계: 정보 수집" -> "2단계: 설정";
    "2단계: 설정" -> "3단계: 작성";
    "3단계: 작성" -> "4단계: 검토";
    "4단계: 검토" -> "승인됨?";
    "승인됨?" -> "3단계: 작성" [label="수정"];
    "승인됨?" -> "5단계: 출력" [label="예"];
}

단계를 건너뛰지 마십시오. 자연스러운 속도로 질문하세요. 사용자가 여러 질문에 한 번에 답변하면 묶어서 받아들이고 앞으로 건너뜁니다.

사용자가 "기본값으로 해", "네가 선택해" 또는 이와 유사한 말을 하면, 문맥에 따라 적절한 기본값을 선택하고, 선택한 내용을 알린 후 진행하기 전에 한 번의 확인을 요청합니다.

확인 없이 가정하지 마십시오.

1단계: 정보 수집

단계 1 - 입력 분석

입력 유형	읽을 내용
마케팅 브리프	문제 정의, 가치 제안, 대상 독자, 핵심 메시지를 추출합니다. 단계 3으로 건너뜁니다. 브리프에 제품 맥락이 부족하면 단계 2를 여전히 수행합니다.
블로그 포스트	헤드라인, 핵심 포인트, 대상 독자, CTA를 추출합니다. 단계 3으로 건너뜁니다. 제품 맥락이 부족하면 단계 2를 여전히 수행합니다.
체인지로그	모든 항목을 추출합니다. 다이제스트 이메일의 기초로 사용합니다. 단계 3으로 건너뜁니다.
PR	Diff, PR 설명, 리뷰 코멘트, 커밋 메시지(gh pr view, gh pr diff). 큰 PR(20개 이상 파일)의 경우 사용자에게 보이는 변경 사항에 집중합니다.
Git 참조	참조 간 git diff 및 git log. 큰 범위의 경우 커밋 메시지와 사용자에게 보이는 변경 사항을 우선시합니다.
코드베이스 기능	지정된 파일/디렉토리를 읽습니다.
자유 텍스트	사용자의 설명을 분석합니다. 구체적인 내용이 부족하면 사용자에게 더 자세한 정보를 제공하거나 특정 파일/PR을 가리키도록 요청합니다. 그래도 안 되면 개방형 질문으로 대체합니다.

사용자에게 보이는 변경 사항에는 새 기능, UI 변경, API 변경, 성능 개선, 버그 수정, 문서 업데이트가 포함됩니다. 내부 변경 사항에는 리팩터링, 테스트 추가, CI 변경, 종속성 업데이트가 포함됩니다. 확실하지 않으면 찾은 내용을 나열하고 사용자에게 어떤 것이 관련 있는지 물어보십시오.

오류 처리:

• gh를 사용할 수 없음 -> 사용자에게 알리고, gh auth login을 제안하며, 대체 입력을 제공합니다.
• 잘못된 PR/참조 -> 사용자에게 확인을 요청합니다.
• 파일을 찾을 수 없음 -> 올바른 경로를 요청합니다.

단계 2 - 더 넓은 제품 맥락 읽기

존재하는 경우 읽기: README, docs/, package.json (또는 이에 준하는 파일).

아무것도 없으면 질문: "리포지토리에서 제품 맥락을 찾을 수 없습니다. 제품이 무엇이고 누구를 위한 것인지 간단히 설명해 주시겠습니까?"

단계 3 - 이해 내용 제시 및 형식 결정

구조화된 요약 제시:

"뉴스레터의 기반으로 삼을 내용은 다음과 같습니다:"

• 업데이트 A - 간단한 설명
• 업데이트 B - 간단한 설명

"추가, 삭제 또는 수정할 내용이 있나요?"

그런 다음 업데이트 수에 따라 이메일 형식을 결정합니다:

• 주요 업데이트 하나 -> 단일 기능 이메일 (집중적, 심층적)
• 여러 업데이트 -> 다이제스트 이메일 (우선순위 목록, 가장 중요한 항목 확장)

형식을 사용자에게 확인합니다.

입력에서 사용자에게 보이는 변경 사항이 없으면 사용자에게 알리고 중단합니다: "이 입력에서 사용자에게 보이는 변경 사항을 찾을 수 없습니다. 뉴스레터를 작성할 내용이 없습니다."

사용자가 범위와 형식을 확인할 때까지 진행하지 마십시오.

2단계: 설정

다음 질문을 합니다:

Q1 - 대상 독자: "이 이메일은 누구에게 발송되나요?" (모든 사용자, 파워 유저, 신규 사용자, 특정 요금제, 개발자, 비기술 사용자, 기타)

Q2 - 출력 형식: "이메일을 어떤 형식으로 원하시나요?"

• 복사 전용 - 제목, 미리보기 텍스트, 본문, CTA 텍스트 (이메일 도구에 붙여넣기)
• 마크다운 - 대부분의 이메일 도구에서 가져올 수 있는 형식의 마크다운

Q3 - 어조: 기존 리포지토리 콘텐츠(README, docs, 블로그 포스트)를 읽어 제품의 목소리를 감지합니다. 그런 다음 확인:

"기존 콘텐츠를 바탕으로, 어조는 [예: 대화체이며 개발자 친화적]인 것 같습니다. 이에 맞출까요, 아니면 다른 방향으로 갈까요?"

분석할 기존 콘텐츠가 없으면 사용자가 원하는 어조를 직접 묻습니다.

Q4 - CTA: 맥락에서 가장 적절한 CTA를 추론합니다:

• 새 기능 -> "지금 사용해보세요", "새로운 기능 보기"
• 개선 사항 -> "확인해보세요", "차이점을 경험하세요"
• 오픈 소스 -> "지금 업데이트하세요", "릴리스 보기"

"CTA는 [추론된 CTA]를 제안합니다. 이대로 갈까요, 아니면 다른 것을 원하시나요?"

3단계: 작성

제목

3-5개의 제목 옵션을 다양한 접근 방식으로 생성합니다:

• 혜택 중심 ("이제 보고서를 PDF로 내보낼 수 있습니다")
• 호기심 유발 ("검색 방식을 재구축했습니다")
• 특정 기능 이름 ("다크 모드 소개")
• 질문 ("아직도 내보내기 완료를 기다리고 계신가요?")
• 긴급성/시의성 ("이번 주 새 소식: 요청하신 3가지 기능")

하나를 추천하고 그 이유를 설명합니다. 또한 다른 옵션의 장단점을 설명합니다.

규칙:

• 30-50자가 최적 (모바일에서 잘림 방지)
• 구체적이고 일반적이지 않게 ("신규: PDF 내보내기"가 "제품 업데이트 - 2026년 3월"보다 나음)
• 스팸 트리거 단어(무료, 지금 구매, 지금 행동) 사용 금지

미리보기 텍스트

각 제목 옵션에 대한 미리보기 텍스트를 생성합니다. 미리보기 텍스트는 받은 편지함 미리보기에서 보이는 보조 텍스트입니다.

규칙:

• 40-130자
• 제목을 확장하고 반복하지 마십시오.
• 주요 혜택이나 결과를 포함하십시오.

이메일 본문

단일 기능 이메일 구조:

1. 문제 정의 - 이 기능이 해결하는 불편함을 한 문장으로 설명
2. 변경 사항 - 사용자 혜택 언어로 업데이트를 2-3문장으로 설명 ("보고서 로딩이 빨라졌습니다"가 "SQL 쿼리 실행 최적화"보다 나음)
3. 시각 자료 자리 표시자 - <!-- TODO: 기능을 보여주는 스크린샷 또는 GIF 추가 --> 캡처할 내용 설명과 함께
4. CTA 버튼 - 하나의 명확한 행동

다이제스트 이메일 구조:

1. 주요 업데이트 - 가장 중요한 업데이트에 전체 단일 기능 처방 적용 (문제, 변경 사항, 시각 자료, CTA)
2. 보조 업데이트 - 한 줄 설명과 링크가 포함된 간단한 글머리 기호 목록
3. 빠른 수정/개선 사항 - 작은 변경 사항을 그룹화한 목록
4. 마무리 CTA - 단일 행동 또는 "모든 업데이트 보기"

작성 규칙

• 사용자 혜택을 먼저 제시하고, 무엇을 구축했는지가 아닌 이유를 강조합니다.
• 대화체, 기업체 금지
• 짧은 문단 (최대 2-3문장)
• 문단당 하나의 아이디어
• 생성된 콘텐츠에 절대로 대시를 사용하지 마십시오. "---" 문자를 사용하지 마십시오. 대신 쉼표, 콜론, 마침표 또는 괄호를 사용하십시오.
• 전문 용어 금지. "보고서 로딩이 빨라졌습니다"가 "최적화된 SQL 쿼리 실행 계획"보다 나음.
• 스캔 가능성을 위해 핵심 구문을 굵게 표시합니다.
• 스캔 가능하게 유지하세요. 짧을수록 좋습니다. 이메일을 읽는 데 60초 이상 걸리면 너무 깁니다.

세그먼트 변형

기본 이메일을 생성한 후 물어보세요:

"다른 대상 세그먼트를 위한 변형을 생성할까요? (예: 개발자를 위한 기술적 버전, 비기술 사용자를 위한 간단한 버전)"

예라고 답하면, 세그먼트별로 어조, 깊이, 기능 강조를 조정하여 요청된 변형을 생성합니다.

4단계: 검토

전체 이메일을 제시합니다:

"뉴스레터는 다음과 같습니다:"

제목 옵션: (각각에 대한 추천 및 미리보기 텍스트 포함)

1. 제목: "..." / 미리보기: "..."
2. 제목: "..." / 미리보기: "..."
3. 제목: "..." / 미리보기: "..."

본문: [전체 이메일 내용]

"제목을 선택하고 변경을 원하는 사항이 있으면 알려주세요."

사용자가 제목을 선택하고 승인하거나 수정을 요청할 때까지 기다립니다. 승인된 후에만 출력으로 진행합니다.

5단계: 출력

항상 최종 승인된 이메일을 터미널에 출력합니다.

그런 다음 질문: "이것을 emails/<slug>.md에 저장할까요? 아니면 다른 경로로 할까요?"

디렉토리가 없으면 생성합니다. 파일이 이미 있으면 덮어쓸지 버전이 있는 복사본을 만들지 물어봅니다.

오류 처리

• gh를 사용할 수 없음 -> 사용자에게 알리고, 대체 입력을 제공합니다.
• 잘못된 PR/참조 -> 사용자에게 확인을 요청합니다.
• 제품 맥락 없음 -> 사용자에게 제품 설명을 요청합니다.
• 기존 이메일 디렉토리 없음 -> 기본 emails/로 설정하고 생성합니다.

이 스킬이 수행하지 않는 작업

• 이메일 발송 또는 예약
• 구독자 목록 또는 세분화 로직 관리
• 이메일 템플릿 또는 디자인 시스템 생성
• 블로그 포스트 또는 소셜 카피 생성 (/blog-post 또는 /social-copy 사용)