한국 특허 명세서 전체 워크플로우 (오케스트레이터)

무엇을 하는가

다른 8개 kr-patent- 스킬을 적절한 순서로 호출하여 명세서 한 건을 처음부터 끝까지* 진행한다. 변리사가 "이번 건 하나 끝까지 도와줘"라고 했을 때, 단계별로 빠뜨림 없이 진행하는 체크리스트 + 진행 추적 도구다.

이 스킬은 직접 산출물을 만들지 않고, 다른 8개 스킬을 적절히 호출만 한다. 오케스트레이터 역할.

전체 워크플로우 (11단계)

┌─────────────────────────────────────────────────────────┐
│ Stage 0: 입력 점검 + 기술분야 프로파일 판정 (G / H / 혼합)     │
│          — 어느 단계부터 시작할지 판단                       │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 1: 발명자 미팅 질문 생성 (선택)                       │
│ → kr-patent-inventor-meeting                            │
└──────────────────────────────┬──────────────────────────┘
                               │ (미팅 후 청구항 확정 대기)
┌──────────────────────────────▼──────────────────────────┐
│ Stage 2: 청구항 확정 확인 — 사용자가 청구항 제공            │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 3: 부호 체계 설계                                  │
│ → kr-patent-symbol-design                               │
│ ★ 체크포인트: 사용자 OK 받기                              │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 4: 스토리텔링 설계 (배경→과제→수단→효과 큰 흐름)         │
│ → kr-patent-spec-drafting (Step 3)                      │
│ ★ 체크포인트: 사용자 OK 받기                              │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 5: 명세서 본문 작성 (1차 초안)                       │
│ → kr-patent-spec-drafting (Step 4-6)                    │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 6: 권리범위 보강 — 용어 정의 삽입 ★ 체크포인트          │
│ → kr-patent-definition-insertion                        │
│ → 청구항 한정 용어 자체 사전 정의 인라인 삽입               │
│   (모드 A) 단일 용어 정의 — (i)(ii)(iii) 3요소 골격         │
│   (모드 B) 열거 항목 풀이 — 나열된 노드·관계·소스 개별 단락   │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 6.5: 권리범위 보강 — 구성요소·파이프라인 구체화 ★      │
│ → kr-patent-implementation-elaboration                  │
│   (모드 A) 각 ~부/~모듈에 판단 기준 3단(기준→적용→효과)      │
│   (모드 B) 시스템 전체 데이터 처리 파이프라인 통합 단락       │
│   (provenance flag · 식별자 연계)                        │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 7: 권리범위 보강 — 변형 실시예 추가 ★ 체크포인트        │
│ → kr-patent-embodiment-addition                         │
│ → 기술 도메인 16카테고리 + 설계 결정 8축(D1~D8) 직교 적용     │
│ → 절별 도메인 4~7개 + 설계 3~5개 변형 단락 부가             │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 8: 정합성 점검                                     │
│ → kr-patent-consistency-check                           │
│ → 점수 + 수정안                                          │
│ ★ 체크포인트: 어떤 수정 적용할지 사용자 결정                  │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 9: 수정 반영                                       │
│ → kr-patent-spec-drafting (수정 모드)                    │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 10: docx 출력                                      │
│ → kr-patent-docx-builder                                │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ Stage 11: 회고 → 학습 항목 누적 (선택)                      │
│ → kr-patent-skill-updater                               │
└─────────────────────────────────────────────────────────┘

진행 원칙

1. TodoList로 진행 상태 추적

워크플로우 시작 시 11단계를 TodoList에 등록. 각 단계 완료 시 체크. 사용자가 언제든 "어디까지 왔지?" 물으면 답할 수 있도록.

2. 단계 사이 체크포인트 (★ 표시된 5개)

중요한 결정이 필요한 단계에서만 사용자에게 명시적 OK를 받는다. 나머지는 자연스럽게 다음 단계로.

다른 단계는 자동 진행 가능. 단, 사용자가 "잠깐 멈춰", "체크해줘"라고 하면 즉시 멈춤.

3. 시작 단계 자동 판단 (Stage 0)

사용자가 /full 호출 시 현재 입력 상태를 보고 어느 단계부터 시작할지 판단:

판단이 모호하면 사용자에게 묻기:

"현재 자료를 보니 청구항은 있는데 도면이 안 보입니다. 어느 단계부터 시작할까요?"

4. 부분 실행 허용

사용자가 일부 단계만 원하면 그것만 실행:

• "부호 설계만 해줘" → Stage 3만
• "권리범위 보강만 해줘" → Stage 6-7만 (정의 → 구성요소·파이프라인 → 변형 실시예 3단 자동 진행)
• "정의만 삽입해줘" → Stage 6만
• "구성요소 구체화만 해줘" / "파이프라인 단락만 추가" → Stage 6.5만
• "변형 실시예만 추가해줘" → Stage 7만
• "점검만 해줘" → Stage 8만
• "본문 작성부터 점검까지" → Stage 4-8

/full은 default가 전체이지만, "부호부터 docx까지", "처음부터 점검까지" 같은 자연어로 범위 지정 가능.

작업 순서

Stage 0: 입력 점검 (자동)

1. 사용자 업로드 파일 확인: IDS, 청구항, 도면, 부호표, 명세서 초안, 정의·변형례 적용 여부 중 무엇이 있나?
2. 기술분야 프로파일 판정 (★ 필수, 다른 판단보다 먼저)

H로 판정되면 유형 A(단일 실시형태) / 유형 B(복수 실시형태)까지 이 시점에 확정한다. 유형이 뒤집히면 S4, S5, S13 전체를 다시 써야 하므로 Stage 4 진입 전 사용자 확인 필수.

1. 위 "시작 단계 자동 판단" 표에 따라 시작 Stage 결정
2. TodoList 작성: 시작 Stage부터 끝까지의 단계들을 todo로 등록
3. 사용자에게 진행 계획 알리기:

## 📋 진행 계획

현재 자료 확인:
- ✅ 기술내용설명서 (IDS)
- ❌ 청구항 초안
- ❌ 도면

기술분야 프로파일: G (AI/SW/제어/시스템)   ← H면 "H (기계) / 유형 B 복수 실시형태" 형태로 명시

→ Stage 1 (발명자 미팅 질문 생성)부터 시작합니다.

총 11단계 중 10단계 진행 예정. 진행하시겠습니까?

Stage 1: 발명자 미팅 질문 생성

조건: IDS만 있고 청구항이 없을 때.

행동:

• kr-patent-inventor-meeting 스킬 호출
• 7관점 질문 리스트 생성
• 사용자가 발명자 송부용 docx 원하면 kr-patent-docx-builder 호출

이후: "발명자 미팅 후 청구항 받으시면 알려주세요. 다음 단계를 기다리겠습니다."

Stage 2: 청구항 확정 확인

조건: 청구항이 있을 때.

행동:

• 청구항 원문 확인 (변경 금지 항목)
• 청구항 카테고리 분류 (물건/방법/시스템/프로그램)
• 청구항 갯수 카운트
• 종속 관계 트리 작성
• 핵심 어휘 추출

체크: 청구항에 명백한 오류(인용 누락, 종속 관계 오류 등)가 있으면 사용자에게 경고. 단 임의 수정은 금지.

카테고리 정합 체크 (★ Stage 0 프로파일 연동): Stage 0에서 H 또는 혼합으로 판정되었는데 제1항이 방법항이면, 청구항이 아직 확정 전(사내 초안, 미출원)인 경우에 한해 물건항 전환을 1회 제안한다.

"기구 발명인데 제1항이 방법항입니다. 물건항으로 세우면 침해 입증이 피고 제품 구조 대비만으로 끝나고, 유통 단계까지 권리가 미칩니다. 제1항을 물건항으로 재구성하고 현재 방법항을 제2독립항으로 내릴까요? (근거가 공정 진보성에 있다면 현행 유지)"

승인하면 kr-patent-claim1-drafting P-0-2로 물건항을 작성하고, 방법항은 kr-patent-dependent-claim-drafting으로 제2독립항 처리한다. 이미 출원된 건, 또는 사용자가 현행 유지를 택하면 원문 그대로 진행한다. 어떤 경우에도 임의 수정은 금지.

Stage 3: 부호 체계 설계 ★ 체크포인트

행동:

• kr-patent-symbol-design 스킬 호출
• 청구항·도면 분석 → 계층적 부호 트리 생성
• 부호-명칭 매핑표는 내부 작업용 참고 자료로 보존 (명세서의 【부호의 설명】 섹션 박는 것은 default 생략 — 자세한 이유는 symbol-design SKILL.md Step 4 참조)

체크포인트 — 사용자에게 표시하고 OK 받기:

## 🔢 부호 체계 안

[계층 트리]
100 시스템
├─ 110 ...
├─ 120 ...
   ├─ 121-124 ...
S100 방법
├─ S110 ...
...

이대로 진행해도 될까요? 수정 필요한 부호가 있으면 알려주세요.

OK 받으면 다음 단계.

Stage 4: 스토리텔링 설계 ★ 체크포인트

행동:

• kr-patent-spec-drafting 스킬의 Step 3 (스토리 설계) 부분 실행
• 배경기술 4단락 흐름, 해결과제 5-8개, 효과 매핑을 1페이지 요약

체크포인트:

## 📖 스토리텔링 설계

【배경기술】
- 1단락: <산업적 동향>
- 2단락: <기존 방식>
- 3단락: <기존 한계>
- 4단락: <브릿지>

【해결과제 5개】
1. ~ 위한 것
2. ~ 위한 것
...

【효과 5개】 (해결과제와 1:1 매핑)
1. <구조→메커니즘→이점>
...

이 스토리로 본문 작성하겠습니다. OK?

OK 받으면 본문 작성.

Stage 5: 명세서 본문 작성 (1차 초안)

행동:

• kr-patent-spec-drafting의 Step 4-6 실행
• Stage 0에서 판정한 프로파일에 따라 규범을 로드한다.
• G: kr-patent-spec-drafting/references/sw-ai-spec-supplement.md (볼륨 V1~V7, 실시예 L1~L4, 챕터 목차, G1~G4 필수 서술)
• H: kr-patent-spec-drafting/references/hw-mechanical-spec-rules.md (유형 A/B 구조, 독립항 확정형 어미, 도면 순차 참조, 섹션 마무리 효과 문단, 마감 문단)
• 해외출원(미국, PCT) 가능성이 있고 프로그램 청구항을 두는 건이면 `kr-patent-spec-drafting/references/overseas-crm-support.md`를 함께 로드한다. 저장매체 지지문언은 S4와 S14 0파트 두 곳에 최초 명세서 단계에서만 넣을 수 있다(이후 보정 불가). 착수 시 사용자에게 해외출원 예정 여부를 1회 확인한다.
• 도면이 미확보이거나 신규 설계가 필요하면 `kr-patent-spec-drafting/references/drawing-set-design.md`를 로드하고, S11 서두보다 S12(도면 세트 설계)를 먼저 수행한다. 산출물에 도면별 대응 청구항 매핑표와 도면 뒷받침이 없는 청구항 목록을 포함시킨다.
• 섹션 순서대로 작성:
• 발명의 명칭 → 기술분야 → 배경 → 과제 → 수단 → 효과 → 도면설명 → 실시예 → 부호설명 → 청구범위 → 요약
• 작성 중간에 사용자에게 보고:

  ⏳ 실시예 작성 중 (도 4 / 8 도면 완료)

내부 자가 점검:

• 금지어 0건 (종래, 구성되는 / H는 "구현하는", "반드시" 추가)
• 청구항 누락 0건
• 부호 매핑 OK
• 어미 규칙: G는 신규 문장 "~할 수 있다", H는 독립항 대응 구성만 확정형 "~한다"
• H 유형 B: 실시형태 전환 브릿지, 중복 회피 문구, 차이점 명시 3종 존재

content.js 객체 형태로 정리하여 다음 단계 준비.

이 시점의 산출물은 1차 초안 — 권리범위 보강(Stage 6·6.5·7)이 추가되어야 비로소 실무 수준 명세서가 됨.

Stage 6: 권리범위 보강 — 용어 정의 삽입 ★ 체크포인트

행동:

• kr-patent-definition-insertion 스킬 호출
• 청구항·본문에서 정의 대상 용어 추출 (필수: 청구항 한정 용어, 권장: 추상적·다의적 용어)
• 정의 대상 리스트를 사용자에게 제시

체크포인트 화면 예:

## 📖 정의 삽입 대상 용어

🔴 필수 (청구항 한정): N개
- "최적 해체 방법 데이터"
- "분류 모델"
- "디지털 트윈 모델"
- ...

🟡 권장 (추상적·다의적): M개
- "정밀도"
- "효율"
- ...

어떤 용어를 정의할까요?
- 필수만
- 필수 + 권장
- 항목별 선택

OK 받으면 4원칙(자체 사전·동의어 방어망·기능 중심 추상화·비제한적 예시) 적용 표준 4단 템플릿으로 본문 첫 등장 위치 직후에 인라인 단락 정의 삽입.

내부 자가 점검:

• 모든 종결 어미 "~할 수 있다" 형태
• "한정되지 않는다" 마무리 존재
• 동의어 3개 이상 (필수급 용어)
• 최적화·예측 용어는 "근사해 포함" 명시

Stage 6.5: 권리범위 보강 — 구성요소·파이프라인 구체화 ★ 체크포인트

행동:

• kr-patent-implementation-elaboration 스킬 호출
• 본문에서 "~부(NNN)", "~모듈(NNN)", "~엔진(NNN)" 패턴을 모두 추출
• 각 구성요소의 첫 도입 단락이 (a) 입력 분류 기준, (b) 처리 분기 기준, (c) 임계값/우선순위 중 어느 하나도 본문에서 읽히지 않으면 모드 A 대상으로 등록
• 모든 구성요소 개별 설명 종료 위치를 모드 B 삽입 후보로 등록

진입 트리거 (자동 추천): 본문에 "~부/~모듈/~엔진" 패턴이 3개 이상 등장 + 그중 어느 하나가 "보다 구체적으로,"로 시작하는 단락 없이 끝남.

체크포인트 화면 예:

## 🔧 구성요소·파이프라인 보강 대상

🔴 모드 A (구성요소 3단 보강) — N개
- 수신부(310) — 입력 분류 기준 부재
- 지식그래프 생성부(320) — 추출 분기 기준 부재
- 정합성 데이터 생성부(340) — 매칭 임계값/우선순위 부재
- ...

🟡 모드 B (파이프라인 통합 단락) — 1회
- 삽입 위치: "이상에서 살펴본 시스템에 의하여 수행되는 방법에 대하여 살펴본다" 직전

어떻게 진행할까요?
- 모드 A 전체 + 모드 B
- 모드 A 항목별 선택 + 모드 B
- 모드 B만

OK 받으면 표준 3단(판단 기준 → 적용 방식 → 효과) + 4요소(흐름/변환/플래그/식별자) 템플릿으로 본문 단락 부가.

내부 자가 점검:

• 모드 A 내부 마커([1단][2단][3단])가 최종 본문에서 모두 제거됨
• 모든 단락 말미 "다만, 본 발명에서 ~는 이에 한정되지 않는다"
• (i)(ii)(iii) 열거 사용
• consistency-check H섹션 규칙 4·5·8 자체 점검 통과
• 【청구범위】 섹션이 Stage 진입 시점 원본과 byte-단위로 동일

Stage 7: 권리범위 보강 — 변형 실시예 추가 ★ 체크포인트

행동:

• kr-patent-embodiment-addition 스킬 호출
• "발명을 실시하기 위한 구체적인 내용" 절의 각 하위 절별 핵심 실시예 식별
• 기술 도메인 16카테고리 + 설계 결정 8축(D1~D8) 두 축에서 각각 추천 (절×카테고리×축 매트릭스 작성). 도메인 4~7개 + 설계 3~5개 권장.

체크포인트 화면 예:

## 🔀 변형 실시예 적용 매트릭스

| 절 | 핵심 실시예 | 추천 카테고리 |
|---|---|---|
| 2-1. 좌표계 정합 | ICP 알고리즘 | ① 알고리즘 변형, ② 단계적 분해, ④ 데이터 종류 |
| 3. 손상 데이터 생성 | RGB 이미지 입력 | ④ 데이터 종류, ⑤ 모델 구조, ⑥ 학습 메커니즘 |
| 4. 자재 등급 산출 | 분류 모델 | ⑤ 모델 구조, ⑥ 학습 메커니즘, ⑦ 시간축 |
| 5. 최적 해체 방법 도출 | 단일 목적 최적화 | ⑧ 불확실성, ⑮ 제약 조건 (다목적) |
| 7. 해체 시뮬레이션 | 결정적 결과 | ⑪ 배포 형태, ⑫ 가시화 (AR/VR) |
| 8. 프로그램 | 단일 서버 | ⑪ 배포 형태, ⑬ 블록체인 |

이대로 작성할까요? 추가/제외할 카테고리가 있으면 알려주세요.

OK 받으면 도입어 변주(한편 → 또 다른 → 또한 → 나아가) + 단락 3단 구조(변형 도입 → 구체 설명 → 효과 + 한정 부정)로 각 변형 실시예 단락 작성.

⛔ 청구범위 비수정 원칙: 본 Stage는 "발명을 실시하기 위한 구체적인 내용" 절에만 변형 실시예 단락을 부가한다. 【청구범위】 섹션은 절대 수정하지 않는다 — 청구항 추가·수정·삭제 0건. 변형은 잠재적 종속청구항의 "후보"로 기술될 뿐이며, 실제 청구항화 여부는 추후 분할/계속출원 또는 보정 단계에서 변리사가 별도 판단. 사용자가 "이 변형도 청구항에 넣어줘"라고 요청해도 거부하고 별도 작업으로 분리.

내부 자가 점검:

• 한 절 안 도입어 중복 없음
• 모든 단락 끝 "한정되지 않는다" 마무리
• 변형이 청구항을 침해하지 않음
• 도면번호 임의 추가 없음
• 【청구범위】 섹션이 Stage 진입 시점 원본과 byte-단위로 동일 (불변식)

Stage 8: 정합성 점검 ★ 체크포인트

행동:

• kr-patent-consistency-check 스킬 호출
• 마스터 체크리스트 7개 영역(A-G) 모두 점검 — 이때 정의·변형 실시예의 일관성도 함께 검증
• H 프로파일이면 L섹션 분기 적용 — G 전용 정형 요구를 제외하고 HW 12항목(L-2-1~L-2-12) 추가 점검
• 점수표 작성 (10개 항목 가중 평균)

체크포인트:

## 📊 정합성 점검 결과

종합 점수: NN/100 (등급)

🔴 필수 수정 N건
🟡 권장 수정 N건
🟢 미세 조정 N건

[상세 리스트와 수정안]

어떤 수정을 적용할까요?
- 필수만
- 필수 + 권장
- 모두 적용
- 항목별 선택

사용자 결정 받기.

Stage 9: 수정 반영

행동:

• Stage 8에서 결정된 수정 사항 적용
• 수정 후 재점검 (간이 버전 — 적용한 항목만 검증)

수정 적용 후 사용자에게 변경 사항 요약:

## ✅ 수정 완료

| 항목 | Before → After |
|---|---|
| 배경 4단락 | "100 dB" → "광범위한 동적 영역" |
| 해결과제 3번 | "정량적으로 판정하여" 표현 제거 |
| 효과 5번 | 3단 인과 구조로 재구성 |
| 정의 "분류 모델" | 동의어 1개 → 4개로 확장 |

Stage 10: docx 출력

행동:

• kr-patent-docx-builder 스킬 호출
• content.js 작성 (또는 메모리 객체)
• build_kr_patent.js 실행
• validate.py로 검증
• 파일을 /mnt/user-data/outputs/에 출력
• present_files로 사용자에게 전달

파일명 패턴:

_<법인명>__<관리번호>_명세서초안<버전>_<담당자>__<YYYYMMDD>_<발명명>.docx

선택: 외부 검토용으로 보낼 docx라면 kr-patent-navigation-pane 추가 호출하여 Word 탐색창에 outline 노출.

Stage 11: 회고 (선택)

행동:

• 사용자에게 회고 진행할지 묻기:

  🎉 명세서 docx 출력 완료!
  
  이번 작업에서 새로 발견한 패턴/실수가 있다면 다른 스킬에 반영할까요?
  → kr-patent-skill-updater로 학습 항목 누적

• Y 응답이면 kr-patent-skill-updater 호출
• N이면 작업 종료

출력 정리 (산출물 보존)

전체 워크플로우 종료 시 다음 산출물들을 모두 사용자에게 전달:

진행 중 사용자 발화 대응

"어디까지 왔어?"

→ 현재 진행 중인 Stage 번호와 진행률 답변. TodoList 보여주기.

"잠깐 멈춰"

→ 즉시 중단. 현재 상태 저장(요약). 다음 발화 대기.

"X 단계만 다시 해줘"

→ 해당 Stage로 점프. 이전 단계 출력은 보존.

"X 단계 건너뛰어줘"

→ Stage 1, 4, 6, 6.5, 7, 9, 11은 조건에 따라 건너뛸 수 있음. Stage 2, 3, 5, 8, 10은 핵심이라 건너뛰면 경고. 특히 Stage 6·6.5·7(권리범위 보강)을 건너뛸 경우 "권리범위가 좁아질 수 있습니다. 정말 건너뛰시겠습니까?" 명시 경고.

"처음부터 다시"

→ TodoList 리셋. Stage 0부터 재시작.

사용 예시

예시 1: IDS만 있는 상태

User: /full

Claude: 
📋 진행 계획
현재 자료 확인:
- ✅ IDS (기술내용설명서)
- ❌ 청구항
- ❌ 도면

→ Stage 1 (발명자 미팅 질문 생성)부터 시작합니다. 총 10단계 진행 예정.

[Stage 1 진행: 7관점 질문 리스트 생성]
[미팅 후 청구항 받으시면 알려주세요.]

예시 2: 청구항 + 도면 있는 상태 (가장 흔한 케이스)

User: /full

Claude:
📋 진행 계획
- ✅ 청구항 20개
- ✅ 도면 8장
- ❌ 부호 체계

→ Stage 3 (부호 체계 설계)부터 시작합니다. 9단계 진행 예정.

[Stage 3: 부호 트리 제시 → 사용자 OK]
[Stage 4: 스토리 1페이지 → 사용자 OK]
[Stage 5: 본문 1차 작성]
[Stage 6: 정의 대상 용어 리스트 → 사용자 OK → 인라인 정의 삽입]
[Stage 7: 절×카테고리 매트릭스 → 사용자 OK → 변형 실시예 단락 추가]
[Stage 8: 점검 → 점수표 + 수정안]
[Stage 9: 수정 반영]
[Stage 10: docx 출력]
[Stage 11: 회고? Y/N]

예시 3: 1차 본문은 있는데 권리범위 보강이 필요한 상태

User: /full

Claude:
📋 진행 계획
- ✅ 청구항·도면·부호
- ✅ 명세서 본문 1차 초안 (정의·변형례 미적용)

→ Stage 6 (권리범위 보강 — 정의 삽입)부터 시작합니다. 6단계 진행 예정.

[Stage 6: 정의 대상 용어 N개 추출 → 사용자 OK → 인라인 정의 삽입]
[Stage 7: 절×카테고리 매트릭스 → 사용자 OK → 변형 실시예 단락 추가]
[Stage 8-10: 점검 → 수정 → docx]

예시 4: 기존 명세서 점검만

User: /full 점검부터만 해줘

Claude:
범위: Stage 8 (점검) → Stage 9 (수정) → Stage 10 (재출력)

[Stage 8: 점검]
[수정 적용 여부 결정]
[Stage 10: 수정된 docx 재출력]

예시 5: 권리범위 보강만 (정의 + 변형 실시예)

User: 이 명세서 권리범위 보강만 해줘

Claude:
범위: Stage 6 (정의 삽입) → Stage 7 (변형 실시예) → Stage 8 (점검)

[Stage 6: 정의 대상 용어 추출 → 인라인 삽입]
[Stage 7: 절×카테고리 매트릭스 → 변형 단락 추가]
[Stage 8: 권리범위 보강 결과 정합성 점검]

컴파운딩 루프 (개선 메모)

/full을 사용할수록 어느 단계에서 사용자가 자주 멈추는지, 어느 체크포인트가 부족한지 패턴이 보임. 이를 본 SKILL.md 끝에 누적.

누적 학습 항목

• (예시) 사용자가 Stage 3 부호 체계에서 자주 수정 요청 → 부호 제안 시 변형 대안도 2-3개 함께 제시
• (예시) Stage 8 점검 후 수정 반영(Stage 9)이 한 번에 안 끝나고 2-3회 반복되는 패턴이 잦음 → Stage 9 후 자동 재점검 추가 검토
• (예시) Stage 6 정의 삽입 시 변리사가 "정밀도", "효율" 같은 추상 용어를 거의 항상 정의 대상에 추가 → 처음부터 권장 리스트에 포함하여 제시
• (예시) Stage 7 변형 실시예에서 카테고리 ⑬(블록체인), ⑫(AR/VR)는 청구항과 무관한 경우가 많아 사용자가 제외하는 패턴 → 절 성격 분석 시 해당 카테고리 가중치 하향
• (2026-07-14, 사건 E) Stage 0에서 발명자 답변서 동반 확인 — IDS(기술내용설명서) 외 발명자 Q&A 답변서가 케이스 폴더에 있으면 반드시 함께 읽어 '오버클레임 금지선'(미구현 기능, 삭제요청 규격, 자유형식/개방루프 여부, 정량데이터 미확보→도면 예시적 처리)을 확정한 뒤 Stage 5~7 진행. 프로젝트 메모리로 저장.
• (2026-07-14, 사건 E) 도면부호 처리 분기 — Stage 8에서 본문 부호가 도면에 없는 결함(내부 블록 무번호)이 나오면, 도면 태깅(drawing-tagging) 또는 본문 부호 삭제 중 사용자 선호를 물을 것. 사용자가 태깅 거부 성향이면 부호 삭제가 기본 대안.
• (2026-07-14, 사건 E) Stage 10 후 참조 서식 정합 요청 빈발 — 사용자가 기존 최종본 docx의 탭 간격(들여쓰기)을 기준으로 재빌드 요청하는 패턴. build 전 참조 서식(firstLine 등) 실측→로컬 빌드 상수 반영. [[feedback_kr_patent_docx_indent]]