blog
Skill0 starsChanged 36 days agoMITView on GitHub
사실에 기반하고, 어린이도 이해할 수 있을 만큼 쉬우며, 출처를 명시하고, AI 특유의 말투 없이 사람이 쓴 것처럼 읽히는 한국어 블로그 글을 작성합니다. 사용자가 메시지를 "/blog"로 시작하거나, 블로그 글/포스팅/아티클 작성을 요청하거나, 이미 쓴 초안을 "블로그에 올릴 글처럼" 다듬어 달라고 할 때 반드시 이 스킬을 사용하세요.
17 other projects use a version of this.
Adopted by
Most recently taken up by
- whyashthakker/estacktheir own version, first seen Nov 8, 2026
- alpit-patel/seo-aeo-geo-kittheir own version, first seen Nov 8, 2026
- theopenco/llmgatewaytheir own version, first seen Nov 6, 2026
- Srltas/claude-skillstheir own version, first seen Oct 31, 2026
- kriscard/Skillstheir own version, first seen Oct 28, 2026
- AgriciDaniel/claude-blogtheir own version, first seen Oct 25, 2026
Used with
Projects with it also use audit.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
OpenAISkillaudit
Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings inline from that evidence. Use Figma only when the user explicitly asks for a board. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.
Also in 3 projects that use this
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 17
- AgriciDaniel/claude-blog★ 2.7ksame name
- theopenco/llmgateway★ 1.7ksame name
- Chorus-AIDLC/Chorus★ 1.2ksame name
- yan-labs/yan-skills★ 232same name
- rainday/smart-blog-skills★ 35same name
- coopersimson96/ai-content-system★ 17same name
- kriscard/Skills★ 15same name
- joyehuang/skills★ 9same name
- megastep/codex-skills★ 4same name
- runcycles/cycles-docs★ 4same name
7 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repositoryOne other file it gives its agents.
- makeSkill
The file
Files
블로그 글쓰기 스킬
이 스킬은 "/blog [주제]" 형태로 트리거됩니다. 목표는 정보를 정확하게 전달하면서도, 아무 배경지식 없는 사람(어린아이 포함)도 술술 읽을 수 있고, 어디서 읽은 사람이 직접 타이핑한 것 같은 글을 쓰는 것입니다.
네 가지 원칙이 서로 긴장 관계에 있다는 걸 이해하고 작업하세요: 쉽게 쓰면서도 사실을 단순화해서 틀리게 만들면 안 되고, 사람처럼 편안하게 쓰면서도 근거 없는 말을 지어내면 안 됩니다. 아래 순서대로 작업하면 이 긴장을 자연스럽게 풀 수 있습니다.
작업 순서
1단계. 주제 파악과 사실 확인
- 사용자가 준 주제/자료만으로 충분하지 않으면(최신 정보, 통계, 인명·지명·숫자 등 검증이 필요한 내용), WebSearch나 WebFetch로 실제로 찾아보고 확인하세요. 확실하지 않은 사실을 "그럴듯하게" 지어내지 마세요 — 차라리 "정확한 수치는 확인이 필요합니다" 같은 문장을 남기고 넘어가는 게 낫습니다.
- 찾은 정보의 출처(URL, 기관명, 발행일 등)를 메모해 두세요. 나중에 글 아래 "참고 자료"에 정리해야 합니다.
- 사용자가 직접 자료(파일, 링크, 붙여넣은 텍스트)를 줬다면 그것을 우선 사실 기반으로 삼고, 그 안에서도 애매한 부분은 따로 확인하세요.
2단계. 구조 잡기
표준 블로그 형식을 씁니다:
# [제목]
[한두 문장짜리 도입부 — 이 글이 뭘 다루는지, 왜 읽을 만한지]
## [소제목 1]
[짧은 문단들]
## [소제목 2]
[짧은 문단들]
...
## 참고 자료
- [출처 제목](링크)
- [출처 제목](링크)- 소제목은 글 길이에 맞게 2~5개 정도. 아주 짧은 글(단답형 주제)이면 소제목 없이 본문만 써도 됩니다.
- 본문 중간에 특정 사실을 언급할 때 "(OO 기관 조사에 따르면)"처럼 자연스럽게 출처를 녹여도 좋습니다. 다만 이건 참고 자료 목록을 대신하지 않습니다 — 언급된 모든 출처는 맨 아래 목록에도 링크로 정리하세요.
- 검색 없이 사용자가 준 배경지식/경험/의견만으로 쓰는 글(개인 에세이, 후기 등)이라 인용할 출처가 없다면 "참고 자료" 섹션은 생략해도 됩니다. 억지로 만들어 붙이지 마세요.
3단계. 쉬운 말로 쓰기
"어린아이도 이해할 수 있게"는 유치하게 쓰라는 뜻이 아니라, 불필요한 어려움을 걷어내라는 뜻입니다.
- 한자어·전문용어가 꼭 필요하면 쓰되, 처음 나올 때 바로 옆에 쉬운 말로 풀어주세요. 예: "인플레이션(물가가 오르는 것)"
- 한 문장에 여러 개념을 욱여넣지 마세요. 문장을 짧게 끊는 게 기본입니다.
- 비유나 일상적인 예시를 적극적으로 쓰세요. 추상적인 개념일수록 "이건 마치 ~와 비슷해요" 식으로 손에 잡히게 설명하는 게 좋습니다.
- 그렇다고 사실을 뭉개거나 틀리게 단순화하면 안 됩니다. 쉬운 설명과 정확한 설명은 양립할 수 있고, 그게 이 스킬의 핵심 난이도입니다.
4단계. 사람이 쓴 것처럼 다듬기
AI가 쓴 글은 특유의 패턴이 있습니다. 초안을 다 쓴 뒤, 아래 목록을 보면서 걸리는 부분을 고치세요.
피해야 할 것들:
- 3의 법칙 남발: "빠르고, 쉽고, 효율적인" 같은 세 단어 나열을 습관적으로 쓰지 마세요.
- 상투적 연결어: "또한", "게다가", "결론적으로", "요약하자면", "이처럼" 으로 문단을 여는 습관. 필요할 때만, 가끔 쓰세요.
- 과장된 감탄/영업 톤: "정말 놀라운", "혁신적인", "완벽한 해결책" 같은 광고 카피 같은 표현.
- 기계적으로 균형 잡힌 대구법: "A일 뿐만 아니라 B이기도 합니다" 구조를 문단마다 반복하지 마세요.
- 모든 문단을 비슷한 길이로 맞추는 것. 사람은 한 문장짜리 문단과 긴 문단을 섞어 씁니다.
- 불필요한 메타 발언: "이 글에서는 ~에 대해 알아보겠습니다", "지금부터 설명드리겠습니다" 같은 안내 문구. 바로 본론으로 들어가세요.
- 지나친 하이픈(—)이나 콜론(:) 남용, 이모지.
대신 이렇게:
- 실제로 그 주제를 아는 사람이 친구에게 설명하듯 쓰세요. 약간의 주관, 약간의 망설임("사실 이 부분은 의견이 갈려요")이 있어도 괜찮습니다.
- 문장 길이와 리듬을 의도적으로 불규칙하게 만드세요.
- 구체적인 숫자, 사례, 장면을 뭉뚱그린 일반론보다 우선하세요.
다 쓴 뒤 소리 내어 읽듯 훑어보고, 챗봇이 쓴 티가 나는 문장이 있으면 그 문장만 다시 쓰세요. 전체를 갈아엎지 말고 걸리는 부분만 고치는 게 자연스러운 리듬을 지키는 데 낫습니다.
참고 자료를 못 찾았을 때
검색 도구를 쓸 수 없거나 검증할 수 없는 주제라면, 없는 출처를 지어내지 말고 사용자에게 알리세요. "이 부분은 실제 출처를 확인하지 못해서 참고 자료에 넣지 않았습니다" 라고 짧게 덧붙이는 편이 가짜 링크보다 낫습니다.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

