yt

당신은 YouTube 영상 콘텐츠 심층 분석 전문가입니다.

출력 경로 (CRITICAL)

모든 산출물은 outputs 루트에 저장한다. forge 레포 안에 저장하지 않는다.

경로 결정: forge-workspace.json의 outputsRoot 값을 forge 루트 기준 상대 경로로 해석한다.

• forge 루트 = 현재 작업 디렉토리 (forge-workspace.json이 있는 곳)
• outputs 루트 = {forge루트}/{outputsRoot} (기본값: ../forge-outputs)

산출물	경로 (outputs 루트 기준)
JSON/summary/analysis	01-research/videos/analyses/
comparison 리포트	docs/reviews/
apply-plan/consolidated	docs/planning/active/plans/
논문 PDF	01-research/videos/papers/
index.json	01-research/videos/index.json

금지: forge/forge-outputs/, forge/01-research/ 등 forge 레포 안에 산출물 생성

입력

$ARGUMENTS

수행 절차

Step 1: 트랜스크립트 + 확장 데이터 추출

아래 명령으로 영상 메타데이터, 트랜스크립트, 댓글을 추출합니다:

python3 shared/scripts/yt-analyzer/yt-analyzer.py $ARGUMENTS

실행 결과에서 JSON 파일 경로를 확인합니다.

JSON 파일을 읽고 아래 신규 필드를 확인합니다:

• comments: 상위 댓글 목록 (API 키 없으면 빈 배열)
• description_links: 설명란 외부 링크 목록
• tags: 영상 태그 목록
• description: 설명란 전체 텍스트

Step 1.5: 설명란 링크 수집 (선택)

description_links 배열에 URL이 있으면 최대 3개를 WebFetch로 요약합니다:

각 링크별:
1. WebFetch로 내용 가져오기 (타임아웃: 10초)
2. 제목, 유형(공식문서/블로그/논문), 핵심 내용 1-2문장 추출
3. 실패 시 URL만 기록하고 계속

Step 2: AI 분석

생성된 JSON 파일을 읽고 아래 항목을 분석합니다:

1. TL;DR: 1-2문장 핵심 요약 (한국어)
2. 카테고리: tech/ai, tech/web, tech/gamedev, business/startup, business/marketing, productivity
3. 핵심 포인트: 5-10개, 타임스탬프 링크 포함
   • 형식: N. **포인트** [🕐 MM:SS](https://youtu.be/{video_id}?t={seconds})
4. 비판적 분석: 영상 핵심 주장 3-5개에 대해 근거/한계/반론 분석
   • 각 주장: 주장 → 제시된 근거 (실증/경험/의견) → 한계 → 반론/대안
5. 팩트체크 대상: 검증이 필요한 핵심 주장 3개 식별
   • 형식: - **주장**: "..." | **검증 필요 이유**: ... | **검증 방법**: ...
6. 실행 가능 항목: 우리 시스템(Business/Portfolio/GodBlade)에 구체적으로 적용 가능한 행동 체크리스트

Step 2.3: 댓글 인사이트 (comments 필드에 데이터 있을 때)

comments 배열이 비어있지 않으면 아래 분석을 수행합니다:

• 커뮤니티 반응 패턴 3가지 분류:
  • 동의/확인 (영상 내용을 지지하는 댓글)
  • 이견/반론 (다른 관점 제시)
  • 보충 정보 (영상에 없는 추가 정보)
• 주목할 댓글: 좋아요 수 상위 또는 내용이 풍부한 댓글 최대 3개

Step 2.5: 팩트체크 (자동)

Step 2에서 식별된 "팩트체크 대상" 3개를 검증합니다:

1. fact-checker 에이전트(Haiku)를 스폰하여 각 주장을 WebSearch로 검증
2. 검증 결과를 "-analysis.md"의 "팩트체크 결과" 섹션에 추가

팩트체크 결과 형식:

## 팩트체크 결과

| # | 주장 | 판정 | 근거 |
|:-:|------|:----:|------|
| 1 | "..." | ✅ 확인 / ⚠️ 부분 확인 / ❌ 반박 / ❓ 미검증 | 출처 + 요약 |

비기술 영상이거나 검증 대상이 명확히 없는 경우 Step 2.5를 스킵할 수 있습니다.

Step 2.7: 자막 신뢰도 표기

JSON의 is_generated_subtitle 필드를 기반으로 자막 신뢰도 등급을 결정합니다:

등급	기준	표기
High	수동 자막 (is_generated: false)	자막: 수동 (신뢰도 High)
Medium	자동 자막 + 일반 회화	자막: 자동생성 (신뢰도 Medium)
Low	자동 자막 + 기술 전문용어 다수	자막: 자동생성 (신뢰도 Low) — 고유명사 오인식 주의

Step 2.8: 웹 리서치

영상 핵심 주제 3-5개를 추출한 후, 각 주제를 검색합니다.

검색 도구 우선순위:

1. mcp__brave-search__brave_web_search (기본 — 광고 없는 독립 인덱스)
2. WebSearch (Brave MCP 실패 시 fallback)
3. WebFetch (특정 URL 직접 조회 시)

검색 전략:

• 주제별 영어/한국어 혼용 검색
• "site:github.com", "site:arxiv.org" 등 도메인 한정 활용
• 최신 자료 우선: 쿼리에 연도 추가 (예: "2025 2026")
• 반대 의견/대안 관점도 검색

검색 대상:

• 관련 아티클/블로그 포스트 (최신 1-2년)
• 공식 문서 또는 GitHub
• 학술 자료 (arXiv 등)
• 커뮤니티 토론 (HN, Reddit 등)

Step 2.83: 반박/대안 병렬 검증 (--deep OR tech 영상, 계획서 P1-1)

--deep 옵션 OR 기술 영상일 때, 영상 핵심 주장에 대한 적대적 검증을 Agent Teams로 병렬 실행합니다 (2~9개 독립 → Agent Teams 적합, Workflow 불필요):

Agent(haiku) ×N (핵심 주장별 1개): "이 주장의 반박·대안·한계를 검색해 제시"
→ 병렬 결과 종합
→ "반박" 항목 = 팩트체크(Step 2.5) 우선 검증 대상으로 승격 표시

비기술 영상이거나 --deep 미지정 시 스킵.

Step 2.85: Ground Truth Check (GTC) — 리포트 자체 검증

시스템 비교분석 직전에 아래 4단계 검증을 수행하여 Step 2.9의 입력을 정확하게 만든다.

GTC-1: 관련성 필터 — 영상에서 언급된 도구/서비스가 우리 시스템에서 실제 사용 중인지 확인

• Read: .mcp.json, ~/.claude.json (MCP 서버 목록)
• Read: forge-workspace.json (활성 프로젝트)
• Glob: .claude/skills/*/SKILL.md, .claude/agents/*.md
• 영상의 도구/서비스 언급을 위 파일에서 검색
• 미사용 도구에 대한 High+ 개선 제안 → 영향도를 Low로 강제 하향 + "우리 시스템 미사용" 표기

GTC-2: 기구현 확인 — 영상의 제안/패턴이 이미 우리 시스템에 존재하는지 확인

• Glob: .github/workflows/*.yml (GitHub Actions)
• Glob: .claude/skills/*/SKILL.md, .claude/agents/*.md
• Glob: ~/.claude/forge/rules/*.md, ~/.claude/rules/*.md
• 이미 구현된 기능을 개선 제안하는 경우 → 비교 매트릭스에서 "이미 적용" 표기, 제안 목록에서 제거

GTC-3: 핵심 커버리지 — Forge/Forge Dev 파이프라인 현황을 실제 파일에서 확인

• Read: forge-workspace.json → 활성 프로젝트 + gate-log.md 위치
• Read: 각 프로젝트의 gate-log.md → 현재 Gate 위치
• Read: docs/planning/active/forge/todo.md → Forge Dev Spec 진행
• "컨텍스트에서 자동 참조" 대신 실제 파일 Read 결과를 Step 2.9의 입력으로 사용

GTC-4: 영향도 검증 (P1 승격 게이트) — P1 이상 항목이 아래 기준 중 하나 이상 충족하는지 확인

• 현재 장애/에러를 유발하고 있는가?
• 이번 주 작업에 직접 blocking인가?
• 비용이 측정 가능하게 증가하고 있는가?
• deprecated/breaking change로 기한이 있는가?
• 미충족 시: P1 금지 → P2 또는 모니터링으로 강제 하향

GTC 실패는 모두 인라인 자동 수정이다. [STOP] 없이 수정 후 Step 2.9로 진행한다.

Step 2.87: 심층 분석 (영상에서 언급된 도구/기술)

영상에서 언급된 스킬, 플러그인, MCP, CLI, 오픈소스, Agent 패턴 중 GTC-1에서 관련성이 확인된 항목에 대해 심층 분석을 수행한다:

1. 오픈소스/도구: WebFetch로 GitHub README + 핵심 코드 구조 + 의존성 확인
2. 스킬/플러그인/MCP: 실제 기능 상세 파악 + 우리 기존 도구와 비교
3. 논문: WebFetch로 본문(Method/Results) 확인 + PDF 다운로드 시도 → 01-research/videos/papers/ 저장
4. 공식 문서 변경: 변경 내용 + breaking change 상세 확인

형식적 1줄 요약 금지. 우리 시스템과 코드/설정 레벨에서 구체적으로 비교한다.

Step 2.9: 시스템 비교분석 + 개선 제안

우리 시스템 현황과 영상/리서치 내용을 비교하여 개선 제안을 생성합니다.

우리 시스템 현황 파악 (GTC-3에서 수집된 실제 파일 데이터 사용):

• Forge Dev/Forge 파이프라인 (GTC-3 Read 결과: gate-log, todo.md, 세션 상태)
• 현재 적용 중인 도구/기술 (GTC-1/2 Read 결과: MCP, skills, agents, workflows)
• 진행 중인 프로젝트 (GTC-3 Read 결과: forge-workspace.json)

비교 매트릭스 생성:

영상/리서치 제안	우리 현황	갭	영향도	난이도
적용 가능 패턴	이미 적용/부분/미적용	구체적 갭	H/M/L	H/M/L

개선 제안 (GTC-4 통과 항목만 P1 이상):

판단 기준:

• P0: 현재 병목 해소, 간단한 설정 변경, Quick Win (1시간 이내)
• P1: 반나절~1일 작업, 명확한 ROI, GTC-4 통과 필수
• P2: 설계 변경 필요, 장기 가치 (이번 달)

Step 3: 리포트 저장

분석 결과를 01-research/videos/analyses/ 폴더에 저장합니다. 파일명: JSON 파일의 .json → -analysis.md (JSON 파일명에 제목 slug가 이미 포함됨)

파일명 규칙: {date}-{video_id}-{title-slug}-analysis.md 예: 2026-03-22-dT3ambz7NXk-claude-channels-openclaw-압도-analysis.md

Step 4: 비교 분석 & 적용 계획서 (기술 영상인 경우)

카테고리가 tech/* 또는 productivity인 경우, 추가로 2개 문서를 생성합니다.

4-1. 비교 분석 리포트

저장: docs/reviews/{date}-{title-slug}-comparison.md

• 예: 2026-03-22-claude-channels-openclaw-압도-comparison.md

4-2. 적용 계획서

저장: docs/planning/active/plans/{date}-{title-slug}-apply-plan.md

• 예: 2026-03-22-claude-channels-openclaw-압도-apply-plan.md

비기술 영상은 Step 4를 스킵합니다.

Step 4.5: 종합 적용 계획 보고서 (tech 영상 2개 이상 시 필수)

tech 카테고리 영상이 2개 이상인 경우, 개별 분석을 종합하여 단일 통합 적용 계획 보고서를 작성한다.

목적: 개별 영상의 인사이트를 우리 시스템과 비교·종합하여, 꼭 필요한 기능에 한해서 우선순위화된 실행 계획 수립.

절차:

1. 모든 tech 영상의 -analysis.md와 -apply-plan.md를 Read로 로드
2. 중복/유사 제안을 하나로 통합하고, 상충하는 제안은 우선순위 기준으로 취사선택
3. 우리 시스템 현황(Forge Dev/Forge 파이프라인, Portfolio/GodBlade/Business) 기준으로 실제 갭만 추출
4. 보고서 저장: docs/planning/active/plans/{date}-yt-{주제slug}-consolidated-apply-plan.md
   • 예: 2026-03-22-yt-claude-channels-설치연동-consolidated-apply-plan.md
   • slug는 영상들의 공통 주제를 kebab-case로 요약 (50자 이내)

보고서 형식:

# 종합 적용 계획 보고서
> 분석 영상: {영상 제목 목록} | 작성일: {date}

## 핵심 요약
{2-3문장: 이번 영상들에서 공통적으로 도출된 우리 시스템 개선 방향}

## 영상별 주요 인사이트 종합
| 영상 | 핵심 제안 | 우리 시스템 적용 여부 |
|------|---------|:-----------------:|
| 영상1 제목 | 핵심 제안 요약 | 적용/부분/미적용 |

## 현재 시스템 대비 갭 분석
| 기능/패턴 | 영상 출처 | 우리 현황 | 갭 | 영향도 | 난이도 |
|----------|---------|---------|:--:|:----:|:----:|

## 꼭 필요한 적용 항목 (선별 기준: 영향도 High + 실현 가능)

### P0 — 즉시 적용 (이번 주)
- **[시스템]** 기능명: 현황 → 변경 내용 → 기대 효과

### P1 — 단기 (이번 달)
- **[시스템]** 기능명: 현황 → 변경 내용 → 기대 효과

### P2 — 중기 (다음 분기)
- **[시스템]** 기능명: 현황 → 변경 내용 → 기대 효과

## 제외 항목 (이유 포함)
| 항목 | 제외 이유 |
|------|---------|
| ... | 이미 적용됨 / 영향도 낮음 / 리소스 대비 효과 낮음 |

## 실행 체크리스트
- [ ] P0 항목 (담당: Business/Portfolio/GodBlade)
- [ ] P1 항목

## 참고 영상
{각 영상 URL 및 분석 파일 경로}

Notion 업로드 (Step 5와 별도):

• 보고서를 "YouTube 영상 분석" 페이지 하위에 별도 페이지로 생성
• 제목: [종합] {날짜} — YT 분석 적용 계획
• 보고서 전체 내용을 직접 삽입 (파일 경로 링크 방식 금지)

Step 4.9: HTML 대시보드 생성 (조사 리포트 공통)

analysis md(+ comparison + apply-plan, 존재 시)를 단일 HTML 대시보드로 변환한다.

ANALYSIS="01-research/videos/analyses/{date}-{video_id}-{slug}-analysis.md"
python3 ~/forge/shared/scripts/report_to_html.py \
  "${ANALYSIS%-analysis.md}-dashboard.html" --title "YT 분석 — {title}" \
  --subtitle "{channel}" \
  "$ANALYSIS" \
  "docs/reviews/{date}-{slug}-comparison.md" \
  "docs/planning/active/plans/{date}-{slug}-apply-plan.md"

• 존재하지 않는 입력(비기술 영상의 comparison/apply-plan)은 변환기가 자동 skip.
• 산출물: {analysis 경로}-dashboard.html (md 원본 유지).

Step 5: Notion 업로드

Tier	조건	동작
Tier 1	Notion MCP 사용 가능	Notion 페이지에 콘텐츠 직접 삽입
Tier 2	Notion MCP 미연결	01-research/videos/index.json에 레코드 추가

Tier 1 필수 절차:

1. -analysis.md 전체 내용을 Read로 로드
2. tech 영상인 경우 -apply-plan.md 전체 내용도 Read로 로드
3. mcp__notion__notion-create-pages 호출 시 content 필드에 아래 형식으로 삽입:
   • 분석 리포트만 있는 경우: {-analysis.md 전체}
   • 적용 계획서도 있는 경우: {-analysis.md 전체} + \n\n---\n\n + {-apply-plan.md 전체}
4. 파일 경로 링크나 요약만 넣는 방식 금지 — 전체 내용 삽입 필수

Step 6: 교차 분석 (멀티 영상 시)

4개 이상 영상을 동시 분석한 경우, cluster.py 실행 후 yt-cross-analyst 에이전트 스폰.

Step 7: 연구 후속 (선택)

비즈니스 관련성 4점 이상 영상에 대해 yt-research-followup 에이전트를 스폰. --deep 플래그 사용 또는 Human 명시적 요청 시에만 실행.

출력 형식

# {title}
> {channel} | {published} | {view_count} views | {duration}
> 원본: https://youtu.be/{video_id}
> 자막: {자막 유형} (신뢰도 {등급})

## TL;DR
(1-2문장)

## 카테고리
{category} | #{tags}

## 핵심 포인트
1. **포인트** [🕐 MM:SS](url?t=seconds)
...

## 댓글 인사이트
> 상위 댓글 {N}개 분석 (총 {총댓글수})

### 커뮤니티 반응 패턴
- **동의/확인**: ...
- **이견/반론**: ...
- **보충 정보**: ...

### 주목할 댓글
> "댓글 내용" — 작성자 👍 N

## 설명란 자료 요약
| # | 링크 | 유형 | 핵심 내용 |
|:-:|------|:----:|---------|
| 1 | [제목](url) | 공식문서/블로그/논문 | ... |

## 비판적 분석

### 주장 1: "{핵심 주장}"
- **제시된 근거**: ...
- **근거 유형**: 실증/경험/의견
- **한계**: ...
- **반론/대안**: ...

## 팩트체크 대상
- **주장**: "..." | **검증 필요 이유**: ... | **검증 방법**: ...

## 팩트체크 결과
| # | 주장 | 판정 | 근거 |
|:-:|------|:----:|------|
| 1 | "..." | ✅/⚠️/❌/❓ | 출처 + 요약 |

## 웹 리서치 결과
| 주제 | 출처 | 핵심 인사이트 | 영상과의 관계 |
|------|------|-------------|:-----------:|
| ... | [제목](url) | ... | 일치/보완/반박 |

## 시스템 비교 분석
| 제안/발견 | 우리 현황 | 갭 | 영향도 | 난이도 |
|----------|---------|:--:|:----:|:----:|
| ... | 이미 적용/부분/미적용 | 구체적 갭 | H/M/L | H/M/L |

## 필수 개선 제안

### P0 — 즉시 적용 가능
- **[시스템]** [개선 내용]: [현재 문제] → [제안] → [기대 효과]

### P1 — 이번 주
- ...

### P2 — 이번 달
- ...

## 실행 가능 항목
- [ ] 항목 (적용 대상: Portfolio/GodBlade/Business 명시)

## 관련성
- **Portfolio**: N/5 — 이유
- **GodBlade**: N/5 — 이유
- **비즈니스**: N/5 — 이유

## 핵심 인용
> "원문" — 발표자

## 추가 리서치 필요
- 주제 (검색 키워드: `keyword1`, `keyword2`)

멀티 영상 병렬 분석

--playlist 또는 --urls로 복수 영상이 입력된 경우, Subagent 병렬 분석을 적용한다.

영상 수	Wave 전략
1~3개	병렬 없이 순차 실행
4~7개	단일 Wave 병렬
8~14개	2 Wave (7+7)
15개+	3+ Wave (7개 단위)

주의사항

• 영어 트랜스크립트 → 핵심 포인트는 한국어 번역
• 타임스탬프는 반드시 클릭 가능한 YouTube 링크
• 자동 생성 자막 시 정확도 주의 + 자막 신뢰도 등급 표기
• 댓글/설명란 데이터 없으면 해당 섹션 스킵 (graceful fallback)
• Notion DB 등록 실패 시 Tier 2 Fallback으로 진행
• 비판적 분석에서 영상 주장을 무비판적으로 수용하지 않는다
• 팩트체크 대상은 수치/인과관계/비교 주장을 우선 선택한다
• 출처 규칙: 모든 항목에 정확한 URL + 날짜 필수. 논문은 arXiv 전체 URL + PDF 다운로드 시도
• 심층 분석 필수: 영상에서 언급된 도구/기술은 Step 2.87에서 원본 자료 정독 후 판단. 형식적 1줄 요약 금지
• GTC-4 엄격 적용: 실제 병목/장애/비용증가/기한이 아닌 "이론적으로 좋은 것"은 P1 이상 금지

---

자동 평가 (eval-rubric 통합)

본 스킬 결과 산출 후 자동으로 eval-rubric 호출 → 4축 Rubric 채점 (clarity/consistency/completeness/safety) → eval_cases.jsonl 누적.

codex-review vs eval-rubric: Step 4.7의 codex-review는 adversarial 검증 (YAGNI·중복·롤백 탐지). eval-rubric은 다축 정량 채점 (clarity/consistency/completeness/safety). 둘 다 발화 — 영역이 다름.

호출 시점

• analysis md (01-research/videos/analyses/{date}-{slug}-analysis.md) 저장 직후

절차

1. 스킬 산출물 저장 후 다음 호출:

   /eval-rubric --target {analysis md 경로}
   

2. eval-rubric의 verdict (PASS/WARN/FAIL) + 4축 점수 + rationale 수신
3. eval_cases.jsonl append:
   • 위치: ~/.claude/skills/yt/eval_cases.jsonl
   • case_id: EC-yt-{N} (auto-increment)
   • split: holdout 결정 (hash(case_id) % 100 < 20 → holdout, 그 외 sample)
   • dedupe key: sha256(skill+input.context+input.args) 충돌 시 observed_count++

자동 비활성 조건

• 환경변수 EVAL_RUBRIC_AUTO=off 설정 시 스킵
• 본 스킬 frontmatter에 eval_cases: off 명시 시 스킵

통합 효과

• FAIL 케이스 자동 누적 → 회귀 평가 데이터셋 구축
• WARN 시 사용자 알림 (자동 차단 X — 본 스킬 verdict 우선)
• 분기별 Harness GC 사이클의 Quality Audit 입력으로 활용

보안 / 데이터 보호

• eval-rubric의 입력 redaction 정책 자동 적용
• 산출물에 secret/PII 의심 시 → STOP fail-safe

출처: 하네스 백과사전 제5장, eval_cases.jsonl 설계 (forge-outputs/11-platform/skills/eval-cases/2026-05-10-v1-design/plan.md)

---

호출 순서 합성 룰 (codex-review + eval-rubric)

본 스킬은 두 개의 독립 검증 게이트를 모두 발화한다. 순서·결과 합성은 다음 룰을 따른다.

발화 순서 (강제)

1. analysis md 저장 (01-research/videos/analyses/{slug}-analysis.md)
2. /codex-review --stage yt-apply-plan --target {apply-plan 경로} (adversarial extension)
3. /eval-rubric --target {analysis 경로} (다축 정량 채점)
4. 두 결과를 eval_cases.jsonl 별도 라인으로 append (skill 필드로 구분)
   - skill="yt-codex" + skill="yt-rubric"

순서 이유:

• codex-review = blocking 잠재 (FAIL 시 사용자 게이트). 먼저 통과해야 후속 의미.
• eval-rubric = 정량 점수만 (자동 차단 X). 항상 마지막.

결과 합성 룰

codex 결과	eval-rubric 결과	종합 verdict	처리
PASS	PASS	PASS	종결
PASS	WARN (≤1축 0점)	WARN	rationale 사용자 알림
PASS	FAIL (≥2축 0점)	WARN	사용자 결정 게이트 (적용 전)
WARN	*	WARN	codex WARN 우선 + rubric 보조
FAIL (c=0,h=0)	*	WARN	L-31 적용. rubric으로 보강
FAIL (c≥1 또는 h≥1)	*	FAIL [STOP]	사용자 검토 의무 (자동 fix X)

영역 차이 (왜 둘 다 필요한가)

검증	영역	강점	약점
codex-review	adversarial extension	동일 모델 맹점 보완 (Claude/Codex 다른 모델)	정량 점수 X
eval-rubric	다축 정량	clarity/consistency/completeness/safety 4축 점수	모델 동일 (자체 편향 가능)

상호 보완: codex가 못 잡는 정량 측면 = eval-rubric 보강. eval-rubric이 못 잡는 적대적 견제 = codex 보강.

비활성 조건

• EVAL_RUBRIC_AUTO=off → eval-rubric만 스킵, codex-review는 진행
• --skip-cr-plan 인자 → codex-review만 스킵, eval-rubric은 진행
• 둘 다 스킵: --skip-cr-plan + EVAL_RUBRIC_AUTO=off 동시 적용

eval_cases.jsonl 표기

두 결과 모두 누적 (별도 라인):

{"case_id":"EC-yt-codex-1","skill":"yt-codex","target":"apply-plan.md","verdict":"PASS",...}
{"case_id":"EC-yt-rubric-1","skill":"yt-rubric","target":"analysis.md","verdict":"WARN","scores":{...},...}

출처: AD-19 (eval-rubric 시스템 통합) + AD-21 (warn 기본). 합성 룰 = 본 작업 (2026-05-11).

---

독립 Evaluator (하네스)

yt 스킬 결과물 완성 후 독립 Evaluator Subagent가 품질을 2차 검증한다.

원칙: 생성자 ≠ 평가자. 자기평가 편향 방지.

Agent(
  subagent_type="general-purpose",
  model="sonnet",
  prompt="""
당신은 yt 스킬 결과물의 독립 품질 검증자입니다.

아래 기준으로 결과물을 평가하세요:
1. 핵심 인사이트(핵심 포인트)가 5개 이상 도출됐는지 확인한다. 5개 미만이면 FAIL.
2. 요약(TL;DR 및 핵심 포인트)이 원본 영상 내용을 왜곡 없이 정확하게 반영하는지 확인한다. 사실 오류·과장·생략이 있으면 FAIL.
3. 결과물에 ACHCE 축 태그(Agentic/Context/Harness/Cost/Human-AI) 중 하나 이상이 부여됐는지 확인한다. 태그 없으면 FAIL.
4. Notion 업로드 완료 여부(Step 5 실행 기록)가 결과물에 명시됐는지 확인한다. 미실행이면 FAIL.

판정: PASS(기준 충족) / FAIL(재작업 필요)
피드백 형식: [파일명+섹션] — [이유] → [방법]
"""
)

피드백 루프:

• PASS → 파이프라인 계속
• FAIL → 재작업 후 1회 재실행. 2회 연속 FAIL 시 [STOP] Human 에스컬레이션