| name | kr-patent-skill-updater |
| description | 한국 특허 명세서 작업의 회고(retrospective)를 수행하여 발견된 패턴·실수·개선점을 다른 kr-patent-* 스킬들의 "누적 학습 항목" 섹션에 자동 반영하는 메타 스킬. 컴파운딩 루프(스킬이 사용할수록 똑똑해지는 메커니즘)를 실제로 작동시키는 도구. "회고", "회고해줘", "이번 작업 정리", "스킬 업데이트", "스킬에 반영", "lessons learned", "배운 점 정리", "다음에 더 잘하려면", "작업 마무리" 같은 표현이 보이거나, 명세서 작업이 끝나고 검토자 피드백을 받은 직후 사용. 명시적 요청 없이도 긴 명세서 작업이 종료되는 시점에 "회고하실래요?"라고 제안 가능. |
한국 특허 스킬 업데이터 (메타 스킬)
무엇을 하는가
방금 끝낸 한국 특허 작업(명세서 작성, 점검, 미팅 질문 생성 등)을 회고하여 *다른 kr-patent- 스킬에 누적시켜야 할 학습 항목**을 식별하고, 사용자 승인 후 해당 SKILL.md 파일을 자동 업데이트한다.
이 스킬이 없으면 컴파운딩 루프는 이론적 개념에 머문다. 이 스킬을 주기적으로 호출해야 다른 5개 스킬이 사용할수록 똑똑해진다.
입력
- 방금 끝낸 작업의 컨텍스트 (대화 히스토리)
- (선택) 검토자/발명자 피드백
- (선택) 작업 중 발견한 실수·놀라움·예상 못 한 패턴
출력
- 회고 보고서: 어느 스킬에 어떤 학습 항목을 추가할지 분류한 제안 리스트
- 사용자 승인: 항목별 OK/NO/수정 받기
- SKILL.md 자동 업데이트: 승인된 항목을 해당 SKILL.md의 "누적 학습 항목" 섹션 끝에 append
분류 카테고리 (5개 스킬 매핑)
작업에서 발견된 학습 항목을 다음 카테고리 중 어디에 속하는지 판단한다:
| 카테고리 | 어떤 종류의 학습 항목? | 대상 스킬 |
|---|
| A. 발명자 정보 누락 | "이번엔 X를 미리 물어봤어야 했다", IDS의 새로운 구멍 유형 | kr-patent-inventor-meeting |
| B. 부호 설계 실수 | "처음부터 X 부호 범위를 예약했어야 했다", 충돌·재설계 사례 | kr-patent-symbol-design |
| C. 명세서 본문 가이드라인 | 새로운 금지 표현, 위험 패턴, 좋은 표현 양식, 검토자 지적 | kr-patent-spec-drafting (+ references/ko-patent-style-rules.md) |
| D. 새로운 점검 항목 | 마스터 체크리스트에 없던 위반 유형, 정합성 오류의 새 패턴 | kr-patent-consistency-check |
| E. docx 양식 버그·개선 | 폰트/들여쓰기/페이지 양식 이슈, 검토자가 지적한 표지 양식 | kr-patent-docx-builder/scripts/build_kr_patent.js (스크립트 직접 수정) |
분류가 모호하면 사용자에게 묻는다. "이 항목은 A로 가야 하나요, C로 가야 하나요?"
작업 순서
Step 1. 회고 트리거 확인
다음 중 하나면 진행:
- 사용자가 명시적으로 "회고해줘", "스킬 업데이트해줘" 요청
- 명세서 작업이 명확히 종료됨 (deliverable 전달 완료)
- 검토자 피드백이 들어옴
명세서 작업이 진행 중이면 회고하지 않음. 흐름을 끊지 말 것.
Step 2. 대화 컨텍스트 회상
방금 끝낸 작업의 핵심 사건들을 회상한다. 우선적으로 다음에 주목:
- 수정·재작성·되돌리기 사례: "이거 다시 해줘", "이 부분 빼고", "지난 버전이 나았다" → 첫 시도가 틀렸다는 신호. 왜 틀렸는지 분석.
- 사용자가 직접 보완한 부분: Claude가 놓쳤는데 사용자가 짚어준 항목들.
- 반복 질문: 사용자가 같은 종류의 질문을 두 번 이상 했다면, 첫 답이 부족했음.
- 놀라움 (surprise): "이걸 깜빡할 줄 몰랐다" 종류의 일.
- 검토자/발명자 피드백: 외부 인풋이 있었다면 그 내용.
Step 3. 학습 항목 추출
각 사건에 대해 다음 형식으로 추출:
[학습 항목]
- 사건: <무엇이 일어났나, 1문장>
- 일반화: <개별 사건을 일반 규칙으로>
- 대상 카테고리: A/B/C/D/E 중 하나
- 새 누적 항목 문구: <SKILL.md에 그대로 들어갈 한 줄>
좋은 항목 vs 나쁜 항목:
| 좋음 (일반화·재사용 가능) | 나쁨 (너무 특수) |
|---|
| 회로 발명에서 V_REF 정전위 조건은 시스템 효과로 명시 | 빔진단 시스템에서 V_REF=1.65V 사용 |
| 알고리즘 발명은 윈도우 크기·오버랩·업데이트 주기를 변형예에 명시 | 특정 모델의 LSTM 윈도우 32 사용 |
| 청구항 한정 수치가 도면 박스 라벨에 노출되면 위험 | 도 4의 10mV 표기 위험 |
너무 특수한 항목은 일반화한 뒤 등록. 일반화 불가능하면 등록 안 함.
Step 4. 사용자에게 제안 표시
추출된 항목들을 카테고리별로 묶어 사용자에게 표시:
## 회고 결과 — 학습 항목 N개 후보
### A. 발명자 미팅 (kr-patent-inventor-meeting)
1. [후보] <문구>
- 근거: <어떤 사건에서 도출됐는지>
- 승인? Y/N/수정
### C. 명세서 본문 (kr-patent-spec-drafting)
2. [후보] <문구>
...
사용자가 항목별로 Y/N/수정 응답.
Step 5. SKILL.md 자동 업데이트
승인된 항목을 해당 SKILL.md의 "누적 학습 항목" 섹션 끝에 append한다.
스크립트: scripts/append_learning.py
python3 /path/to/kr-patent-skill-updater/scripts/append_learning.py \
--skill-path /path/to/kr-patent-spec-drafting/SKILL.md \
--item "회로 발명에서 V_REF 정전위 조건은 시스템 효과로도 명시해야 함"
스크립트는:
- 대상 SKILL.md 백업 (
.bak.YYYYMMDD-HHMMSS)
- "### 누적 학습 항목" 섹션을 찾아서 끝에 새 줄 추가
- 항목 추가 후 통계 출력 (총 N개 항목)
Step 6. 결과 보고
업데이트가 완료된 후:
✓ kr-patent-spec-drafting/SKILL.md: 1개 항목 추가 (총 3개)
✓ kr-patent-consistency-check/SKILL.md: 2개 항목 추가 (총 4개)
백업 파일: SKILL.md.bak.20260523-180000
회고 작성 가이드
좋은 회고 항목 작성법
- 특정 사건을 일반화하라: "이번 회로 발명 건에서 V_REF가 빠졌다" → "회로 발명의 정전위 조건은 시스템 효과로도 명시"
- 재현 가능하게 써라: 누가 읽어도 "이걸 어떻게 검사할 수 있겠다" 이해되도록
- 한 줄로 압축: 너무 길면 SKILL.md가 부풀어 오른다. 한 줄로 안 되면 두 줄까지.
- 이유보다 룰: "~인 이유는 ~이다" 보다 "~할 것" 명령형. SKILL.md는 실행 가이드.
적절한 회고 빈도
- 매 명세서 작성 후: 최소 한 번 회고. 1-3개 항목 추가가 일반적.
- 검토자 피드백 받은 후: 즉시 회고. 가장 가치 있는 정보가 외부에서 옴.
- 분기/반기 정리: 누적된 학습 항목들 중 비슷한 것 합치기, 일반화 수준 재조정.
절대 하지 말 것
- 무차별 추가: 모든 작업 디테일을 다 누적하지 말 것. 일반화·재사용 가능한 것만.
- 추측으로 추가: 실제 사건이 없는데 "이런 게 있을 법하다"로 추가하지 말 것. 실증 기반만.
- 사용자 승인 없이 수정: 반드시 사용자가 OK 한 항목만 append. 자동 추론으로 수정 금지.
- 백업 누락: 항상 .bak 파일 만든 뒤 수정.
컴파운딩의 컴파운딩
이 메타 스킬 자체도 사용할수록 똑똑해진다. 회고 패턴을 발견하면 본 SKILL.md 끝의 "회고 노하우 누적" 섹션에 추가.
회고 노하우 누적
- (예시) 검토자 피드백이 있는 회고는 점검 항목(D 카테고리)으로 갈 가능성이 높음
- (예시) "이걸 깜빡했다" 사건은 90% 이상 A 또는 C 카테고리
- (2026-05-28) 도면-명세서 정합성 문제는 D 카테고리(consistency-check 점검)와 B 카테고리(symbol-design 설계) 양쪽에 동시 등록되는 경우가 흔함. 점검은 사후 검출, 설계는 사전 회피 — 같은 결함도 두 시점에서 다르게 막을 수 있음.
- (2026-05-28) AI 생성 흔적류 항목(em-dash·가운뎃점·'이해될 수 있다' 다발)은 일관되게 C 카테고리(spec-drafting)에 누적. 명세서 한 건에서 발견된 패턴은 다른 명세서에도 거의 항상 동일 적용.
- (2026-05-28) '옛 버전 자료 보고 잘못 진단함' 같은 메타 사건은 E 카테고리(docx-builder/인프라)에 등록 가능. 본질은 검토 인프라 보강 — '어떤 버전이 정본인지' 자동 판정 도구 누적.
