아름다운 기사
배경 원칙
AI가 생성하는 콘텐츠가 복잡해질수록 출력 매체의 중요성은 더욱 커집니다. HTML의 가치는 정보 밀도, 시각적 명확성, 공유 편의성, 상호작용 능력을 동시에 향상시킨다는 점에 있습니다: 표, SVG, CSS, 코드 조각, 조정 가능한 컨트롤, 복사 및 내보내기 버튼은 독자가 단순히 '읽는 것'을 넘어 비교, 탐색, 조정, 재확인 및 지속적인 사용을 가능하게 합니다. Beautiful Article의 목적은 지루하고, 선형적이며, 소화하기 어려운 텍스트 자료를 시각적 경험이 더 아름답고, 읽기 리듬이 더 명확하며, 검토와 공유가 더 쉬운 단일 파일 웹 페이지 기사로 변환하는 것입니다.
경계 (먼저 이 스킬을 사용할지 판단)
- 최종 주요 산출물은 단일 HTML 기사이며, 웹 애플리케이션이 아닙니다.
- 기사에는
Raw자유 계층(임의 HTML / CSS / JS / React: 상호작용, 레이아웃排版, 동적 효과, 소형 도구, 필요에 따른 SVG / canvas 다이어그램)이 포함될 수 있지만 반드시 독서, 설명, 논증, 리듬 또는 미학을 위한 목적이어야 합니다. - 생성하지 않음: 백엔드, 양식, 드래그 앤 드롭 작업대, 전체 대시보드, 제품 프로토타입, 범용 웹 앱.
- 정보 밀도는 사용자가 확인하며 기본적으로 100% 정보를 유지하고 장문 형식의 웹 페이지 기사를 생성합니다.
사용자가 애플리케이션이 아닌 기사를 원한다면 중단하고 명확히 한 후, 이 스킬로 진입하지 마십시오.
워크플로우 개요
Phase 0 Intake 이 스킬 진입 여부 판단 + 초기 기사 유형
▼
Phase 1 Source → Markdown URL/PDF/DOCX/MD/텍스트 → source.md + extraction-notes.md
└ 메인 에이전트가 5가지 체크리스트를 인라인으로 자체 점검 (복잡/저신뢰 소스만 SubAgent로 업그레이드)
▼
Phase 2 Editorial Planning plan.md 생성 (Brief / Outline / Theme / Assets 네 섹션)
└ 메인 에이전트 인라인 자체 점검 (SubAgent 없음, review 파일 없음)
▼
Phase 3 Plan Checkpoint ★Checkpoint 1 반드시 중단. 5가지 항목을 하나씩 확인: 기사 유형(기본 정보 유지 비율 포함) / 주제 / 레이아웃 / 이미지 모드 / 표지
▼
Phase 4 First Spread 첫 화면 + 첫 번째 섹션 + 대표적인 시각적 블록 하나 (여기서 스캐폴드 생성)
└ First Spread Reviewer SubAgent (review/first-spread-review.md 작성)
└ ★Checkpoint 2 반드시 중단. 2가지 항목을 하나씩 확인: 검수 결론 / 개발 모드 A/B
▼
Phase 5 Full Article Build 전체 웹 페이지 기사 생성 (기본 단일 에이전트, 매우 긴 경우 Section별로 분리)
└ Section Reviewer SubAgent (메시지로 pass/fail 반환, review 파일 작성 불필요)
▼
Phase 6 Final Review 편집 / 시각 / 기술 세 가지 관점 최종 검수 (review/final-review.md 작성)
▼
Phase 7 Repair 최소 단위 수정, 수정 사항이 있을 때만 repair-log.md 작성
▼
Phase 8 Delivery ★Checkpoint 3 반드시 중단. 전달 결정을 하나씩 확인 → article.html + 간단한 편집 설명 전달
작업 공간 구조 (스캐폴드가 생성함; 이 파일들은 스킬의 장기 기억이며, 채팅 컨텍스트에만 의존하지 마십시오):
<workspace>/
source/ original.* source.md source.<lang>.md(번역 필요 시) extraction-notes.md
plan/ plan.md # 단일 계획 파일: Brief / Outline / Theme / Assets 네 섹션
article/ Cover.tsx(기본) Article.tsx sections/ raw-blocks/ assets/ article.html(산출물)
review/ first-spread-review.md final-review.md # 이 두 가지만 정기 산출물
source-review.md(복잡한 소스만) repair-log.md(수정 있을 때만)
index.html package.json vite.config.ts tsconfig*.json (빌드 도구)
엄격한 품질 검사 프로토콜 (스킬 전체에 적용)
품질 검사 방식은 노드에 따라 구분됩니다. 모든 품질 검사에 SubAgent를 열 필요도, 모든 품질 검사에 파일을 작성할 필요도 없습니다. 잘못된 SubAgent 실행 / 잘못된 파일 작성은 가장 중요한 성능 문제이므로, 아래 표를 엄격히 따르십시오:
| 노드 | 품질 검사 방식 | 산출물 | 이유 |
|---|---|---|---|
| Phase 1 Source (기본) | 메인 에이전트 인라인 5가지 체크리스트 | 파일 없음 | 메인 에이전트가 어차피 source.md를 통독함 |
| Phase 1 Source (복잡/저신뢰 소스만) | Source Reviewer SubAgent (original.* diff 대조) | review/source-review.md | 조용한 누락은 diff로만 잡을 수 있음 |
| Phase 2 Plan / Checkpoint 1 전 | 메인 에이전트 인라인 자체 점검 (SubAgent 열지 않음) | 파일 없음 | plan은 텍스트 기반 결정이며 200-400줄, 컨텍스트가 hot 상태이므로 SubAgent 콜드 스타트가 더 느림 |
| Phase 4 First Spread / Checkpoint 2 전 | First Spread Reviewer SubAgent | review/first-spread-review.md | 첫 화면이 분위기를 결정하므로 별도의 독립적인 검토가 더 안정적임 |
| Phase 5 각 Section | Section Reviewer SubAgent | 메시지로 pass/fail + 수정 포인트 반환 (파일 작성 안 함) | 한 기사에 5-15개 섹션이 있을 수 있으며, N개의 review 파일은 아무도 다시 읽지 않음 |
| Phase 6 최종 검수 / Checkpoint 3 전 | Editorial + Visual + Technical Reviewer SubAgent | review/final-review.md | 전달 산출물의 일부로, 기록 보존 가치가 있음 |
철칙:
- Plan Checkpoint (Phase 2 → Checkpoint 1)에서 SubAgent를 열어 품질 검사를 하는 것을 금지합니다. 메인 에이전트가
plan.md를 작성한 후 즉시 5가지 목록(references/review-checklist.md의 Plan 자체 점검 섹션 참조)을 대조하여 확인하고, 결론에 따라plan/plan.md를 수정한 후, review 파일을 작성하지 말고 Checkpoint 1로 진입합니다. - First Spread / Final은 반드시 SubAgent를 사용해야 합니다 (이 두 노드는 SubAgent의 가치가 비용보다 큼). SubAgent 환경을 감지할 수 없는 경우에만 메인 에이전트가 대응하며, 파일 첫 줄에 "SubAgent 환경 없음, 메인 에이전트 대응"이라고 명시합니다.
- Section Reviewer는 SubAgent를 사용하지만 반환값은 메시지 (pass / fail + 수정 포인트)입니다. fail 항목은 메인 에이전트가 받은 후 직접 수정하며, SubAgent가
review/section-NN-review.md파일을 작성하게 해서는 안 됩니다. - 품질 검사 결과를 받으면 먼저 fail 항목에 따라 산출물을 수정한 후, "완료 + 자체 점검 결과 + 수정 사항"을 보고합니다. 원시 결과를 보고하면서 수정하지 않는 것은 위반입니다.
- 결정 수집 철칙 · 사용자를 대신하여 조용히 선택하는 것을 금지합니다: 각 Checkpoint(1 / 2 / 3)에서 사용자 확인이 필요한 모든 결정 항목은 반드시 각각 독립적으로 나열하고 사용자의 답변을 기다려야 합니다. 에이전트는 추천할 수 있지만 ("X를 추천합니다. 왜냐하면 …"), "이미 X로 결정했습니다. 틀리면 말씀해 주세요"라고 해서는 안 됩니다. 이는 선택 기회를 박탈하는 것과 같습니다.
- 우선: 환경에
AskQuestion도구가 있으면 각 결정 항목을 독립적인 question으로 전달합니다(한 번 호출로 여러 question 전송 가능). 사용자는 선택 카드를 통해 항목별로 확인할 수 있습니다. - 그 외: 메시지에서 모든 질문을 번호를 매겨 나열하고 (각 질문은 별도 단락, 추천 항목 + 이유 + 대안 명시), "항목별 답변을 기다린 후 계속 진행하겠습니다"라고 명확히 말하고 후속 작업을 진행하지 마십시오.
- 절대: 여러 결정 사항을 하나의 "제 추천을 모두 선택하시겠습니까? / 모두 괜찮습니까?"와 같은 yes/no 질문으로 묶지 마십시오. 또한 "추천 한 마디" 후 기본적으로 다음 단계로 바로 진행하지 마십시오.
- 우선: 환경에
각 노드의 체크리스트와 SubAgent 프롬프트 템플릿은 references/review-checklist.md를 참조하십시오.
각 단계 파일 읽기 가이드 (점진적으로 로드, 한 번에 모두 읽지 않음)
| 단계 | 필독 | 필요 시 참조 |
|---|---|---|
| Phase 0 Intake | references/harness.md | —— |
| Phase 1 Source→MD | references/source-to-markdown.md | scripts/source-to-markdown-markitdown.py · scripts/source-to-markdown.py |
| Phase 2 Planning | references/article-types.md · references/information-density.md · references/plan-template.md · references/theme-selection.md · references/layout.md · references/asset-policy.md · references/cover.md (표지 구성 아이디어) | references/article-types/<type>.md · theme-profiles/*.md |
| Phase 4 First Spread / Phase 5 Build (각 섹션마다 재참조) | references/section-build.md · references/component-policy.md · references/raw-policy.md · 선택한 주제 theme-profiles/<id>.md · 표지: references/cover.md | references/scaffold.md (프로젝트 생성 시 한 번) · references/html-output.md |
| Phase 6/7 Review & Repair | references/review-checklist.md · references/repair-policy.md | —— |
| Phase 8 Delivery | references/html-output.md | references/pdf-output.md (사용자가 PDF 내보내기를 선택한 경우에만) |
긴 세션에서 에이전트가 원칙을 잊기 쉬움 — Phase 5는 N개의 Section을 반복 구현하므로, 매번 작업 시작 전에
component-policy.md+raw-policy.md+ 현재 주제theme-profiles/<id>.md를 다시 확인하십시오.
Phase 0 —— Intake
이 스킬로 진입할지 판단하고, 초기 기사 유형과 출력 모드(기본 단일 HTML)를 제시합니다.
| 사용자가 제공한 것 | 수행할 작업 |
|---|---|
| 하나 이상의 자료 (URL/PDF/DOCX/MD/텍스트/스크린샷) | Phase 1로 진입 |
| "X 기사를 만들어 주세요"라고만 하고 자료는 없음 | 역질문: 먼저 자료나 개요를 요청. 스킬이 사용자를 대신하여 내용을 공짜로 만들지 않음 |
| 명백히 애플리케이션/도구/대시보드를 원함 | 중단하고 명확히 한 후, 이 스킬로 진입하지 않음 |
대상 언어 캡처: 시작할 때 사용자가 최종 기사에 원하는 언어를 기록합니다 (예: "한국어로/영어로 만들어 주세요" 등).
- 사용자가 언어를 지정함 →
plan/plan.md의 Brief 섹션 "대상 언어"에 기록. 소스 자료 언어와 다를 경우, Phase 1에서 먼저 자연스러운 번역 버전의 소스 텍스트를 생성하고, 이후 번역 버전을 기반으로 작성합니다 (Phase 1 참조). - 사용자가 언어를 지정하지 않음 → 기본적으로 최종 기사 언어는 소스 자료 언어를 따르며, 번역하지 않습니다.
자체 점검: 사용자가 원하는 것은 기사인가 웹 애플리케이션인가? 전체 정보가 필요한가? 먼저 더 많은 자료를 요청해야 하는가? 사용자가 최종 언어를 지정했는가? 소스 언어와 일치하는가?
Phase 1 —— Source → Markdown
모든 입력을 통일하여 source/source.md로 만들고, 불확실한 항목은 source/extraction-notes.md에 기록합니다.
규칙 및 다양한 입력 유형 처리는 references/source-to-markdown.md를 참조하십시오. PDF/DOCX/HTML 추출에는 MarkItDown 메인 경로 또는 경량 폴백 스크립트를 사용할 수 있습니다.
저장 후 메인 에이전트가 인라인으로 자체 점검 (references/source-to-markdown.md의 5가지 체크리스트)을 수행하고, 결론에 따라 수정한 후 Phase 2로 진입합니다. extraction-notes.md가 저신뢰/복잡 소스로 표시된 경우에만 독립적인 Source Reviewer SubAgent로 업그레이드하여 original.*과 diff 방식으로 대조 검사하고 (review/source-review.md 작성)합니다.
언어 처리 (추출 직후): source.md의 언어를 판단합니다.
- 사용자가 대상 언어를 지정하지 않았거나, 대상 언어가 소스와 일치하는 경우 → 번역하지 않고, 이후
source.md를 기반으로 작성하며, 최종 기사 언어 = 소스 언어. - 사용자가 대상 언어를 지정했으며 소스와 일치하지 않는 경우 → 먼저 자연스러운 번역 버전
source/source.<lang>.md(예:source.zh.md/source.en.md)를 생성하여 이후 Phase 2+의 사실적인 기반으로 삼고, 원본source.md는 참고용으로 보존합니다. 번역 요구 사항: 목표 언어에 맞는 자연스러운 표현 사용, 번역체 제거 (목표 언어의 표현 관용구에 따라 문장 재구성, 단어 그대로 직역하지 않으며, 어색한 외국어 어순/수동태 중복/이국적 구두점 남기지 않음), 용어/숫자/코드/공식/인용문은 정확하게 유지, 구조와 정보 유지 비율은 변경하지 않음. 번역 설명은extraction-notes.md에 기록합니다.
Phase 2 —— Editorial Planning
편집 계획을 수립하고, HTML을 직접 작성하지 않습니다. plan/plan.md 하나만 생성합니다 (네 섹션: Brief / Outline / Theme / Assets). 템플릿은 references/plan-template.md를 참조하십시오:
- Brief: 대상 독자 / 기사 유형 / 정보 유지 비율 / 반드시 유지할 내용 / 삭제 가능한 내용 / 어조 / 주요 관점 / 읽기 목표 / 대상 언어 / 레이아웃 너비 / TOC / 이미지 전략.
- Outline: Hero / Lead / Summary / Section 목록 / 각 섹션에서 유지할 정보 / 각 섹션에 Raw·Table·CodeBlock·Formula·Image가 필요한지 / 종결 방식.
- Theme: 선택한 주제 + 이유 + 충돌 설명 (
references/theme-selection.md참조). - Assets: 이미지 전략 및 이미지별 계획 (
references/asset-policy.md참조;none모드에서는 이 섹션을 한 문장으로 작성).
기사 유형 라우팅은 references/article-types.md를 참조하십시오. 정보 밀도와 컴포넌트 비율은 references/information-density.md를 참조하십시오.
자체 점검 방식 · 강력 제약: plan/plan.md를 작성한 후 메인 에이전트가 인라인으로 5가지 Plan 자체 점검 목록을 대조하여 확인하고 (references/review-checklist.md의 Plan 자체 점검 섹션 참조), 결론에 따라 plan/plan.md를 수정한 후, 직접 Checkpoint 1로 진입하고, SubAgent를 열지 말고, review/plan-review.md를 작성하지 마십시오.
Phase 3 —— Plan Checkpoint (★하드 노드 · Checkpoint 1, 반드시 중단)
철칙: 사용자를 대신하여 조용히 선택하는 것을 금지합니다. 각 결정 항목은 반드시 독립적으로 나열하고 독립적으로 사용자의 답변을 기다려야 합니다.
추천할 수 있지만 ("X를 추천합니다. 왜냐하면 …"), "이미 X로 결정했습니다. 틀리면 말씀해 주세요"라고 해서는 안 됩니다. 후자는 기본값을 몰래 통과시키고 선택 기회를 박탈하는 것과 같습니다.
수집 방식 (환경에 따라 둘 중 하나 선택):
- 우선
AskQuestion도구: 각 항목을 독립적인 question으로 전달합니다 (한 번 호출로 여러 question 전송 가능). 사용자는 선택 카드를 통해 항목별로 확인합니다. AskQuestion도구 없음: 메시지에서 각 질문을 번호를 매겨 나열 + 별도 단락 + 추천 항목 + 이유 + 대안을 명확히 작성하고, "항목별 답변을 기다린 후 계속 진행하겠습니다"라고 명확히 말하고, 후속 작업을 진행하지 마십시오.
어떤 방식이든: 각 독립적인 결정은 하나의 독립적인 질문에 해당하며, "모두 괜찮습니까?"라는 yes/no로 묶지 마십시오.
반드시 독립적으로 확인해야 할 5가지 항목 (하나도 빠짐 없음):
| # | 결정 항목 | 옵션 (의미적 레이블 · 기본 정보 유지 비율 포함) | 비고 |
|---|---|---|---|
| 1 | 기사 유형 (정보 유지 비율 포함) | 완전 장문 / 아카이브 longform · ~100% ／ 연구 보고서 / 정식 분석 full-report · ~80% ／ 교육 단계 / 시작 가이드 tutorial · ~90% ／ 개념 / 시스템 설명 explainer · ~80% ／ 대화 / 인터뷰 / 팟캐스트 dialogue · ~80% ／ PR / 계획 / 사고 검토 review · ~70% ／ 의견 / 논평 / 내러티브 essay · ~70% ／ 대화형 학습 / 개념 체험 interactive-explainer · ~25% 원문 발췌 + 75% AI 재구성 ／ 결정 요약 / 바쁜 사람을 위한 briefing · ~50% ／ 그림 위주 / 전시 및 공유 visual-essay · ~40% | AI가 하나를 추천하고 이유를 한 문장으로 작성. 비율은 이미 유형 옵션에 포함되어 있으므로 별도 질문으로 만들지 않음 (그렇지 않으면 longform + 20%와 같은 가짜 조합이 발생할 수 있음). 사용자가 기본값에서 벗어나려면 자유 텍스트로 한 문장으로 덮어씁니다 ("longform + 60% 원함"). 아래 "기본값에서 벗어나는 방법" 참조 |
| 2 | 주제 | tufte / press / 기타 등록된 주제 (theme-profiles/index.json 읽기) | AI가 하나를 추천하고 이유를 한 문장으로 작성 |
| 3 | 레이아웃 너비 | narrow / regular / wide / full | AI가 하나를 추천; 기본값 regular |
| 4 | 이미지 모드 (필수 선택 · "기본 통과" 허용 안 함) | none / user-assets / placeholders / ai-generated | 한 문장으로 "외부 Image 사용 여부만 결정; Raw는 영향을 받지 않음" |
| 5 | 표지 (3:4 책 표지 스타일 제목 이미지, TOC + 본문 위에 위치) | 켜기 (기본) / 끄기 | AI가 "켜기"를 추천하고, 구성 아이디어를 한 문장으로 제시 (어떤 메인 비주얼 + 어떤 표지 템플릿 A/B/C/D/E 선택). briefing / dialogue는 "끄기"를 추천할 수 있음. 자세한 내용은 references/cover.md 참조 |
TOC는 기본 켜기: 하나의 스위치만 있으며 거의 모든 기사에서 켜야 하므로, Plan Checkpoint 시작 설명에서 "TOC는 기본 켜기, 끄려면 알려주세요"라는 한 문장으로 처리할 수 있으며, 별도 질문으로 만들 필요는 없습니다.
이미 기본값으로 처리되어 별도로 물을 필요가 없는 항목 (단, 시작 설명에서 "변경하려면 알려주세요"라고 명시하여 사용자가 번복할 기회를 주어야 하며, 완전히 숨겨서는 안 됨):
- 최종 기사 언어: 소스 언어를 따름 (사용자가 이미 앞서 지정했거나 번역이 완료된 경우 제외).
- 편집 삭제, 재구성, 어조 변경 허용 여부: 기본 허용 (위의 정보 유지 비율에 따라 실행).
- 먼저 첫 화면 견본을 볼지 여부: 기본적으로 먼저 수행 (이것이 Phase 4).
- TOC: 기본 켜기.
사용자가 주제에 대해 "당신이 정하세요"라고 하면 → 당신이 추천한 첫 번째 것을 선택하되, 옵션에서 여전히 다른 후보와 함께 나열하고, "기본 · AI 추천"이라고 표시하여 번복의 여지를 남기고, 주제 질문을 건너뛰지 마십시오.
정보 유지 비율의 "기본값"에서 벗어나는 방법: 각 기사 유형에는 권장 유지 비율이 내장되어 있습니다 (위 표 참조). 대부분의 경우 기본값을 사용하면 됩니다. 사용자가 정밀 조정을 원할 경우 (예: "longform인데 60%만 유지" → 깊이 편집된 장문), 사용자에게 시작 설명 후 자유 텍스트로 "<유형> + <X%> 원함"이라고 한 문장을 작성하도록 합니다. AI는 이 덮어쓰기를 받은 후 plan/plan.md의 Brief 섹션에 "유형 / 기본 유지 비율 / 사용자 덮어쓰기 X%"를 동시에 기록하고, 이것이 "기본값이 아닌 조합"임을 사용자에게 알려야 합니다. 이러한 조합은 메인 에이전트가 각 섹션을 작성할 때 본문/시각 비율을 수동으로 조정해야 합니다.
Plan Checkpoint 시작 메시지 템플릿 (결정을 수집하기 전에 먼저 짧은 설명을 보냄):
plan/plan.md가 작성되었습니다 (자체 점검 통과). 5가지 항목을 하나씩 확인하겠습니다: 기사 유형 / 주제 / 레이아웃 너비 / 이미지 모드 / 표지.
제 추천은 참고용으로 여기에 먼저 제시합니다 (선택하지 않음):
- 유형: <X> (기본 정보 유지 비율 <Y%> 포함. 이유: …)
- 주제: <theme> (이유: …)
- 레이아웃 너비: <width> (이유: …)
- 이미지 모드: <전략> (이유: …)
- 표지: 켜기 / 끄기 (이유: …; 켜기의 경우 구성 아이디어: …)
기본값으로 진행하지만 변경 가능: 언어는 소스 언어를 따름; 편집 삭제/재구성 허용; TOC 켜기; 다음으로 먼저 첫 화면 견본을 만들 예정.
정보 유지 비율을 유형 기본값에서 벗어나려면 아래 답변과 함께 구체적인 백분율을 알려주세요 (예: "longform인데 60%만 유지").
아래에서 항목별로 확인하겠습니다.
위 설명을 보낸 후 즉시 AskQuestion을 사용하여 5개의 question을 전송하거나 (또는 도구가 없는 환경에서 5개의 질문을 번호를 매겨 나열하고 답변을 기다림). 5가지 항목에 대한 답변을 모두 수집해야 Phase 4로 진입할 수 있습니다. 사용자가 자유 텍스트로 "기본값이 아닌 유지 비율"을 제공한 경우, AI가 이를 plan/plan.md에 기록했는지 확인한 후 Phase 4로 진입합니다.
Phase 4 —— First Spread (기사 버전의 "첫 장 검수")
먼저 "표지 (켜져 있는 경우) + 첫 화면 + 첫 번째 섹션 + 대표적인 시각적 블록 하나"를 만듭니다. 여기서 스캐폴드가 작업 공간을 생성합니다:
# 기본 표지 켜기
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id>
# Checkpoint 1에서 사용자가 "표지 · 끄기" 선택
bash <path-to-beautiful-article>/scripts/scaffold.sh ./my-article --theme=<id> --no-cover
bash <path-to-beautiful-article>/scripts/scaffold.sh --list-themes
Vite + React + TS 작업 공간 (npm에서 reacticle 최신 릴리스 설치) + source/ plan/ review/ 메모리 디렉토리 + 어셈블러 article/Article.tsx + 예시 섹션 컴포넌트 (+ 기본 article/Cover.tsx, --no-cover가 아닌 경우)를 생성합니다. 자세한 내용은 references/scaffold.md를 참조하십시오.
첫 화면 (Hero / Lead)은 어셈블러 article/Article.tsx에 작성합니다. 첫 번째 Section은 반드시 독립 컴포넌트 파일 article/sections/01-*.tsx로 작성해야 합니다 (이것은 이후 병렬 처리를 위한 코드 앵커입니다. references/section-build.md 참조). 표지 (켜져 있는 경우)는 article/Cover.tsx의 <CoverPlaceholder />를 주제와 기사 주제에 맞춤화된 그림 및 텍스트 구성으로 교체하며, 외부 셸 (3:4 컨테이너 + 인쇄 페이지 나누기)은 건드리지 않습니다. 표지 디자인 가이드는 references/cover.md를 참조하십시오. npm run dev로 미리 봅니다. 이것이 제목 분위기/글자 크기/내용 밀도/Raw 스타일/이미지 방식/주제 적합성을 결정합니다.
첫 번째 Section 완료 후, 엄격한 품질 검사 프로토콜에 따라 First Spread Reviewer SubAgent를 생성하고 review/first-spread-review.md를 작성한 후 (표지 5가지 자체 점검 포함, references/cover.md 참조), 수정 후 Checkpoint 2로 진입합니다.
Checkpoint 2 · First Spread (★하드 노드, 반드시 중단)
사용자에게 첫 화면 + 첫 번째 Section을 검수하게 하고, 후속 개발 모드를 선택하게 합니다. Checkpoint 1의 결정 수집 철칙이 동일하게 적용됩니다: 두 항목을 독립적으로 확인하고, 묶음 금지; AskQuestion 우선, 도구 없으면 번호를 매겨 나열하고 답변을 기다림.
먼저 짧은 메시지를 보냅니다:
첫 화면 + 첫 번째 Section이 완료되었습니다. npm run dev로 localhost에서 미리 보실 수 있습니다.
품질 검사 결과는 review/first-spread-review.md를 참조하십시오 (fail 항목에 따라 수정 완료, 수정 사항 나열).
아래 두 가지를 독립적으로 확인해 주십시오: 1) 검수 결론 2) 후속 개발 모드.
그런 다음 AskQuestion을 사용하여 두 개의 독립적인 question을 전송하거나 (또는 두 개의 질문을 번호를 매겨 나열하고 답변을 기다림):
- 검수 결론 — 옵션:
통과 · 전체 생성으로 진행/부분 수정 · 수정할 부분을 별도로 말씀드리겠습니다/주제 또는 레이아웃이 부적합 · Checkpoint 1로 돌아가기. - 후속 개발 모드 — 옵션:
A · 단일 에이전트 순차 (기본 · 가장 안정적 · 스타일 가장 일관됨)/B · 다중 에이전트 병렬 (가장 빠름 · 스타일 약간 차이 가능).
이 두 가지를 "통과 + A, 괜찮습니까?"로 묶지 마십시오. — 사용자는 "검수 통과했지만 B 사용"을 원하거나 그 반대일 수 있습니다. 두 질문에 대한 답변을 모두 수집한 후 Phase 5로 진입합니다.
Phase 5 —— Full Article Build
Checkpoint 2에서 선택한 개발 모드에 따라 전체 기사를 생성합니다. 자세한 내용은 references/section-build.md + references/component-policy.md + references/raw-policy.md를 참조하십시오.
철칙 · 각 Section은 반드시 독립 컴포넌트 파일 (article/sections/NN-*.tsx)이어야 하며, 여러 Section을 하나의 컴포넌트에 직접 작성하는 것을 절대 허용하지 않습니다. article/Article.tsx는 어셈블러일 뿐입니다: 각 Section을 import하고 정렬하며, 메인 에이전트가 소유합니다. 대규모 Raw도 article/raw-blocks/NN-*.tsx로 분리합니다. 파일 수준 분리는 다중 에이전트 병렬 처리의 전제 조건입니다.
개발 모드 (Checkpoint 2에서 선택):
- A · 단일 에이전트 순차 (기본): 메인 에이전트가 각
sections/NN-*.tsx를 순서대로 작성하며, 가장 안정적이고 스타일이 가장 일관됩니다. - B · 다중 에이전트 병렬: 서브 에이전트가 각각 하나의
sections/NN-*.tsx파일을 소유하여 병렬로 개발합니다. 메인 에이전트는 병합 및 안정성을 담당합니다. —Article.tsx의 import와 순서를 유지하고,npm run typecheck/build를 실행하며, 주제와 스타일 일관성을 보장하고, 충돌을 해결합니다. 서브 에이전트 프롬프트 템플릿은references/section-build.md를 참조하십시오.
나머지 원칙: 본문이 주체입니다. 모든 Raw는 --ra-* 테마 토큰을 사용하며, 야생 스타일을 금지합니다. 100% 정보 유지는 장문 구조를 중심으로 하고, Raw/이미지로 강화합니다. 낮은 정보 밀도는 시각적 블록 비율을 높일 수 있지만, 여전히 기사 형태여야 합니다.
각 Section이 완료된 후 반드시 엄격한 품질 검사 프로토콜에 따라 Section Reviewer SubAgent를 실행해야 합니다: outline 작업을 완료했는지 / 정보 유지 비율을 준수하는지 / 앞뒤와 연결되는지 / 과도하게 컴포넌트화되었는지 / 충분한 본문이 있는지 / Raw와 이미지에 명확한 목적이 있는지 / 이 섹션의 번호가 일관된지.
SubAgent는 메시지로 pass/fail + 수정 포인트를 반환 (pass면 한 줄 OK; fail이면 수정 포인트 나열)하며, review/section-NN-review.md 파일을 작성하지 마십시오. 메인 에이전트는 fail 항목을 받은 후 해당 section 파일을 직접 수정하고, 그런 다음 이 섹션의 전달을 보고합니다.
Phase 6 —— Final Review (세 가지 관점 최종 검수)
독자 / 주제 / 기술 세 가지 관점에서 검수하여 review/final-review.md + 수정 목록을 산출합니다. 전체 엄격한 체크리스트는 references/review-checklist.md를 참조하십시오. 세 명의 Reviewer를 권장합니다 (Teams가 없을 경우 최소 하나의 독립적인 SubAgent):
- Editorial Reviewer: 기사성, 정보 선택, 구조.
- Visual Reviewer: 주제, Raw, 이미지, 모바일.
- Technical Reviewer: 빌드, 콘솔, 코드/공식, 접근성.
핵심 레드라인: 여전히 하나의 기사 (애플리케이션이 아님) · 정보 유지 비율이 Plan과 일치 · 반드시 유지해야 할 정보가 누락되지 않음 · 주제 분위기가 통일됨 · Raw에 야생 스타일 없음 · 명백한 AI 느낌 없음 · 데스크탑 + 모바일에서 읽을 수 있음 · HTML을 빌드하고 열고 공유할 수 있음.
Phase 7 —— Repair (최소 단위)
최소 단위로 수정하며, 규칙은 references/repair-policy.md를 참조하십시오. 금지: 한 곳만 수정 지적하고 전체를 다시 작성하는 것 / 수정을 위해 이미 확인된 기사 구조를 시각적으로 변경하는 것 / 정보 압축을 위해 사용자가 지정한 유지 필수 내용을 삭제하는 것. 수정 사항이 있을 때만 review/repair-log.md를 작성합니다 (수정 없음 / 한 번에 통과 시 작성하지 않음).
Checkpoint 3 · Final (★전달 확인)
최종 검수 수정 후, 중단하고 사용자가 독립적으로 전달 결정을 확인하게 합니다 ("HTML을 내보내려고 합니다. 문제 없으면 이대로 진행하겠습니다"라고 바로 넘어가지 않음). AskQuestion을 우선하고, 도구가 없으면 메시지에 질문을 번호를 매겨 나열하고 답변을 기다립니다.
- 전달 결정 — 옵션:
통과 · HTML 내보내기 전달/통과 · HTML + PDF 동시 내보내기/부분 수정 필요 · 구체적인 수정 사항을 알려드리겠습니다/잠시 중단 · 다시 살펴보겠습니다.
이 결정 한 가지만 있지만, 여전히 적극적으로 중단하고 물어봐야 하며, 기본 HTML 내보내기로 조용히 진행해서는 안 됩니다.
Phase 8 —— Delivery
빌드 및 전달 (명령어는 references/html-output.md 참조):
article/article.html(자체 포함 단일 페이지, CSS + JS 인라인, 오프라인에서 열 수 있음) — 주 전달물.- 선택 사항
article/article.pdf: Checkpoint 3에서 사용자가 "통과 · HTML + PDF 동시 내보내기"를 선택한 경우에만 생성합니다. 명령어:
스크립트가 시스템을 탐지합니다.bash <path-to-beautiful-article>/scripts/html-to-pdf.sh
이후 references/ 디렉토리의 각 참조 파일에 대한 자세한 내용은 원본 SKILL.md의 references/ 섹션을 참조하십시오.