ppt-yeong-style

name

ppt-yeong-style

description

yeong 스타일 강의·제안 덱 작성 규약 — ppt-master 빌드 엔진 위에 얹는 작성 레이어(엔진 자체가 아님). 덱 유형·md 소스 규약·작성 원칙 16종·밀도 리듬(중간 강화 기본)·역할 기반 색 팔레트·codex-image vs SVG 경계·앱 UI 실물 강제·ppt-master 레버 조합 차별화·빌드 후 스토리 흐름 review·공식 로고 fetch·윤문·렌더 QA를 한 세션·어느 repo에서든 일관 적용. ppt-master/slidev로 그냥 'PPT/슬라이드 만들기'와 달리, yeong 특유의 담백한 명사구 제목·anti-slop 본문 + 표지/목차/전환 pop 무드·일상 비유 보조선이 필요할 때. 트리거 — 'yeong 스타일 덱', '강의 덱/실습 덱 만들어줘', '제안서 슬라이드 만들어줘', 'ppt-master로 강의자료', '발표자료 yeong 스타일로', 'yeong style lecture/proposal deck', even when this skill is not named. 일반 'PPT 만들어줘'는 ppt-master, 'slidev 슬라이드'는 slidev로 — 이 스킬은 yeong 규약이 필요할 때만.

ppt-yeong-style

Hermes Agent Compatibility

When this skill is loaded through Hermes as ppt-yeong-style:ppt-yeong-style, map Claude/Codex tool names to Hermes tools:

Claude/Codex term	Hermes tool
Bash	terminal
Read	read_file
AskUserQuestion	clarify
Skill	skill_view (list available via skills_list)
(image generation)	image_generate

Treat $ARGUMENTS as the natural-language arguments supplied when the user asks Hermes to load the skill. Plugin-provided skills are explicit opt-in loads in Hermes; use skill_view("ppt-yeong-style:ppt-yeong-style") (or ask Hermes to load that qualified skill) rather than relying on bare text.

Hermes 전제: 이 스킬은 외부 ppt-master 플러그인의 빌드 엔진(uv run 스크립트)에 의존한다. Hermes 세션에서는 (1) ppt-master 플러그인이 enable 되어 있고 (2) uv가 설치되어 있어야 한다. 둘 중 하나라도 없으면 빌드 단계 진입 전에 중단하고 사용자에게 설치를 요청한다 (skill_view("ppt-master:ppt-master")로 엔진 스킬 로드 가능).

목차

• §0. 미감 토대 (Aesthetic foundation)
• §0b. 엔진·의존 (cross-skill 관용구)
• §0c. 언제 쓰나 / 안 쓰나
• §1. 덱 유형과 파이프라인
• §2. md 소스 작성 규약
• §3. 발표 덱 작성 원칙 16종
• §3b. 밀도·리듬 (정량 프리셋 + 기본값)
• §3c. 색·이미지·로고 (핵심 1줄 + 포인터)
• §3d. 스크린샷 — 옆에 둘까, 위에 짚을까 (앱 UI 실물 전제)
• §4. ppt-master 깊이 활용 — 조합으로 차별화
• §5. 서브스킬·리뷰 에이전트 (0.7.0 — 강의 덱 운영은 lecture-deck, 리뷰는 deck-review)
• 부록 A. 다른 세션에 규칙 주입

참조 파일 지도

파일	담당 SKILL.md 섹션	자기 내부 §라벨
references/design-language.md	§0 상세	(무번호, 전체가 §0 상세)
references/color-typography.md	§3c 상세(색·타이포)	§3c 상세
references/images-and-pop.md	§3c 상세(이미지)	§5·§5b·§5d
references/icons-logos.md	§3c 상세(로고)	§5c
references/ppt-master-craft.md	§4 상세	§4 상세
references/ppt-master-and-qa.md	§1 파이프라인 상세(7-step·윤문·완료 QA·스토리 흐름)	§6~§8c

참조 파일들 자체의 §5·§5b·§5c·§6~§8c 번호는 이번 라운드에서 재편하지 않는다(리스크 대비 이득 작음, 스펙 §2.4/§4 참고) — 위 표가 SKILL.md 쪽과의 대응만 명시한다.

yeong이 강의/실습/제안/학술 덱을 만들 때 적용하는 작성 규약. 빌드는 ppt-master 워크플로 위에서 돌고, 이 스킬은 그 위에 얹는 "무엇을·어떻게 쓸지" 레이어다.

핵심 명제: 덱 품질은 엔진이 아니라 작성 규약에서 갈린다 — 담백한 명사구 제목, 한 장=한 메시지, anti-slop 본문 + 표지/전환 pop, 역할 기반 색, 일상 비유 보조선. 이 규약을 매번 재유도 없이 일관 적용하는 게 목적.

§0. 미감 토대 (Aesthetic foundation)

시그니처 한 줄: "Editorial restraint, one committed accent." 따뜻한 중립 에디토리얼 캔버스를 페이지당 단 하나의 의도된 라우드 모먼트로 깬다. anti-slop은 "하지 마"의 신뢰 바닥이고, 이 시그니처는 그 위에 얹는 "이렇게 해"의 톤 — signature within trust(금지는 그대로 두고 톤으로만 차별화). 그래서 규칙을 다 지켜도 "무난한 AI 톤"에서 멈추지 않는다.

• tonality는 색보다 먼저. 인터뷰·색 락(파이프라인 (4)) 전에 감정 온도(절제↔pop, 권위↔즉시성)부터 합의하고, 그 톤에 맞춰 색·타입·사진을 고른다. 색을 먼저 고르고 톤을 끼워 맞추지 않는다.
• 6축(레이아웃·여백·색·타이포·사진·pop)과 anti-slop↔하이엔드 양립표, ppt-master 레버 락은 → references/design-language.md. 이 파일은 색·이미지·craft 모든 결정의 상위 미감 계약이다 — 충돌 시 design-language의 톤 의도가 우선.

§0b. 엔진·의존 (cross-skill 관용구)

• ppt-master = 빌드 엔진·구현 owner. canvas init·source 변환·template·executor 스타일 등 명시 안 한 세부는 ppt-master SKILL.md 그대로 따른다. bare name으로 참조(vendor·복제 금지 — 이 repo에 동봉하지 않는 별도 marketplace 플러그인). ppt-master의 python 스크립트(image_gen.py·finalize_svg.py·svg_to_pptx.py 등)는 uv run으로 실행(시스템 python 직접 의존 금지). 필수 엔진이라 graceful degrade 대상이 아니다 — 미설치 시 Step 5 빌드 진입 전에 중단하고 ppt-master 설치를 먼저 안내(수기 대체 금지).
• 의존 스킬은 있으면 사용, 없으면 생략 + 설치 제안 문구 출력: codex-image(이미지)·interview(인터뷰)·anti-slop-design(영문 slop·디자인 감사)·humanize-korean(한국어 윤문)·design-shotgun(색 후보 생성)·codex:rescue(교차 리뷰)·drawio:drawio-skill(자유형 구조 도식 PNG — §5d 삼분 경계). 미설치 시 그 단계는 수기로 대체하되 규약은 유지하고, 어떤 스킬이 빠져 어떤 단계가 수기로 강등됐는지 + "marketplace에서 <플러그인> 설치 시 자동화됩니다" 한 줄을 사용자에게 알린다(조용한 강등 금지 — ppt-master만 예외로 prerequisite-stop).
• 의존 스킬은 로드가 먼저다. 설치돼 있으면 해당 단계에서 그 스킬을 Skill 도구로 로드해 절차를 그대로 따른다 — 호출법·사용법을 리서치 에이전트로 재조사하지 않는다(실측: codex-image 호출법을 조사 에이전트로 재도출하느라 140k+ 토큰 소모 — 스킬 본문에 전부 있던 내용).

§0c. 언제 쓰나 / 안 쓰나

쓴다: 강의·실습·제안·학술 덱을 yeong 규약대로 만들거나 감사·개선할 때. "강의 덱 만들어줘", "제안서 슬라이드", "ppt-master로 강의자료 yeong 스타일로".

안 쓴다: 그냥 "PPT 만들어줘"(엔진만 필요 → ppt-master), "slidev 슬라이드"(→ slidev). 정확한 라벨·표만 필요한 단발 SVG, 디자인 감사 단독(→ anti-slop-design).

강의/제안 덱은 생성 비용이 크다. 사양(아래 §1 파이프라인 (1)~(4)) 확정 전에는 빌드(Step 5) 진입 금지. 모호하면 추측 말고 먼저 질문.

§1. 덱 유형과 파이프라인

두 유형을 매번 재유도 없이 일관되게:

• 제안 덱(클라이언트 미팅·발표) — 참고 예: 제안 10장.
• 실습/강의 덱(교육·핸즈온) — 참고 예: 실습 18장.

분량은 고정하지 않는다 — 매 프로젝트 인터뷰로 결정. 위 숫자는 참고치. (강의 슬라이드 수 매핑: 30분=1518 / 60분=2530 / 90분=3542 / 120분=4555 — 강의 외엔 인터뷰 우선.)

파이프라인(내용 SOT는 사용자) — 단계별 도구:

(1) 인터뷰: interview 스킬 → (2) md 소스 작성 → (3) 사용자 검토
→ (4) 색 락: design-shotgun + AskUserQuestion(확정된 md 콘텐츠의 톤/무드를 반영해서 고른다) → (5) ppt-master 빌드(SVG 생성) → (6) anti-slop 감사 → 윤문(SVG·노트 내용 수정)
→ (7) finalize_svg → svg_to_pptx → PDF(CJK 덱은 Playwright 렌더 dsf=2 + img2pdf — 아래 참조) → 렌더 Visual QA(PPT→PNG export 기준 최종 검증, §8)
→ 완료 게이트 리포트(감사·윤문·렌더QA·스토리 흐름 전부 확인 후 이때 처음 완료 선언)
이미지 = codex-image · 산출물 = 항상 pptx + PDF

• 해상도 ≠ 밀도: SVG 벡터라 720p/1080p가 레이아웃 동일·선명도만 다르다. viewBox 1280×720로 1회 작성·밀도 판단, 내보내기 해상도는 분리 변수(고해상도라고 글자를 더 넣지 않는다).
• PDF 경로 — 한글(CJK) 덱은 cairosvg 금지: "cairo 없으면 대체"가 아니라 금지다 — cairosvg는 CJK 폰트 폴백이 없어 한글이 tofu 박스로 깨진다(실측). 표준 경로 = 브라우저(Playwright/Chromium) 렌더 device_scale_factor=2(2560×1440 PNG) → img2pdf. 화면 검토용은 1280px로 축소(읽기 도구 2000px 한도 회피). 라틴 전용 덱만 cairosvg 허용.
• anti-slop 2단계 시점: (6)의 감사는 anti-slop-design의 Phase B(납품 전 체크리스트)다. Phase A(생성 전 self-critique, 최고 레버리지)는 빌드 후가 아니라 (2)~(4) md 소스·사양 확정 시점에 적용한다 — 빌드가 끝나고 처음 스킬을 로드하면 Phase A가 통째로 죽는다(실측).

ppt-master 7-step 세부(Eight Confirmations·Executor HARD rules)·윤문·완료 QA·실사용 주의는 → references/ppt-master-and-qa.md.

§2. md 소스 작성 규약

기본 = 단일 md 한 파일. 한 파일에 전체 슬라이드를 ---로 구분하고, 파일 앞머리에 전역 규약 블록(컨텍스트·톤·색·흐름)을 둔다(흐름 한눈·재배치·검색 우위). 큰 덱(25장+)이거나 섹션을 우선순위별로 따로 작업할 때만 deck_spec.md(전역) + 01_*.md·02_*.md 섹션 분리로 전환. 장표마다:

---
## 슬라이드 제목 (담백한 주제형 — 영업·당위 꼬리표 금지)
<!-- layout: two-col | timeline-table | diagram | image-bg | table | checklist | 자유 서술 -->
<!-- visual: bg-faded(codex-image) | concept-story(codex-image) | user-image | none -->
<!-- diagram-note: (layout:diagram일 때) 좌→우 흐름·강조 지점 등 도식 상세 지시 -->

[ 핵심 메시지 1 ]
[ 핵심 메시지 2 ]

- 보조 불릿 (필요 시)
- 표/일정은 마크다운 표로 작성 → ppt-master가 SVG 표/타임라인으로 렌더

• 제목은 담백한 명사형이되 한두 단어로 끊지 말 것 — 주체·맥락을 담은 명사구로. (✓ "할 수 있는 일" → "클로드 코드로 할 수 있는 일", "이미지" → "이미지 — 자동 생성이 기본") 문장형·질문형 제목은 그대로 금지.
• [ ... ] = 그 장표의 키 메시지(기본 2개) — 소스 전용 마커. md만 봐도 핵심이 한눈에. 렌더 출력엔 대괄호 글리프([·])를 절대 노출하지 않는다 — 내부 텍스트만 키 메시지 스타일(주색 리드/강조 면)로 그린다. 슬라이드에 대괄호가 그대로 보이면 버그(executor가 마커를 리터럴 렌더) → ppt-master의 spec_lock·executor 지시에 "대괄호는 키-메시지 표식, 출력 시 strip"을 명시(엔진 계약이라 이 repo에 spec_lock.md를 두지 않는다).
  • 2중 강제(규칙만으론 샌다 — 반드시 둘 다). ① 빌드 전: spec_lock.md(또는 executor 지시)에 strip 지시를 명문으로 기입. 누락 시 executor가 [ ]를 리터럴 렌더 — 실제로 한 덱 34장 전수가 이 누락으로 새어나간 사례 있음. ② 빌드 후: 빌드 산출 SVG 전체에 grep -nE '>\s*\[|\[ |\]\s*<| \]'로 여닫는 대괄호 글리프 0 확인(렌더 QA 필수 항목). 1건이라도 잡히면 해당 장 재생성.
• <!-- layout --> = ppt-master 레이아웃 의도. 위 6종은 시작 어휘일 뿐 닫힌 목록이 아니다 — 3열 카드·상하 분할·중심 방사형·풀블리드 이미지+텍스트 오버레이·Z/워터폴 흐름 등 자유 서술로 지시 가능하다(executor는 서술 의도를 따른다). 6종 안에서만 고르면 레이아웃 단조로움이 실제로 발생한다(실측: 13장 초안이 checklist 4·two-col 4로 몰림). 페이지 구조를 엔진 템플릿에서 상속하려면 §4 page_layouts, 이미지+텍스트 배치가 막히면 엔진의 배치 패턴 어휘집(→ ppt-master-craft.md 함정) — 정확한 이름·범위는 설치된 ppt-master 문서가 SOT. <!-- visual --> = codex-image 배경/사용자 이미지 필요 여부. <!-- diagram-note --> = 도식 구조 지시(번호 나열 금지, 화살표 박스 흐름). 도식 형태도 변주 — 모든 도식을 좌→우 화살표 체인으로 통일하지 말고 내용 구조에 맞춰 상하 단계·방사형·매트릭스를 섞는다(체인만 반복하면 그 자체가 새 단조로움). 인접 장과는 형태를 강제 차별화 — 유사 주제 장을 이어 붙이거나 새 장을 삽입할 때 바로 앞 장과 다른 도식 형태를 고른다(실측: folder-tree 장 뒤 신설 장은 2단 비교 카드로 — 같은 형태 연속이면 분포 게이트 전에 이미 단조).
• 중요 신규 기능은 표 한 줄보다 장면 스포트라이트 — 새로 알리는 핵심 기능을 비교표의 행 하나로 묻지 말고, 별도 1장으로 장면화한다(상황 → 동작 → 복귀의 3단 stepper 등). 표 행은 "차이가 있다"까지만 전하고, 장면 장이 "언제 어떻게 쓴다"를 전한다(실측: 사이드 챗 기능을 표 행에서 독립 장으로 승격).
• 레이아웃 분포 셀프 체크(md 소스 확정 시): layout 태그를 종류별로 카운트한 분포 표를 사용자 검토(파이프라인 (3))에 함께 제출한다. 하드 트리거 = 동일 layout 3장 연속 또는 텍스트형(two-col·checklist·table·timeline-table) 합이 전체의 50% 초과 → 재분산 후 다시 검토. 단일 유형 % 임계 하나로는 못 잡는다(실측: 13장 중 checklist 4 + two-col 4 = 각 31%뿐인데도 단조로움 지적) — 분포 표를 사람 눈에 통과시키는 것까지가 게이트다.
• 표·일정·범위는 마크다운 표로 → SVG 변환. 애매한 무드 도식만 codex-image.
• 전역 규약(컨텍스트·톤·디자인 락·흐름 표·출처)은 단일 md면 앞머리 블록에, 섹션 분리면 별도 deck_spec.md에.
• 목차(TOC) 슬라이드는 마지막에 작성한다. md 소스 초안 단계에서 다른 슬라이드와 같이 쓰지 않는다 — md 소스 안에서 전체 페이지 순서가 정해진 뒤(ppt-master 빌드 전, 이 저작 단계 안에서) 그 순서를 그대로 옮겨 적는다. 빌드 이후 페이지 순서를 바꿀 때(예: §8c 완료 게이트에서 순서 문제가 드러난 경우)는 목차뿐 아니라 spec_lock.md도 함께 갱신한다 — Executor가 페이지마다 spec_lock을 재읽으므로, md만 고치고 spec_lock을 안 갱신하면 다음 빌드가 예전 순서·리듬 계약으로 진행돼 다시 어긋난다(재확인 없이 방치 금지 — ppt-master-and-qa.md §8b의 "목차-실제 순서 일치" 체크와 짝).

§3. 발표 덱 작성 원칙 16종

1. 표지에 금액·수치·세부 목적·절차 금지. 표지 = 무엇/누구/언제만. (✓ [흩어진 업무를 정리하는 AI PM] [OO 대표님 × OO컴퍼니 · 2026.06.09])
2. AI-slop 일반론 문제제기 슬라이드 금지. "쏟아지는데/결국 사람 손" 류 명사 나열+당위는 통째 삭제 후 솔루션 도식으로 직진.
3. 단순 번호 나열(①②③④⑤) 대신 좌→우 흐름 도식. layout: diagram + diagram-note로 화살표 박스 흐름, 단계/하는 일 2열 표.
4. 기술 전제는 추측 말고 확인 후 명시. 도식·명령·UI는 실제 런타임 사실 근거. 사실확인은 공식 docs·신뢰 출처로(Claude 런타임이면 claude-code-guide 에이전트도 활용 — 미번들·타 런타임이면 공식 docs 직접 확인). 자사/자체 배포 시스템·제품을 설명하는 장은 일반 문서·강의자료보다 실제 배포 인스턴스(설정·상태 파일·메모리·로그·실측 화면) 조회가 우선이다 — 일반론으로 채우면 "실물을 파싱해 보여달라"는 정정이 돌아온다(실측). 도구 자체의 /help는 명령 목록일 뿐이라 기능·UX·권한모드 검증 근거로 쓰지 말 것. 미확인은 unverified. 공식 docs와 실사용 경험이 갈리면 병기한다 — 공식이 기능 존재를 확인해도 실사용 한계가 기록돼 있으면 "기능 있음 + 규모/조건 한계"를 한 문장에 담는다(실측: 병렬 세션은 공식 기능이나 수십 개 규모에선 GUI가 버벅임 → 표에 그대로 병기). 공식만 믿고 장밋빛으로도, 실사용만 믿고 기능 부정으로도 기울지 않는다. 정량·규모 주장도 코드·데이터 근거 필수 — 곱셈 산출값(예: 6×10=300)을 결론 수치로 내밀지 말고 "검증된 베이스 + 확장 축"으로 보수적으로 제시, 그 상수가 고정인지·가변인지·구현됐는지·향후 계획인지 확인(미확인은 unverified). 코드 식별자를 라벨로 노출하기 전엔 실제 코드 리터럴인지 grep 확인.
5. 비개발자 청중 = 일상어. "구축/산정/연동" → "만들기/잡기/이어주기". [ ] 메시지는 발화 호흡 1줄.
6. 제목은 담백하게, 설득은 [ ] 박스에. 제목에 영업·당위 꼬리표("— 오늘 결정합니다") 금지. (✓ ## 다음 스텝 + [오늘 환경·범위가 정해지면 → 정밀 견적 → 착수]) 단, 담백함이 과도한 단어 압축은 아니다 — 한두 단어로 끊지 말고 맥락 담은 명사구로(§2 제목 규약).
7. 내부 표기·버전 라벨 청중 노출 금지. "v4", "intake", "Option A/B" → "확정 견적", "수집·분류". 단, grep으로 확인된 실제 코드 리터럴은 한국어명 아래 보조 mono 라벨로 노출해도 된다(추적성) — 지어낸 내부 표기(v4·intake) 노출 금지의 예외.
8. 메시지형/번역투 문장 재점검. "정밀화합니다/이렇게 일합니다" → 발화 호흡 담백한 한국어. (✓ "6/4 견적은 참고용 — 오늘 함께 보고 확정합니다") 문장 구조만이 아니라 개념어 선택 자체의 AI 냄새도 본다 — 조사·어미는 자연스러운데 단어가 청중의 일상어가 아닌 경우(실측: "배수만 차이" → "사용량만 차이", "회사 중앙 관리" → "회사가 관리"). 윤문 단계에서 "이 단어를 그 청중이 평소에 쓰나?"를 별도 체크.
9. 표·그리드 텍스트는 행 밴드 수직 중앙 정렬. 행 텍스트 baseline을 밴드 중앙(center + ~8px)에. 헤더 밴드는 옅은 음영으로 구분. (정렬 어긋나면 "어수선" 인상.)
10. 세로 연결 화살표 = 명시적 아래방향 삼각형 path. 짧은 세로선에 markerEnd + orient="auto"를 쓰면 옆방향 삼각형으로 깨진다 → 세로 흐름엔 짧은 선 + 직접 그린 아래방향 삼각형 path.
11. 개념 슬라이드는 도식 우선. 서브에이전트(순수 컨텍스트 vs 메인 I/O)·컨텍스트 바 같은 추상 개념은 텍스트 나열보다 막대·박스 도식으로. 강사 비유를 보조 설명선으로(§3b 중간 강화).
12. 과감한 삭제·통합 허용. 중복·약한 슬라이드는 합치거나 부록으로, 장수 증감 자유. "전사/스토리 우선"이 기준 — 분량 채우기 금지.
13. 담백·사실 우선, 오그라드는 친근·위로조 금지. 강의 교안은 사실 + 납득되는 비유로. [ ]·본문에서 감정 친근화 금지: "함께 시작/함께 본다", "걱정 말고", "쉽게·금방", "같이 ~해요", "딱 ~만 알면 돼요". (✓ "막히면 설치 화면 그대로 확인" / ✗ "막히면 함께 봐요") 비유는 구조를 설명할 때만(§3b), 청중을 다독이는 어조는 아니다.
14. 주 surface 1개 고정 — 명령·스크린샷 일관. 한 덱은 터미널(CLI)·데스크톱 앱·웹 중 하나를 주 화면으로 정하고 설치·실행 명령·스크린샷·문구를 그 surface로 일관한다. "데스크톱 앱으로 시작"이라며 claude CLI 명령·CLI 설치를 섞으면 비개발 청중이 혼란(실측 실패). 보조 surface는 "이런 경로도 있다" 한 장으로만. 주 surface는 인터뷰에서 확정하고 원칙 4로 사실 검증.
15. 온보딩·입문 덱은 본류에 경쟁/탈선 도구 금지. 한 제품(예: 클로드 코드) 입문 덱에 경쟁 도구(코덱스 등)·곁가지를 본 흐름에 끼우면 청중이 길을 잃는다. 브리프가 명시 요구할 때만 끝부분 "비교/큰 그림" 1장으로 격리(본류 데모와 섞지 않음).
16. [ ] 핵심 메시지는 비자명한 트레이드오프·인사이트를 진술. 페이지 키 메시지가 전제를 재진술한 truism이면 reject 후 재작성 — 청중이 몰랐던 기술 트레이드오프·판단 근거를 담아야 한다. (✗ "사고는 우연이 아니라 설계" = 전제 재진술 당연론 / ✓ "무작위 물리로는 8초 내 충돌이 드물다 → 그래서 통제한다" = 트레이드오프 진술) 자동화·R&R·제안 덱의 비자명한 프레이밍은 속도·무노력이 아니라 역량·재현성(규격 고정·시드 재현·게이트 통과 류)으로 — "사람 개입 없이 / 코드 한 번"식 무노력 프레이밍은 R&R 민감 맥락에서 금지.

§3b. 밀도·리듬 (정량 프리셋 + 기본값)

page_rhythm 3종을 장면별 선택지로 병존시키되, 측정 가능한 고정선을 둔다.

리듬	용도	본문 요소	글자 가이드
anchor	표지·섹션 전환·마무리	0~1	[ ] 메시지 1~2, 본문 불릿 없음
breathing	실습 스텝·개념 1개	불릿 ≤3	불릿당 한 호흡(한 줄), 여백 넉넉
dense	표·비교·개념 정리	표 또는 불릿 ≤5	한 메시지 유지, 표로 분산

고정선(1280×720 기준): 본문 폰트 바닥 20pt · 터미널 블록 12줄 초과 시 2페이지 분할 · 불릿당 1호흡(한 줄) · wall-of-text·단락형 금지(anti-slop).

기본값 = 중간 강화:

• 핵심 메시지([ ] 박스)는 유지하되 슬라이드당 설명 1~2줄(비유·근거·맥락) 을 보조 muted 텍스트로 덧붙인다.
• 불릿 길이 상한을 완화(엄격 ≤20자 → 한 호흡 안의 자연스러운 길이). 본문 바닥 20pt는 유지.
• 강사의 일상 비유(매뉴얼=책, 컨텍스트=하루 뇌 용량/배터리, 서브에이전트=인격체, GitHub=코드계 구글드라이브, 하네스=회사/팀, Git=카톡 업데이트 롤백)를 개념 슬라이드 보조선으로 적극 활용.
• 중간 강화 ≠ dense: dense는 "표로 분산", 중간 강화는 "메시지 + 비유 보조선". 둘 다 wall-of-text는 금지.

§3c. 색·이미지·로고 (핵심 1줄 + 포인터)

• 색: 역할·면적 기반 팔레트("색 여러 개 = slop") — 중립 2(배경+잉크 85%) + 주색 12 + 액센트 footprint ≤10%. deck-wide 락 후 슬라이드별 색 날조 금지. 폰트 폴백 Pretendard → Noto Sans KR → Malgun Gothic. 상세 → references/color-typography.md.
• 이미지: codex-image가 기본 — 본문 개념 설명은 스토리 일러스트(§5d)가 주 경로(개념이 벌어지는 장면·서사, 정적 아이콘 아님), 무드컷·배경·hero도 codex. 정확한 라벨·표·정형 차트는 SVG, 자유형 구조 도식(관계·플로우·트리)은 drawio PNG. 배경 fade·장식 마스코트·pop만 표지·목차·전환 divider 한정. 앱 UI(로그인·diff·권한·설정 화면 등)는 실물 스크린샷 또는 점선 placeholder만 — codex/AI로 앱 화면 생성 금지(지어낸 UI는 틀린 UX를 가르쳐 placeholder보다 나쁘다). 미보유 시 playwright 실물 캡처·공식 docs 스크린샷·placeholder 순. 상세 → references/images-and-pop.md.
• 로고: 브랜드·도구 로고는 직접 그리기·codex 생성 금지 → 공식 SVG 라이브러리 fetch → 인라인 → 근접성. 상세 → references/icons-logos.md.

§3d. 스크린샷 — 옆에 둘까, 위에 짚을까 (앱 UI 실물 전제)

기준은 "이 화면에서 뭐가 메시지냐".

• 화면 자체·첫 소개·분위기, 또는 설명이 길거나 화면이 빽빽 → 2단(좌 스크린샷 + 우 설명).
• 화면 안 특정 위치(이 버튼·이 게이지)를 "여기 보세요"로 가르칠 때 → 콜아웃(화면 위에 짚기).
• 콜아웃은 덱 액센트 1색만: 번호 핀 + 여백 설명에 가는 선, 또는 얇은 테두리(면 안 채움). UI를 덮지 말고 필요한 것만.
• 프레임은 이미지 실측 비율에서 출발(shrink-to-hug) — 스샷 박스를 먼저 그려놓고 이미지를 욱여넣지 말 것. PIL 등으로 실측 → 필요 시 crop 파생본 생성 → 프레임 좌표를 이미지 비율에 맞춰 재계산. 비율이 깨진 스크린샷은 "가짜 UI 금지"만큼 신뢰를 깎는다(실측: 게이지 화면을 박스에 맞춰 늘였다가 재계산으로 정정).

§4. ppt-master 깊이 활용 — 조합으로 차별화

ppt-master를 단순 변환기로 쓰지 말 것. 엔진 안의 레버를 인터뷰·사양에서 의도적으로 골라 조합해야 "아무나 못 만드는" 덱이 나온다(레버 목록·조합 레시피·함정 전부 → references/ppt-master-craft.md). 핵심 레버:

• 레이아웃 3축: page_rhythm(§3b 리듬) + page_layouts(per-page 템플릿) + page_charts(차트 템플릿)를 페이지별로 변주 → "모든 장이 카드 그리드"의 균일함 탈피(page_layouts+page_charts는 호환될 때만 병용).
• 이미지 rendering×palette 매트릭스(20 렌더링 × 14 팔레트): deck-wide로 1조합 락 후 per-image type만 조절 → 일관된 아트디렉션.
• 3종 템플릿 fusion: brand(아이덴티티) + layout(구조) + deck(중간)을 섞어 검증된 구조 위에 yeong 색·톤.
• 아이콘 라이브러리 1종(chunk-filled/tabler/phosphor 중 택1) + simple-icons는 브랜드 로고 전용.
• 검증된 차트 템플릿(charts_index.json)으로 표·도식을 — codex가 아니라 정확·편집가능한 SVG 차트. verify-charts로 좌표 오차(10~50px) 보정.
• animations.json으로 핵심 장 등장 애니메이션만 의도 튜닝 · live preview 서버로 생성 중 실시간 확인.

원칙: 레버는 '더 화려하게'가 아니라 한 덱 안의 의도된 리듬·아트디렉션·정확도를 위해. anti-slop·역할 기반 색은 그대로 유지.

§5. 서브스킬·리뷰 에이전트 (0.7.0)

이 스킬은 작성 규약만 담는다. 강의 덱의 운영 문제와 리뷰 파이프라인은 같은 플러그인의 서브스킬로 분리:

• lecture-deck — 강의 덱 전용: 시간→장수 구성, 실습 handouts 생성 규약(자료-지시문 정합 검증) + 실습 프롬프트 카드, placeholder→실캡처 스크린샷 슬롯 운영, 장 삽입 리넘버링 파이프라인(read-all-then-write-all + 4중 동기화), 표 행 수 변경 재배치, 전사 회고 루프(강의 후 전사→커버리지 맵→기존 장 보강), 강사 노트 운영 태그([시연 필수]·수치 고정 대본·주차장 멘트). 완성 실례 = ../lecture-deck/references/cc-common-reference.md(47장 로스터·리듬·검증 이력 + 대표 렌더 5장).
• deck-review — 리뷰 파이프라인 오케스트레이션: 관점별 서브에이전트 4종을 병렬 dispatch — audience-fit(청중 페르소나 — 페르소나는 파라미터 주입)·story-flow(§8b 9항목)·fact-check(공식 docs 대조 + 공식 vs 실사용 병기)·design-qa(렌더 QA·anti-slop). codex:rescue 설치 시 교차 리뷰 1회 추가. 리뷰어는 관찰+제안만 반환, 수정은 메인 세션이 수정 규율대로.

강의 덱 요청이면 이 스킬과 lecture-deck을 함께 로드하고, 완료 게이트 전 검수는 deck-review로 돌린다.

부록 A. 다른 세션에 규칙 주입

ppt-master·codex-image 등이 설치된 다른 서버/세션에서 이 규약을 한 번에 쓰려면 → assets/injection-prompt.md의 압축 프롬프트(복붙 페이로드)를 대화 맨 앞에 붙인 뒤 실제 요청을 잇는다(위 §1~§4 + 색·이미지·로고·craft의 1:1 압축판).