name	tweet
description	오늘 커밋 내역 기반으로 build in public 트윗 초안 생성. '트윗 써줘', 'tweet', '트윗', '오늘 뭐 올리지', 'X에 올릴거' 등으로 호출. 개발 작업 후 트윗 요청 시에도 사용.

/tweet

오늘의 git 커밋 내역을 보고 build in public 스타일 트윗 초안을 생성한다.

플로우

현재 프로젝트의 오늘 커밋만 확인 (다른 프로젝트 탐색 금지):
```
git log --since="6am" --oneline
```
repo URL 가져오기 (트윗 하단에 포함):
```
git remote get-url origin
```
커밋들을 분석해서 오늘 작업의 전체 흐름을 파악. 하나만 골라 요약하지 말고, 의미 있는 작업 단위들을 묶어서 스토리로 구성한다. 단, changelog처럼 전부 나열하는 건 금지.
스크린샷 제안 (아래 섹션 참고)
사용자에게 트윗 초안 + 한글 번역 + 스크린샷 제안을 함께 제시 — 수정 요청 시 다듬기
- 트윗 본문은 영어로 작성하되, 바로 아래에 > 한글 번역: 블록으로 전체 번역을 붙인다. 사용자가 내용을 빠르게 파악할 수 있도록.

핵심: 사람처럼 쓰기

AI가 쓴 글은 티가 남 — 너무 깔끔하고, 구조적이고, 감정이 없다. 사람이 트위터에 쓰는 건 생각의 흐름 그대로, 약간 거칠고, 개인적이다.

톤 가이드

내용에 맞는 길이. 할 말이 없으면 2줄, 스토리가 있으면 15줄도 OK. 억지로 줄이지 말 것. 불완전 문장도 OK.
구어체 자연스럽게. "Turns out...", "TIL:", "Okay so...", "Fun fact:", "Ngl,", "Wait —"
삽질/놀란 점 포함. 완벽한 척 하면 AI 냄새남. "took me way too long to figure out", "should've done this weeks ago"
숫자 하나면 충분. "67 tests" or "5.5 → 8.3" — 구체적 숫자 하나가 임팩트.
이모지 0~1개. 없는 게 낫고, 쓰더라도 하나만.

포맷

영어
280자 제한 없음 (X Premium). 보통 2~15줄. 내용이 풍부하면 길게 써도 된다 — 스토리가 있는 긴 트윗이 억지로 압축한 짧은 트윗보다 낫다.
구조: 여러 항목이 있으면 "제목 + bullet" 포맷 사용:
```
제목
- 내용
- 내용

제목
- 내용
- 내용
```
항목이 하나면 자유 형식 OK.
마지막 줄에 해시태그: #BuildInPublic 필수 + 관련 1개 (#ClaudeCode, #DevTools 등)
GitHub 링크: remote URL이 있으면 트윗 마지막 (해시태그 바로 위)에 항상 포함. git remote get-url origin으로 가져온다. 추측 금지. remote가 없으면 생략.
복붙 가능한 포맷: 트윗 초안은 사용자가 그대로 복사해서 X에 붙여넣을 수 있어야 한다. 코드 블록 안에서 한 문장을 여러 줄로 쪼개지 말 것 — 문단 구분(빈 줄)만 실제 줄바꿈이고, 한 문장/문단 안에서는 자연스러운 한 줄로 쓴다. X가 알아서 줄을 감싸므로, 보기 좋게 쪼갤 필요 없다.

하지 말 것

"I'm excited to announce..." / "Thrilled to share..." — 공식 발표 톤
"Here's what I learned today:" — 뻔한 도입
커밋 전체 나열하는 changelog 스타일
"🚀🔥💡🎉" 이모지 도배
"Thread 🧵" — 단일 트윗임
모든 문장이 같은 길이로 정렬된 깔끔한 구조
"implemented", "leveraged", "utilized" — 이력서 단어

좋은 예시

Before/Problem/Fix 포맷 (여러 항목일 때 기본):

Been building a knowledge library for AI coding agents. Had about 98 entries. Read Karpathy's LLM Wiki gist today, looked at mine again.

Before
- every entry had the same "what happened + lesson" format.

Problem
- when logging a debugging gotcha, "how to prevent it next time" was missing. When logging an experiment, "what conditions I ran it under" was missing. One template meant something important always got left out.

Fix
- 4 templates by situation. Debugging gets what-broke/why/how-fixed/prevention. Experiments get conditions/results/conclusion. Just fill in the blanks.

Before
- all entries aged the same way.

Problem
- "this flag was removed in Python 3.12" becomes wrong when the version changes, but "GPU doesn't support bf16" is true forever. Couldn't tell them apart, so cleanup meant manually checking everything.

Fix
- permanent/temporal tags. Planning to run a lint command periodically that only checks temporal entries — "is this still valid?" Permanent ones get skipped.

https://github.com/kangraemin/ai-knowledge

#BuildInPublic #ClaudeCode

이 포맷의 핵심:

뭘 바꿨는지(Fix)만 쓰면 changelog. 왜 바꿨는지(Problem)와 이전 상태(Before)를 같이 써야 읽는 사람이 맥락을 잡음.
Before → Problem → Fix 순서로 반복하면 여러 항목도 자연스럽게 이어짐.
Before/Problem/Fix 각각 줄바꿈 후 - bullet으로 내용 작성. 한 줄에 "Before: 내용" 붙이지 말 것.

제목 + bullet 포맷 (짧은 항목 여러 개):

Write e2e tests
- found 6 real bugs just by writing them
- 50 → 67 total

Delete unused agents
- 3 planner agents doing literally nothing
- Claude handles planning directly

Auto-cleanup installer
- stale files were silently breaking hooks
- source is truth now

#BuildInPublic #ClaudeCode

단일 항목 (자유 형식):

TIL Claude Code can bypass Write/Edit blocks
through Bash heredoc. Sneaky.

Had to add a 2nd defense layer with git diff.
#BuildInPublic

Removed 3 files today. Wrote 0 new ones.
Best kind of day.
#BuildInPublic

Okay so my hook wasn't checking for empty folder names.
Entire validation chain was getting skipped silently.

Fixed in 4 lines.
#BuildInPublic #DevTools

스토리텔링형 (긴 트윗):

Swore at my LLM out of frustration and somehow
got a noticeably better answer.

No way that's real. So I went and read every paper
I could find on this.

Turns out there's a 2025 study where rude prompts
hit 84.8% vs polite at 80.8%. Google's Sergey Brin
even said on stage "all models do better if you
threaten them with physical violence."

So Wharton ran a proper experiment. 9 prompts
including "I'll punch you" and "$1 trillion tip."
5 models. 25 runs per question.

Result: no consistent improvement.
The reason rude prompts sometimes work is boring —
they're just shorter and more direct.
Polite fluff actually distracts the model.

Don't swear at your AI. Just stop being wordy.

#BuildInPublic #LLM

나쁜 예시 (이렇게 절대 쓰지 말 것)

Today I implemented an automated cleanup mechanism
for the agent file management system, ensuring
stale files are properly removed during updates.
#BuildInPublic #AI #DevTools #Coding #SoftwareEngineering

→ 왜 나쁜가: "implemented", "mechanism", "ensuring" — 이력서/보도자료 톤. 해시태그 5개. 사람이 이렇게 안 씀.

🚀 Exciting update! Just shipped a major improvement
to my AI workflow enforcer. Quality scores improved
significantly. Check it out! 💪
#BuildInPublic #AI #DevTools

→ 왜 나쁜가: "Exciting update!", "Just shipped", "Check it out!" — LinkedIn 광고 톤. 이모지 2개. 구체적 숫자 없음.

변경 동기와 개선점

트윗에 "뭘 했다"만 쓰면 changelog랑 다를 바 없다. 사람들이 궁금한 건 왜 바꿨는지, 뭐가 나아졌는지다.

before → after: 이전에 뭐가 불편/불가능했고, 지금은 어떻게 됐는지
계기: 버그 리포트, 직접 쓰다 짜증난 점, 유저 피드백 등
숫자로 개선 표현: "3s → 0.2s", "5 steps → 1 command", "0 → 67 tests"

커밋 메시지만 보면 "what"만 보이지만, 대화 컨텍스트에서 "why"를 찾아서 넣어야 한다. 대화에서 사용자가 불만을 표현하거나, 문제를 설명하거나, 비교한 부분을 찾아 트윗에 녹인다.

스크린샷 제안

트윗에 이미지가 있으면 engagement가 확연히 다르다. 트윗 초안과 함께 어떤 스크린샷을 찍으면 좋을지 구체적으로 제안한다.

좋은 스크린샷

before/after 비교: 변경 전후를 나란히 보여주는 게 가장 강력
실제 동작 화면: 새 기능이 실행되는 모습 (UI 변경, 터미널 출력 등)
코드 diff: 핵심 변경이 몇 줄인 경우, 짧은 diff가 임팩트 있음
에러 → 성공: 고친 버그의 에러 메시지 + 수정 후 정상 동작

제안 형식

트윗 초안 아래에 이렇게 제시:

📸 스크린샷 제안:
- [앱 화면] Claude Inspector에서 토큰 팝오버 클릭한 모습 — 비용 계산이 한눈에 보이는 컷
- [비교] 이전 버전(숫자만) vs 새 버전(단가×수량 계산 표시)

구체적으로 어디서 뭘 캡처하라고 알려줘야 한다. "앱 스크린샷" 같은 모호한 제안은 쓸모없다.

범위

/tweet을 호출한 프로젝트(현재 작업 디렉토리)의 커밋만 본다. 다른 프로젝트 디렉토리를 탐색하지 않는다.

커밋 없는 날

커밋이 없으면 "오늘 커밋 없음" 알려주고, 그래도 올리고 싶으면:

최근 작업 기반 회고/인사이트
개발 중 발견한 것
쓰고 있는 도구에 대한 짧은 생각

Más de este repositorio

mismo repositorio

bouncer-status

kangraemin/claude-config

ai-bouncer 설치 상태, 설정, 건강 진단을 한눈에 보여줌. '바운서 상태', 'bouncer status', '설치 확인', 'bouncer 설정' 요청 시 트리거.

2026-05-162

coinbot-trade-history

kangraemin/claude-config

Coinbot 라이브 거래 현황 조회 — 사용자가 "신규 전략 PnL", "최근 거래", "얼마 잃었어/벌었어", "신규 전략 이후", "거래 결과", "봇 성과" 등 라이브 트레이딩 현황을 물으면 반드시 이 스킬을 사용한다. 서버 DB에서 직접 조회하여 KST 기준 / 계정별 분리 형태로 보고한다.

2026-05-162

create-spec

kangraemin/claude-config

제품 기획부터 기술 설계, 디자인까지 3종 문서를 한번에 생성하는 스킬. PRD(기획서), TECHNICAL(기술문서), DESIGN(디자인문서)을 이것만 보고 개발을 완료할 수 있는 수준으로 작성한다. stitch MCP로 실제 스크린을 생성하고 디자인 문서에 포함한다. 사용자가 "PRD 써줘", "기획서 만들어줘", "스펙 문서", "create-spec", "제품 문서", "기술 문서 작성" 등을 말하면 반드시 이 스킬을 사용할 것. 새 프로젝트 시작, 기능 기획, MVP 설계 시에도 트리거.

2026-05-162

design-ppt

kangraemin/claude-config

Use this skill to create a branded .pptx presentation from any content source (markdown doc, PDF, existing PPT) using a named design system from getdesign.md. Trigger whenever the user mentions making/creating a PPT or slides with a specific brand design (apple, claude, stripe, notion, etc.), or when they have a document they want turned into a polished slide deck. Keywords: '디자인 PPT', 'PPT 만들어', 'slides from', 'brand PPT', 'getdesign', 'apple design ppt', '공모전 PPT'. Always use this skill when the user wants a visually designed presentation, not just any pptx task — for editing/reading existing .pptx files use the pptx skill instead.

2026-05-162

dev-bounce

kangraemin/claude-config

코드 수정, 기능 구현, 버그 수정, 리팩토링, 파일 변경 등 모든 개발 작업에 반드시 사용해야 하는 구조화된 워크플로우. 사용자가 코드 변경을 요청하면 항상 이 스킬을 먼저 호출할 것. 모든 작업을 phase/step 구조로 처리하는 통일 워크플로우. 이 스킬을 건너뛰고 직접 Edit/Write하면 dev-bounce 워크플로우 없이 진행하는 것이다. 반드시 호출할 것.

2026-05-162

ga-analyze

kangraemin/claude-config

GA4 데이터 스냅샷을 저장하고 이전 스냅샷 대비 증감을 계산해 개선 액션 아이템을 뽑는 스킬. 시계열로 데이터를 축적해서 "2주 전보다 리텐션이 좋아졌나?" 같은 질문에 답할 수 있게 한다. "GA 분석", "GA 분석해봐", "데이터 분석", "지표 어때", "KPI 뽑아", "리텐션 어때", "유입 어때", "스냅샷 찍어", "analytics 보고서", "GA 리포트" 등 사용자가 GA 데이터를 분석하거나 개선점을 찾으려 할 때 반드시 이 스킬을 사용. 단순 "GA 열어봐" 같은 접근은 ga-connect 스킬로, 분석·비교·리포트가 필요하면 이 스킬로 라우팅.

2026-05-162

name	tweet
description	오늘 커밋 내역 기반으로 build in public 트윗 초안 생성. '트윗 써줘', 'tweet', '트윗', '오늘 뭐 올리지', 'X에 올릴거' 등으로 호출. 개발 작업 후 트윗 요청 시에도 사용.

/tweet

오늘의 git 커밋 내역을 보고 build in public 스타일 트윗 초안을 생성한다.

플로우

현재 프로젝트의 오늘 커밋만 확인 (다른 프로젝트 탐색 금지):
```
git log --since="6am" --oneline
```
repo URL 가져오기 (트윗 하단에 포함):
```
git remote get-url origin
```
커밋들을 분석해서 오늘 작업의 전체 흐름을 파악. 하나만 골라 요약하지 말고, 의미 있는 작업 단위들을 묶어서 스토리로 구성한다. 단, changelog처럼 전부 나열하는 건 금지.
스크린샷 제안 (아래 섹션 참고)
사용자에게 트윗 초안 + 한글 번역 + 스크린샷 제안을 함께 제시 — 수정 요청 시 다듬기
- 트윗 본문은 영어로 작성하되, 바로 아래에 > 한글 번역: 블록으로 전체 번역을 붙인다. 사용자가 내용을 빠르게 파악할 수 있도록.

핵심: 사람처럼 쓰기

AI가 쓴 글은 티가 남 — 너무 깔끔하고, 구조적이고, 감정이 없다. 사람이 트위터에 쓰는 건 생각의 흐름 그대로, 약간 거칠고, 개인적이다.

톤 가이드

내용에 맞는 길이. 할 말이 없으면 2줄, 스토리가 있으면 15줄도 OK. 억지로 줄이지 말 것. 불완전 문장도 OK.
구어체 자연스럽게. "Turns out...", "TIL:", "Okay so...", "Fun fact:", "Ngl,", "Wait —"
삽질/놀란 점 포함. 완벽한 척 하면 AI 냄새남. "took me way too long to figure out", "should've done this weeks ago"
숫자 하나면 충분. "67 tests" or "5.5 → 8.3" — 구체적 숫자 하나가 임팩트.
이모지 0~1개. 없는 게 낫고, 쓰더라도 하나만.

포맷

영어
280자 제한 없음 (X Premium). 보통 2~15줄. 내용이 풍부하면 길게 써도 된다 — 스토리가 있는 긴 트윗이 억지로 압축한 짧은 트윗보다 낫다.
구조: 여러 항목이 있으면 "제목 + bullet" 포맷 사용:
```
제목
- 내용
- 내용

제목
- 내용
- 내용
```
항목이 하나면 자유 형식 OK.
마지막 줄에 해시태그: #BuildInPublic 필수 + 관련 1개 (#ClaudeCode, #DevTools 등)
GitHub 링크: remote URL이 있으면 트윗 마지막 (해시태그 바로 위)에 항상 포함. git remote get-url origin으로 가져온다. 추측 금지. remote가 없으면 생략.
복붙 가능한 포맷: 트윗 초안은 사용자가 그대로 복사해서 X에 붙여넣을 수 있어야 한다. 코드 블록 안에서 한 문장을 여러 줄로 쪼개지 말 것 — 문단 구분(빈 줄)만 실제 줄바꿈이고, 한 문장/문단 안에서는 자연스러운 한 줄로 쓴다. X가 알아서 줄을 감싸므로, 보기 좋게 쪼갤 필요 없다.

하지 말 것

"I'm excited to announce..." / "Thrilled to share..." — 공식 발표 톤
"Here's what I learned today:" — 뻔한 도입
커밋 전체 나열하는 changelog 스타일
"🚀🔥💡🎉" 이모지 도배
"Thread 🧵" — 단일 트윗임
모든 문장이 같은 길이로 정렬된 깔끔한 구조
"implemented", "leveraged", "utilized" — 이력서 단어

좋은 예시

Before/Problem/Fix 포맷 (여러 항목일 때 기본):

Been building a knowledge library for AI coding agents. Had about 98 entries. Read Karpathy's LLM Wiki gist today, looked at mine again.

Before
- every entry had the same "what happened + lesson" format.

Problem
- when logging a debugging gotcha, "how to prevent it next time" was missing. When logging an experiment, "what conditions I ran it under" was missing. One template meant something important always got left out.

Fix
- 4 templates by situation. Debugging gets what-broke/why/how-fixed/prevention. Experiments get conditions/results/conclusion. Just fill in the blanks.

Before
- all entries aged the same way.

Problem
- "this flag was removed in Python 3.12" becomes wrong when the version changes, but "GPU doesn't support bf16" is true forever. Couldn't tell them apart, so cleanup meant manually checking everything.

Fix
- permanent/temporal tags. Planning to run a lint command periodically that only checks temporal entries — "is this still valid?" Permanent ones get skipped.

https://github.com/kangraemin/ai-knowledge

#BuildInPublic #ClaudeCode

이 포맷의 핵심:

뭘 바꿨는지(Fix)만 쓰면 changelog. 왜 바꿨는지(Problem)와 이전 상태(Before)를 같이 써야 읽는 사람이 맥락을 잡음.
Before → Problem → Fix 순서로 반복하면 여러 항목도 자연스럽게 이어짐.
Before/Problem/Fix 각각 줄바꿈 후 - bullet으로 내용 작성. 한 줄에 "Before: 내용" 붙이지 말 것.

제목 + bullet 포맷 (짧은 항목 여러 개):

Write e2e tests
- found 6 real bugs just by writing them
- 50 → 67 total

Delete unused agents
- 3 planner agents doing literally nothing
- Claude handles planning directly

Auto-cleanup installer
- stale files were silently breaking hooks
- source is truth now

#BuildInPublic #ClaudeCode

단일 항목 (자유 형식):

TIL Claude Code can bypass Write/Edit blocks
through Bash heredoc. Sneaky.

Had to add a 2nd defense layer with git diff.
#BuildInPublic

Removed 3 files today. Wrote 0 new ones.
Best kind of day.
#BuildInPublic

Okay so my hook wasn't checking for empty folder names.
Entire validation chain was getting skipped silently.

Fixed in 4 lines.
#BuildInPublic #DevTools

스토리텔링형 (긴 트윗):

Swore at my LLM out of frustration and somehow
got a noticeably better answer.

No way that's real. So I went and read every paper
I could find on this.

Turns out there's a 2025 study where rude prompts
hit 84.8% vs polite at 80.8%. Google's Sergey Brin
even said on stage "all models do better if you
threaten them with physical violence."

So Wharton ran a proper experiment. 9 prompts
including "I'll punch you" and "$1 trillion tip."
5 models. 25 runs per question.

Result: no consistent improvement.
The reason rude prompts sometimes work is boring —
they're just shorter and more direct.
Polite fluff actually distracts the model.

Don't swear at your AI. Just stop being wordy.

#BuildInPublic #LLM

나쁜 예시 (이렇게 절대 쓰지 말 것)

Today I implemented an automated cleanup mechanism
for the agent file management system, ensuring
stale files are properly removed during updates.
#BuildInPublic #AI #DevTools #Coding #SoftwareEngineering

→ 왜 나쁜가: "implemented", "mechanism", "ensuring" — 이력서/보도자료 톤. 해시태그 5개. 사람이 이렇게 안 씀.

🚀 Exciting update! Just shipped a major improvement
to my AI workflow enforcer. Quality scores improved
significantly. Check it out! 💪
#BuildInPublic #AI #DevTools

→ 왜 나쁜가: "Exciting update!", "Just shipped", "Check it out!" — LinkedIn 광고 톤. 이모지 2개. 구체적 숫자 없음.

변경 동기와 개선점

트윗에 "뭘 했다"만 쓰면 changelog랑 다를 바 없다. 사람들이 궁금한 건 왜 바꿨는지, 뭐가 나아졌는지다.

before → after: 이전에 뭐가 불편/불가능했고, 지금은 어떻게 됐는지
계기: 버그 리포트, 직접 쓰다 짜증난 점, 유저 피드백 등
숫자로 개선 표현: "3s → 0.2s", "5 steps → 1 command", "0 → 67 tests"

스크린샷 제안

트윗에 이미지가 있으면 engagement가 확연히 다르다. 트윗 초안과 함께 어떤 스크린샷을 찍으면 좋을지 구체적으로 제안한다.

좋은 스크린샷

before/after 비교: 변경 전후를 나란히 보여주는 게 가장 강력
실제 동작 화면: 새 기능이 실행되는 모습 (UI 변경, 터미널 출력 등)
코드 diff: 핵심 변경이 몇 줄인 경우, 짧은 diff가 임팩트 있음
에러 → 성공: 고친 버그의 에러 메시지 + 수정 후 정상 동작

제안 형식

트윗 초안 아래에 이렇게 제시:

📸 스크린샷 제안:
- [앱 화면] Claude Inspector에서 토큰 팝오버 클릭한 모습 — 비용 계산이 한눈에 보이는 컷
- [비교] 이전 버전(숫자만) vs 새 버전(단가×수량 계산 표시)

구체적으로 어디서 뭘 캡처하라고 알려줘야 한다. "앱 스크린샷" 같은 모호한 제안은 쓸모없다.

범위

/tweet을 호출한 프로젝트(현재 작업 디렉토리)의 커밋만 본다. 다른 프로젝트 디렉토리를 탐색하지 않는다.

커밋 없는 날

커밋이 없으면 "오늘 커밋 없음" 알려주고, 그래도 올리고 싶으면:

최근 작업 기반 회고/인사이트
개발 중 발견한 것
쓰고 있는 도구에 대한 짧은 생각