Style Guide
Keep Korean READMEs, specs, and customer-facing copy in one formal register with consistent citations, numbers, and list styles.
Overview
style-guide is an agent skill most often used in Build (also Launch, Grow) that enforces Korean document-type style rules and produces consistency audits with concrete corrections.
Install
npx skills add https://github.com/daleseo/korean-skills --skill style-guideWhat is this skill?
- Infers document type (학술 논문 vs 비즈니스 문서) and applies matching 어조 rules (~이다/~한다 vs 격식체 ~합니다)
- Runs style consistency audits with categorized findings (어조, 주어, 용어) and explicit correction suggestions
- Enforces academic conventions: APA parenthetical citations, *이탤릭* titles, English glosses for key terms
- Standardizes numbers, dates, and lists (가./나./다. or 1./2., Arabic numerals for counts and percentages)
- Ships v1.1.0 criteria tables so agents can self-check whether output matches the declared document profile
- Bundled correction walkthrough documents 23 style inconsistencies across categories
- v1.1.0 academic criteria matrix covers 어조, 용어, 숫자·단위, 목록, 인용, and 날짜
- Example analysis corpus references 234 academic papers (illustrative sample text)
Adoption & trust: 894 installs on skills.sh; 51 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have Korean drafts that mix casual and formal endings, inconsistent citations, and conflicting list or date formats, and readers lose trust in the product or paper.
Who is it for?
Solo builders publishing Korean READMEs, landing copy, or academic-style reports who want one register end-to-end before release.
Skip if: English-only documentation, intentional casual SNS voice, or finalized manuscripts that already passed publisher-specific copyediting.
When should I use this skill?
You are drafting or editing Korean Markdown for business or academic audiences and need document-type-specific tone, citations, and formatting enforced.
What do I get? / Deliverables
After the skill runs, the Markdown matches a declared academic or business profile with aligned tone, terminology, numbers, lists, and citations plus an audit trail of fixes.
- Style-consistent Korean document aligned to the chosen profile
- Inconsistency audit with categorized findings and suggested replacements
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Documentation is where solo builders first need repeatable Korean prose rules before those same standards are reused in launch and growth content. The skill targets editorial consistency—tone, terminology, APA-style citations, and numbering—which is the core Docs subphase concern for agent-written Markdown.
Where it fits
Normalize a bilingual README’s Korean sections to 격식체 ~합니다 before tagging a release.
Align pricing and feature bullets on a Korean landing page so honorifics and subject forms do not mix.
Refresh help-center Korean articles with the same list, date, and terminology standards as the main docs.
How it compares
Use instead of generic rewrite prompts that do not classify document type or cite 국립국어원-style formal rules.
Common Questions / FAQ
Who is style-guide for?
Solo and indie builders using Claude Code, Cursor, or Codex who write Korean product docs, customer-facing pages, or structured research summaries and need stable formal style.
When should I use style-guide?
During Build when polishing READMEs and specs; during Validate or Launch when tightening landing-page Korean; and during Grow when refreshing help or lifecycle content—whenever tone, citations, or numbering might be inconsistent.
Is style-guide safe to install?
It is a prose-style skill without implied shell or network calls; review the Security Audits panel on this Prism page and inspect SKILL.md in the repo before enabling it in your agent.
SKILL.md
READMESKILL.md - Style Guide
# 인공지능 윤리에 관한 연구 동향 분석 ## 1. 서론 본 연구는 최근 인공지능 윤리 분야의 연구 동향을 체계적으로 분석한다. 분석 대상은 2020년부터 2025년까지 발표된 학술 논문 234건이다. ## 2. 연구 방법 ### 2.1 문헌 검색 다음 데이터베이스를 활용하였다. - 가. Web of Science (Clarivate) - 나. Scopus (Elsevier) - 다. Google Scholar ### 2.2 분석 프레임워크 본 연구는 *Foucault* (1977)의 권력-지식(power-knowledge) 관점을 적용한다. ## 3. 결과 분석 결과, 책임성(accountability) 담론이 전체의 47%를 차지하였으며 (Smith & Lee, 2023), 투명성(transparency) 논의가 31%로 그 뒤를 이었다. ## 4. 결론 본 연구의 결과는 AI 윤리 담론이 점차 책임성 중심으로 재편되고 있음을 시사한다. --- **v1.1.0 적용 기준**: **학술 논문** | 카테고리 | 이 글에서 적용된 기준 | |---|---| | 어조 | ~이다/~한다 한다체, 본 연구·필자 | | 용어 | 학술 용어 + 영어 원어 병기 (책임성/accountability) | | 숫자·단위 | 엄격 아라비아 (`234건`, `47%`) | | 목록 | `가./나./다.` 또는 `1./2.` 번호, ~함·명사구 종결 | | 인용 | APA 정형 `(Smith & Lee, 2023)`, 책 제목 *이탤릭* | | 날짜 | `2020년부터 2025년까지` 한글 형식 | **일관성 평가**: ✅ 일관됨. APA 인용·이탤릭·영어 병기 모두 학술 표준 준수. # 스타일 일관성 분석 예시 이 문서는 `inconsistent.md`에서 `consistent.md`로 교정하는 과정에서 감지된 스타일 불일치와 교정 근거를 설명합니다. --- ## 문서 타입 분석 - **판단**: 비즈니스 문서 (제품 소개서) - **근거**: 고객 대상, 공식적 톤, 제품 정보 포함 - **권장 스타일**: 격식체 경어 (~합니다), 표준 용어, 일관된 날짜 형식 --- ## 발견된 불일치 (총 23개) ### 1. 어조 및 격식 (3개) #### 불일치 #1: 경어체 혼용 - 🔄 "~합니다": 8회 사용 - 🔄 "~해요": 2회 사용 ("제공해요", "보호해요") - ✅ **제안**: 비즈니스 문서이므로 "~합니다" 격식체로 통일 - 📚 **근거**: 국립국어원 공문서 작성 지침 - 대외 문서는 격식체 사용 **교정**: - "제공해요" → "제공합니다" - "보호해요" → "보호합니다" #### 불일치 #2: 주어 불일치 - 🔄 "우리 회사": 1회 (문서 끝) - 🔄 "저희 회사": 1회 (문서 시작) - ✅ **제안**: 고객 대상 문서이므로 "저희"로 통일 (겸양 표현) - 📚 **근거**: 실무 관행 - 대외 문서는 겸손한 표현 사용 **교정**: - "© 2026 우리 회사" → "© 2026 저희 회사" #### 불일치 #3: 문장 종결 불완전 - 🔄 "개발자는 SDK를 사용하여 기능 확장" (종결어미 없음) - ✅ **제안**: 완전한 문장으로 종결 - 📚 **근거**: 문법 규칙 - 문장은 종결어미로 끝나야 함 **교정**: - "기능 확장" → "기능을 확장할 수 있습니다" --- ### 2. 용어 통일 (5개) #### 불일치 #4: 동일 개념 다른 표현 - 🔄 "사용자": 4회 - 🔄 "유저": 1회 - ✅ **제안**: "사용자"로 통일 (다수결 + 공식 문서 표준) - 📚 **근거**: 국립국어원 표준 용어 **교정**: - "유저는 여러 기기에서..." → "사용자는 여러 기기에서..." #### 불일치 #5: 외래어 표기 - 띄어쓰기 - 🔄 "데이터 베이스": 1회 (띄어쓰기) - 🔄 "웹사이트": 1회 (붙여쓰기) - ✅ **제안**: "데이터베이스", "웹사이트" 붙여쓰기로 통일 - 📚 **근거**: 국립국어원 외래어 표기법 **교정**: - "데이터 베이스" → "데이터베이스" #### 불일치 #6: 띄어쓰기 오류 (의존명사) - 🔄 "접근할수있습니다" (붙여쓰기 오류) - ✅ **제안**: "접근할 수 있습니다" (의존명사 "수" 띄어쓰기) - 📚 **근거**: 국립국어원 띄어쓰기 규정 **교정**: - "접근할수있습니다" → "접근할 수 있습니다" #### 불일치 #7: 외래어 약어 - 🔄 "Android OS" (공식 표기) - 🔄 "Android" (축약) - ✅ **제안**: "Android"로 통일 (공식 제품명, OS 생략 가능) - 📚 **근거**: Kakao Enterprise 가이드 - "AOS"는 비공식, "Android" 사용 **교정**: - "Android OS" → "Android" #### 불일치 #8: 따옴표 혼용 - 🔄 큰따옴표 ("사용자"): 1회 - 🔄 작은따옴표 ('보안'): 1회 - ✅ **제안**: 강조 표기는 **굵게**로 통일 (용어 강조에 따옴표 불필요) - 📚 **근거**: 테크니컬 라이팅 가이드 - 강조는 굵게 또는 기울임 **교정**: - "사용자" → 사용자 (따옴표 제거) - '보안' → **보안** (굵게 처리) --- ### 3. 숫자 및 단위 (4개) #### 불일치 #9: 단위 띄어쓰기 - 🔄 "4 GB" (띄어쓰기): 1회 - 🔄 "500MB" (붙여쓰기): 1회 - ✅ **제안**: SI 표기법에 따라 "4 GB", "500 MB" 띄어쓰기로 통일 - 📚 **근거**: 국제단위계(SI) 표기법 **교정**: - "500MB" → "500 MB" #### 불일치 #10: 화폐 단위 띄어쓰기 - 🔄 "10,000 원" (띄어쓰기): 1회 - 🔄 "5만원" (붙여쓰기): 1회 - ✅ **제안**: "10,000원", "50,000원"으로 통일 (아라비아 숫자 + 붙여쓰기) - 📚 **근거**: 실무 관행 **교정**: - "10,000 원" → "10,000원" - "5만원" → "50,000원" (표기 형식 통일) #### 불일치 #11: 숫자 표기 혼용 - 🔄 "20%" (아라비아 숫자): 기본 - 🔄 "1년" (아라비아 + 한글): 관용 표현 허용 - ✅ **판단**: 혼용 허용 (구체적 수치는 아라비아, 기간은 혼용 가능) - 📚 **근거**: 실무 관행 **교정 불필요** #### 불일치 #12: 퍼센트 띄어쓰기 - 🔄 모두 "20%" (올바름) - ✅ **판단**: 일관적, 교정 불필요 --- ### 4. 목록 구조 (2개) #### 불일치 #13: 목록 부호 혼용 - 🔄 "1. 2. 3.": 2개 목록 - 🔄 "1. - 3)": 1개 목록 (혼용) - ✅ **제안**: 모두 "1. 2. 3." 형식으로 통일 - 📚 **근거**: Markdown 관행 + 다수결 **교정**: ``` 1. 빠른 처리 속도 - 메모리 효율성 개선 → 2. 메모리 효율성 개선 3) 직관적인 UI → 3. 직관적인 UI ``` #### 불일치 #14: 목록 종결어미 혼용 - 🔄 완전 문장 ("~합니다"): 2개 항목 - 🔄 명사형 ("계정 생성", "기능 확장"): 2개 항목 - 🔄 명령형 ("~하세요"): 1개 항목 - ✅ **제안**: "~합니다" 완전 문장으로 통일 - 📚 **근거**: 문서의 격식적 톤 + 다수결 **교정**: ``` 2. 계정 생성 → 2. 계정을 생성합니다. 3) 로그인하세요 → 3. 로그인합니다. - 설정 메뉴에서 환경 설정 → 4. 설정 메뉴에서 환경을 설정합니다. ``` --- ### 5. 인용 및 강조 (3개) #### 불일치 #15: 강조 표기 혼용 - 🔄 **굵게**: 2회 ("혁신적인", "API") - 🔄 *기울임*: 1회 ("데이터 베이스") - 🔄 따옴표: 2회 ("사용자", '보안') - 🔄 백틱: 1회 (`SDK`) - ✅ **제안**: 일반 강조는 **굵게**, 코드/명령어는 백틱(`)으로 구분 - 📚 *