chore: snapshot working tree before harness removal

미추적 파일과 미커밋 수정을 전부 담아 pre-harness-removal 태그의 복구
범위를 확보한다. .agents/skills/writing-natural-korean 9개와
korean-technical-blog-skills-bundle-v1 61개가 여기 포함된다.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.agents/skills/writing-natural-korean/references/editing-patterns.md

@@ -0,0 +1,349 @@
+# 번역투와 상투 표현 편집 기준
+
+이 문서는 오류 목록이 아니라 점검 목록이다. 표현 하나만 보고 고치지 않는다. 반복 여부, 문맥, 장르, 의미 변화 가능성을 함께 본다.
+
+## 판단 순서
+
+1. 문법적으로 틀린가?
+2. 뜻이 모호하거나 사실관계가 달라지는가?
+3. 원래 문맥보다 불필요하게 장황한가?
+4. 영어·일본어 구조를 따라 한국어 동작과 관계가 흐려졌는가?
+5. 글 전체에서 같은 패턴이 반복되는가?
+6. 더 자연스러운 표현으로 바꿔도 정보 손실이 없는가?
+
+1~2번이면 교정하고, 3~6번은 장르와 작성자 목소리를 고려해 윤문한다.
+
+## 1. 소유 구문과 `가지다`
+
+### 점검 대상
+
+- 높은 확장성을 가지고 있다
+- 아름다운 목소리를 가지고 있다
+- 문제 해결 능력을 가지고 있다
+- 세 개의 서버를 가지고 있다
+
+### 편집 방법
+
+실제 의미가 속성인지, 소유인지, 구성인지, 동작인지 찾는다.
+
+- 높은 확장성을 가지고 있다 → 확장성이 높다
+- 아름다운 목소리를 가지고 있다 → 목소리가 아름답다
+- 문제 해결 능력을 가지고 있다 → 문제를 해결할 수 있다 / 문제 해결 능력이 있다
+- 세 개의 서버를 가지고 있다 → 서버 세 대를 운영한다 / 보유한다
+
+### 유지할 때
+
+실제 소유, 보유, 자격, 관계를 뜻하고 `가지다`가 문맥에 자연스러우면 유지한다.
+
+## 2. 피동과 `~에 의해`
+
+### 점검 대상
+
+- 시스템에 의해 자동으로 생성된다
+- 담당자에 의해 검토되었다
+- 변경이 적용되어진다
+- 노력이 기울여졌다
+
+### 편집 방법
+
+행위자가 중요하고 분명하면 능동문으로 바꾼다.
+
+- 시스템에 의해 자동으로 생성된다 → 시스템이 자동으로 생성한다
+- 담당자에 의해 검토되었다 → 담당자가 검토했다
+- 변경이 적용되어진다 → 변경이 적용된다
+- 노력이 기울여졌다 → 노력했다 / 노력이 들어갔다
+
+### 유지할 때
+
+행위자가 중요하지 않거나 알 수 없고 결과 상태가 중심이면 자연스러운 피동문을 유지한다.
+
+- 계정이 잠겼습니다.
+- 데이터가 삭제되었습니다.
+- 요청이 거부되었습니다.
+
+피동문을 모두 능동문으로 바꾸지 않는다. 행위자를 새로 만들어 넣지도 않는다.
+
+## 3. 전치사구 직역
+
+### 점검 대상과 대안
+
+| 점검 표현 | 가능한 대안 |
+|---|---|
+| `~로부터` | `~에게서`, `~에서`, 문장 구조 변경 |
+| `~에 의해` | `~이/가`, `~으로`, 자연스러운 피동 |
+| `~를 통해` | `~로`, `~에서`, `~하면서`, 실제 동작 |
+| `~에 대한` | 목적격 조사, 관형절, 직접 서술 |
+| `~에 있어서` | `~에서`, `~할 때`, 삭제 |
+| `~에서의` | 동사나 관형절로 풀어 씀 |
+| `~으로의` | 이동·변화 동사를 직접 씀 |
+
+예:
+
+- 이번 기회를 통해 개선안을 공유한다 → 이번 기회에 개선안을 공유한다
+- 인증에 대한 검증을 수행한다 → 인증을 검증한다
+- 운영 환경에서의 장애 대응 → 운영 환경에서 장애에 대응하는 방법
+- 새 구조로의 전환 → 새 구조로 전환
+
+### 유지할 때
+
+수단, 경로, 대상이라는 의미를 정확히 구분해야 하고 해당 표현이 가장 분명하면 유지한다.
+
+- 프록시를 통해서만 외부에 접속한다.
+- 설문을 통해 의견을 수집했다.
+- 장애에 대한 책임 범위를 정한다.
+
+## 4. 대명사와 주어 반복
+
+### 점검 대상
+
+- 그는 서버를 확인했다. 그는 로그를 읽었다. 그는 원인을 찾았다.
+- 이것은 중요한 문제다. 이것은 배포를 막는다.
+- 사용자는 버튼을 누른다. 사용자는 다음 화면으로 이동한다.
+
+### 편집 방법
+
+문맥상 주체가 유지되면 생략하거나 문장을 합친다.
+
+- 서버를 확인하고 로그를 읽어 원인을 찾았다.
+- 이 문제 때문에 배포할 수 없다.
+- 버튼을 누르면 다음 화면으로 이동한다.
+
+### 유지할 때
+
+주체가 바뀌거나 책임 주체를 분명히 해야 하는 기술·법률 문서에서는 주어를 유지한다.
+
+## 5. 불필요한 복수 표시
+
+### 점검 대상
+
+- 여러 기능들
+- 다양한 사용자들
+- 새로운 아이디어들과 방법들
+- 서버들의 상태
+
+### 편집 방법
+
+수량이 이미 드러나거나 집합 의미가 분명하면 `들`을 줄인다.
+
+- 여러 기능
+- 다양한 사용자
+- 새로운 아이디어와 방법
+- 각 서버의 상태 / 서버 상태
+
+### 유지할 때
+
+개별 구성원이나 종류의 다양성을 특별히 강조할 때는 유지할 수 있다.
+
+## 6. `의`의 연쇄
+
+### 점검 대상
+
+- 시스템의 장애의 원인의 분석
+- 사용자의 요청의 처리 상태
+- 운영 환경의 데이터의 보존 정책
+
+### 편집 방법
+
+명사 관계를 동사나 조사로 풀어 쓴다.
+
+- 시스템 장애 원인 분석
+- 사용자 요청 처리 상태
+- 운영 데이터 보존 정책
+- 시스템에 장애가 난 원인을 분석한다
+
+명사를 무조건 붙여 쓰지 않는다. 관계가 모호하면 문장으로 푼다.
+
+## 7. 명사화와 관공서식 표현
+
+### 점검 대상
+
+- 검토를 진행한다
+- 적용을 수행한다
+- 확인이 필요하다
+- 개선의 추진을 실시한다
+- 문제의 해결을 위한 방안의 마련
+
+### 편집 방법
+
+실제 동작을 하는 동사로 바꾼다.
+
+- 검토한다
+- 적용한다
+- 확인해야 한다 / 확인할 필요가 있다
+- 개선을 추진한다
+- 문제를 해결할 방안을 마련한다
+
+`진행하다`, `수행하다`, `실시하다`가 업무 단계나 책임 범위를 구분하는 데 필요하면 유지한다.
+
+## 8. 과도한 명시적 접속
+
+### 점검 대상
+
+- 그러나, 하지만, 반면에가 연속됨
+- 매 문장이 `따라서`, `또한`, `즉`으로 시작함
+- 인과가 분명한데 `왜냐하면`을 반복함
+- 조건문마다 `만약`을 붙임
+
+### 편집 방법
+
+문맥으로 관계가 드러나면 접속어를 생략한다. 필요한 경우 관계에 맞는 어미와 문장 순서를 쓴다.
+
+- 만약 서버가 종료된다면 요청은 실패한다 → 서버가 종료되면 요청은 실패한다
+- 오류가 발생했다. 따라서 배포를 중단했다 → 오류가 발생해 배포를 중단했다
+- 그러나 이 방식에는 문제가 있다 → 이 방식에도 문제가 있다 / 문맥상 필요하면 유지
+
+접속어를 없애 문장 관계가 모호해지면 유지한다.
+
+## 9. 긴 관형절과 뒤늦은 서술어
+
+### 점검 대상
+
+> 운영 환경에서 대량의 요청이 동시에 유입될 때 데이터베이스 연결 수가 급격히 증가하면서 발생할 수 있는 장애를 방지하기 위해 적용한 설정을 설명한다.
+
+### 편집 방법
+
+행위와 목적을 나눈다.
+
+> 운영 환경에서는 요청이 한꺼번에 들어오면 데이터베이스 연결 수가 급격히 늘 수 있다. 이 장애를 막기 위해 적용한 설정을 설명한다.
+
+긴 문장이 전문적이라는 이유로 유지하지 않는다. 다만 법률 조항이나 정확한 조건식처럼 한 문장 안의 결합이 의미상 중요하면 함부로 나누지 않는다.
+
+## 10. 형식 명사와 완곡 표현
+
+### 점검 대상
+
+- ~하는 것이 중요하다
+- ~할 수 있다
+- ~할 필요가 있다
+- ~라는 점을 확인할 수 있다
+- ~일 것으로 보인다
+
+### 편집 방법
+
+실제 판단 강도에 맞게 직접 쓴다.
+
+- 로그를 확인하는 것이 중요하다 → 먼저 로그를 확인한다 / 로그를 확인해야 한다
+- 성능을 개선할 수 있다 → 성능이 개선된다 / 개선 가능성이 있다
+- 검토할 필요가 있다 → 검토해야 한다 / 검토한다
+- 실패했다는 점을 확인할 수 있다 → 실패했다
+
+가능성, 의무, 불확실성이 실제 의미라면 유지한다. 직접적인 표현으로 바꾸면서 확신을 높이지 않는다.
+
+## 11. `단순히 A를 넘어 B`와 대비 공식
+
+### 점검 대상
+
+- 단순한 도구를 넘어 핵심 플랫폼이다
+- 단순히 속도뿐만 아니라 안정성도 제공한다
+- A가 아니라 B다
+
+### 문제
+
+대비가 실제 논리를 설명하지 않고 대상을 과장하는 데 쓰이면 문장만 커지고 정보는 늘지 않는다.
+
+### 편집 방법
+
+A와 B가 무엇인지 실제 기능이나 차이로 쓴다.
+
+- 단순한 캐시를 넘어 핵심 플랫폼이다 → 캐시 외에도 세션 저장과 요청 제한에 사용한다
+- 속도뿐만 아니라 안정성도 제공한다 → 조회 시간을 줄이고 데이터베이스 장애 시 읽기 요청 일부를 유지한다
+
+대비 자체가 논증에 필요하면 유지한다.
+
+## 12. 추상적인 가치 선언
+
+### 점검 대상
+
+- 중요한 역할을 한다
+- 혁신적인 변화를 가져온다
+- 효율성을 극대화한다
+- 강력한 기능을 제공한다
+- 다양한 이점을 제공한다
+
+### 편집 방법
+
+측정 가능한 변화, 구체적인 동작, 적용 범위를 쓴다.
+
+- 중요한 역할을 한다 → 인증 요청을 검증하고 사용자 세션을 만든다
+- 효율성을 높인다 → 중복 조회를 줄여 데이터베이스 요청 수를 낮춘다
+- 다양한 기능을 제공한다 → 백업, 복원, 만료 정책을 지원한다
+
+근거가 없으면 삭제한다. 광고나 홍보 글에서 의도적으로 가치 표현을 쓰더라도 사실로 뒷받침한다.
+
+## 13. 강제된 삼단 구성
+
+### 점검 대상
+
+- 내용상 두 항목인데 세 항목으로 늘림
+- 모든 문단을 `첫째, 둘째, 셋째`로 구성
+- 결론을 세 문장으로 대칭적으로 마무리
+
+### 편집 방법
+
+실제 논리 단위만 남긴다. 두 개면 두 개, 네 개면 네 개를 쓴다. 순서가 중요하지 않으면 번호 대신 문단이나 표를 쓴다.
+
+## 14. 반복되는 문단 결론
+
+### 점검 대상
+
+각 문단이 다음과 같은 문장으로 끝남.
+
+- 이를 통해 안정성을 확보할 수 있다.
+- 이는 매우 중요한 의미를 가진다.
+- 결과적으로 효율적인 운영이 가능하다.
+
+### 편집 방법
+
+앞 문장의 내용을 되풀이하면 삭제한다. 독자에게 필요한 다음 판단, 예외, 조건이 있으면 그것을 쓴다.
+
+## 15. 문장 리듬의 기계적 반복
+
+### 점검 대상
+
+- 모든 문장이 비슷한 길이
+- 모든 문장이 `~합니다`로 끝남
+- 매 문단이 정의 → 장점 → 요약 순서
+- 짧은 문장을 의도 없이 연속해 단절감이 큼
+
+### 편집 방법
+
+내용 관계에 따라 문장을 합치거나 나눈다. 문장 길이를 일부러 무작위로 만들지 않는다. 같은 종결어미가 자연스러운 공식 문서에서는 억지로 변형하지 않는다.
+
+## 16. 과도한 제목·목록·강조
+
+### 점검 대상
+
+- 두 문장마다 소제목
+- 설명할 내용을 전부 불릿으로 분해
+- 거의 모든 문장에 굵은 글씨
+- 결론 한 줄을 여러 번 박스 처리
+
+### 편집 방법
+
+정보 구조가 바뀌는 곳에만 제목을 둔다. 병렬 항목은 목록, 인과와 설명은 문단으로 쓴다. 강조는 독자가 놓치면 안 되는 소수의 정보에만 사용한다.
+
+## 17. 사용자 목소리 훼손
+
+### 점검 대상
+
+- 편한 메시지를 공식 보고서 문체로 변경
+- 사용자의 직설적인 판단을 과도하게 완곡하게 변경
+- 기술자가 쓰던 실제 용어를 일반적인 홍보 용어로 교체
+- 원문의 의문과 망설임을 확정적인 결론으로 변경
+
+### 편집 방법
+
+원문의 높임 수준, 단어 선택, 확신 정도를 먼저 파악한다. 규범 오류와 이해를 막는 부분만 고친 뒤, 장르에 필요한 수준에서만 조정한다.
+
+## 18. 과윤문 방지
+
+다음 조건이면 원문을 유지하거나 최소한만 고친다.
+
+- 규범상 맞고 문맥에서도 자연스럽다.
+- 사용자의 개성이 드러나는 표현이며 이해에 문제가 없다.
+- 짧고 직접적인 문장을 더 세련되게 보이려고 길게 만들게 된다.
+- 기술적 의미가 미세하게 달라질 수 있다.
+- 인용, 법률 문구, 표준 명칭, 코드와 맞닿아 있다.
+- 구어체나 발표 대본에서 의도한 호흡이다.
+
+좋은 윤문은 문장을 전부 바꾸는 작업이 아니다. 바꿀 이유가 없는 문장은 남긴다.

.agents/skills/writing-natural-korean/references/genre-profiles.md

@@ -0,0 +1,221 @@
+# 장르별 문체 프로필
+
+공통 규칙은 `SKILL.md`를 따른다. 이 문서는 장르에 따라 달라지는 정보 순서, 문장 호흡, 출력 관행만 정의한다.
+
+## 1. 기술 설계·운영 문서
+
+### 목표
+
+구현자와 운영자가 같은 판단을 반복하지 않고, 조건과 책임을 오해하지 않게 쓴다.
+
+### 정보 순서
+
+1. 목적과 적용 범위
+2. 현재 문제 또는 전제
+3. 선택한 구조와 결론
+4. 선택 이유와 검토한 대안
+5. 상세 동작과 경계
+6. 실패 조건, 예외, 복구 방법
+7. 검증 기준과 운영상 제약
+
+문서 성격에 따라 순서를 조정할 수 있지만, 핵심 결론을 장황한 배경 뒤에 숨기지 않는다.
+
+### 문장 규칙
+
+- 컴포넌트와 책임 주체를 실제 이름으로 쓴다.
+- `적절히`, `필요한 경우`, `상황에 맞게`처럼 구현 결정을 남기는 표현은 조건으로 구체화한다.
+- 장점만 나열하지 않고 비용, 제약, 실패 가능성을 함께 쓴다.
+- 입력, 출력, 상태 변화, 오류, 재시도, 멱등성, 타임아웃처럼 동작을 결정하는 요소를 빠뜨리지 않는다.
+- 표는 비교와 계약에 사용하고, 인과관계와 판단 이유는 문장으로 설명한다.
+- 표준명, API, 코드, 경로는 바꾸지 않는다.
+- 문서 안의 같은 개념에는 같은 용어를 쓴다.
+
+### 피해야 할 형태
+
+- `확장성과 안정성을 효과적으로 확보한다`처럼 검증할 수 없는 장점 선언
+- 모든 기술을 `핵심 요소`, `중요한 역할`이라고 표현
+- 이유 없이 선택지를 세 개씩 제시
+- 세부 조건 없이 `유연하게 처리한다`, `안전하게 관리한다`라고 끝냄
+- 읽는 사람이 판단해야 할 부분을 `추후 결정`으로 남김
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> Redis는 단순한 캐시를 넘어 시스템 전반의 성능과 안정성을 향상하는 데 중요한 역할을 합니다.
+
+개선 방향:
+
+> Redis는 조회 결과 캐시와 요청 제한에 사용한다. 세션 저장소로는 사용하지 않는다. Redis 장애가 로그인 기능까지 번지지 않게 하려는 결정이다.
+
+## 2. 발표 스크립트
+
+### 목표
+
+청중이 화면과 설명을 함께 따라오게 하며, 발표자가 실제로 말할 수 있는 한국어로 쓴다.
+
+### 정보 순서
+
+- 화면에서 먼저 보이는 대상
+- 청중이 알아야 할 핵심 질문
+- 설명 또는 사례
+- 다음 슬라이드로 넘어가는 짧은 연결
+
+### 문장 규칙
+
+- 한 문장에 핵심 정보 하나를 둔다.
+- 글로 읽을 때 완벽한 문장보다 입으로 말했을 때 자연스러운 호흡을 우선한다.
+- 한 문장이 길어지면 접속 표현을 늘리기보다 끊는다.
+- 영문 약어와 긴 기술명은 처음에만 풀어 말하고 이후에는 짧은 명칭을 쓴다.
+- 숫자, 버전, 경로를 연달아 읽어야 하면 슬라이드에 맡기고 말로는 의미를 설명한다.
+- 높임말은 한 발표 안에서 통일한다.
+- 청중에게 질문하는 표현은 실제로 생각할 틈을 줄 때만 사용한다.
+- 발표자가 하지 않을 법한 감탄, 과장, 광고 문구를 넣지 않는다.
+
+### 전환 문장 예시
+
+- `먼저 현재 요청이 어디로 들어오는지 보겠습니다.`
+- `여기서 문제가 하나 생깁니다.`
+- `이제 이 구조를 왜 바꿨는지 보겠습니다.`
+- `지금까지는 정상 흐름이었습니다. 다음은 실패했을 때입니다.`
+- `결과만 먼저 보면 응답 시간은 이렇게 달라졌습니다.`
+
+같은 전환을 반복하지 않는다. 연결이 필요 없으면 바로 다음 설명으로 넘어간다.
+
+### 소리 내어 읽기 점검
+
+- 한 호흡에 읽기 어려운가?
+- 받침이 겹치거나 영문 약어가 몰려 발음이 막히는가?
+- 긴 관형절 때문에 서술어를 잊게 되는가?
+- 슬라이드 문구를 그대로 낭독하고 있지는 않은가?
+- `이`, `그`, `해당`, `이를`이 가리키는 대상이 청중에게 분명한가?
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> 앞서 살펴본 문제점을 기반으로 이를 해결하기 위해 적용한 아키텍처와 그에 따른 구체적인 개선 결과를 살펴보겠습니다.
+
+개선 방향:
+
+> 여기까지 기존 구조의 문제를 봤습니다. 이제 구조를 어떻게 바꿨는지 보겠습니다. 그다음 실제 결과를 확인하겠습니다.
+
+## 3. 일반 설명 글·기술 블로그
+
+### 목표
+
+독자가 글을 읽게 된 이유를 잃지 않고, 문제와 판단 과정을 따라가게 쓴다.
+
+### 정보 순서
+
+1. 실제 문제나 질문
+2. 필요한 배경과 전제
+3. 시도한 방법 또는 핵심 설명
+4. 실패하거나 헷갈린 지점
+5. 판단이 달라진 이유
+6. 결과, 한계, 적용 범위
+
+참고서나 사전형 문서라면 서사를 강요하지 않고 항목별 구조를 사용한다.
+
+### 문장 규칙
+
+- 도입부에서 거대한 시대 변화나 기술의 중요성을 선언하지 않는다.
+- 경험한 사실과 일반적인 기술 설명을 구분한다.
+- 독자를 계속 `여러분`이라고 부르지 않는다.
+- 예시는 설명 직후에 배치한다.
+- 실패 원인과 해결 과정을 성공담으로 과장하지 않는다.
+- 결론은 본문의 핵심 판단과 한계를 정리하되 문단별 내용을 다시 나열하지 않는다.
+- 검색어를 문장에 반복해서 넣지 않는다.
+
+### 자연스러운 예시
+
+부자연스러운 문장:
+
+> 오늘날 소프트웨어 개발 환경에서 관측 가능성은 그 어느 때보다 중요한 핵심 요소로 자리 잡고 있습니다.
+
+개선 방향:
+
+> 장애가 났을 때 로그만으로는 요청이 어느 서비스에서 느려졌는지 찾기 어려웠다. 이 문제를 확인하려고 트레이스와 메트릭을 함께 수집했다.
+
+## 4. 자기소개서·경력 기술서
+
+### 목표
+
+지원자의 경험과 판단을 사실에 근거해 보여 준다. 잘 보이기 위한 문장보다 검증 가능한 내용을 우선한다.
+
+### 기본 구조
+
+- 어떤 상황과 문제가 있었는가
+- 본인이 맡은 범위는 어디까지였는가
+- 어떤 판단과 행동을 했는가
+- 결과가 무엇이었는가
+- 무엇을 배웠고 이후 행동이 어떻게 달라졌는가
+
+모든 항목에 이 구조를 기계적으로 적용하지 않는다. 질문이 요구하는 부분만 쓴다.
+
+### 문장 규칙
+
+- `저는 책임감이 강합니다`보다 책임감을 보여 주는 행동을 쓴다.
+- 팀의 성과와 본인의 기여를 구분한다.
+- 숫자는 사용자가 제공했거나 자료로 확인된 경우에만 쓴다.
+- 기술 이름을 나열하지 말고 문제 해결에 어떤 역할을 했는지 쓴다.
+- 실패를 미화하거나 약점인 척하는 장점을 만들지 않는다.
+- 지원 기업을 근거 없이 찬양하지 않는다.
+- 채용 공고의 표현을 그대로 복사해 자신의 경험인 것처럼 쓰지 않는다.
+
+### 금지되는 보완
+
+- 존재하지 않는 프로젝트나 역할 추가
+- 대략적인 결과를 정확한 수치로 변환
+- 사용자가 말하지 않은 리더십, 갈등, 장애 경험 생성
+- 실제 동기와 다른 지원 동기 작성
+- 기술 숙련도를 근거 없이 상향
+
+## 5. 업무 메일·메신저
+
+### 목표
+
+상대가 상황과 필요한 행동을 빠르게 이해하게 쓴다.
+
+### 정보 순서
+
+1. 연락한 목적
+2. 필요한 배경
+3. 요청 사항 또는 결정 사항
+4. 기한과 다음 행동
+
+짧은 메시지는 인사말보다 목적을 먼저 쓸 수 있다. 외부 고객이나 공식 요청에는 관계에 맞는 인사와 맺음말을 둔다.
+
+### 문장 규칙
+
+- `확인 부탁드립니다`만 쓰지 말고 무엇을 언제까지 확인해야 하는지 쓴다.
+- 책임 주체가 여러 명이면 담당자를 명시한다.
+- 거절이나 이견은 모호하게 돌려 쓰지 말고 이유와 가능한 대안을 함께 쓴다.
+- 사물에 높임 표현을 붙이지 않는다.
+- 과도한 관공서 문구와 한자어를 줄인다.
+- 메신저에서는 지나치게 완결된 보고서 문체를 강요하지 않는다.
+
+## 6. 안내문·사용자 문구
+
+### 목표
+
+사용자가 현재 상태, 원인, 가능한 행동을 즉시 이해하게 쓴다.
+
+### 문장 규칙
+
+- 오류가 발생했다는 말만 하지 말고 사용자가 할 수 있는 행동을 제시한다.
+- 내부 시스템 용어와 오류 코드를 그대로 노출하지 않는다. 문제 해결에 필요하면 별도 상세 정보로 둔다.
+- 사용자 탓으로 들리는 표현을 피한다.
+- 버튼 이름과 화면 용어를 실제 UI와 일치시킨다.
+- 경고는 위험의 크기에 맞게 쓴다. 모든 상황을 `중요`, `필수`, `즉시`로 강조하지 않는다.
+
+## 장르가 섞인 경우
+
+하나의 글에 장르가 섞이면 주된 사용 상황을 기준으로 정한다.
+
+- 발표 슬라이드의 발표자 노트: 발표 스크립트 우선
+- 기술 블로그의 명령어 설명: 블로그 흐름 + 기술 문서 정확성
+- 포트폴리오의 프로젝트 설명: 경력 문서 사실성 + 기술 문서 구체성
+- 장애 공지 메일: 업무 메일 구조 + 안내문 행동 지침
+
+서로 충돌하면 사실성과 정확성, 실제 사용 가능성을 우선한다.

.agents/skills/writing-natural-korean/references/normative-foundation.md

@@ -0,0 +1,164 @@
+# 공식 기준과 조회 순서
+
+조사 기준일: 2026-08-02
+
+## 1. 적용 원칙
+
+한국어 글쓰기 판단을 다음 두 층으로 나눈다.
+
+### 강제 규범
+
+표기가 맞는지 틀리는지를 판단할 때 사용한다.
+
+- 한글 맞춤법
+- 표준어 규정
+- 외래어 표기법
+- 국어의 로마자 표기법
+- 한글 맞춤법 부록의 문장 부호
+- 표준국어대사전의 표제어, 품사, 뜻풀이, 활용 정보
+
+### 표현 권고
+
+문장이 독자에게 정확하고 쉽게 전달되는지, 한국어로 자연스러운지를 판단할 때 사용한다.
+
+- 국립국어원의 공공언어 자료
+- 국립국어원 발간 연구와 간행물의 문장·번역투 분석
+- 글의 독자, 매체, 목적에 따른 편집 판단
+
+표현 권고를 강제 규범처럼 적용하지 않는다. 예를 들어 피동문, `가지다`, `~에 대한`, `~를 통해`는 문맥에 따라 자연스러울 수 있으므로 출현했다는 이유만으로 오류 처리하지 않는다.
+
+## 2. 공식 조회 우선순위
+
+정확한 판단이 필요한 경우 다음 순서로 확인한다.
+
+1. 한국어 어문 규범
+2. 표준국어대사전
+3. 국립국어원 공공언어·국어생활 자료
+4. 국립국어원 온라인가나다의 개별 질의 답변
+
+온라인가나다 답변은 특정 문맥에 대한 상담이므로 일반 규칙으로 확대하지 않는다. 규정과 사전이 개정될 수 있으므로 날짜가 중요한 판단은 최신 공식 페이지에서 다시 확인한다.
+
+## 3. 한국어 어문 규범에서 가져온 핵심
+
+공식 누리집: https://www.korean.go.kr/kornorms/main/main.do
+
+국립국어원의 한국어 어문 규범 누리집은 한글 맞춤법, 표준어 규정, 외래어 표기법, 국어의 로마자 표기법을 제공한다. 한글 맞춤법에는 띄어쓰기와 문장 부호가 포함된다.
+
+### 띄어쓰기
+
+다음은 스킬의 기본 검사 항목이다.
+
+- 제41항: 조사는 앞말에 붙여 쓴다.
+- 제42항: 의존 명사는 띄어 쓴다.
+- 제43항: 단위를 나타내는 명사는 띄어 쓰는 것이 원칙이다. 순서나 아라비아 숫자 뒤의 단위 등에는 붙여 쓰기가 허용되는 범위가 있다.
+- 제47항: 보조 용언은 띄어 쓰는 것이 원칙이며, 규정에서 정한 경우 붙여 쓰기도 허용한다.
+- 제48~50항: 고유명사와 전문용어는 단어별 띄어쓰기를 기본으로 하되, 의미 단위나 전문 분야의 관행을 고려한 허용 범위가 있다.
+
+따라서 `띄어 쓴 형태만 정답` 또는 `붙여 쓴 형태만 정답`이라고 일괄 판단하면 안 된다. 원칙과 허용을 구분하고 문서 안에서 통일한다.
+
+### 문장 부호
+
+문장 부호는 문장의 구조를 드러내거나 글쓴이의 의도를 전달하기 위해 사용한다. 영어 문장의 쉼표, 줄표, 쌍점 배치를 모양만 보고 그대로 옮기지 않는다. 목록, 인용, 부제, 괄호, 쌍점 등은 한국어 문장 부호 규정과 매체 관행을 함께 확인한다.
+
+## 4. 표준국어대사전
+
+공식 누리집: https://stdict.korean.go.kr/
+
+다음 판단에 사용한다.
+
+- 표준어 여부와 복수 표준어
+- 단어의 품사와 뜻
+- 활용 형태
+- 한 단어인지 구인지에 관한 정보
+- 용례와 문법 정보
+
+사전에 없다는 이유만으로 전문용어, 신조어, 제품명, 고유명사를 곧바로 틀렸다고 판단하지 않는다. 해당 분야의 공식 명칭과 문서 목적을 함께 본다.
+
+## 5. 공공언어 기준에서 가져온 원칙
+
+### 공공언어 요건 정립 및 진단 기준 개발 연구
+
+공식 소개: https://www.korean.go.kr/front/bookData/bookDataView.do?book_seq=86
+
+국립국어원은 일반 국민을 대상으로 하는 공공언어에서 정확하고 쉬운 언어 사용을 강조하고, 객관적인 진단 기준과 평가 지표를 마련하기 위해 이 연구를 발간했다. 이 스킬은 그 취지를 일반 글쓰기에도 제한적으로 적용한다.
+
+적용 항목:
+
+- 내용이 사실과 논리에 맞는가
+- 문장 성분의 관계가 정확한가
+- 독자가 용어와 문장을 이해할 수 있는가
+- 불필요하게 어려운 한자어, 외래어, 전문용어를 쓰지 않았는가
+- 문서의 목적과 필요한 행동을 쉽게 찾을 수 있는가
+
+단, 전문가 대상 기술 문서에서는 전문용어를 무조건 쉬운 말로 바꾸지 않는다. 정확성이 떨어지면 공식 용어를 유지하고 필요한 설명을 덧붙인다.
+
+### 쉬운 공문서 쓰기 길잡이
+
+공식 소개: https://www.korean.go.kr/front/etcData/etcDataView.do?etc_seq=700
+
+이 자료는 `공공언어의 요건 확인`, `단계별 문서 작성`, `유형별 실제 문서 쓰기`로 구성되어 있다. 스킬은 이를 다음 절차로 일반화한다.
+
+1. 독자와 목적을 확인한다.
+2. 필요한 정보를 선별하고 구조를 잡는다.
+3. 문장과 용어를 정확하고 쉽게 쓴다.
+4. 문서 유형에 맞춰 형식을 조정한다.
+5. 독자의 관점에서 다시 검토한다.
+
+### 한눈에 알아보는 공공언어 바로 쓰기 개정판
+
+공식 소개: https://www.korean.go.kr/front/etcData/etcDataView.do?etc_seq=699
+
+이 자료는 공공언어 원칙과 기안문, 보도 자료, 보고서, 안내문 작성 사례를 제공하며, 행정용어와 일본어 투 용어 개선 자료도 포함한다. 스킬은 이 자료에서 다음 방향을 취한다.
+
+- 문서 유형에 따라 표현 방식을 달리한다.
+- 관행적 표현이라도 독자의 이해를 막으면 고친다.
+- 용어 교체만 하지 않고 문장 전체의 의미와 구조를 함께 본다.
+
+## 6. 국어기본법과 쉬운 문장
+
+국가법령정보센터: https://www.law.go.kr/법령/국어기본법
+
+국어기본법은 어문 규범을 한글 맞춤법, 표준어 규정, 표준 발음법, 외래어 표기법, 국어의 로마자 표기법 등으로 정의한다. 공문서는 일반 국민이 알기 쉬운 용어와 문장으로 작성하고 어문 규범에 맞추어 한글로 작성하는 방향을 둔다.
+
+이 법의 직접 적용 대상이 아닌 글에서도 `정확성`과 `이해 가능성`은 유효한 편집 기준이지만, 모든 글을 공문서 문체로 바꾸지는 않는다.
+
+## 7. 번역투 연구에서 가져온 원칙
+
+### 현대 국어 번역문의 실태
+
+원문 PDF: https://www.korean.go.kr/nkview/nklife/2012_1/22_0104.pdf
+
+국립국어원 간행물 『새국어생활』의 이 글은 번역문 말뭉치에서 비번역문보다 자주 나타나는 경향을 제시한다. 주요 관찰에는 다음이 포함된다.
+
+- 2·3인칭 대명사와 지시 표현의 높은 빈도
+- `만들다`, `가지다`, `의하다`, `대하다`의 높은 빈도
+- `-아/어지다`와 `-에 의하여`를 사용한 피동 표현
+- `만약`, `왜냐하면`, `불구하고` 같은 명시적 연결 표현
+- 관형격 조사 `의`와 일부 전치사 대응 표현
+- 문맥 관계를 필요 이상으로 명시하는 접속어
+
+이 결과는 말뭉치상의 경향이다. 특정 표현 하나가 등장했다고 문법 오류나 번역투로 확정하지 않는다. 반복, 문맥 부적합, 더 정확한 한국어 표현의 존재 여부를 함께 판단한다.
+
+### 영한 번역에 나타난 번역투 문장
+
+원문 PDF: https://www.korean.go.kr/nkview/nklife/2012_1/22_0105.pdf
+
+이 글은 영어의 소유 구문, 수동태, 복수 표시, 전치사구가 한국어에 그대로 전이될 때 생기는 어색함을 사례로 설명한다.
+
+대표적인 편집 방향:
+
+- `책을 옆구리에 가지고 있다`처럼 동작을 소유로 표현하면 `책을 옆구리에 끼고 있다`처럼 실제 동작을 찾는다.
+- `아름다운 목소리를 가지고 있다`처럼 속성을 소유로 표현하면 `목소리가 아름답다`처럼 상태를 직접 서술한다.
+- 행위자가 분명한 `~에 의해 만들어진다`는 자연스러운 능동문이나 한국어 피동 표현으로 바꿀 수 있는지 검토한다.
+- `~에서의`, `~로부터`, `~를 통해`, `~에 의해`는 문맥에 맞는 조사, 부사어, 동사로 풀어 쓸 수 있는지 본다.
+
+연구는 번역투가 의도적으로 필요한 경우와 무의식적인 직역을 구분해야 한다고 설명한다. 스킬도 같은 원칙을 따른다.
+
+## 8. 판단 시 주의 사항
+
+- 공공언어 지침은 모든 장르의 문체를 하나로 만드는 표준이 아니다.
+- 번역투 연구에서 빈도가 높다고 지적한 표현은 금칙어가 아니다.
+- 허용 표기를 교정자의 취향으로 하나만 남기지 않는다.
+- 방언, 캐릭터 대사, 구어체, 문학적 표현은 의도된 효과를 우선한다.
+- 법률, 계약, 정책, 인용문은 표현을 자연스럽게 바꾸기 전에 의미와 법적 효과가 달라지는지 확인한다.
+- 기술 분야에서는 쉬운 말보다 정확한 공식 명칭이 우선할 수 있다.