| 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: 입력 점검 (자동)
- 사용자 업로드 파일 확인: IDS, 청구항, 도면, 부호표, 명세서 초안, 정의·변형례 적용 여부 중 무엇이 있나?
- 위 "시작 단계 자동 판단" 표에 따라 시작 Stage 결정
- TodoList 작성: 시작 Stage부터 끝까지의 단계들을 todo로 등록
- 사용자에게 진행 계획 알리기:
## 📋 진행 계획
현재 자료 확인:
- ✅ 기술내용설명서 (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차 초안)
행동:
내부 자가 점검:
- 금지어 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) 두 축에서 각각 추천 (절×카테고리×축 매트릭스 작성). 도메인 4
7개 + 설계 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: 회고 (선택)
행동:
출력 정리 (산출물 보존)
전체 워크플로우 종료 시 다음 산출물들을 모두 사용자에게 전달:
| 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)는 청구항과 무관한 경우가 많아 사용자가 제외하는 패턴 → 절 성격 분석 시 해당 카테고리 가중치 하향
