book-writing-orchestrator

Name: book-writing-orchestrator
Author: tobyilee

77stars16forks

How to install book-writing-orchestrator?

tobyilee/book-writer/book-writing-orchestrator

$npx -y skills add tobyilee/book-writer --skill book-writing-orchestrator

Installs into the current project.

Summary

Orchestrate a full book-writing workflow from topic to finished EPUB with cover image. Use when the user asks to "write a book", "draft a book", "author a book", "책 쓰기", "책 저술해줘", "책 만들어줘", "전자책 만들어줘", "EPUB 생성", provides a topic/audience/outline and asks to turn it into a book,

Files · 1

View on GitHub

SKILL.md

1	# Book Writing Orchestrator
2
3	주제·주요 내용·대상 독자를 받아 Toby 스타일의 완성된 EPUB을 산출하는 전 과정을 조율한다. 각 Phase에서 전문 에이전트를 호출하고, 중간 산출물을 `{slug}/` 하위에 축적한 뒤 최종 EPUB을 프로젝트 루트에 만든다.
4
5	## 실행 모드
6
7	\| Phase \| 모드 \| 왜 이렇게 \|
8	\|-------\|------\|----------\|
9	\| 1. 리서치 \| 서브 에이전트(팬아웃) \| 소스별 독립 수집 → 병렬화가 이득 \|
10	\| 2. 저술 계획 \| 단일 서브 \| 통합적 사고가 필요, 분할 이점 없음 \|
11	\| 3. 계획 리뷰 \| 에이전트 팀(생성-검증 왕복) \| 저자와 리뷰어의 토론이 품질을 높임 \|
12	\| 4. 챕터 저술 \| 에이전트 팀 \| 챕터 저술가 ↔ 스타일 가디언 ↔ 편집자 실시간 조율 \|
13	\| 4.5. 통권 수락 검수 \| 단일 서브(신선 컨텍스트) \| editor와 분리된 새 눈이 통권을 게이트 — 자기 승인 방지 \|
14	\| 5. 표지 + EPUB \| 서브(부분 병렬) \| cover-designer를 background로 띄우고 epub-builder의 cover-독립 준비를 병행, `cover.png` 소비 지점에서 join \|
15
16	## Phase 0: 컨텍스트 확인
17
18	워크플로우를 시작하기 전에 기존 산출물 존재 여부를 확인한다.
19
20	1. 사용자 입력에서 주제, 주요 내용, 대상 독자를 추출한다. 셋 중 하나라도 불명확하면 사용자에게 짧게 질문한다 (AskUserQuestion 사용). 추가로 `저자: {이름}` 형태의 저자 지정이 있는지 확인한다 — 없으면 기본값 `Toby-AI`를 사용하고, 있으면 해당 값을 매니페스트·표지 메타까지 전파한다. `라이선스: {값}` 형태가 있는지도 확인한다 — 없으면 하네스 기본값 `CC BY-NC-SA 4.0`을 매니페스트에 그대로 두고(또는 `license` 필드를 비워두면 빌드 스크립트가 채움), 있으면 해당 값을 매니페스트의 `license` 필드로 전달한다.
21	2. 장르 감지 + 확인. `profiles/_registry.md`의 자동 감지 규칙으로 주제·주요 내용·대상 독자에서 장르를 추정한다 (`tech-book` / `narrative` / `practical` / `essay`, 기본 `tech-book`). 사용자가 `장르: {값}`을 명시했으면 그대로 채택. 아니면 `AskUserQuestion`으로 추정값을 첫 옵션·추천으로 제시해 확인받는다 (단, 신호가 강하고 명백하면 추정값을 알리고 진행해도 된다). 확정된 `genre`는 이후 모든 Phase로 전파되고, Phase 4의 editor가 `book_manifest.json`의 `genre` 필드에 기록한다. 활성 프로필 경로는 `profiles/{genre}/`.
22	3. 위임 다이얼 (운영자 학습 루프). 사용자 입력에서 `모드: 학습` 명시 또는 "이 주제를 공부하려고/잘 몰라서" 류의 명확한 학습 신호를 확인한다. 있으면 `delegation_mode: learning`, 없으면 기본 `production` — 신호가 없으면 묻지 않는다. 어차피 AskUserQuestion을 쓸 일이 있으면 그 질문에 다이얼 확인을 편승시켜도 된다 (추가 왕복 금지). 확정 값은 Phase 4의 editor에게 전달해 `book_manifest.json`의 `delegation_mode`에 기록하고 (재실행 결정성 — `genre`와 같은 취급), Phase 3·4·완료 보고의 학습 터치포인트가 이 값을 따른다. 정전 스펙은 `docs/learning-loop.md`.
23	4. 책 제목 후보(슬러그 포함)를 만든다. 예: `AI 시대의 개발자 철학` → 슬러그 `ai-developer-philosophy`.
24	5. `{slug}/`의 존재 여부를 확인한다.
25	- 미존재 → 초기 실행, Phase 1부터 순차 실행
26	- 존재 + 사용자가 부분 수정 요청 (예: "챕터 3만 다시", "계획만 수정") → 부분 재실행, 해당 Phase만 재호출. 이때 장르는 기존 `book_manifest.json`의 `genre`를 재사용한다 (사용자가 장르 변경을 명시하지 않는 한)
27	- 존재 + 새 입력 제공 → 기존 `{slug}/`를 `{slug}_prev-{timestamp}/`로 이동 후 새 실행
28
29	## Phase 1: 리서치 (팬아웃)
30
31	실행 모드: 서브 에이전트 병렬 호출
32
33	`research-lead` 에이전트를 호출하고, 내부에서 `web-researcher`, `paper-researcher`, `community-researcher`를 `run_in_background: true`로 병렬 스폰한 뒤 결과를 종합하도록 지시한다.
34
35	입력: `genre` (Phase 0에서 확정 — 리서처의 장르별 소스 세트 선택 기준), 주제, 주요 내용, 대상 독자, 슬러그
36	출력:
37	- `{slug}/01_reference.md` — 리서치 종합 문서 (섹션: 개념·정의, 주요 관점, 사례, 논쟁점, 참고문헌)
38	- `{slug}/research/web.md`·`papers.md`·`community.md` — 소스별 원본 리서치. `01_reference.md` 합성 후에도 보존한다 (Phase 4 `fact-checker`의 1차 대조 근거)
39
40	신선도 메타: tech-book·최신 기술 주제에서는 리서처가 각 출처의 발행일과 검색 시점("검색: {날짜} 기준")을 기록한다. 버전·릴리스 정보는 "{버전}/{연도} 기준"으로 못 박는다. 이 메타가 Phase 4 `fact-checker`의 대조 기준이 된다.
41
42	모델 라우팅: 판단·합성이 필요한 Phase(리서치·계획·리뷰·챕터 저술·수락 검수)는 `model: "opus"`를 명시하고, 기계적 Phase(`epub-builder`·`cover-designer`)는 각 에이전트 frontmatter의 `sonnet`을 따른다.
43
44	## Phase 2: 저술 계획
45
46	실행 모드: 단일 서브 에이전트
47
48	`book-planner` 에이전트를 호출한다.
49
50	입력: `genre`, 주제, 주요 내용, 대상 독자, `{slug}/01_reference.md`, 활성 `profiles/{genre}/scaffolds.md`
51	출력: `{slug}/02_plan.md` — 책 구조 설계 문서
52	- 책 제목 후보 3개
53	- 책 특성 (장르, 분량, 난이도, 독자 여정)
54	- 챕터 목록 (번호, 제목, 핵심 질문, 주요 내용, 예상 분량)
55	- 챕터 간 흐름(내러티브 아크)
56
57	## Phase 3: 계획 리뷰 (팀)
58
59	실행 모드: 에이전트 팀 (생성-검증 왕복)
60
61	`TeamCreate`로 `book-planner`와 `plan-reviewer`를 팀으로 구성한다. `plan-reviewer`가 계획을 비판적으로 읽고 `SendMessage`로 `book-planner`에게 피드백을 보낸다. `book-planner`는 피드백을 반영해 계획을 갱신한다.
62
63	수렴 기준: 왕복은 모든 Critical 항목이 planner가 반영했거나 `03_review_log.md`에 사유와 함께 명시적으로 유보(deferred)될 때, 또는 최대 2회 후 종료한다. 종료 시점에 미해소 Critical이 남아 있으면 위험으로 `03_review_log.md`에 로그한다. 그 뒤 팀을 해체한다.
64
65	산출물: `{slug}/02_plan.md` (갱신됨) + `{slug}/03_review_log.md` (리뷰 기록)
66
67	팀 해체 후 사용자에게 최종 계획을 제시하고 승인을 받는다. 사용자 피드백이 있으면 `book-planner`를 한 번 더 호출해 반영한다.
68
69	선판단 후공개 (운영자 학습 루프 1겹): 계획을 보여주기 직전, 운영자에게 "이 주제·독자라면 어떤 챕터 흐름을 기대하시나요? (한두 줄, 건너뛰어도 됩니다)"를 초대한다 — `learning` 모드에서는 기본 단계로, `production` 모드에서는 승인 요청 메시지에 한 줄로 편승한다. 스케치가 오면 계획 제시 때 운영자 예상과 갈라진 지점을 짚어준다 (예측 오류가 학습 신호다). 응답이 없거나 자율 실행 중이면 조용히 생략한다 — 비블로킹. 계획 제시에는 `02_plan.md`의 "설계 근거" 섹션(채택 이유 + 기각 대안)이 포함되어야 한다.
70
71	## Phase 4: 챕터 저술 (에이전트 팀)
72
73	실행 모드: 에이전트 팀 (핵심 Phase)
74
75	가장 중요한 Phase다. 팀 구성:
76
77	- `chapter-wr

People who liked this also viewed

6 picks

Type

book-writing-orchestrator

77stars16forks

View on GitHub

How to install book-writing-orchestrator?

tobyilee/book-writer/book-writing-orchestrator

$npx -y skills add tobyilee/book-writer --skill book-writing-orchestrator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Book Writing Orchestrator
2
3	주제·주요 내용·대상 독자를 받아 Toby 스타일의 완성된 EPUB을 산출하는 전 과정을 조율한다. 각 Phase에서 전문 에이전트를 호출하고, 중간 산출물을 `{slug}/` 하위에 축적한 뒤 최종 EPUB을 프로젝트 루트에 만든다.
4
5	## 실행 모드
6
7	\| Phase \| 모드 \| 왜 이렇게 \|
8	\|-------\|------\|----------\|
9	\| 1. 리서치 \| 서브 에이전트(팬아웃) \| 소스별 독립 수집 → 병렬화가 이득 \|
10	\| 2. 저술 계획 \| 단일 서브 \| 통합적 사고가 필요, 분할 이점 없음 \|
11	\| 3. 계획 리뷰 \| 에이전트 팀(생성-검증 왕복) \| 저자와 리뷰어의 토론이 품질을 높임 \|
12	\| 4. 챕터 저술 \| 에이전트 팀 \| 챕터 저술가 ↔ 스타일 가디언 ↔ 편집자 실시간 조율 \|
13	\| 4.5. 통권 수락 검수 \| 단일 서브(신선 컨텍스트) \| editor와 분리된 새 눈이 통권을 게이트 — 자기 승인 방지 \|
14	\| 5. 표지 + EPUB \| 서브(부분 병렬) \| cover-designer를 background로 띄우고 epub-builder의 cover-독립 준비를 병행, `cover.png` 소비 지점에서 join \|
15
16	## Phase 0: 컨텍스트 확인
17
18	워크플로우를 시작하기 전에 기존 산출물 존재 여부를 확인한다.
19
20	1. 사용자 입력에서 주제, 주요 내용, 대상 독자를 추출한다. 셋 중 하나라도 불명확하면 사용자에게 짧게 질문한다 (AskUserQuestion 사용). 추가로 `저자: {이름}` 형태의 저자 지정이 있는지 확인한다 — 없으면 기본값 `Toby-AI`를 사용하고, 있으면 해당 값을 매니페스트·표지 메타까지 전파한다. `라이선스: {값}` 형태가 있는지도 확인한다 — 없으면 하네스 기본값 `CC BY-NC-SA 4.0`을 매니페스트에 그대로 두고(또는 `license` 필드를 비워두면 빌드 스크립트가 채움), 있으면 해당 값을 매니페스트의 `license` 필드로 전달한다.
21	2. 장르 감지 + 확인. `profiles/_registry.md`의 자동 감지 규칙으로 주제·주요 내용·대상 독자에서 장르를 추정한다 (`tech-book` / `narrative` / `practical` / `essay`, 기본 `tech-book`). 사용자가 `장르: {값}`을 명시했으면 그대로 채택. 아니면 `AskUserQuestion`으로 추정값을 첫 옵션·추천으로 제시해 확인받는다 (단, 신호가 강하고 명백하면 추정값을 알리고 진행해도 된다). 확정된 `genre`는 이후 모든 Phase로 전파되고, Phase 4의 editor가 `book_manifest.json`의 `genre` 필드에 기록한다. 활성 프로필 경로는 `profiles/{genre}/`.
22	3. 위임 다이얼 (운영자 학습 루프). 사용자 입력에서 `모드: 학습` 명시 또는 "이 주제를 공부하려고/잘 몰라서" 류의 명확한 학습 신호를 확인한다. 있으면 `delegation_mode: learning`, 없으면 기본 `production` — 신호가 없으면 묻지 않는다. 어차피 AskUserQuestion을 쓸 일이 있으면 그 질문에 다이얼 확인을 편승시켜도 된다 (추가 왕복 금지). 확정 값은 Phase 4의 editor에게 전달해 `book_manifest.json`의 `delegation_mode`에 기록하고 (재실행 결정성 — `genre`와 같은 취급), Phase 3·4·완료 보고의 학습 터치포인트가 이 값을 따른다. 정전 스펙은 `docs/learning-loop.md`.
23	4. 책 제목 후보(슬러그 포함)를 만든다. 예: `AI 시대의 개발자 철학` → 슬러그 `ai-developer-philosophy`.
24	5. `{slug}/`의 존재 여부를 확인한다.
25	- 미존재 → 초기 실행, Phase 1부터 순차 실행
26	- 존재 + 사용자가 부분 수정 요청 (예: "챕터 3만 다시", "계획만 수정") → 부분 재실행, 해당 Phase만 재호출. 이때 장르는 기존 `book_manifest.json`의 `genre`를 재사용한다 (사용자가 장르 변경을 명시하지 않는 한)
27	- 존재 + 새 입력 제공 → 기존 `{slug}/`를 `{slug}_prev-{timestamp}/`로 이동 후 새 실행
28
29	## Phase 1: 리서치 (팬아웃)
30
31	실행 모드: 서브 에이전트 병렬 호출
32
33	`research-lead` 에이전트를 호출하고, 내부에서 `web-researcher`, `paper-researcher`, `community-researcher`를 `run_in_background: true`로 병렬 스폰한 뒤 결과를 종합하도록 지시한다.
34
35	입력: `genre` (Phase 0에서 확정 — 리서처의 장르별 소스 세트 선택 기준), 주제, 주요 내용, 대상 독자, 슬러그
36	출력:
37	- `{slug}/01_reference.md` — 리서치 종합 문서 (섹션: 개념·정의, 주요 관점, 사례, 논쟁점, 참고문헌)
38	- `{slug}/research/web.md`·`papers.md`·`community.md` — 소스별 원본 리서치. `01_reference.md` 합성 후에도 보존한다 (Phase 4 `fact-checker`의 1차 대조 근거)
39
40	신선도 메타: tech-book·최신 기술 주제에서는 리서처가 각 출처의 발행일과 검색 시점("검색: {날짜} 기준")을 기록한다. 버전·릴리스 정보는 "{버전}/{연도} 기준"으로 못 박는다. 이 메타가 Phase 4 `fact-checker`의 대조 기준이 된다.
41
42	모델 라우팅: 판단·합성이 필요한 Phase(리서치·계획·리뷰·챕터 저술·수락 검수)는 `model: "opus"`를 명시하고, 기계적 Phase(`epub-builder`·`cover-designer`)는 각 에이전트 frontmatter의 `sonnet`을 따른다.
43
44	## Phase 2: 저술 계획
45
46	실행 모드: 단일 서브 에이전트
47
48	`book-planner` 에이전트를 호출한다.
49
50	입력: `genre`, 주제, 주요 내용, 대상 독자, `{slug}/01_reference.md`, 활성 `profiles/{genre}/scaffolds.md`
51	출력: `{slug}/02_plan.md` — 책 구조 설계 문서
52	- 책 제목 후보 3개
53	- 책 특성 (장르, 분량, 난이도, 독자 여정)
54	- 챕터 목록 (번호, 제목, 핵심 질문, 주요 내용, 예상 분량)
55	- 챕터 간 흐름(내러티브 아크)
56
57	## Phase 3: 계획 리뷰 (팀)
58
59	실행 모드: 에이전트 팀 (생성-검증 왕복)
60
61	`TeamCreate`로 `book-planner`와 `plan-reviewer`를 팀으로 구성한다. `plan-reviewer`가 계획을 비판적으로 읽고 `SendMessage`로 `book-planner`에게 피드백을 보낸다. `book-planner`는 피드백을 반영해 계획을 갱신한다.
62
63	수렴 기준: 왕복은 모든 Critical 항목이 planner가 반영했거나 `03_review_log.md`에 사유와 함께 명시적으로 유보(deferred)될 때, 또는 최대 2회 후 종료한다. 종료 시점에 미해소 Critical이 남아 있으면 위험으로 `03_review_log.md`에 로그한다. 그 뒤 팀을 해체한다.
64
65	산출물: `{slug}/02_plan.md` (갱신됨) + `{slug}/03_review_log.md` (리뷰 기록)
66
67	팀 해체 후 사용자에게 최종 계획을 제시하고 승인을 받는다. 사용자 피드백이 있으면 `book-planner`를 한 번 더 호출해 반영한다.
68
69	선판단 후공개 (운영자 학습 루프 1겹): 계획을 보여주기 직전, 운영자에게 "이 주제·독자라면 어떤 챕터 흐름을 기대하시나요? (한두 줄, 건너뛰어도 됩니다)"를 초대한다 — `learning` 모드에서는 기본 단계로, `production` 모드에서는 승인 요청 메시지에 한 줄로 편승한다. 스케치가 오면 계획 제시 때 운영자 예상과 갈라진 지점을 짚어준다 (예측 오류가 학습 신호다). 응답이 없거나 자율 실행 중이면 조용히 생략한다 — 비블로킹. 계획 제시에는 `02_plan.md`의 "설계 근거" 섹션(채택 이유 + 기각 대안)이 포함되어야 한다.
70
71	## Phase 4: 챕터 저술 (에이전트 팀)
72
73	실행 모드: 에이전트 팀 (핵심 Phase)
74
75	가장 중요한 Phase다. 팀 구성:
76
77	- `chapter-wr

People who liked this also viewed

6 picks

Type