DongHyeonkaandClaude Opus 5
25644cc4d9
.agents/skills의 technical-document-author, revising-korean-technical-prose, writing-natural-korean을 korean-technical-blog-skills-bundle-v1의 세 스킬로 교체한다. - writing-korean-technical-blogs: 문제·제약·선택·구현·결과·한계 구조화 - reducing-ai-like-korean-writing: 상투성·추상화·반복 제거 - editing-korean-grammar-and-expression: 맞춤법·띄어쓰기·호응 검수 상류를 수정하지 않고 복사했다. diff -r 0건, MANIFEST.sha256 검증 통과, 번들 validate_skill.py 3/3 PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
4.2 KiB
name, description, metadata
| name | description | metadata | ||||
|---|---|---|---|---|---|---|
| writing-korean-technical-blogs | Use when drafting, restructuring, or revising a Korean technical blog post from source material, experiment notes, incident records, code, or an existing draft, especially when the article must expose the problem, constraints, decisions, implementation, evidence, results, and limitations without inventing facts. |
|
한국어 기술 블로그 작성
개요
자료의 기술적 판단과 증거를 보존하면서 독자가 문제·제약·선택·구현·결과·한계를 따라갈 수 있는 기술 블로그를 작성하거나 재구성한다.
좋은 글처럼 보이는 것보다 자료가 실제로 뒷받침하는 내용을 선명하게 전달하는 것이 우선이다.
REQUIRED SUB-SKILL: 초안을 완성한 뒤 reducing-ai-like-korean-writing으로 상투성·추상화·반복을 점검한다.
REQUIRED SUB-SKILL: 최종 맞춤법·띄어쓰기·호응 검수에는 editing-korean-grammar-and-expression을 사용한다.
사용 경계
자료 기반 글 한 편을 작성·재구성·검토할 때 사용한다. 조사·실행 검증·이미지·게시·재개 상태까지 관리해야 하면 하네스를 사용한다. 순수 문법이나 문체 편집에는 하위 스킬을 직접 사용한다.
입력
원자료·초안, 목적, 독자, 글 유형, 검증 상태, 보호할 수치·코드·인용·공식 명칭과 문체 가이드를 사용한다. 필수 정보가 없으면 [확인 필요: 항목]으로 남기고 선택 섹션은 생략한다.
필수 절차
- 잠금: 수치, 날짜, 버전, 단위, 코드, 명령어, URL, 인용, 법무·보안 문구와 공식 명칭을 보호한다.
- 근거 지도: 각 핵심 주장에 원자료, 외부 출처, 관찰, 추론, 미검증 상태를 연결한다.
- 프로필 선택:
references/structure-patterns.md와profiles/에서 독자와 글 유형에 맞는 골격을 고른다. - 구조화: 첫 15% 안에 문제·대상·독자가 얻을 정보를 드러내고, 핵심 결과가 있으면 측정 범위와 함께 먼저 제시한다.
- 작성: 선택 이유와 대안, 구현·실험, 결과, 비용, 실패 조건과 한계를 분리한다.
- 문체 정리: 근거 없는 평가어와 의례적 도입·결론을 줄이되 경험·실패·감정을 만들지 않는다.
- 검증: 보호 항목, 불확실성, 불리한 결과, 용어와 문체를 원자료와 다시 대조한다.
빠른 판정
| 입력 상태 | 처리 |
|---|---|
| 근거가 충분함 | 글에 반영 |
| 필수 근거가 없음 | [확인 필요] 또는 최소 질문 |
| 선택 정보가 없음 | 섹션 생략 |
| 코드·인용·법무 문구 | 그대로 보존 |
| 미측정 결과 | 미측정 상태와 다음 검증만 기록 |
절대 규칙
- 출처 없는 수치, 성과, 사용자 반응, 실패담, 감정이나 기업 입장을 만들지 않는다.
- 가능성을 확정으로, 상관관계를 인과로, 일부 결과를 전체 결과로 강화하지 않는다.
- 홍보를 위해 비용·위험·실패 조건·불리한 결과를 삭제하지 않는다.
- 기술 용어를 문체 변주용으로 바꾸거나 다른 기업의 말투를 모방하지 않는다.
- 인간적으로 보이게 하려고 오류·억지 유머를 넣지 않는다.
출력
기본값은 article이다. outline, audit, revision, compare, publication-package는 references/output-modes.md를 따른다.
대표 예시
자료: 배포에 평균 18분이 걸렸다. 실패 단계 추적이 어려웠다. 재설계 후 단계별 로그를 확인할 수 있다.
도입: 기존 배포는 평균 18분이 걸렸고, 실패가 발생해도 어느 단계에서 멈췄는지 확인하기 어려웠다. 이 글에서는 배포 파이프라인을 재설계해 실패 단계를 추적할 수 있게 만든 과정을 설명한다.
흔한 실패
| 실패 | 대응 |
|---|---|
| 없는 숫자로 구체화 | 확인 필요 표시 |
| 장점만 나열 | 대안·비용·적용 조건 포함 |
| 결론에서 본문 반복 | 결과·한계·다음 검증 제시 |
| 코드나 단위 변경 | 수정 롤백 |
배포 전에는 tests/의 사례와 압박 시나리오로 검증한다.