| name | kr-patent-format-unify |
| description | 한국 특허 명세서 .docx 안에서 후속 작업으로 신설된 단락(insert_paragraph_before·정합성 수정·청구항 본문 매핑·도면 도입 문장 신설·S14 1파트 신설 등으로 추가된 단락)이 인접 본문 단락과 서식(글꼴·글자 크기·색상·줄간격·들여쓰기·첫 줄 들여쓰기·정렬 등)이 달라 시각적으로 튀는 문제를 자동 검출하여 인접 본문 단락의 pPr(paragraph properties) 및 첫 run의 rPr(character properties)를 deepcopy로 복사해 일괄 동기화. python-docx의 `insert_paragraph_before(text, style=...)`는 paragraph style 객체만 승계하고 character formatting(font·size·color·outlineLvl 제외) + paragraph format(들여쓰기·줄간격)을 default로 두기 때문에, 신설 단락이 본문 다른 단락과 서식 어긋남이 자주 발생. 본 스킬은 (1) 명세서 안 신설 추정 단락 자동 검출 — 한국 특허 흔한 신설 도입어 패턴(청구항 정형 "본 발명의 일 실시예에 있어서,", "본 발명에 따른 [발명의 명칭]은,", 도면 도입 "도 N은 ~ 이다.", S14 1파트 "이상에서 살펴본 바와 같이, 본 발명에 따르면,") + 사용자 지정 패턴 + 자동 폰트 불일치 감지 — 와 (2) 인접 본문 단락(직전 우선, 없으면 직후)의 pPr·rPr deepcopy 복사를 수행. outline level은 헤더가 아닌 본문 단락에는 부여하지 않음(자동 제거). 청구범위·요약서 섹션은 처리 대상에서 제외(불변). "서식 통일", "서식 동기화", "format unify", "서식이 다르다", "단락 서식 안 맞아", "쌩뚱맞은 서식", "폰트가 달라", "신설 단락 서식", "insert_paragraph_before 서식"이 언급되거나, 청구항 본문 매핑·도면 도입 문장 신설·정합성 수정 직후 명세서가 서식 어긋남으로 보이는 맥락이면 사용. kr-patent-navigation-pane(outline 부여)과 짝을 이루는 docx 후처리 인프라. |
kr-patent-format-unify — 한국 특허 명세서 신설 단락 서식 동기화
무엇을 하는가
한국 특허 명세서 docx 안에서 후속 작업으로 신설된 단락이 인접 본문 단락과 서식이 달라 시각적으로 튀는 문제를 자동 해소한다.
<w:pPr>(paragraph properties: 들여쓰기·줄간격·정렬·첫 줄 들여쓰기) — 인접 본문 단락에서 deepcopy 복사
<w:rPr>(character properties: 글꼴·크기·굵기·기울임·색상) — 인접 본문 단락의 첫 run rPr을 신설 단락의 모든 run에 deepcopy 복사
<w:outlineLvl> — 본문 단락에는 부여하지 않음 (자동 제거)
명세서 외관을 통째로 바꾸는 게 아니라 튀어나온 단락만 인접 흐름에 맞춤. 외관 자체는 그대로 유지.
언제 사용하는가
kr-patent-spec-drafting 수정 모드 / kr-patent-consistency-check 수정 적용 후 신설 단락 다수
kr-patent-ralph-loop이 도면 도입 문장·S14 1파트 등 신설 단락을 자동 추가한 직후
- 청구항 본문 매핑(청구항 1~N 정형 문언을 S13 안 각 절에 1:1 삽입) 직후
- 외부 변리사 docx에서 일부 단락만 서식이 다를 때 (수동 편집 흔적)
언제 사용하지 않는가
- 명세서 전체 서식을 통째로 바꾸려 할 때 (이건 별도 docx-builder 재빌드)
- 본문이 아닌 표·도면 캡션의 서식 (표 셀 안 서식은 별도 처리 필요)
검출 대상 단락 (default 패턴)
다음 도입어로 시작하는 단락을 신설 추정 단락으로 자동 검출:
| 카테고리 | 도입어 패턴 |
|---|
| 청구항 종속항 풀어쓰기 | 본 발명의 일 실시예에 있어서, |
| 청구항 독립항(방법) 풀어쓰기 | 본 발명에 따른 ~ 방법은, |
| 청구항 독립항(시스템) 풀어쓰기 | 본 발명에 따른 ~ 시스템은, |
| 도면 도입 정형 | 도 N은 ~ 이다. (N = 1~99, 종결 "이다." 또는 "이고,") |
| S14 1파트 정형 | 이상에서 살펴본 바와 같이, 본 발명에 따르면, |
| 변형 실시예 (선택) | 한편,, 또 다른 실시예에 있어서,, 또한, 일 실시예에 있어서,, 나아가, |
추가로 자동 폰트 불일치 감지: 단락의 첫 run rPr이 인접 본문 단락의 첫 run rPr과 다르면 신설 후보. (font name·size·color 비교)
처리 영역
- 포함: 본문 전체 (앞표지 ~ 【부호의 설명】 직전)
- 제외: 【청구범위】 ~ 끝 (청구범위·요약서·요약·대표도는 불변)
- 제외: 표(table) 안 단락 — 표는 자체 서식 관리
참조 단락 선정 규칙
각 신설 단락에 대해 인접 본문 단락의 서식을 복사. 선정 우선순위:
- 직전 본문 단락 (1~5 단락 이내) — 같은 절 안일 가능성 높음
- 직후 본문 단락 (1~5 단락 이내) — 직전이 모두 신설 단락이거나 절 헤더일 때
- 둘 다 없으면 스킵 (안전한 default)
"본문 단락"의 조건:
- 비어있지 않음
- 절 헤더(
【...】 단독)가 아님
- 신설 추정 도입어로 시작하지 않음 (다른 신설 단락 회피)
사용 방법
일반 호출
python "C:\Users\IPLAB\.claude\skills\kr-patent-format-unify\scripts\apply_format_unify.py" "<docx 경로>"
추가 옵션:
--patterns "패턴1|패턴2|..." — 추가 검출 도입어 패턴 (정규식, OR 결합)
--auto-detect — 자동 폰트 불일치 감지 활성화 (default: off, 도입어 패턴 기반만)
--dry-run — 실제 수정 안 하고 어느 단락이 동기화 대상인지만 출력
--no-backup — 백업 생략 (비추천)
사전 점검
- 파일이 Word에서 열려 있지 않은지 확인 — 잠금 시 PermissionError
- 원본은 항상 백업 (
{원본명}_서식통일전.docx)
- 청구범위 무결성 — 시작·종료 시점 byte 단위 비교 (위반 시 즉시 중단)
출력 형식
Backup: <백업 경로>
서식 동기화 적용 — N개 단락:
[85] (청구항 1) ref=[84]: 시뮬레이션 결과 데이터 생성부(170) 동의어 정리
[119] (도 5 도입) ref=[118]: 손상 데이터 생성 절 진입 본문
[231] (S14 1파트) ref=[230]: 다국어 UI 변형 실시예
...
청구범위 byte 일치: ✅
Wrote: <원본 경로>
동작 원리 (왜 deepcopy로 pPr·rPr를 복사하는가)
python-docx의 insert_paragraph_before(text, style=parent_style)는:
- paragraph style 객체(예: "Normal")만 승계
- pPr 안 ind·spacing·jc·outlineLvl 등 직접 속성은 default
- run 안 rPr의 font·size·color 등은 default (style에서 inherit 안 됨)
결과: 신설 단락의 글꼴이 시스템 default(맑은 고딕 11pt 등)로 보임. 명세서 다른 단락이 나눔고딕 10pt·줄간격 200% 등이면 시각적 차이 명확.
해결: 인접 본문 단락의 pPr·rPr 전체 XML element를 copy.deepcopy로 복제하여 신설 단락에 통째로 이식. style을 통한 inherit이 아닌 직접 속성 설정이라 안정적.
왜 outline level은 제거하는가
본 스킬의 대상은 본문 단락. 참조 단락이 우연히 헤더(outlineLvl=0~3)였다면 그 outline 값을 복사하면 안 됨(신설 단락이 잘못 탐색창에 노출). 따라서 deepcopy 후 outlineLvl element는 자동 제거.
탐색창 outline 부여는 kr-patent-navigation-pane이 별도로 담당.
헤더 매칭 규칙
paragraph의 전체 텍스트가 【...】 단독인 단락은 헤더로 인정, 처리 대상에서 제외. 본문 중간의 【…】 인용은 본문으로 인정.
의존성
- Python ≥ 3.8
- python-docx ≥ 0.8.11
다른 스킬과의 관계
| 스킬 | 짝 관계 |
|---|
| kr-patent-navigation-pane | docx 후처리 짝. navigation-pane은 outline level, format-unify는 본문 서식. 두 스킬은 책임이 직교(orthogonal)하여 둘 다 호출해도 충돌 없음. 일반적 순서: 본문 작업 종료 → format-unify → navigation-pane → 최종 검토. |
| kr-patent-spec-drafting | spec-drafting이 수정 모드로 본문 신설할 때마다 호출 직후 format-unify 권장. |
| kr-patent-consistency-check | consistency-check의 자동 수정 결과 신설 단락에 적용. |
| kr-patent-ralph-loop | ralph-loop 각 iteration 종료 직전에 format-unify를 자동 호출하면 매 iter 서식 어긋남 방지. |
| kr-patent-docx-builder | builder가 처음부터 만든 docx는 서식이 일관 — format-unify 불필요. 외부 명세서 수정 흐름에서만 의미. |
사용 예시
예시 1: 청구항 본문 매핑 직후
User: 청구항 14개 본문 매핑했더니 일부 단락 서식이 본문과 다른데?
Claude: [format-unify 호출]
→ 청구항 정형 도입어 검출 14건 + 도면 도입 신설 7건 + S14 1파트 1건
→ 인접 본문 단락의 pPr·rPr deepcopy 복사
→ 청구범위 byte 일치 ✅
→ Word에서 확인: 시각적 차이 사라짐
예시 2: ralph-loop 사이클 종료 직후
User: ralph-loop 엄격 수렴 끝났어. 서식 좀 보고 싶어.
Claude: [format-unify --auto-detect]
→ 도면 도입 신설 (B-1) + 청구항 본문 매핑 + S14 1파트 모두 검출
→ 일괄 서식 동기화
→ Word 탐색창 outline은 navigation-pane이 별도 담당
예시 3: dry-run으로 사전 확인
User: 어떤 단락이 바뀔지 먼저 보고 싶어.
Claude: [format-unify --dry-run]
→ 21개 단락 검출, 각각의 참조 단락 후보 출력
→ 실제 수정 없음
→ OK이면 --dry-run 빼고 재실행
누적 학습 항목
(이 섹션은 kr-patent-skill-updater가 작업 회고 후 자동으로 추가)
- (2026-05-27 신설, P-2026-011-01-KR 첫 사용) python-docx
insert_paragraph_before(text, style=parent.style)는 paragraph style 객체만 승계하고 pPr·rPr의 직접 속성은 default로 두어, 신설 단락이 명세서 본문과 글꼴·줄간격이 다르게 보이는 결함이 빈발. 신설 작업 직후 format-unify 호출이 default. 검출은 도입어 패턴(청구항 정형 + 도면 도입 정형 + S14 1파트) + 자동 폰트 불일치 감지 두 트랙 병행.
- (2026-05-27) outline level은 헤더가 아닌 본문 단락에 부여하면 탐색창에 잘못 노출 — deepcopy 후 outlineLvl element는 자동 제거 필수. format-unify와 navigation-pane은 책임 직교(orthogonal).
- (2026-05-27, P-2026-011-01-KR 첫 사용) python-docx의
paragraph._element.find(qn('w:rPr')).xml은 lxml XmlString 타입이라 set·dict 키로 직접 사용 불가(unhashable). 자동 폰트 불일치 감지 함수에서는 반드시 str() 변환을 거쳐 hashable 보장. 빈발하는 TypeError 버그.