한국 특허 명세서 Stage 추천 (진단 게이트)

무엇을 하는가

명세서 또는 부분 자료를 받아 kr-patent-full-workflow의 어느 Stage부터 시작해야 하는지 진단한다. /full의 Stage 0(입력 점검)을 독립 스킬로 분리·강화한 것으로, 다음과 같은 상황에서 사용한다:

• 외부에서 받은 명세서를 어디까지 손봐야 할지 파악
• 다른 변리사가 작성한 초안을 이어서 작업
• 중단했던 명세서를 다시 시작
• 단순히 "이 docx 어디까지 됐지?" 빠른 진단

본 스킬은 진단만 한다. 워크플로우 실행은 결과를 보고 변리사가 /full 또는 단일 스킬을 직접 호출.

입력

다음 중 하나 또는 복수:

• 명세서 .docx (가장 흔함)
• 명세서 .md 또는 .txt
• 청구항 텍스트만
• IDS(기술내용설명서) 파일
• 도면 파일들
• 부호의 설명 표만
• 자료 없이 대화로 상태 진술 ("청구항만 있어요")

산출물

1페이지 진단 보고서 (Markdown):

1. 자료 현황표 (6개 시그널 ✅/❌/⚠️ 표)
2. 추천 시작 Stage + 근거 3줄
3. 위험 신호 (있다면 — 모순·결손·정형 위반)
4. 권장 명령 — /full <범위> 또는 /kr-patent-<단일스킬>
5. 예상 잔여 단계 수 + 대략 작업량

추가 산출물 없음. 본문 수정·docx 생성 등은 추천된 다음 단계의 스킬이 담당.

진단 알고리즘 — 6개 시그널 검출

시그널 1: 청구항 존재·구조

결손 시그널:

• 청구항 없음 → IDS 단계
• 청구항 있는데 인용 누락 → 위험 신호
• 시스템 청구항만, 방법 청구항 없음 → 보완 권장

시그널 2: 도면·부호 사용

결손 시그널:

• 도면 ID는 있는데 본문에 부호 등장 없음 → Stage 3 미완
• 본문 부호와 부호의 설명 불일치 → 위험 신호

시그널 3: 11개 표준 섹션 완성도

체크할 헤더:

1. 【발명의 명칭】
2. 【기술분야】
3. 【배경기술】
4. 【발명의 내용】 / 【해결하고자 하는 과제】
5. 【과제의 해결 수단】
6. 【발명의 효과】
7. 【도면의 간단한 설명】
8. 【발명을 실시하기 위한 구체적인 내용】
9. 【부호의 설명】 (선택)
10. 【청구범위】
11. 【요약서】

11개 중 N개 작성 → 진행률 = N/11.

시그널 4: ★ 자체 사전 정의 단락 적용 여부 (핵심)

정의 단락의 표준 4단 템플릿 패턴:

"<용어>이란/라 함은 ... 를 의미할 수 있다."
"... 를 포함할 수 있다."
"... 예를 들어 ..., ... 등을 포함할 수 있다."
"... 이에 한정되지 않는다."

검출 방법:

• 라 함은 + 의미할 수 있다 동시 등장 단락 카운트
• 한정되지 않는다 마무리 카운트

판정:

• 둘 다 0건 → 정의 미적용 (Stage 6 진입 권장)
• 일부만 있음 → Stage 6 부분 완료 (보강 권장)
• 청구항 한정 용어와 비교하여 누락 용어 리스트 추출

시그널 5: ★ 변형 실시예 적용 여부 (핵심)

변형 실시예 도입어 패턴:

"한편,"
"또 다른 실시예에 있어서,"
"또한, 일 실시예에 있어서,"
"나아가,"

검출 방법:

• 위 4종 도입어 + 동일 단락 안 한정되지 않는다 마무리 패턴
• "발명을 실시하기 위한 구체적인 내용" 절 안에서만 카운트

판정:

• 핵심 실시예 절당 0~1개 → 변형 미적용 (Stage 7 진입 권장)
• 절당 4~7개 → 변형 충분
• 절당 8개 이상 → 과적용 의심 (검토 권장)

시그널 6: 금지어·정형 위반 흔적

판정:

• 위반 0~2건 → 정형 OK
• 위반 3건 이상 → Stage 8 (정합성 점검) 필요 시그널

Stage 매핑표

판정이 모호하거나 두 Stage 사이 → 더 빠른 단계부터 시작 권장 + 사용자에게 확인.

작업 순서

Step 1. 입력 식별

사용자가 첨부한 파일 또는 대화 안 자료를 식별:

• .docx → python-docx로 텍스트 추출 (또는 base 디렉토리의 도구 활용)
• .md / .txt → 직접 읽기
• 자료 없음 → 사용자에게 상태 진술 요청 ("어느 단계까지 진행되었나요?")

명세서 헤더 정형(【발명의 명칭】 등)이 깨져 있으면 일반 텍스트로 처리하고 fuzzy 매칭.

Step 2. 6개 시그널 검출 (병렬 가능)

각 시그널을 grep/regex/카운트로 자동 검출. 결과를 표로 정리:

| 시그널 | 상태 | 값 |
|---|---|---|
| 1. 청구항 | ✅ | 20개 (시스템 1, 방법 1, 종속 18) |
| 2. 도면·부호 | ✅ | 8장, 부호 47개 |
| 3. 11개 섹션 | ⚠️ | 9/11 (요약서·부호의 설명 없음) |
| 4. 정의 단락 | ❌ | 0건 |
| 5. 변형 실시예 | ❌ | 0건 |
| 6. 정형 위반 | ⚠️ | "종래" 1건 |

Step 3. Stage 매핑

Step 2 결과를 Stage 매핑표에 대입하여 추천 시작 Stage 결정.

판정이 두 Stage에 걸치면 두 안 모두 제시 + 사용자 결정 요청.

Step 4. 위험 신호 추출

다음 항목 별도 강조:

• 청구항 인용 누락
• 본문 부호 ↔ 부호의 설명 불일치
• 청구항 한정 용어 중 정의 단락 누락 ≥ 5개
• 시그널 6 위반 ≥ 5건
• 11개 섹션 중 누락 ≥ 4개

Step 5. 권장 명령 생성

추천 Stage에 맞는 명령을 그대로 복사 가능한 형태로 제시:

다음 명령 중 하나 선택:

# 전체 워크플로우 (default — 추천 Stage부터 끝까지)
/full

# 부분 실행 (해당 단계만)
/kr-patent-definition-insertion
/kr-patent-embodiment-addition

# 점검만
/kr-patent-consistency-check

Step 6. 진단 보고서 출력

아래 정형으로 한 번에 출력. 추가 질문 없이 종료.

출력 정형 (1페이지 진단 보고서)

# 📋 한국 특허 명세서 Stage 진단 보고서

**대상**: <파일명 또는 자료 설명>
**진단 일시**: <YYYY-MM-DD>

## 1. 자료 현황

| 시그널 | 상태 | 세부 |
|---|---|---|
| ① 청구항 | ✅/⚠️/❌ | <개수, 카테고리, 종속관계> |
| ② 도면·부호 | ✅/⚠️/❌ | <도면 N장, 부호 N개, 계층 OK/NG> |
| ③ 11개 표준 섹션 | ✅/⚠️/❌ | <N/11 작성, 누락: ...> |
| ④ 자체 사전 정의 단락 | ✅/⚠️/❌ | <N건 검출, 청구항 한정 용어 대비 M개 누락> |
| ⑤ 변형 실시예 | ✅/⚠️/❌ | <도입어 N건, 절당 평균 K개> |
| ⑥ 금지어·정형 위반 | ✅/⚠️/❌ | <"종래" N건, "구성되는" M건, 기타> |

## 2. 추천 시작 Stage

### → **Stage N (<이름>)** 부터 시작

**근거**:
1. <시그널 X가 ❌이고 그 이전 단계는 모두 ✅이므로>
2. <시그널 Y는 본 Stage의 산출물이므로>
3. <위험 신호 Z를 함께 처리할 수 있음>

**예상 잔여 단계**: <N>단계 (Stage <N>~11)
**대략 작업량**: <짧음/보통/큼>

## 3. 위험 신호 (있다면)

- ⚠️ <항목 1: 위치 + 내용 + 권장 조치>
- ⚠️ <항목 2: ...>

(없으면 "발견된 위험 신호 없음" 한 줄)

## 4. 권장 명령

추천 진행

/full

또는 부분 실행

/kr-patent-<해당 단일 스킬>

## 5. 참고 — 건너뛸 단계

이전 Stage 1~<N-1>은 이미 완료되어 건너뜁니다.
다만 만약 <특정 의심 사항>이 있다면 Stage <X>로 거슬러 올라가는 것을 권장.

사용 예시

예시 1: 외부 변리사 작성 초안 받은 케이스

User: 이 docx 어디까지 됐는지 봐줘 [draft_v2.docx 첨부]

Claude: [시그널 검출 → 보고서 산출]

📋 한국 특허 명세서 Stage 진단 보고서
대상: draft_v2.docx
- ① 청구항 ✅ 15개
- ② 도면·부호 ✅ 6장, 부호 32개
- ③ 11개 섹션 ✅ 11/11
- ④ 정의 단락 ❌ 0건 (청구항 한정 용어 7개 중 0개 정의)
- ⑤ 변형 실시예 ❌ 0건
- ⑥ 정형 위반 ⚠️ "종래" 2건

→ Stage 6 (정의 삽입)부터 시작 권장.

권장 명령: /full

예시 2: 청구항만 있는 케이스

User: 청구항이랑 IDS만 있어. 어디부터 시작할까?

Claude:
→ Stage 2 (청구항 확정 확인) + 도면 보완 요청부터 시작.
권장 명령: /full
참고: 도면이 없으면 Stage 3(부호 설계)으로 진입할 수 없으므로 발명자에게 도면 초안 요청 병행.

예시 3: 권리범위 보강 직후 진단

User: 정의·변형 다 넣었어. 다음은?

Claude:
- ④ 정의 단락 ✅ 12건
- ⑤ 변형 실시예 ✅ 절당 평균 5.3개
- ⑥ 정형 위반 ⚠️ 4건 (E. 효과 3단 인과 누락)

→ Stage 8 (정합성 점검)부터 시작.
권장 명령: /kr-patent-consistency-check (점검만) 또는 /full (점검→수정→docx)

예시 4: 거의 끝난 명세서

User: 작업 다 됐는데 docx만 안 뽑았어.

Claude:
- 시그널 ①~⑥ 모두 ✅
→ Stage 10 (docx 출력)부터.
권장 명령: /kr-patent-docx-builder
참고: 외부 검토용이면 navigation-pane도 같이 호출.

예시 5: 자료 없이 대화만

User: 새 명세서 시작하려고 하는데 어디부터?

Claude: 현재 자료 상태를 알려주세요:
- IDS만 있나요?
- 청구항 초안까지 있나요?
- 도면 초안까지 있나요?

[답변 받은 뒤 Stage 매핑]

진행 원칙

1. 진단만, 실행은 별도

본 스킬은 진단 보고서 출력 후 자동으로 다음 스킬을 호출하지 않는다. 변리사가 보고서를 보고 /full 또는 단일 스킬을 명시적으로 호출. 이는 변리사 판단 우선 원칙.

예외: 사용자가 "진단하고 그대로 진행해줘"라고 명시 요청하면 보고서 산출 후 추천 명령을 자동 호출 가능.

2. 모호한 판정은 사용자 확인

시그널이 두 Stage 사이에 걸치거나 (예: 정의 일부만 적용), 자료 자체가 부족할 때는 추정하지 말고 사용자에게 한 줄 질문:

"정의 단락이 3건 검출되었는데 청구항 한정 용어는 8개입니다. 나머지 5개도 미정의로 보고 Stage 6부터 다시 시작할까요, 아니면 적용한 3개는 그대로 두고 Stage 7로 넘어갈까요?"

3. 진단은 빠르게 (보고서 1페이지)

상세 점검은 Stage 8 (consistency-check)의 일이다. 본 스킬은 어느 단계인지만 빠르게 판정한다. 위반 사항 전수 리스트는 만들지 않음 — 위험 신호 3~5건만 강조.

4. 자료가 .docx면 파싱 우선

python-docx로 텍스트 추출. 헤더 스타일(outline level) + 본문 텍스트 + 표를 분리 추출. 패턴 매칭은 추출된 텍스트에 적용.

파싱 실패 시 사용자에게 .md 또는 .txt 변환본 요청.

5. 검출 누락보다 과검출 우선

시그널이 애매하면 ⚠️로 표시. ❌ 확정은 강한 증거가 있을 때만. 변리사가 보고 판단할 수 있도록 정량 정보(개수·위치) 함께 제시.

다른 kr-patent-* 스킬과의 관계

누적 학습 항목

(컴파운딩 루프 — 본 스킬을 사용할수록 시그널 검출·매핑 정확도 개선)

• (시드) 변리사 IPLAB의 가장 흔한 진입점은 "본문 1차 초안 완료 + 정의·변형 미적용" → Stage 6 추천이 default 가까움. 시그널 표시 시 이 경우를 가장 먼저 매칭 시도.
• (시드) 외부 변리사 작성본은 시그널 ⑥(금지어) 위반이 흔함 → 처음 진단 시 grep 우선 수행.
• (시드) "어느 단계?" 단발 질문일 때는 보고서를 짧게 (자료 현황표 + 추천 Stage + 권장 명령만, 위험 신호·근거 생략) 출력하여 빠르게 답.
• (2026-05-27, P-2026-011-01-KR 첫 사용) 시그널 ④(자체 사전 정의 단락) 검출은 표준 4단 템플릿("라 함은 ~ 의미할 수 있다") 외 변형 형식도 인정 필수. 변형 패턴: "본 명세서에서 ~ 정의될 수 있다", "본 발명에서 ~ 명명될 수 있다", "라고 함은 ~ 의미할 수 있다", "~ 라 함은 ~ 이해될 수 있다". 표준 템플릿만 검색하면 정의 적용된 명세서를 "미적용"으로 오진.