umarmsharif/strategy-deck-builder

strategy-deck-builder은(는) 무엇을 하나요?

컨설팅 수준의 덱을 제작하기 위한 스킬로, v5 Bright White & Pine 디자인 시스템을 기반으로 합니다. 밝은 거의 흰색 바탕(FCFCFA), 하나의 깊은 소나무 악센트(12564A), 에스프레소 잉크(1A1A1A) 텍스트, 덱별 디스플레이 폰트(기본 Charter)와 Manrope 본문을 사용하며, 강조는 컬러 바보다는 가는 선과 글꼴 두께로 표현합니다. PPTX 형식을 우선 제공합니다. 이 시스템은 현재 AI 디자인 특유의 패턴(따뜻한 크림색 바탕, 단일 폰트, 한쪽 악센트 바, 눈썹형 라벨, 지나치게 큰 섹션 숫자)을 의도적으로 배제하여 구축되었습니다. 반-슬롭(anti-slop) 자세는 DNA에 내재되어 있습니다. references/anti-slop.md (덱 관련 '슬롭' 카탈로그)와 scripts/deck_qa.js의 정적 검사를 참조하세요.

표준 참조 구현은 assets/reference-build.js에 있습니다. 이는 완전하고 렌더링 테스트된 pptxgenjs 예제입니다. 이 파일을 열어 슬라이드 의도를 패턴 매칭하고, 필요한 블록을 복사하여 사용하세요. 전체 레시피 라이브러리, 헬퍼 함수, 주의 사항 표는 references/build-helpers.md에 있습니다.

트리거 시점

다음과 같은 경우에 이 스킬을 적극적으로 사용하세요:

• 전략 덱, 피치 덱, 컨설팅 결과물, 사례 연구 답변
• 이사회 발표, 경영진 브리핑, 로드맵 덱, 혁신 계획
• 시장 진출 분석, 진단 덱, 권장 사항 덱, 경영진 요약
• 사용자가 "컨설팅 스타일", "MBB 스타일", "McKinsey 스타일", "Bain 스타일", "BCG" 또는 실제 회사 이름을 언급하는 경우
• 사용자가 브랜드 수준의 결과물과 명확한 산문을 원하는 정제된 고객용 덱

워크플로우

다음 단계를 순서대로 따르세요. 사전/사후 반-슬롭 게이트는 협상 불가능합니다.

0단계 — 필수 반-슬롭 사전 점검

이 스킬은 비판적인 독자를 견뎌낼 수 있는 산문을 생성합니다. 슬라이드 카피, 발표자 노트, 논제 라인, 컨텍스트 라인 또는 브리핑 텍스트를 초안하기 전에 references/anti-slop.md를 읽어 언어가 AI가 작성한 것으로 읽히게 만드는 징후에 대해 보정되도록 하십시오.

읽은 후, 다음 제약 조건을 유지하면서 카피를 초안하십시오:

• 특정 작업을 수행하고 방어할 수 있는 경우가 아니라면 em-대시 사용 금지 (페이지당 최대 1개)
• 0개의 필터-버즈워드 어휘 (delve, leverage, robust, seamless, transformative, paradigm, cutting-edge, game-changer 및 anti-slop.md에 있는 나머지 카탈로그)
• 부정적 병렬 구조 금지 ("X가 아니라 Y입니다"; "A뿐만 아니라 B")
• 문장 30단어 미만; 추상적인 것보다 구체적인 명사와 특정 숫자 사용
• 주제 제목이 아닌 행동 중심 제목 사용 (가장 중요한 규칙 — slide_patterns.md 참조)

구조적 장인 정신이 완벽하더라도 산문이 일반적인 컨설팅 AI 스타일로 읽히는 순간 덱의 가치는 떨어집니다. 이 게이트는 이를 방지하기 위해 존재합니다.

1단계 — 덱 브리핑

하나의 슬라이드나 build.js 한 줄을 작성하기 전에, AskUserQuestion (또는 도구를 사용할 수 없는 경우 인라인으로 질문)을 두 번 연속 호출하여 사용하십시오:

호출 1 — 덱 설정:

1. 청중 + 목표 — 누가 이 자료를 읽고, 그들에게서 어떤 결정이나 행동을 원하십니까?
2. 덱 아키텍처 — 진단 / 권장 사항 / 로드맵 / 시장 진출 / 혁신 / 피치 / SCQA / SCR / BLUF / 귀납적 / 이슈 트리 / 연역적. 덱은 단순형(전체에 하나의 아키텍처) 또는 계층형(기본 아키텍처 + 섹션 수준 오버라이드)일 수 있습니다. 계층형인 경우, 각 아키텍처가 실행되는 슬라이드 범위를 결정하고 이를 준수하십시오. 하나의 형태로 축소하지 마십시오.
3. 출력 형식 — pptx / html / md / gamma / briefing (다중 선택, 기본값: pptx)

호출 2 — 브랜드 + 시각적 브리핑:

1. 색상 구성표 — 의도에 따라 질문 (악센트만; 밝은 흰색 바탕 + 차분한 중성색은 고정). 선택지: Pine 12564A (기본값; 차분하고 현대적이며 성장) / Slate blue 1F3A5F (기업, 금융, 신뢰) / Oxblood 6E1423 (격식, 설립) / Client hex (브랜드 고정 작업). 선택한 값은 ACCENT를 설정하고 ACCENT_DK (~70% 휘도) + TINT (~8% 흰색) + TINT_BORDER를 파생합니다. Oxblood의 틴트는 약간 핑크빛으로 기울어져 있습니다. 선택했다면 따뜻하게 조정하십시오. 검증된 구성표 값은 design_system.md §1에 있습니다.
2. 헤더 폰트 — 의도에 따라 질문 (본문은 Manrope 고정; 헤드라인 면만 변경). 선택지: Charter (사설 세리프, 기본값, 어디서나 깔끔하게 렌더링) / Manrope Bold (모던, 올 산스, 세리프 없음) / Palatino (따뜻한 세리프) / Baskerville (격식 있는 세리프; PowerPoint/Google Slides에서 최고, LibreOffice 미리보기에서는 약함). 선택한 값은 DISPLAY를 설정하고, 올 산스 옵션의 경우 DISPLAY_BOLD=true. 과도하게 사용된 목록(Inter, Roboto, Fraunces, Geist, Plus Jakarta, Space Grotesk)에 없는 설치 가능한 폰트라면 괜찮습니다. 올 산스 선택은 단일 계열 권고를 의식적으로 수락하는 것입니다 — references/anti-slop.md 참조.
3. 브랜드 + 콘텐츠 브리핑 — 고객/회사 이름, 발표자, 날짜, 대략적인 슬라이드별 아이디어 (불렛 노트도 괜찮습니다; Claude가 구조화합니다).

스키마는 assets/inputs.example.json에 있습니다. 슬라이드 수는 필수 입력이 아닙니다. 콘텐츠 인터뷰와 아키텍처에 따라 결정됩니다. 경영진 덱은 8-12개, 심층 분석은 15-18개, 종합 덱 합성은 26개 이상을 기본값으로 합니다.

빌드 스크립트를 건드리기 전에 답변에서 inputs.json을 작성하십시오. 입력을 빌드 스크립트와 분리하면 동일한 스크립트가 모든 미래의 덱을 처리할 수 있습니다.

1.5단계 — 콘텐츠 초안 작성 전 필수 고스트 덱

슬라이드 본문, 패널, 점, 간트 행 또는 산문을 채우기 전에: inputs.json의 고스트 덱 버전을 다음과 같이 출력하십시오:

• title_slide만 채워짐
• slides[i].breadcrumb, slides[i].title, slides[i].context만 채워짐 (제목은 행동 제목이어야 함 — slide_patterns.md의 보편적 규칙 참조)
• slides[i].layout 선택됨 (Claude가 아키텍처별로 필터링된 풀에서 결정적으로 선택)
• 모든 slides[i].content 블록은 빈 {} 또는 스텁 필드 이름만으로 남겨짐

고스트 덱을 표로 제시하십시오. 열: # | 섹션 / 아키텍처 | Breadcrumb | 행동 제목 | 레이아웃 | 컨텍스트 라인 (1문장) | 주요 시각 자료 / 데이터 (5초 테스트).

섹션 / 아키텍처 열은 계층 구조를 한눈에 볼 수 있게 만듭니다. 단순형 덱(전체에 하나의 아키텍처)의 경우 모든 행이 동일한 값을 갖습니다 (예: — / 진단). 계층형 덱의 경우 열은 슬라이드가 속한 섹션과 해당 섹션에서 실행되는 아키텍처의 이름을 지정합니다 — 예: 사례 구축 / 귀납적, 시퀀스 플레이 / 로드맵, 마무리 요청 / BLUF. 섹션 경계가 시각적으로 명확해집니다 (인접한 행이 동일한 섹션 레이블을 공유하다가 변경점에서 구분).

그런 다음 AskUserQuestion (또는 인라인으로 질문)을 사용하여 다음 질문을 하십시오:

1. 섹션 간 내러티브 아크가 타당합니까? (모두 승인 / 특정 슬라이드 수정 / 주요 재구성)
2. "그래서 무엇?"을 명시하지 않은 제목이 있습니까? (수정할 슬라이드 번호를 나열하거나 "모두 괜찮음")
3. 슬라이드의 역할에 비추어 잘못된 레이아웃 선택이 있습니까 — 레이아웃이 해당 섹션의 아키텍처와 충돌하는 슬라이드를 포함하여? (슬라이드 번호를 나열하거나 "모두 괜찮음")
4. 컨텍스트 라인 또는 시각적 설명에 중요한 세부 정보가 누락되었습니까? (슬라이드 번호를 나열하거나 "모두 괜찮음")

본문 콘텐츠를 초안하기 전에 명시적인 승인을 기다리십시오. 사용자가 변경을 요청하면 고스트 덱 표를 업데이트하고 다시 질문하십시오. 사용자가 "모두 괜찮음" 또는 이에 상응하는 말을 할 때까지 1.6단계로 진행하지 마십시오.

이 단계가 존재하는 이유: 완성된 슬라이드 10개를 버리는 것보다 슬라이드 제목 10개를 버리는 것이 더 빠릅니다. 피라미드 원리 / SCQA 구조화 논의는 이 저렴한 버전에서 이루어집니다. 이 단계를 건너뛰는 것은 완성된 덱을 재구축해야 하는 가장 흔한 이유이며, 또한 밀도 높은 작업 패턴이 속해야 할 슬라이드에 희소한 히어로 슬라이드가 새어 들어오는 방식이기도 합니다.

고스트 덱 내 패턴 선택: Claude는 아키텍처별로 필터링된 풀(scripts/pattern_filter.js --archetype=<값>)에서 결정적으로 레이아웃을 선택합니다. AskUserQuestion은 두 패턴이 콘텐츠 적합성 측면에서 진정으로 동률이거나 사용자가 이전에 취향을 표현한 경우에만 사용하여 선택을 표면화하십시오. 세분화된 슬라이드별 선택은 덱 당 10-12개의 강제 질문을 생성하지만 비례적인 품질 향상은 없습니다. 이를 피하십시오.

단조로움 방지 (옵트인 선택기): Layout 열을 채울 때 동일한 시각적 관용구(대부분 수평 막대)를 공유하는 인접한 슬라이드가 두 개 이상 있는지 스캔하십시오 (references/slide_patterns.md → "인접한 슬라이드 간 막대 관용구를 다양화" 참조). 실행을 찾으면 직접 처리를 다양화하거나 반복되는 슬라이드에 대한 미리보기 선택기를 제기하십시오: 먼저 권장 레이아웃(레이블 (권장))과 함께 AskUserQuestion을 사용한 다음, 2개의 렌더링 안전 대안을 제시하되, 각각 옵션의 preview 필드에 레이아웃의 짧은 ASCII 미니 목업을 포함시켜 사용자가 패턴 이름이 아닌 그림으로 선택하도록 하십시오. 이는 옵트인 상태를 유지합니다. 감지된 반복, 진정한 동률 또는 사용자의 "어떤 옵션이 있나요?" 요청 시에만 실행되며, 모든 슬라이드에 대해 실행되지 않습니다. 이는 4.5단계 변형 모드의 저렴한 대응물입니다. 사용자가 선택할 때까지 아무것도 구축되지 않습니다.

1.5단계는 사용자가 이미 완전한 inputs.json을 제공했거나 "고스트 덱 건너뛰기"라고 명시적으로 작성한 경우에만 건너뛰십시오. 그렇지 않으면 협상 불가능합니다.

1.6단계 — 슬라이드별 생성 규율 (5단계)

모든 슬라이드에 대해 이 순서로 스키마를 작성하십시오. 앞서 뛰어넘지 마십시오.

1. 메시징 — 먼저 slides[i].title을 작성하십시오. 행동 제목이어야 합니다 ("그래서 무엇?"). 제목을 쓸 수 없다면 슬라이드의 목적을 아직 이해하지 못한 것입니다.
2. 구조 — 제목을 지원하는 카탈로그에서 slides[i].layout을 선택하십시오. 밀도 높은 작업 패턴(진단-세-패널, 우선순위-매트릭스, 단계적-로드맵-간트, 세-열-비교, 폭포-기준-대-목표)을 기본값으로 사용하십시오. 드문 조미료용 패턴(통계-행, 큰-숫자-발견)은 섹션 브리지로만 사용하고, 덱의 대부분으로 사용하지 마십시오.
3. 그래픽 / 주요 시각 자료 — slides[i].content를 채우십시오. 시각 자료는 5초 안에 읽을 수 있어야 합니다. 매트릭스의 경우: 점은 어디에 있습니까? 간트의 경우: 어떤 작업 흐름이 겹칩니까? 폭포의 경우: 어떤 라인 항목이 우세합니까?
4. 지원 — slides[i].context (데이터가 도달하기 전의 한 문장 프레임)와 slides[i].footer_note (출처 + 주의 사항)를 채우십시오. 둘 다 데이터 슬라이드에서는 협상 불가능합니다.
5. 다듬기 — scripts/check_titles.js + 7단계 반-슬롭 사후 점검 + 8단계 비행 확인 전달 게이트에서 처리됩니다. 전달 전에 실행하십시오.

메시징 전에 레이아웃을 선택하는 방식은 희소한 히어로 슬라이드가 새어 들어가는 방식입니다. 레이아웃 전에 시각 자료를 선택하는 방식은 차트가 제목을 지원하지 못하는 방식입니다. 콘텐츠 전에 다듬는 것은 낭비입니다. 순서가 중요합니다.

전체 참조: references/methodology/slide_creation_process.md.

2단계 — 디자인 시스템 + 패턴 읽기

항상 읽기 (모든 빌드에서), 다음 순서로:

1. references/design_system.md — 고정된 팔레트/타이포그래피/해부학. 이유 없이 변경하지 마십시오.
2. references/slide_patterns.md — 마스터 패턴 카탈로그 + 보편적 규칙 (행동 제목, 선택적 색상, 차트 정직성, 막대/열 순서, 레이블 직접, 면적-규모 원, 바닥글 규율, 폭포 관련 규칙).
3. references/build-helpers.md — 팔레트 상수, header()/title()/footer() 헬퍼, 모든 패턴 레시피 (§2.x), 주의 사항 표. 모든 빌드의 구현 참조입니다. assets/reference-build.js는 이를 실행하는 작업 예제입니다.
4. references/methodology/content-interview.md — 콘텐츠 인터뷰 프레임워크 (상황 → 문제 → 가설 → 증거 → 논증 → 답변). 빌드 스크립트를 건드리기 전에 1단계를 실행하십시오.

요청 시 읽기 (트리거가 적용될 때만):

• references/chart-selection-guide.md + references/chart-library/ — 슬라이드에 차트가 필요한 경우. 2.5단계에 의해 구동됩니다. 미리 로드하지 마십시오.
• references/slide-job-to-layout.md — 1.5단계와 4.5단계에서 레이아웃을 선택할 때 패턴 선택을 직관적이 아닌 추적 가능하게 만들기 위해.
• references/raci-guidance.md — RACI 또는 역할 소유권 슬라이드를 구축할 때.

사용자가 매칭할 참조 덱이나 슬라이드를 제공하는 경우, 썸네일에서 레이아웃을, 텍스트에서 섹션 구조를 추출하십시오. 외부 참조는 구조 전용으로 취급하십시오: 어떻게 구축되었는지 연구하고, 단어, 숫자 또는 이미지를 절대 복사하지 마십시오.

2.5단계 — 차트 슬라이드: 차트 라이브러리 + 차트 선택 가이드 참조

슬라이드에 차트가 필요한 경우 (막대, 선, 누적, 이중 패널, 결합 막대/선, 소규모 다중, 폭포, 메코), 즉흥적으로 하지 마십시오. 순차적으로 두 개의 참조를 사용하십시오:

첫째, references/chart-selection-guide.md — 상단의 빠른 선택 표는 슬라이드의 의도된 메시지를 차트 유형에 매핑합니다. 원칙: 차트 유형은 데이터 형태가 아닌 메시지에 맞습니다. 차트별 팁(3D 금지, 라인 레이블 직접, 막대 논리적 순서 등)을 적용하십시오.

...

[원본이 잘렸으므로 여기까지 번역되었습니다.]