matzehg/minto-deck

Minto Deck

덱이나 메모는 청중이 제목만으로 논증을 따라갈 수 있는 주장입니다. 이 스킬은 모든 덱과 모든 메모를 답변 우선으로 만들고, 먼저 스토리라인을 구축하여 변경 비용이 적을 때 논증을 승인받으며, 기존 덱과 메모를 동일한 기준으로 검토합니다. 방법론은 references/에 저장되어 렌더링 도구와 독립적이므로, 스킬은 Claude.ai, Cowork, Claude Code 또는 Agent-Skills 호환 호스트에서 동일하게 작동합니다.

세 가지 모드

요청당 정확히 하나의 모드를 선택하고 답변의 첫 줄에 이름을 명시하세요.

• Build (빌드): 사용자가 새 덱, 스토리라인, 고스트 덱, 아직 존재하지 않는 덱의 스피커 노트, 또는 자료를 슬라이드로 재구성하기를 원합니다.
• Memo (메모): 사용자가 답변 우선으로 주장하는 산문을 원합니다: 경영 요약, 브리핑 노트 또는 Vermerk, 이벤트 또는 회의 보고서, 하루 또는 회의의 논제, 결정 메모, 상태 노트, 또는 결론을 먼저 제시해야 하는 요약. 출력은 텍스트(채팅, 문서 또는 파일)이며, 슬라이드가 아닙니다.
• Audit (감사): 사용자가 덱이나 메모(파일, 링크, 붙여넣은 개요, 내보낸 텍스트)를 가지고 있으며 이를 검토, 확인, 비평 또는 평가하기를 원합니다. 사용자가 재작성을 요청하지 않는 한 Audit 모드에서는 내용을 변경하지 마세요. 재작성을 요청하면 먼저 보고한 다음 재작성하세요.

"내 덱을 고쳐줘"와 같은 요청은 Audit 후 수정된 스토리라인에 대한 Build 1단계입니다. 시작하기 전에 그렇게 말하세요. "이 노트를 요약해줘"와 같이 더 이상의 바람이 없는 요청은 일반 요약이며 이 스킬의 범위를 벗어납니다. "핵심 메시지가 먼저 오도록 요약해줘", "오늘의 논제는 무엇인가", "경영 요약을 작성해줘"는 Memo 모드입니다. 메모와 덱이 모두 필요한 경우, Memo를 먼저 실행하세요: 승인된 메모 스토리라인이 고스트 덱의 지배 사상 및 핵심 라인이 됩니다(Memo 모드의 "Build로의 연결" 참조).

언어

답변, 제목, 노트 및 모든 결과물은 브리핑 언어로 작성하세요. 브리핑이 혼합된 경우 한 번 물어보세요. 방법론 용어는 영어로 유지하고, 덱이 독일어인 경우 첫 사용 시 독일어 설명을 추가하세요(예: "Governing Thought (Kernbotschaft)"). references/glossary.md에는 고정된 쌍이 있으므로 프로젝트 간 덱 일관성을 위해 이를 사용하세요.

Build 모드

0단계: 브리핑 계약

단일 제목을 작성하기 전에 아래 항목을 설정하세요. 먼저 요청, 첨부 자료 및 대화 기록에서 가져오세요. 누락되어 스토리라인을 변경할 수 있는 항목에 대해서만 질문하고, 그렇지 않으면 1단계 출력에서 가정을 명시하고 진행하세요. 한 번에 세 개 이상의 질문을 하지 마세요.

1. 청중과 그들의 질문: 회의실에 누가 앉아 있으며, 덱이 끝날 때 그들이 무엇을 이해, 결정 또는 실행해야 하는가.
2. 목적과 덱 유형: 결정 문서, 상태 보고서, 제안 또는 피치, 전문가 발표, 읽기용 덱. references/audit-checklist.md는 유형별 필수 요소를 나열합니다. 유형은 2단계에 포함되어야 할 내용을 결정합니다.
3. 사용자가 이미 가지고 있는 지배 사상(있는 경우). 사용자가 없으면 자료에서 파생하고 파생된 것으로 표시하세요.
4. 설정: 라이브 발표 또는 발표자 없이 읽기. 이는 밀도 모드(스피커 주도 또는 읽기 우선)와 핸드아웃 변형 필요 여부를 결정합니다.
5. 토론 시간을 포함한 기간과 그에 따르는 슬라이드 예산.
6. 자료 및 출처: 존재하는 증거, 누락된 것, 만들어질 수 없는 것. 숫자, 인용문 및 예시는 사용자의 자료에서 가져오거나 명확히 자리 표시자로 표시해야 합니다.
7. 제약 사항: 템플릿, 기업 디자인, 기밀성, 슬라이드 제한, 필수 슬라이드. 템플릿은 assets/templates/에 있으며, 템플릿당 하나의 폴더에 파일과 레이아웃에 대한 간단한 설명이 있습니다. 브리핑이 명명한 템플릿을 선택하거나 여러 개가 적합할 경우 질문하세요. 템플릿은 사용자 또는 고용주의 자산이므로 공개 리포지토리에서 제외하세요.
8. 표기법: 자료에 실적, 계획, 예측, 이전 기간 또는 차이가 포함된 경우, 덱은 기본적으로 IBCS 표기법을 사용합니다. 레지스터에 이를 명시하고 게이트에서 공개 사항으로 "IBCS 표기법 없음"을 나열하여 사용자가 거부할 수 있도록 하세요.

1단계: 고스트 덱

빌드하기 전에 references/minto-pyramid.md 및 references/storyline-ghost-deck.md를 읽으세요. 고스트 덱은 슬라이드 본문이 없는 완전한 논증입니다.

다음 순서로 빌드하세요:

1. 지배 사상을 작성하세요: 청중의 질문에 답하고 합리적인 사람이 동의하지 않을 수 있는 한 문장.
2. SCQA로 서두를 작성하세요. 청중이 이미 공유하지 않는 상황과 복잡성만 유지하세요. 지배 사상이 나타나는 위치를 결정하세요(기본적으로 2번 슬라이드 경영 요약).
3. 핵심 라인을 작성하세요: 지배 사상을 함께 증명하는 3~5개의 주장. 하나의 집합으로 테스트하세요: 동일한 종류의 아이디어, 중복 없음, 함께 충분함, 하나의 논리적 순서.
4. 각 핵심 라인 주장을 지원 슬라이드로 확장하세요. 모든 슬라이드 제목은 하나의 주장을 진술하는 완전한 문장입니다. 동료를 평행 문법으로 그룹화하세요.
5. 마무리를 추가하세요: 지배 사상 재진술, 청중이 결정하는 제안으로서의 결정 또는 다음 단계, 덱 유형에 명시적 요청이 있는 경우 요청.
6. 레지스터를 빌드하세요: 모든 명명된 개체(프로세스, 기관, 역할, 시스템, 옵션, 기준)에 대해 모든 슬라이드에 나타날 정확한 이름, 범주, 정의 및 상태(브리핑 또는 가설에서)를 포함. 각 집합을 하나의 범주와 하나의 명명 패턴으로 테스트하세요. 레지스터는 사용자의 이름, 구성원 및 순서 편집 지점이며, 2단계는 이를 유일한 출처로 사용합니다.
7. 기간에서 타임라인 골격을 도출하고 삭제 우선순위를 표시하세요. 약 20개 슬라이드부터만 섹션 구분자를 사용하고, 더 짧은 덱은 트래커를 사용하세요.
8. 읽기 테스트를 실행하세요: 제목만 위에서 아래로 읽으세요. 논증에 공백, 반복 또는 점프가 있으면 본문이 아닌 제목을 수정하세요.

references/storyline-ghost-deck.md의 고스트 덱 형식을 정확히 출력하세요: 섹션별로 그룹화된 번호 매겨진 제목, 레지스터, 타임라인 골격, 가정, 공개 사항, 자료가 다른 구조를 지원하는 경우 최대 하나의 대안 핵심 라인. 그런 다음 중지하세요. 답변을 승인 질문으로 끝내세요. 사용자가 "덱"을 요청했더라도 동시에 슬라이드, 노트 또는 파일을 생성하지 마세요. 게이트는 방법의 핵심이며, 스토리라인 변경은 지금은 몇 분이 걸리지만 나중에는 몇 시간이 걸립니다. 사용자가 명시적으로 원샷 실행을 요청한 경우, 요청에 따라 게이트를 건너뛰고 있다고 말하고 계속하세요.

사용자가 제목을 편집할 때, 스토리라인의 영향을 받은 부분만 다시 생성하고 읽기 테스트를 다시 실행하세요. 승인된 섹션을 다시 열지 마세요.

표기법 미리보기: 사용자가 IBCS 표기법에 대해 확신이 없으면, 2단계 본격적으로 시작 전에 두 변형으로 차트 슬라이드 하나를 빌드하고 선택하게 하세요. 명시적 요청 시에만 두 표기법으로 두 개의 완전한 덱을 만드세요.

2단계: 전체 덱

승인된 고스트 덱에서만 시작하세요. 먼저 references/stage-2-checklist.md를 읽으세요. 이 페이지는 전달 전에 체크됩니다. 그런 다음 references/consulting-practices.md, references/visual-design.md, references/speaker-notes.md 및 references/timing-qa-handout.md를 읽으세요. 자료에 실적, 계획, 예측, 이전 기간 또는 차이가 포함된 경우 references/ibcs-notation.md도 읽으세요. 읽기 우선 덱 또는 핸드아웃 단계의 경우 references/reading-decks.md를 읽으세요.

다음 순서로 생성하세요:

1. 슬라이드 본문. 슬라이드당 하나의 메시지; 본문은 제목을 증명합니다. 메시지가 만드는 비교에 따라 증거 형식(차트, 표, 카드, 다이어그램, 텍스트)을 선택하세요. consulting-practices.md의 차트 및 표 규칙에 따릅니다. 모든 외부 주장에는 출처 줄이 있어야 하고, 모든 숫자에는 단위, 기간 및 분모가 있어야 합니다. 밀도는 0단계에서 고정된 모드를 따릅니다. 스피커 주도 밀도에서는 구멍을 남기지 않고 슬라이드를 채우도록 유형과 모양을 조정하세요. 결정 문서에서는 권장 옵션의 세부 사항 전에 옵션을 보여주고 제목에서 옵션으로 표시하세요. 모든 개체는 레지스터에서, 레지스터의 이름과 순서로 가져옵니다.
2. 2번 슬라이드의 경영 요약: 고스트 덱(지배 사상, 핵심 라인, 요청)에서 초안 작성; 최종 버전은 다른 모든 슬라이드가 존재하고 숫자가 알려진 후 8단계에서 작성됩니다. visual-design.md 섹션 8의 밀도 모드별 형식.
3. 모든 슬라이드의 스피커 노트를 노트 창에 speaker-notes.md의 구조로 작성: 핵심 포인트, 시작 대사, 발표 트랙, 가리킬 증거, 전환, 시간 예산. 대본이 아닌 프롬프트.
4. 타이밍 계획을 별도의 표로: 슬라이드, 분, 누계, 삭제 우선순위.
5. Q&A 준비를 별도의 문서로: 청중이 물을 질문, 공격하는 대상별로 그룹화, 각각 짧은 답변과 증거를 담은 슬라이드 또는 백업 포인터.
6. 백업 슬라이드는 예상 질문에 답하지만 주요 논증을 담지 않는 증거를 위해. Q&A 문서에서 참조하세요.
7. 핸드아웃 변형 덱이 발표자 없이도 읽힐 경우: 동일한 스토리라인, 읽기 우선 밀도, 슬라이드에 출처 표시, 전달 큐 없음; reading-decks.md 섹션 6의 변환 규칙.
8. 경영 요약, 최종. 완성된 슬라이드에 대해 2번 슬라이드를 다시 작성: 각 굵은 줄은 슬라이드가 증명하는 주장이며, 각 숫자는 해당 슬라이드와 일치합니다.
9. 일관성 점검. 덱 텍스트를 덤프하고 레지스터의 모든 집합을 확인: 모든 슬라이드에서 동일한 구성원, 동일한 이름, 동일한 순서; 나타나거나 사라지는 구성원은 슬라이드나 노트에 명시된 이유가 있어야 합니다. 하위 집합이 해당 우주와 기준을 명명하는지 확인하세요. 고스트 덱의 증거 열을 확인: "누락"으로 표시된 모든 제목은 이제 슬라이드와 전달 노트에 자리 표시자가 있습니다.
10. 전달 전 references/audit-checklist.md에 대한 자체 점검, visual-design.md 섹션 12의 시각적 점검 포함. 차단 항목 수정; 전달 노트에 경고 나열.

렌더링

방법론은 도구 독립적입니다. 파일은 호스트가 제공하는 어떤 것이든 생성되며, 다음 선호도 순서를 따릅니다:

1. 호스트의 네이티브 PowerPoint 기능(Anthropic의 pptx 스킬, PowerPoint 커넥터 또는 이에 상응하는 슬라이드 도구). 텍스트, 표 및 차트를 편집 가능하게 유지하고 노트를 노트 창에 넣기 때문입니다.
2. 이러한 기능이 없을 경우 샌드박스에서 pptxgenjs와 scripts/pptx-helpers.js 사용. 헬퍼는 영역, 그리드, 유형 스케일, 목록 스타일 표, 카드, 셰브론 및 노트 창을 인코딩하므로 빌드 파일은 덱의 내용만 담습니다(scripts/README.md 및 scripts/example-build.js 참조).
3. 파일을 전혀 생성할 수 없을 경우 노트가 포함된 Markdown 개요. 그렇게 말하세요.

편집 가능한 .pptx를 전달하세요. Keynote 및 Google Slides에서 가져올 수 있습니다. Keynote 네이티브 파일을 생성하지 마세요. 차트를 네이티브로 유지하세요. 스피커 노트를 슬라이드의 텍스트 상자가 아닌 노트 창에 넣으세요. 사용자가 템플릿을 제공한 경우 적용하고, 그렇지 않으면 중립을 유지하고 그렇게 말하세요. 전달 전에 덱 텍스트를 덤프하고 제목, 순서, 노트 존재 여부 및 남은 자리 표시자를 확인하세요. 그런 다음 모든 슬라이드를 전체 크기로 렌더링하고 각각 검토하세요: 겹침, 부동 커넥터, 가리키는 대상보다 좁은 상자, 줄바꿈된 키-값 줄, 모인 공백, 스프레드시트 스타일 표. 썸네일로는 이러한 문제를 볼 수 없습니다.

Memo 모드

시작하기 전에 references/memo-format.md 및 references/minto-pyramid.md를 읽으세요. 메모는 덱과 동일한 피라미드를 산문으로 평탄화한 것입니다: 지배 사상이 먼저 나오고, 섹션 제목이 핵심 라인 주장이며, 각 단락은 해당 제목을 증명합니다. 두 단계, 하나의 가벼운 게이트.

0단계: 브리핑

요청, 자료 및 대화에서 아래 항목을 가져오세요. 스토리라인을 변경할 수 있는 누락된 항목에 대해서만 질문하고, 한 번에 최대 세 개의 질문을 하세요.

1. 청중과 그들의 질문: 누가 이것을 읽고, 그들이 이후 무엇을 이해, 결정 또는 실행해야 하는가. 혼합 청중(내부 및 외부 독자)은 내부 참조 밀도를 낮추고 귀속 기준을 높입니다.
2. 메모 유형: 경영 요약, 브리핑 노트 (Vermerk), 이벤트 또는 회의 보고서, 결정 메모, 상태 노트. memo-format.md는 유형별 필수 요소를 나열합니다.
3. 사용자가 이미 가지고 있는 지배 사상. 없으면 자료에서 파생하고 파생된 것으로 표시하세요. 게이트는 사용자가 이를 교체할 수 있도록 존재합니다.
4. 분량 예산 (단어 또는 페이지) 및 대상: 채팅 답변, 문서, 파일.
5. 자료 및 출처: 사용할 수 있는 것, 만들어서는 안 되는 것, 진술이 어떻게 귀속되는지. 발표 또는 회의에 대한 보고서의 경우, 발표자가 이름으로, 역할로, 또는 전혀 명명되지 않는지 결정하세요 (memo-format.md 섹션 5).
6. 덱이 뒤따르는지 여부. 예인 경우, 스토리라인이 이전될 수 있도록 빌드하세요.

1단계: 스토리라인

memo-format.md 섹션 2의 형식으로 전달하세요: 한 문장의 지배 사상; 네 줄의 SCQA로 서두, 상황과 복잡성 각각 한 문장, 복잡성이 제기하는 질문, 지배 사상을 그대로 답변으로 하여 독자가 게이트에서 답변이 질문에 답하는지 확인할 수 있도록; 각각 증거 표시(사용 가능, 누락 또는 자리 표시자, 출처)가 있는 완전한 문장의 3~5개 주장 핵심 라인, 출처 자료의 순서가 아닌 주제 또는 논증 순서; 순서와 그 기준; 출처 간 불일치가 있는 위치와 어떤 주장 아래에서 논증될지; 메모 유형에 해당 요소가 있을 경우 메모가 독자에게 무엇을 제안하는지; 귀속 설정; 가정과 공개 사항; 메모가 프로세스, 기관, 역할, 시스템 또는 옵션을 명명하여 일관성을 유지해야 할 경우 짧은 레지스터, "집합" 줄로 각 집합을 하나의 복수 명사로 명명하고 구성원을 고정 순서로 나열(복수 명사 테스트: 연구소는 프로세스 집합에 속하지 않습니다). 핵심 라인에 대해 읽기 테스트를 실행하세요. 하나의 승인 질문으로 끝내고 중지하세요. 예외: 사용자가 원샷 실행을 요청했거나, 메모가 덱과 함께 가고 덱 스토리라인이 이미 승인된 경우(이 경우 Memo 1단계는 승인된 스토리라인을 적응시키고 게이트를 건너뜁니다).

2단계: 산문

승인된 스토리라인에서만 시작하세요. memo-format.md의 구조를 사용하고 consulting-practices.md의 증거 규칙을 적용하세요(인용문, 예시, 표, 출처 줄). 출처 자료의 순서가 아닌 스토리라인의 순서와 그룹화를 따르세요. 레지스터가 있는 경우 모든 명명된 개체에 일관되게 사용하세요. 모든 단락은 해당 제목을 증명합니다; 스토리라인의 주장을 재진술하는 단락이 없어야 합니다. 길이는 0단계 예산에 맞추세요. 대상(채팅, 문서, 파일)으로 전달하고, 덱이 뒤따르는 경우 "Build로의 연결"을 추가하세요.

Build로의 연결

메모가 완료되고 덱이 승인되거나 요청된 경우: "다음은 덱 스토리라인입니다"라고 말하고, 메모의 지배 사상을 고스트 덱의 지배 사상으로, 메모의 SCQA 서두를 서두로, 메모의 핵심 라인 주장을 덱의 핵심 라인으로 사용하여 Build 1단계를 즉시 작성하세요. 스토리라인 후 "이 스토리라인을 승인하면 2단계를 빌드하겠습니다"라고 말하세요. 그런 다음 중지하세요.

Audit 모드

references/audit-checklist.md를 읽은 후에만 시작하세요. 파일, 링크, 붙여넣은 개요 또는 내보낸 텍스트를 허용합니다. 텍스트를 사용할 수 없으면 요청하세요. 덱인 경우, 각 슬라이드 제목을 추출하세요(텍스트 내보내기, 복사-붙여넣기, 스크린샷을 텍스트로, 또는 덱을 열지 않고 사용자가 제공한 목록). 노트가 제공된 경우만 노트를 포함하세요. 메모인 경우, 제목(있는 경우), 각 섹션의 첫 번째와 마지막 문장을 추출하고 전체 텍스트를 참조로 유지하세요.

다음을 보고하세요:

1. 논증 구조(피라미드): 지배 사상이 청중의 질문에 답하는 한 문장인가? SCQA 서두가 상황을 설정하고, 복잡성을 도입하며, 그로부터 질문을 제기하며, 답변이 지배 사상인가? 핵심 라인 주장이 동일한 종류(모든 권장 사항, 모든 이유 등)이며, 함께 지배 사상을 증명하고, 중복되지 않으며, 명확한 순서가 있는가? 각 주장에 증거(출처 포함 숫자, 인용문, 예시)가 있는가? 제목이 완전한 문장이며 논증을 진술하는가? 요약 및 요청이 효율적인가? 모든 슬라이드가 제목을 증명하는가?(본문이 제목이 아닌 다른 것을 증명할 때마다 주의). 크로스 참조: 첫 번째, 두 번째 및 마지막 슬라이드가 고스트 덱과 일치하는가?
2. 요소(감사 체크리스트): 덱 유형에 대한 필수 요소가 존재하는가?(결정 문서에는 옵션, 기준, 권장 사항이 있어야 하며, 진행 보고서에는 이전 기간이 있어야 합니다). 각각에 대해 누락, 불완전, 깨짐, 좋음을 표시하고 관련 슬라이드를 참조하세요.
3. 약한 주장(강도): 주장이 검증할 수 없는가?(예: 출처가 없거나, '우리의 접근 방식이 최고입니다'가 증거 없이). 도전할 수 있는가?(분명한 반대 의견을 무시함). 너무 광범위한가?(명확성을 위한 하위 주장이 없음). 가정을 숨기는가?(데이터가 부족한 곳을 숫자가 채움). 각 약한 주장에 대해 재작성을 제안하되, 감사 보고서 후에만 제안하고 적용하지는 마세요.
4. 누락된 것: 청중이 물을 질문, 덱이 답변하지 않는 질문, 결정에 필요한 증거, 필수 슬라이드(타이틀, 목차, 용어 설명, 출처?), 백업에 대한 참조(백업이 있든 없든, 그들을 위한 슬라이드가 있든 없든 질문이 있는 경우). 각 누락에 대해 '백업 필요', '답변 필요', '슬라이드 추가' 등 영향 심각도.
5. 시각적 및 서식(전달 전 확인): 스피커 노트가 슬라이드마다 존재하는가? 수동? 스피커 주도 덱의 경우 노트가 입증할 증거를 말하는가? 읽기 우선 덱의 경우 출처가 슬라이드에 있는가? 밀도가 모드와 일치하는가?(스피커 주도는 얇음, 읽기 우선은 조밀함). 차트가 올바른 비교 유형을 사용하는가? 표가 데이터를 저장하는 것이 아니라 메시지를 진술하는가? 슬라이드에 구멍, 겹침, 너무 좁은 상자, 플로팅 커넥터, 감싸진 키-값 줄이 있는가? 슬라이드가 레지스터를 따르는가?

사용자가 재작성을 요청할 때만 제안을 적용하세요. 감사 보고서에 "재작성" 섹션을 추가하여 각 변경 사항을 문제에 연결하세요. 보고서 순서: 구조, 요소, 약한 주장, 누락, 시각적. 각 항목을 "좋음/문제/심각"으로 표시하고, 문제에 대해 "근거: ..."를 작성하고, 필요한 경우 "제안: ..."를 추가하세요.

재작성 없이 감사 보고서를 전달하는 것은 괜찮습니다. 사용자가 "내 덱 수정"을 요청하면 Audit(보고서) 후 Build 1단계를 실행하세요(보고된 문제를 해결하기 위해 제목이 업데이트된 고스트 덱). 사용자가 "까다롭게 검토"를 요청하면 문제를 가장 까다로운 표준과 비교하고('이 슬라이드가 증명하는 제목' 테스트를 통과하지 못하는 모든 슬라이드에 플래그 지정), 그렇지 않으면 상식 기준을 사용하세요.

일반 규칙

• 자료 사용: 숫자, 인용문 및 예시는 사용자의 자료에서 가져오거나(첨부 파일, 대화, 회사 파일) 명확히 자리 표시자로 표시하세요. 없는 것을 발명하지 마세요. "자리 표시자: 2024년 수익"이라고 말하고 계속하세요.
• 한 번에 한 가지: 메모와 덱이 모두 필요한 경우, 메모를 먼저 실행하고 게이트를 통해 덱으로 연결하세요. 감사와 재작성이 모두 필요한 경우, 감사를 먼저 실행하고 게이트를 통해 재작성으로 연결하세요.
• 외부 도구 의존성 없음: 방법론은 references/에 있습니다. 렌더링은 호스트가 제공하는 도구를 사용합니다. 렌더링 단계에 대해서는 발명하지 마세요. 작성한 제목이 적용 가능하다면 pptxgenjs 스크립트를 참조할 수 있지만 가정하지 마세요.
• 에이전트 간 호환성: 이 스킬은 Anthropic의 에이전트 스킬 형식을 준수하며 SKILL.md 및 references/에 저장됩니다. Claude.ai, Cowork, Claude Code 등 이 형식을 따르는 모든 호스트에서 작동합니다.

참조

references/ 폴더에는 이 스킬의 방법론이 포함되어 있습니다:

• minto-pyramid.md: 피라미드 원리(MECE, SCQA, 지배 사상)
• storyline-ghost-deck.md: 고스트 덱 형식 및 규칙
• stage-2-checklist.md: 2단계 전달 전 체크리스트
• consulting-practices.md: 증거, 차트, 표, 인용문
• visual-design.md: 레이아웃, 유형, 그리드, 색상
• speaker-notes.md: 스피커 노트 형식
• timing-qa-handout.md: 타이밍, Q&A, 핸드아웃
• reading-decks.md: 읽기 우선 덱
• ibcs-notation.md: IBCS 표기법
• audit-checklist.md: 감사 체크리스트
• memo-format.md: 메모 구조 및 규칙
• glossary.md: 용어집(영어-독일어 쌍)

assets/templates/에는 사용자 템플릿이 포함됩니다(공개 리포지토리에서 유지). scripts/에는 렌더링을 위한 pptx-helpers.js 및 예시가 포함됩니다.