Menu
코드베이스 기반 AI 자동 특허 발굴·평가·출원 파이프라인. "특허", "가출원", "patent", "발명 발굴" 등 특허 관련 작업 요청 시 반드시 사용. /patent-pipeline으로 호출.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Configure, observe, and recover Discord AI jobs from the ADK workspace with either Codex or Claude. Use for Discord setup, background-job status, live activity, stalled-job diagnosis, reboot recovery, idle rotation, or session history.
Codex 또는 Claude로 실행되는 Discord 백그라운드 작업의 설정·상태·실시간 활동·재부팅 복구를 ADK 워크스페이스에서 관리합니다.
세션 변경사항을 분석해 verify-* 스킬 드리프트를 탐지하고 자동 생성/업데이트합니다. issue-driven-development Sync 단계, 새 패턴/규칙 도입 후, PR 전 검증 스킬 커버리지 확인 시 반드시 사용. /manage-skills로 호출.
원요청 무결성과 세션 바인딩 하네스의 원문 해시체인, 완전 범위 추적, 서명 권한, 2회 Clean 결박, Claude Code/Codex 등록·동등성을 결정론으로 검증합니다. request-contract·session-inject 코어/어댑터·설정·스키마·review-pass를 수정한 뒤, Review/Post-test Review 및 커밋 전에 반드시 사용합니다.
등록된 모든 verify-* 스킬을 순차 실행해 통합 검증 보고서를 생성합니다. 기능 구현 후, PR 전, 코드 리뷰 시, issue-driven-development Review/Post-test Review 단계마다 반드시 사용. /verify-implementation으로 호출.
기존 제품의 경로·진입점·내비게이션·사용자 여정·운영 표면이 기능 추가 뒤에도 유지되는지 기준 버전과 보존 계약으로 검증합니다. 기존 프로젝트의 기능 추가·통합·리팩터링 후, planning/integration 리뷰와 release 전에 반드시 사용합니다.
| name | patent-pipeline |
| description | 코드베이스 기반 AI 자동 특허 발굴·평가·출원 파이프라인. "특허", "가출원", "patent", "발명 발굴" 등 특허 관련 작업 요청 시 반드시 사용. /patent-pipeline으로 호출. |
| argument-hint | [target=repo/path] [scope=full|module|feature] [step=0-8] [item=기존후보명] |
코드베이스를 AI가 분석하여 특허 가능한 발명을 발굴하고, 가치평가 → 선행기술 조사 → 최종평가 → 명세서 생성 → 발송/저장까지를 자동화하는 파이프라인 스킬입니다.
| 인수 | 필수 | 설명 |
|---|---|---|
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 | 평가 보고서 |
target 인수 확인. 없으면 사용자에게 질문docs-business/05. 특허/patent-history.json) 로드출력: 분석 대상 파일 목록 + 제외 사유 (있는 경우)
Agent 툴로 헤드리스 서브에이전트 실행:
당신은 소프트웨어 특허 발굴 전문가입니다.
## 분석 대상
{target 경로 및 파일 목록}
## 지시사항
다음 코드베이스를 분석하여 특허 가능한 발명 후보를 도출하세요.
분석 관점:
- 아키텍처 수준의 신규한 구조/조합
- 신규한 알고리즘 또는 데이터 처리 방법
- 기존 기술의 신규한 조합 방식
- 사용자 경험을 혁신하는 인터랙션 패턴
자동 제외:
- 범용 CRUD 패턴
- 표준 라이브러리/프레임워크 사용법
- 공지된 디자인 패턴의 단순 적용
각 파일을 실제로 읽으세요 (기억에 의존 금지).
## 출력 형식
### 읽은 파일
- path/to/file (줄 범위)
### 후보 목록
각 후보마다:
- **명칭**: 발명의 간략한 이름
- **핵심 구성**: 어떤 기술적 구성이 신규한지
- **해결 과제**: 어떤 기술적 문제를 해결하는지
- **관련 코드**: 핵심 파일 및 줄 범위
- **초기 평가**: 특허성 1-10 (근거 포함)
후보가 없으면:
NONE — [구체적 근거]
적대적 반복 리뷰: 서브에이전트 결과를 받은 후, 제2 서브에이전트(비평자)가 검증한다.
| 패스 | 렌즈 | 체크 항목 |
|---|---|---|
| 1 | 기술적 정확성 | 후보의 기술 설명이 코드와 일치하는지. 실제 코드를 읽어 확인. 코드에 없는 기능을 기술 → [CRITICAL] |
| 2 | 누락 발굴 | 분석 대상 코드 중 검토되지 않은 영역이 있는지. 특허성 있는 모듈 간 상호작용이 누락되지 않았는지 |
| 3 | 과잉 발굴 | 공지된 기술의 단순 적용인 후보가 포함되지 않았는지. CRUD/표준패턴이 후보에 남아있으면 → 제거 |
| 4+ | 종합 재확인 | 패스 1–3 재적용. 연속 2회 변경 없음 → 확정 |
비평자 프롬프트에 반드시 포함: "각 후보에 대해 관련 코드 파일을 직접 읽어 기술 설명과 대조하세요."
출력: 확정된 후보 목록. 이력 DB에 status: "candidate" 로 등록.
각 후보에 대해 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 가능.
통과한 후보에 대해 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 2 (가치) + Step 3 (선행기술) 결과를 종합하여 판정:
| 판정 | 조건 | 이력 DB status |
|---|---|---|
| 출원 추천 | 가치 7+ & 신규성 높음 | approved |
| 조건부 추천 | 가치 6+ & 신규성 보통 | conditional |
| 보류 | 추가 조사 필요 | on_hold |
| 폐기 | 가치 낮음 또는 신규성 낮음 | rejected_final |
사용자에게 판정 결과 + 근거 제시. 사용자 게이트 — 사용자 승인 후 Step 5 진행.
출력: 평가 보고서. docs-business/05. 특허/{slug}/evaluation.md 저장.
승인된 후보에 대해 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 + 근거에 확인 항목이 구체적으로 명시 → 클린패스수정 흐름:
출력: docs-business/05. 특허/{slug}/*-draft.md 저장. 이력 DB status → drafted.
사용자에게 옵션 제시:
이력 DB status 업데이트:
draftedsent_to_attorney변리사 피드백 수신 시 step=7로 재호출:
revision_count 증가)기각 시: status → rejected_attorney, 기각 사유 기록.
출원 완료 후 step=8로 재호출하여 상태 추적:
이력 DB status 전이: filed → oa_received → registered / abandoned
{
"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와 동일한 원칙: