kr-patent-full-workflow

name

kr-patent-full-workflow

description

한국 특허 명세서 작성의 전체 워크플로우를 처음부터 끝까지 순차 실행하는 오케스트레이터 메타 스킬. 다른 kr-patent-* 스킬들(inventor-meeting, symbol-design, spec-drafting, definition-insertion, embodiment-addition, consistency-check, docx-builder, skill-updater)을 적절한 순서로 호출하여 발명자 IDS 입력 → 권리범위 보강 → 최종 docx 출력까지 한 흐름으로 진행. "/full", "처음부터 끝까지", "전체 워크플로우", "명세서 한 건 처음부터", "풀 프로세스", "전체 자동", "end-to-end", "토탈 패키지" 같은 표현이 보이면 사용. 사용자가 어느 단계부터 시작해야 할지 자동 판단(IDS만 있으면 미팅부터, 청구항 확정됐으면 부호 설계부터, 본문 1차 초안 있으면 권리범위 보강부터). 각 단계에서 중요 체크포인트는 사용자 승인 받음.

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

무엇을 하는가

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

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

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

┌─────────────────────────────────────────────────────────┐
│ Stage 0: 입력 점검 — 어느 단계부터 시작할지 판단              │
└──────────────────────────────┬──────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────┐
│ 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를 받는다. 나머지는 자연스럽게 다음 단계로.

체크포인트	왜 중요한가
Stage 3 (부호 체계)	본문 전체에 영향. 잘못 정하면 본문 재작성.
Stage 4 (스토리텔링)	배경/과제/수단/효과의 큰 흐름. 잘못 잡으면 권리범위 영향.
Stage 6 (정의 삽입)	청구항 한정 용어 누락 시 권리범위 축소. 변리사가 정의 대상 용어 리스트 승인 필요.
Stage 6.5 (구성요소·파이프라인)	어떤 ~부/~모듈에 판단 기준 3단을 적용할지 + 파이프라인 통합 단락의 4요소(흐름/변환/플래그/식별자) 내용 확정 변리사 판단 필요.
Stage 7 (실시예 추가)	16 기술 도메인 + 8 설계 결정 축 중 어떤 카테고리·축을 어느 절에 적용할지 변리사 판단 필요 (절 성격 적합성·청구항 충돌 회피).
Stage 8 (점검 결과)	어떤 수정을 적용할지(필수/권장/미세) 변리사 판단 필요.

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

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

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

입력 상태	시작 Stage
IDS(기술내용설명서)만 있음, 청구항 없음	Stage 1 (미팅 질문)
IDS + 청구항 초안 있음, 도면 없음	Stage 2 (청구항 확정 확인) + 도면 제안
청구항 + 도면 확정	Stage 3 (부호 설계)
부호 체계까지 있음	Stage 4 (스토리텔링)
1차 명세서 본문 있음, 정의·변형례 미적용	Stage 6 (정의 삽입)
정의 삽입까지 완료, 구성요소·파이프라인 미적용	Stage 6.5 (구성요소·파이프라인)
정의·구성요소·변형례까지 완료	Stage 8 (점검)
점검까지 끝나고 수정만 남음	Stage 9 (수정 반영)

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

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

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. 위 "시작 단계 자동 판단" 표에 따라 시작 Stage 결정
3. TodoList 작성: 시작 Stage부터 끝까지의 단계들을 todo로 등록
4. 사용자에게 진행 계획 알리기:

## 📋 진행 계획

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

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

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

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

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

행동:

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

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

Stage 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 실행
• 섹션 순서대로 작성:
  • 발명의 명칭 → 기술분야 → 배경 → 과제 → 수단 → 효과 → 도면설명 → 실시예 → 부호설명 → 청구범위 → 요약
• 작성 중간에 사용자에게 보고:

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

내부 자가 점검:

• 금지어 0건 (종래, 구성되는)
• 청구항 누락 0건
• 부호 매핑 OK

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) 두 축에서 각각 추천 (절×카테고리×축 매트릭스 작성). 도메인 47개 + 설계 35개 권장.

체크포인트 화면 예:

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

| 절 | 핵심 실시예 | 추천 카테고리 |
|---|---|---|
| 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) 모두 점검 — 이때 정의·변형 실시예의 일관성도 함께 검증
• 점수표 작성 (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	산출물	위치
1	발명자 미팅 질문서 (md 또는 docx)	outputs/
3	부호 체계 (md 표)	대화 안
4	스토리텔링 1페이지 요약 (md)	대화 안
5	명세서 본문 1차 초안	content.js
6	삽입된 정의 단락 + 정의 대상 용어 리스트	content.js (본문 통합)
6.5	구성요소 3단 보강 단락 + 파이프라인 통합 단락	content.js (본문 통합)
7	추가된 변형 실시예 단락 + 절×(도메인×설계축) 매트릭스	content.js (본문 통합)
8	정합성 점검 보고서 (md)	대화 안
10	최종 명세서 docx	outputs/ ★주산출물
11	회고 보고서 (md)	대화 안

진행 중 사용자 발화 대응

"어디까지 왔어?"

→ 현재 진행 중인 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)는 청구항과 무관한 경우가 많아 사용자가 제외하는 패턴 → 절 성격 분석 시 해당 카테고리 가중치 하향