kr-patent-format-unify — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited kr-patent-format-unify (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
한국 특허 명세서 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파트 등 신설 단락을 자동 추가한 직후다음 도입어로 시작하는 단락을 신설 추정 단락으로 자동 검출:
| 카테고리 | 도입어 패턴 |
|---|---|
| 청구항 종속항 풀어쓰기 | 본 발명의 일 실시예에 있어서, |
| 청구항 독립항(방법) 풀어쓰기 | 본 발명에 따른 ~ 방법은, |
| 청구항 독립항(시스템) 풀어쓰기 | 본 발명에 따른 ~ 시스템은, |
| 도면 도입 정형 | 도 N은 ~ 이다. (N = 1~99, 종결 "이다." 또는 "이고,") |
| S14 1파트 정형 | 이상에서 살펴본 바와 같이, 본 발명에 따르면, |
| 변형 실시예 (선택) | 한편,, 또 다른 실시예에 있어서,, 또한, 일 실시예에 있어서,, 나아가, |
추가로 자동 폰트 불일치 감지: 단락의 첫 run rPr이 인접 본문 단락의 첫 run rPr과 다르면 신설 후보. (font name·size·color 비교)
각 신설 단락에 대해 인접 본문 단락의 서식을 복사. 선정 우선순위:
"본문 단락"의 조건:
【...】 단독)가 아님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 — 백업 생략 (비추천){원본명}_서식통일전.docx)Backup: <백업 경로>
서식 동기화 적용 — N개 단락:
[85] (청구항 1) ref=[84]: 시뮬레이션 결과 데이터 생성부(170) 동의어 정리
[119] (도 5 도입) ref=[118]: 손상 데이터 생성 절 진입 본문
[231] (S14 1파트) ref=[230]: 다국어 UI 변형 실시예
...
청구범위 byte 일치: ✅
Wrote: <원본 경로>python-docx의 insert_paragraph_before(text, style=parent_style)는:
결과: 신설 단락의 글꼴이 시스템 default(맑은 고딕 11pt 등)로 보임. 명세서 다른 단락이 나눔고딕 10pt·줄간격 200% 등이면 시각적 차이 명확.
해결: 인접 본문 단락의 pPr·rPr 전체 XML element를 copy.deepcopy로 복제하여 신설 단락에 통째로 이식. style을 통한 inherit이 아닌 직접 속성 설정이라 안정적.
본 스킬의 대상은 본문 단락. 참조 단락이 우연히 헤더(outlineLvl=0~3)였다면 그 outline 값을 복사하면 안 됨(신설 단락이 잘못 탐색창에 노출). 따라서 deepcopy 후 outlineLvl element는 자동 제거.
탐색창 outline 부여는 kr-patent-navigation-pane이 별도로 담당.
paragraph의 전체 텍스트가 【...】 단독인 단락은 헤더로 인정, 처리 대상에서 제외. 본문 중간의 【…】 인용은 본문으로 인정.
| 스킬 | 짝 관계 |
|---|---|
| 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 불필요. 외부 명세서 수정 흐름에서만 의미. |
User: 청구항 14개 본문 매핑했더니 일부 단락 서식이 본문과 다른데?
Claude: [format-unify 호출]
→ 청구항 정형 도입어 검출 14건 + 도면 도입 신설 7건 + S14 1파트 1건
→ 인접 본문 단락의 pPr·rPr deepcopy 복사
→ 청구범위 byte 일치 ✅
→ Word에서 확인: 시각적 차이 사라짐User: ralph-loop 엄격 수렴 끝났어. 서식 좀 보고 싶어.
Claude: [format-unify --auto-detect]
→ 도면 도입 신설 (B-1) + 청구항 본문 매핑 + S14 1파트 모두 검출
→ 일괄 서식 동기화
→ Word 탐색창 outline은 navigation-pane이 별도 담당User: 어떤 단락이 바뀔지 먼저 보고 싶어.
Claude: [format-unify --dry-run]
→ 21개 단락 검출, 각각의 참조 단락 후보 출력
→ 실제 수정 없음
→ OK이면 --dry-run 빼고 재실행(이 섹션은 kr-patent-skill-updater가 작업 회고 후 자동으로 추가)
insert_paragraph_before(text, style=parent.style)는 paragraph style 객체만 승계하고 pPr·rPr의 직접 속성은 default로 두어, 신설 단락이 명세서 본문과 글꼴·줄간격이 다르게 보이는 결함이 빈발. 신설 작업 직후 format-unify 호출이 default. 검출은 도입어 패턴(청구항 정형 + 도면 도입 정형 + S14 1파트) + 자동 폰트 불일치 감지 두 트랙 병행.paragraph._element.find(qn('w:rPr')).xml은 lxml XmlString 타입이라 set·dict 키로 직접 사용 불가(unhashable). 자동 폰트 불일치 감지 함수에서는 반드시 str() 변환을 거쳐 hashable 보장. 빈발하는 TypeError 버그.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.