Add topic research script and title workflow skills

This commit is contained in:
NINI
2026-10-08 00:48:29 +09:00
parent 5be510704a
commit 1cf5089353
4 changed files with 129 additions and 0 deletions
@@ -0,0 +1,34 @@
---
name: short-video-research
description: 승인된 이야기 각도의 출처·주장·불확실성을 조사해 02-research 결과를 작성한다. 대본에 사용할 사실·숫자·비교 조건의 검증에 사용한다.
---
# 근거와 주장 조사
## 입력과 승인 확인
- [공통 계약](../../../docs/workflow-contracts.md)의 제작 입력, 저장과 전달, 02 완료 기준, 상태와 사용자 검토, 재개와 수정 절을 읽는다.
- [제작 지침](../../../docs/short-video-guide.md)의 근거와 숫자는 작성 전에 정리한다, 참고 자료의 한계, 제작 단계에서 필요한 부분을 읽는다 절을 읽는다.
- [02 양식](../../../templates/stages/02-research.json)과 [검토 양식](../../../templates/review.md)을 사용한다. 상세 타입은 계약에서 연결한 단계 결과 스키마의 02 정의를 확인한다.
- `projects/<project_id>/project.json`의 제작 입력·현재 포인터·topic 검토를 읽고, 지정된 `stages/01-topic/r<revision>/artifact.json`과 review.md를 읽는다. `topic`, `language`는 공백만이 아닌 문자열이어야 하며 선택 ID가 후보에 존재해야 한다.
- topic 승인이 실제 사용자 응답이고 사용하려는 01 버전을 승인했는지 확인한다. 직접 호출되어도 승인 전 조사를 시작하지 않는다. 미승인은 총괄에 `awaiting_review`, 입력·파일 부재는 `awaiting_input`, 오래되거나 잘못된 참조는 문제로 보고한다.
## 조사와 판단
1. 선택한 중심 질문과 범위를 설명할 주장부터 조사한다. 공식 기록·원자료처럼 내용을 직접 뒷받침하는 출처를 우선 확인하고, 관련 없는 흥미로운 사실은 대본의 필수 내용으로 늘리지 않는다.
2. 실제 읽은 출처를 `sources`에 `{id, title, url, publisher, accessed_at}`로 기록한다. `accessed_at`은 실제 확인 날짜의 ISO 8601 `YYYY-MM-DD`다. 검색 요약·URL의 존재만으로 본문을 확인했다고 쓰지 않는다.
3. `claims`는 `{id, text, source_ids, assessment}`다. 주장마다 범위·조건·시점을 보존하고, ID와 출처 참조가 같은 결과 안에서 유효한지 확인한다. `verified`는 실제 확인한 출처 하나 이상이 주장 전체를 뒷받침할 때만 사용한다. 자료 부족·충돌·추정은 `uncertain`으로 남긴다.
4. 관찰한 사실과 해석·추정을 구별한다. 비교의 장소·시점·규모·접근·운영 조건을 확인하고, 숫자는 원수치·단위·비교 기준을 보존한다. 자료에 없는 원인·효과를 만들어 연결하지 않는다.
5. 참고 영상은 구성 참고다. 그 영상의 소재·수치·시각 구조는 별도 출처로 검증한다. 화면에 사용할 지도·구조·시대 배경도 내레이션과 같은 기준으로 확인한다.
6. `open_questions`는 미해결 질문의 문자열 배열이다. 대본의 중심 답을 막는 질문인지, 범위를 좁혀 제외할 수 있는 질문인지 review.md에서 구별한다. 출처 접근이 막히면 미확인 내용을 보존하고 필요한 자료를 보고한다.
주장 설명은 입력 언어로 명확하게 쓰고 출처 제목은 원문을 보존할 수 있다. 쉬운 말로 바꾸더라도 사실의 조건과 예외를 지우지 않는다.
## 제출과 완료
- `inputs`에 실제 사용한 01의 `{stage_id, revision}`을 기록하고 `stage_id="02-research"`로 새 버전을 작성한다.
- `projects/<project_id>/stages/02-research/r<revision>/artifact.json`과 같은 폴더의 `review.md`를 제출한다. 이전 결과는 보존하며 데이터 경로는 저장소 루트 기준이다. 검토 문서 링크는 복사한 위치에 맞춘다.
- 완료 준비를 확인할 때 출처·주장 ID의 유일성, 참조 존재, verified의 실제 근거, 미해결 질문의 영향과 대본에 쓸 중심 답의 근거를 점검한다. 비핵심 질문이 남았다는 이유만으로 확인한 근거를 버리지 않는다.
- review.md에 핵심 주장과 출처, 확인하지 못한 내용·돌아갈 단계, 적용한 구성 원칙과 적용하지 않은 이유를 남긴다. 새 필드나 별도 검토를 만들지 않는다.
- 중심 답의 필수 근거가 없으면 `awaiting_input`과 필요한 자료를 총괄에 보고한다. 유효한 근거로 03·04를 준비할 수 있어도 story 검토는 02 근거·03 대본·04 제목을 함께 확인한다. 실제 사용자 story 승인 전 05로 넘어가지 않는다.
- 담당은 자기 결과와 review.md만 제출하며 `project.json`의 상태·포인터·승인은 총괄만 변경한다. 검증 실패·수정으로 영향받는 후속 결과와 검토를 보고한다.
@@ -0,0 +1,31 @@
---
name: short-video-script
description: 선택한 이야기 각도와 검증된 조사 근거로 03-script 대본을 작성하거나 수정한다. 중심 질문의 답·블록 연결·쉬운 표현과 story 검토 준비에 사용한다.
---
# 근거를 이야기로 쓰기
## 입력 읽기
- [공통 계약](../../../docs/workflow-contracts.md)의 제작 입력, 저장과 전달, 03 완료 기준, 상태와 사용자 검토, 재개와 수정 절을 읽는다.
- [제작 지침](../../../docs/short-video-guide.md)의 먼저 질문 하나를 정한다부터 근거와 숫자는 작성 전에 정리한다까지와 대본과 제목 검토 메모를 읽는다.
- [03 양식](../../../templates/stages/03-script.json)과 [검토 양식](../../../templates/review.md)을 사용한다. 필요한 상세 구조는 계약에서 연결한 단계 결과 스키마의 03 정의를 확인한다.
- `projects/<project_id>/project.json`의 제작 입력·현재 포인터·검토를 읽고, 지정된 01-topic·02-research 버전의 artifact.json과 review.md를 읽는다. `topic`, `language`가 공백만이 아닌 문자열인지, 02가 해당 01을 사용했는지, topic 승인이 실제 사용자 응답과 같은 01 버전을 가리키는지 확인한다.
- 직접 호출해도 선행 결과와 승인을 생략하지 않는다. 입력·근거·파일 부재는 총괄에 `awaiting_input`, topic 미승인은 `awaiting_review`, stale·다른 제작물·잘못된 참조는 문제로 보고한다. 02는 story 검토 전이라도 유효한 준비 결과로 사용할 수 있다.
## 대본 작성
1. 선택한 중심 질문과 끝에서 전달할 답을 고정하고 도입이 약속한 답을 결말에서 회수한다. 소재에 맞는 설명·변화·방법·비교 구성을 선택한다. 지침의 모든 이야기 역할·반전·위기·고정 시간 배분을 강제하지 않는다.
2. `blocks`는 순서가 있는 `{id, text, claim_ids}` 배열이다. 블록마다 질문에 가까워지는 내용과 앞뒤 연결 이유가 있어야 한다. 사실처럼 쓰는 주장은 02의 `verified` 주장에 연결한다. ID는 유일하고 모든 `claim_ids`는 사용한 02 버전에 존재해야 한다.
3. `uncertain`을 확정 사실로 쓰지 않는다. 추정을 다룰 필요가 있으면 추정임을 표현하고 중심 답을 대신하지 않게 한다. 새 사실·숫자·인과 관계가 필요하면 02로 돌아가 검증된 새 버전을 요청한다. 단순 연결·질문 문장은 사실 주장이 없으면 `claim_ids=[]`가 가능하다.
4. 입력 언어로 대본을 쓴다. 한 문장에 행동·관계 하나를 담고 용어보다 기능을 먼저 설명한다. 초등학생도 직관적으로 이해할 표현을 쓰되 시청자를 어린이로 제한하지 않는다.
5. 비유가 공유하는 성질과 적용 한계를 유지한다. 필요한 숫자만 단위·비교 기준과 함께 사용하고, 쉽게 만들기 위해 실제 조건·예외를 지우지 않는다. 참고 영상의 표현·순서를 복제하거나 검증되지 않은 소재를 사실로 쓰지 않는다.
6. `full_text`는 블록 순서대로 읽은 대본과 내용이 일치해야 한다. 예상 길이를 계산할 근거가 있으면 양수 정수 밀리초를 `estimated_duration_ms`에 적고 방법을 review.md에 남긴다. 모르면 `null`이다. 예상은 실측이 아니며 180000ms는 상한이지 채울 목표가 아니다. 블록을 5초 컷으로 확정하거나 글자 수 추정을 실제 음성 시간으로 기록하지 않는다.
## 제출과 완료
- 실제 사용한 01·02의 `{stage_id, revision}`을 `inputs`에 기록한다. `stage_id="03-script"`인 새 버전을 `projects/<project_id>/stages/03-script/r<revision>/artifact.json`과 같은 폴더의 `review.md`로 제출한다. 이전 결과를 덮어쓰지 않고 경로는 저장소 루트 기준으로 기록한다.
- review.md에는 지침의 대본과 제목 검토 메모를 사용한다. 중심 질문·답, 도입의 약속과 답하는 블록, 블록별 연결, 주장·출처, 비유 한계, 덜어낸 정보, 적용한 원칙과 적용하지 않은 이유를 적는다. 04 전에는 제목 검토가 미작성임을 밝히고 새 필드·입력·검토를 만들지 않는다. 문서 링크는 실제 저장 위치에 맞춘다.
- 블록·전체 대본의 순서와 내용, 사실 주장의 verified 근거, 입력 언어·쉬운 표현·예상의 표시를 확인한다. 준비된 03으로 04 제목을 작성할 수 있다.
- 완료는 02 근거·03 대본·04 제목의 같은 유효 버전에 대한 실제 사용자 story 승인이 필요하다. 준비된 결과는 총괄에 `awaiting_review`로 보고하고 승인 전 05 TTS 분할로 넘어가지 않는다. 담당의 추천·침묵은 승인이 아니다.
- 담당은 결과 버전과 review.md만 제출하며 `project.json`의 상태·포인터·승인은 총괄만 변경한다. 내용·언어 수정의 후속 영향과 재승인 필요를 보고한다.
+31
View File
@@ -0,0 +1,31 @@
---
name: short-video-title
description: 준비된 대본의 실제 설명과 도입의 약속에 맞는 입력 언어 제목 후보를 만들고 04-title 결과를 작성한다. 제목 선택·수정과 story 검토 준비에 사용한다.
---
# 대본이 지키는 제목
## 선행 결과 확인
- [공통 계약](../../../docs/workflow-contracts.md)의 제작 입력, 저장과 전달, 04 완료 기준, 상태와 사용자 검토, 재개와 수정 절을 읽는다.
- [제작 지침](../../../docs/short-video-guide.md)의 첫 문장과 제목이 같은 내용을 약속하게 한다, 쉬운 말로 원인을 설명한다, 대본과 제목 검토 메모를 읽는다.
- [04 양식](../../../templates/stages/04-title.json)과 [검토 양식](../../../templates/review.md)을 사용한다. 필요한 상세 구조는 계약에서 연결한 단계 결과 스키마의 04 정의를 확인한다.
- `projects/<project_id>/project.json`의 제작 입력·현재 포인터·검토를 읽고 지정된 `stages/03-script/r<revision>/artifact.json`과 review.md를 읽는다. `topic`, `language`가 공백만이 아닌 문자열인지, 03의 실제 01·02 참조와 해당 01의 topic 승인이 유효한지 확인한다. 주장 범위를 확인할 때는 03이 사용한 02 결과를 읽는다.
- 직접 호출되어도 유효한 선행 결과와 사용자 승인을 우회하지 않는다. 입력·파일·근거 부재는 총괄에 `awaiting_input`, topic 미승인은 `awaiting_review`, 잘못된 참조·stale 결과는 문제로 보고한다. 준비된 03으로 story 승인 전 제목을 작성할 수 있다.
## 후보와 선택
1. 대본의 중심 질문·끝의 답·첫 문장의 약속을 읽고 제목이 약속할 내용을 정한다. 대본이 실제 설명하는 차이·원인·방법을 짧게 표현한다.
2. `candidates`는 `{id, text, rationale}` 배열이다. 후보 ID는 유일하고 텍스트는 비어 있지 않아야 한다. 후보 수·숫자 사용·반전 문형을 고정하지 않는다.
3. `rationale`에 해당 제목의 약속과 그 약속에 답하는 대본 블록 ID를 적는다. 제목은 새로운 사실·과장된 인과·검증되지 않은 수치·대본이 답하지 않는 의문을 추가하면 안 된다. 필요하면 제목을 좁히고 대본 변경이 필요하면 03으로 돌아간다.
4. 제목은 입력 언어의 자연스러운 표현으로 쓴다. 한국어 문형을 다른 언어에 강제로 직역하지 않는다. 쉬운 표현은 어린이 전용 제목을 요구하는 기준이 아니다. 비유를 쓰더라도 사실의 범위와 한계를 유지한다.
5. `selected_id`는 실제 후보 ID 또는 미선택 시 `null`이다. 추천 후보와 실제 사용자의 선택을 review.md에서 구별한다. 담당이 후보를 추천하거나 선택 값을 채워도 story 승인으로 처리하지 않는다.
## 제출과 완료
- `inputs`에는 실제 사용한 03의 `{stage_id, revision}`을 기록한다. 근거를 직접 사용했다면 사용한 02 참조도 계약에 따라 기록한다. 같은 제작물의 유효 버전만 사용한다.
- `stage_id="04-title"`인 새 버전을 `projects/<project_id>/stages/04-title/r<revision>/artifact.json`과 같은 폴더의 `review.md`로 제출한다. 기존 결과를 덮어쓰지 않고 데이터 경로는 저장소 루트 기준으로 기록한다. 검토 문서 링크는 실제 저장 위치에 맞춘다.
- review.md에 중심 질문·답, 제목과 첫 문장의 약속·답하는 블록, 후보별 이유와 선택, 과장·미확인 주장 점검, 적용한 원칙과 적용하지 않은 이유를 적는다. 새 필드·필수 입력·승인 지점을 만들지 않는다.
- 후보·선택 ID의 유효성, 입력 언어, 대본과 제목의 일치를 확인한다. 미선택이면 필요한 선택을 포함해 총괄에 `awaiting_review`로 보고한다.
- 완료에는 선택한 제목과 02 근거·03 대본·04 제목의 해당 버전에 대한 실제 사용자 story 승인이 필요하다. 응답 없음이나 담당의 추천은 승인이 아니다. 승인 전 05 TTS 분할로 넘어가지 않는다.
- 담당은 결과 버전과 review.md만 제출한다. `project.json`의 상태·포인터·승인은 총괄만 변경한다. 제목 수정 시 실제 참조에 따른 후속 결과·story/final 재검토 영향을 보고하되, 관련 없는 음성·이미지를 일괄 재생성하지 않는다.
+33
View File
@@ -0,0 +1,33 @@
---
name: short-video-topic
description: 짧은 영상의 입력 주제 안에서 이야기 각도와 중심 질문을 제안하고 01-topic 결과를 작성한다. 주제 선택·범위 수정·topic 검토 준비에 사용한다.
---
# 주제와 이야기 각도
## 시작할 때
- [공통 계약](../../../docs/workflow-contracts.md)의 제작 입력, 저장과 전달, 01 완료 기준, 상태와 사용자 검토, 재개와 수정 절을 읽는다.
- [제작 지침](../../../docs/short-video-guide.md)의 목적과 적용 범위, 먼저 질문 하나를 정한다, 제작 단계에서 필요한 부분을 읽는다 절을 읽는다.
- [01 양식](../../../templates/stages/01-topic.json)과 [검토 양식](../../../templates/review.md)을 사용한다. 구조가 필요한 경우 계약에서 연결한 단계 결과 스키마의 01 정의를 확인한다.
- `projects/<project_id>/project.json`에서 `brief.topic`, `brief.language`, 현재 01 버전과 topic 검토를 확인한다. 두 입력 모두 공백만이 아닌 문자열이어야 한다. 언어 이름·코드를 보존하며 특정 언어로 고정하지 않는다.
- 직접 호출되어도 제작 ID·필수 입력을 임의로 채우지 않는다. 없으면 총괄에 누락 내용과 `awaiting_input`을 보고한다. 재개 시 같은 제작물의 유효 버전과 실제 사용자 응답을 확인한다.
## 각도 작성
1. 입력 주제 안에서 서로 구별되는 이야기 각도를 제안한다. 후보 수를 고정하지 말고 선택에 필요한 차이를 보여준다.
2. `candidates`의 각 항목은 `{id, angle, summary}`다. `angle`에는 중심 질문 또는 이야기 방향을, `summary`에는 다룰 범위·끝에서 답하려는 내용·보여줄 수 있는 증거를 짧게 적는다. ID는 비어 있지 않고 후보 안에서 유일해야 한다.
3. 아직 조사하지 않은 답은 확인할 가설로 표현한다. 참고 영상에서 관찰한 구성의 장점과 이번 소재에 권하는 구성을 구별하고, 소재 사실은 02에서 별도 출처로 확인하도록 남긴다.
4. 의문·변화가 없는 소재에는 방법 안내·관찰·시간 순서처럼 맞는 구성을 고른다. 위기·반전·실패한 대안이나 고정 시간 배분을 만들지 않는다.
5. `selected_id`는 후보 ID 또는 미선택 시 `null`이다. 추천·선택 근거는 `selection_reason`에 적고, 추천과 실제 사용자 선택을 review.md에서 구별한다. 사용자 선택으로 기존 결과가 달라지면 새 버전으로 제출한다.
쉬운 표현은 초등학생도 직관적으로 이해할 표현 난이도다. 시청자를 어린이로 제한하지 않는다. 후보 설명도 입력 언어의 자연스러운 표현을 사용한다.
## 제출과 완료
- 선행 단계가 없으므로 `inputs`는 빈 배열이다. 실제 제작 ID와 `stage_id="01-topic"`, 새 `revision`을 [01 양식](../../../templates/stages/01-topic.json)에 채운다.
- 결과는 `projects/<project_id>/stages/01-topic/r<revision>/artifact.json`과 같은 폴더의 `review.md`로 제출한다. 이전 버전을 덮어쓰지 않는다. 경로는 저장소 루트 기준이며, 복사한 검토 양식의 문서 링크는 실제 위치에 맞춘다.
- review.md에 중심 질문·범위·후보 차이·선택 이유, 적용한 구성 원칙과 적용하지 않은 이유를 적는다. 새 필드·필수 입력·검토 지점을 추가하지 않는다.
- 후보 텍스트와 ID, 선택 ID의 존재, 선택 이유를 확인한다. 준비된 결과는 topic `awaiting_review`로 보고하고, 미선택이면 필요한 결정을 함께 적는다.
- 01 완료에는 선택된 후보와 해당 버전에 대한 실제 사용자의 topic 승인이 필요하다. 응답 없음·담당 추천을 승인으로 해석하지 않는다. 승인 전 02 자료 조사를 시작하지 않는다.
- 담당은 결과 버전과 review.md만 제출한다. `project.json`의 상태·포인터·승인은 총괄만 변경한다. 검증 실패나 변경 영향은 총괄에 문제와 재검토할 후속 결과로 보고한다.