Menú
코드베이스 기반 AI 자동 특허 발굴·평가·출원 파이프라인. "특허", "가출원", "patent", "발명 발굴" 등 특허 관련 작업 요청 시 반드시 사용. /patent-pipeline으로 호출.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional 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와 동일한 원칙: