patent-pipeline

name	patent-pipeline
description	코드베이스 기반 AI 자동 특허 발굴·평가·출원 파이프라인. "특허", "가출원", "patent", "발명 발굴" 등 특허 관련 작업 요청 시 반드시 사용. /patent-pipeline으로 호출.
argument-hint	[target=repo/path] [scope=full|module|feature] [step=0-8] [item=기존후보명]

Patent Pipeline

목적

코드베이스를 AI가 분석하여 특허 가능한 발명을 발굴하고, 가치평가 → 선행기술 조사 → 최종평가 → 명세서 생성 → 발송/저장까지를 자동화하는 파이프라인 스킬입니다.

• 헤드리스 반복 리뷰: 각 핵심 단계(코드분석, 가치평가, 선행기술, 초안생성)에서 서브에이전트가 반복 검증
• 이력 DB 학습: 과거 발굴·기각·출원 이력을 참조하여 스코프 필터링 및 품질 개선
• 수동/배치 모드: 사용자 지정(수동) 또는 PR 머지 감지(배치, 추후 구현)

인수

인수	필수	설명
target	필수	분석 대상 (리포 경로, 모듈 경로, 또는 기능 설명)
scope	선택	full (전체 스캔), module (모듈 단위), feature (기능 단위). 기본값: feature
step	선택	특정 단계부터 재개 (0-8). 기본값: 0
item	선택	기존 후보 지정 (이력 DB에 있는 후보명. step≥2일 때 사용)

파일 구조

파일	용도
docs-business/05. 특허/patent-history.json	이력 DB (SoT)
docs-business/05. 특허/{slug}/	후보별 산출물 디렉토리
docs-business/05. 특허/{slug}/*-draft.md	가출원 초안
docs-business/05. 특허/{slug}/prior-art.md	선행기술 조사 보고서
docs-business/05. 특허/{slug}/evaluation.md	평가 보고서

워크플로우

Step 0: 트리거 & 스코핑

1. target 인수 확인. 없으면 사용자에게 질문
2. 이력 DB (docs-business/05. 특허/patent-history.json) 로드
3. 이력에서 기각/출원 건과 중복되는 범위를 식별하여 사용자에게 고지
4. 분석 대상 파일 목록 결정

출력: 분석 대상 파일 목록 + 제외 사유 (있는 경우)

Step 1: 코드 분석 — 특허 후보 도출

Agent 툴로 헤드리스 서브에이전트 실행:

당신은 소프트웨어 특허 발굴 전문가입니다.

## 분석 대상
{target 경로 및 파일 목록}

## 지시사항
다음 코드베이스를 분석하여 특허 가능한 발명 후보를 도출하세요.

분석 관점:
- 아키텍처 수준의 신규한 구조/조합
- 신규한 알고리즘 또는 데이터 처리 방법
- 기존 기술의 신규한 조합 방식
- 사용자 경험을 혁신하는 인터랙션 패턴

자동 제외:
- 범용 CRUD 패턴
- 표준 라이브러리/프레임워크 사용법
- 공지된 디자인 패턴의 단순 적용

각 파일을 실제로 읽으세요 (기억에 의존 금지).

## 출력 형식

### 읽은 파일
- path/to/file (줄 범위)

### 후보 목록
각 후보마다:
- **명칭**: 발명의 간략한 이름
- **핵심 구성**: 어떤 기술적 구성이 신규한지
- **해결 과제**: 어떤 기술적 문제를 해결하는지
- **관련 코드**: 핵심 파일 및 줄 범위
- **초기 평가**: 특허성 1-10 (근거 포함)

후보가 없으면:
NONE — [구체적 근거]

적대적 반복 리뷰: 서브에이전트 결과를 받은 후, 제2 서브에이전트(비평자)가 검증한다.

패스	렌즈	체크 항목
1	기술적 정확성	후보의 기술 설명이 코드와 일치하는지. 실제 코드를 읽어 확인. 코드에 없는 기능을 기술 → [CRITICAL]
2	누락 발굴	분석 대상 코드 중 검토되지 않은 영역이 있는지. 특허성 있는 모듈 간 상호작용이 누락되지 않았는지
3	과잉 발굴	공지된 기술의 단순 적용인 후보가 포함되지 않았는지. CRUD/표준패턴이 후보에 남아있으면 → 제거
4+	종합 재확인	패스 1–3 재적용. 연속 2회 변경 없음 → 확정

비평자 프롬프트에 반드시 포함: "각 후보에 대해 관련 코드 파일을 직접 읽어 기술 설명과 대조하세요."

출력: 확정된 후보 목록. 이력 DB에 status: "candidate" 로 등록.

Step 2: 가치 평가

각 후보에 대해 Agent 툴로 헤드리스 서브에이전트 실행:

당신은 특허 가치평가 전문가입니다.

## 평가 대상
{후보 명칭, 핵심 구성, 해결 과제}

## 평가 기준 (각 1-10점, 근거 필수)
1. 시장 규모 — 대상 시장 크기
2. 수익 잠재력 — 매출 또는 비용 절감 효과
3. 경쟁 우위 — 기존 대비 차별점
4. 방어 가치 — 경쟁사 견제 효과
5. 구현 가능성 — 현재 기술로 실현 가능성
6. 확장성 — 타 도메인 확장 가능성

## 출력 형식
### 평가 결과
| 항목 | 점수 | 근거 |
각 항목별 점수와 근거

### 종합 점수: N/10
### 추천: 진행 | 보류 | 폐기
### 추천 근거: ...

적대적 반복 리뷰: 제2 서브에이전트(비평자)가 평가 논리를 검증한다.

패스	렌즈	체크 항목
1	근거 타당성	각 점수의 근거가 구체적 사실에 기반하는지. 근거 없는 높은 점수 → [CRITICAL]. 시장 규모 주장에 출처 없음 → [INFO]
2	비교 공정성	기존 솔루션 대비 차별점 주장이 정확한지. 기존 제품이 이미 유사 기능 제공하는데 누락 → [CRITICAL]
3	리스크 반영	SW 특허 등록 난이도, 각국 법률 차이, 빅테크 진입 리스크 등이 점수에 반영되었는지
4+	종합 재확인	패스 1–3 재적용. 연속 2회 변경 없음 → 확정

임계값: 종합 6.0 미만 → 폐기 (이력 DB에 status: "rejected_value" 기록). 6.0 이상 → Step 3 진행.

사용자에게 평가 결과 요약 제시. 사용자가 override 가능.

Step 3: 선행기술 조사

통과한 후보에 대해 Agent 툴로 헤드리스 서브에이전트 실행:

당신은 특허 선행기술 조사 전문가입니다.

## 조사 대상
{후보 명칭, 핵심 구성, 해결 과제}

## 조사 방법
WebSearch를 사용하여 다음을 검색하세요:
1. 특허 DB — Google Patents, KIPRIS 키워드 검색
2. 기존 제품/서비스 — 유사 기능을 제공하는 제품
3. 학술 논문 — 유사 기술 연구
4. 오픈소스 — GitHub 등에서 유사 구현

## 출력 형식

### 검색 쿼리
- [사용한 검색어 목록]

### 선행기술 목록
각 건마다:
- **명칭/출처**: ...
- **핵심 내용**: ...
- **유사점**: ...
- **차이점**: ...

### 신규성 판단
- 종합 신규성: 높음 | 보통 | 낮음
- 핵심 차별점: [본 발명만의 고유 요소]
- 주의 사항: [청구항 작성 시 강조할 점]

선행기술이 없으면:
NONE — [검색 범위와 사용한 쿼리를 구체적으로 명시]

적대적 반복 리뷰: 제2 서브에이전트(비평자)가 조사의 완전성을 검증한다.

패스	렌즈	체크 항목
1	검색 커버리지	영문/한글 양방향 검색이 되었는지. 특허 DB, 제품, 논문, 오픈소스 4개 영역 모두 조사되었는지. 누락된 영역 → [CRITICAL]
2	유사도 정확성	각 선행기술과의 유사점/차이점 분석이 정확한지. 차이점이라 주장했지만 실제로는 유사한 경우 → [CRITICAL]. 추가 검색어 제안
3	결론 타당성	신규성 판단이 선행기술 목록과 일관되는지. 강한 선행기술이 있는데 "높음" 판정 → [CRITICAL]
4+	종합 재확인	패스 1–3 재적용. 연속 2회 변경 없음 → 확정

비평자 프롬프트에 반드시 포함: "조사자가 사용하지 않은 검색어를 3개 이상 제안하고, 직접 WebSearch로 검증하세요."

출력: 선행기술 조사 보고서. docs-business/05. 특허/{slug}/prior-art.md 저장.

Step 4: 최종 평가

Step 2 (가치) + Step 3 (선행기술) 결과를 종합하여 판정:

판정	조건	이력 DB status
출원 추천	가치 7+ & 신규성 높음	approved
조건부 추천	가치 6+ & 신규성 보통	conditional
보류	추가 조사 필요	on_hold
폐기	가치 낮음 또는 신규성 낮음	rejected_final

사용자에게 판정 결과 + 근거 제시. 사용자 게이트 — 사용자 승인 후 Step 5 진행.

출력: 평가 보고서. docs-business/05. 특허/{slug}/evaluation.md 저장.

Step 5: 초안 생성

승인된 후보에 대해 Agent 툴로 헤드리스 서브에이전트 실행:

당신은 한국 특허 명세서 작성 전문가입니다.

## 발명 정보
{후보 명칭, 핵심 구성, 해결 과제, 관련 코드, 선행기술 분석}

## 작성 지침
다음 구조로 가출원 명세서를 작성하세요:

1. 기술분야
2. 배경기술 — 선행기술 분석 결과 반영
3. 발명의 요약 — 파이프라인/구조 다이어그램 포함
4. 청구범위
   - 독립 청구항 1 (방법)
   - 독립 청구항 2 (시스템)
   - 종속 청구항 3개 이상
5. 발명의 상세한 설명
6. 발명의 효과
7. 도면의 간단한 설명

## 작성 규칙
- 출원인: (주)넥스테인
- 발명자: <YOUR_CEO_NAME>
- 청구항은 구체적 기술 용어 사용, 추상적 표현 최소화
- 배경기술에서 선행기술의 한계를 명확히 기술
- 각 청구항 요소가 상세 설명에서 뒷받침되는지 확인

적대적 반복 리뷰: 초안 생성 후 헤드리스 서브에이전트로 특허 전용 렌즈 리뷰를 반복 실행한다. /review-pass와 동일한 구조이되, 특허 명세서 전용 렌즈를 사용한다.

패스	렌즈	체크 항목
1	청구항 지지성	각 청구항 요소(구성요소, 단계)가 상세 설명에서 뒷받침되는지. 청구항에만 있고 상세 설명에 없는 요소 → [CRITICAL]. 상세 설명에 있지만 청구항에 누락된 핵심 요소 → [CRITICAL]
2	선행기술 차별성	독립 청구항이 선행기술 조사에서 도출한 핵심 차별점을 반영하는지. 선행기술과 구분되지 않는 청구항 → [CRITICAL]. 배경기술 섹션이 선행기술의 한계를 정확히 기술하는지
3	용어 일관성	청구항·요약·상세설명 간 동일 개념에 동일 용어 사용 여부. 같은 구성요소를 다른 이름으로 지칭 → [CRITICAL]. 정의 없이 사용된 약어 → [INFO]
4	청구항 구조	독립항의 범위가 적절한지 (너무 넓으면 선행기술에 걸리고, 너무 좁으면 회피 용이). 종속항이 독립항을 실질적으로 좁히는지. 방법 청구항과 시스템 청구항 간 대응 관계
5	실시예 충분성	상세 설명이 당업자가 실시 가능한 수준으로 기재되었는지. 추상적 서술만 있고 구체적 구현 미기재 → [CRITICAL]. 도면 참조가 누락된 구성요소 → [INFO]
6+	종합 재확인	패스 1–5 렌즈를 순서대로 재적용. 새 발견사항 없으면 CLEAN

리뷰 서브에이전트 프롬프트:

당신은 특허 명세서 리뷰 전문가입니다. Pass {N} / 렌즈: {렌즈명}

## 검토할 파일
{초안 파일 경로}

## 참조 자료
{선행기술 조사 보고서 경로}
{평가 보고서 경로}

## 지시사항
이 특허 명세서 초안에는 문제가 있을 수 있습니다. 찾아내세요.
- 초안 파일을 처음부터 끝까지 읽으세요 (기억에 의존하지 말고 실제로 읽을 것)
- 이번 패스의 렌즈: **{렌즈명}** — {체크 항목}
- "좋아 보입니다"는 금지. 문제가 없다면 왜 없는지 구체적으로 설명해야 합니다
- 발견사항마다 심각도를 표시하세요:
  - [CRITICAL]: 특허 등록 거절 사유가 될 수 있는 문제 — 반드시 수정
  - [INFO]: 품질 개선 권장사항 — 수정 권장하나 비차단

## 출력 형식 (이 형식만 허용)

### 읽은 파일
- path/to/file (읽은 줄 범위)

### 발견사항
[발견된 문제를 `섹션:항목 [CRITICAL|INFO] — 설명` 형식으로 하나씩 나열]
또는
NONE

### NONE인 경우 근거
[이번 패스의 렌즈({렌즈명})로 구체적으로 무엇을 확인했고 왜 문제가 없는지]

클린패스 규칙:

• 발견사항 NONE + 근거에 확인 항목이 구체적으로 명시 → 클린패스
• 최소 패스 5 CLEAN + 패스 6 CLEAN (5개 렌즈 소진 후 연속 2회)
• 근거 없는 NONE → 클린패스 불인정, 패스 재실행
• 형식 미준수 → 결과 무효, 패스 재실행

수정 흐름:

1. 서브에이전트 발견사항 수신
2. 메인 AI가 초안 수정 적용
3. 다음 패스 번호로 리뷰 재실행
4. 연속 2회 CLEAN → 확정

출력: docs-business/05. 특허/{slug}/*-draft.md 저장. 이력 DB status → drafted.

Step 6: 발송 / 저장

사용자에게 옵션 제시:

1. 저장만 — 파일 저장 완료 안내 (기본값)
2. 변리사 발송 — 이메일 초안 생성 (추후 자동 발송 구현)
3. GitHub Issue 연동 — docs-business 이슈에 결과 코멘트 추가

이력 DB status 업데이트:

• 저장만: drafted
• 발송: sent_to_attorney

Step 7: 출원 전 관리 (수동 트리거)

변리사 피드백 수신 시 step=7로 재호출:

1. 피드백 내용을 사용자에게 확인
2. AI가 수정안 생성 (헤드리스 반복 리뷰)
3. 수정된 초안 저장
4. 이력 DB 업데이트 (revision_count 증가)

기각 시: status → rejected_attorney, 기각 사유 기록.

Step 8: 출원 후 관리 (수동 트리거)

출원 완료 후 step=8로 재호출하여 상태 추적:

1. 출원 번호, 출원일 기록
2. OA 수신 시 대응 초안 생성
3. 등록 시 등록 번호, 등록일 기록
4. 갱신 일정 알림 (추후 배치 구현)

이력 DB status 전이: filed → oa_received → registered / abandoned

이력 DB 스키마

{
  "version": "1.0",
  "candidates": [
    {
      "id": "patent-pipeline-001",
      "slug": "patent-pipeline",
      "name": "코드베이스 기반 AI 자동 특허 발굴·출원 파이프라인",
      "source": "manual",
      "target": "naia-adk (root workspace)",
      "status": "drafted",
      "value_score": 7.5,
      "novelty": "high",
      "created_at": "2026-03-24",
      "updated_at": "2026-03-25",
      "issue_url": null,
      "draft_path": "docs-business/05. 특허/patent-pipeline/patent-pipeline-draft.md",
      "prior_art_path": null,
      "evaluation_path": null,
      "rejection_reasons": [],
      "revision_count": 0,
      "filing_number": null,
      "filing_date": null,
      "registration_number": null,
      "notes": ""
    }
  ]
}

헤드리스 반복 리뷰 규칙

/review-pass와 동일한 원칙:

1. 각 핵심 단계에서 제1 에이전트(생성) → 제2 에이전트(비평) 반복
2. 연속 2회 CLEAN → 확정
3. 비평 에이전트는 적대적 프레임 ("문제가 있다고 가정하고 찾아라")
4. 구조화된 출력 형식 강제
5. 형식 미준수 → 패스 무효, 재실행

주의사항

• Step 4 (최종 평가) 후 반드시 사용자 승인을 받아야 Step 5 진행
• 이력 DB 변경 시 항상 파일에 즉시 기록 (컨텍스트 소실 방지)
• 선행기술 조사에서 WebSearch 실패 시, 실패 사실과 검색어를 기록하고 사용자에게 수동 확인 요청
• 가출원 초안은 변리사 검토 전 최종 문서가 아님 — 초안임을 명시
• 배치 모드(PR 머지 트리거)는 추후 구현 예정. 현재는 수동 모드만 지원