user-scope-skills/genspark-presentation/SKILL.md
Use when creating presentation outlines for GenSpark PPT generation. Trigger: "발표 자료", "PPT 만들어", "프레젠테이션", "GenSpark", "젠스파크", "발표 준비", "presentation outline"
npx skillsauth add onejaejae/skills genspark-presentationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
발표 주제와 컨텍스트를 받아 GenSpark PPT 생성에 최적화된 산출물을 만듭니다.
사용자에게 다음을 확인합니다 (이미 제공된 항목은 스킵):
반드시 Sparkline 구조를 적용합니다:
발표는 "현재(What is)"와 "가능성(What could be)"을 반복 대비하며, 최종적으로 "새로운 상태(New Bliss)"에 도달하는 구조여야 합니다.
Hook (결과물/성과를 먼저 보여주기) → What is (현실) → What could be (가능성)
→ How (방법) → Evidence (증거/시연) → New Bliss (전환된 세계)
→ Call to Action (첫 행동)
내러티브 아크 설계 시 필수 체크:
| 체크 항목 | 설명 | |-----------|------| | 오프닝 후크 | 핵심 결과물/성과를 직접 보여주는 방식 우선. 수사적 질문은 차선. 목차/자기소개 금지 | | 개인적 전환점 | "왜 이걸 시작했는지" 감정적 동기 포함 | | Before/After 대비 | 최소 2회 이상 명시적 대비 | | Rule of Three | 핵심 메시지는 3개 이하로 구조화 | | 클로징 콜백 | 마지막에 오프닝 후크를 다시 언급하여 내러티브 완결 | | CTA | 청중이 "오늘" 할 수 있는 1가지 행동. trivially easy해야 함 |
슬라이드 수 기준:
슬라이드당 정보 밀도:
기술 개념 설명 규칙:
시연/영상 슬라이드 규칙:
키워드/개요 슬라이드 규칙:
클로징 규칙:
시간 균형 규칙:
청중 다양성 규칙:
금지 패턴:
출력 형식은 반드시 아래 구조를 따릅니다:
## Presentation Spec
- **Persona**: [발표자 역할 정의]
- **Audience**: [청중 특성]
- **Goal**: [발표 목적 - 1문장]
- **Slide Count**: [N]장
- **Duration**: [N]분
- **Tone**: [톤 키워드 3개]
- **Color Palette**: [hex 코드 3-4개]
- **Layout Type**: [grid/single-column/split-screen]
- **Image Style**: [flat illustration/icon/screenshot/photo]
- **Font**: [제목 폰트 굵게, 본문 폰트 보통]
### Slide N: [제목] ([시간])
**핵심 메시지**: [이 슬라이드의 1문장 요약]
**내용**:
- [bullet 1 - 15단어 이내]
- [bullet 2 - 15단어 이내]
- [bullet 3 - 15단어 이내]
**비주얼**: [구체적 레이아웃 지시. "왼쪽 60% 텍스트, 오른쪽 40% 다이어그램" 수준으로]
**발표자 노트**: [실제 말할 내용 - 구어체, 2-4문장]
**전환**: [다음 슬라이드로 넘어가는 브릿지 문장]
전환(Transition) 필수: 모든 슬라이드에 다음 슬라이드로의 논리적 연결 문장을 포함합니다.
산출물 작성 후 아래 체크리스트를 검증하고, 위반 항목이 있으면 수정합니다:
| # | 체크 항목 | 기준 | |---|-----------|------| | 1 | 오프닝 후크 | 결과물/성과 직접 제시 우선. 수사적 질문은 차선. 목차/자기소개 금지 | | 2 | Sparkline 대비 | "현재 vs 가능성" 대비 최소 2회 | | 3 | Rule of Three | 핵심 구조가 3파트 이하 | | 4 | 슬라이드당 단어 수 | 30단어 이하 (제목 제외) | | 5 | 나열 항목 수 | 5개 초과 나열 없음 | | 6 | 전환 문장 | 모든 슬라이드에 전환 존재 | | 7 | CTA 구체성 | "오늘 할 수 있는 1가지"가 명시적 | | 8 | 클로징 콜백 | 오프닝 후크 재언급 | | 9 | 시간 배분 | 총 시간이 발표 시간 ±2분 이내 | | 10 | PAG + 디자인 스펙 | 문서 상단에 완전한 스펙 존재 | | 11 | 기술 개념 Why | 모든 기술 개념 소개에 "왜 이 구분이 필요한지" 포함 | | 12 | 설계 근거 | 도구 조합 소개 시 "왜 이걸 선택했는지" 근거 포함 | | 13 | 클라이맥스 시간 | 핵심 메시지 파트가 전체의 20% 이상 | | 14 | 클로징 슬라이드 | CTA 이후 발표자 정보 슬라이드 존재 | | 15 | 시연 시나리오 | 시연 슬라이드에 구체적 시나리오명 명시 |
| 실수 | 해결 | |------|------| | 목차 슬라이드로 시작 | 후크로 시작, 구조는 자연스럽게 드러나게 | | 후크가 수사적 질문으로 드라마틱 | 핵심 결과물/성과를 직접 보여주는 방식 우선 | | 항목 나열 (5개+) | 대표 3개 선정, 나머지는 "그 외 N개" | | 비주얼 제안이 추상적 | "왼쪽 60% / 오른쪽 40%" 수준으로 구체화 | | 섹션 간 단절 | 전환 브릿지 문장 필수 | | CTA가 여러 단계 | 1가지 행동으로 축소, trivially easy | | 감정적 동기 없이 나열 | "왜 시작했는지" 개인 스토리 포함 | | GenSpark 스펙 누락 | PAG + 색상 hex + 레이아웃 타입 필수 | | 영상 슬라이드 연속 나열 | 2장까지만 연속, 3장째 전에 인사이트 슬라이드 삽입 | | 키워드 슬라이드가 목차화 | 키워드 단어만 보여주고 부가 설명 금지 | | 사용자 강조 파트 누락 | 사용자가 별도 파트로 강조한 내용은 최소 1슬라이드 보장 | | 기술 개념 What만 나열 | Why(왜 이 구분이 필요한지) 반드시 함께 | | 도구 선택 근거 없이 나열 | "왜 Skill인지 / 왜 Sub Agent인지" 설계 이유 포함 | | 클라이맥스가 가장 짧은 파트 | 제목의 핵심 메시지 파트에 충분한 시간 배분 | | 시연에 시나리오 맥락 없음 | 구체적 작업명 명시 (예: "게시글 CRUD API 추가") | | 클로징 후 빈 화면 | 발표자 정보 + QR 슬라이드로 Q&A 지원 |
testing
CLAUDE.md 기반 환경 안전 체크. 작업 시작 전에 프로젝트의 안전 규칙, 컨벤션, 환경 설정을 자동 검증하여 CLEAR/WARNING/BLOCKED 상태를 보고한다. /check가 "변경 후 검증"이라면, /pre-flight는 "작업 전 환경 검증"이다. Use PROACTIVELY before starting work, especially after switching branches, pulling changes, or resuming a session. Also use when explicitly asked: "/pre-flight", "프리플라이트", "환경 체크", "작업 전 점검", "안전 체크", "environment check", "pre-flight check", "시작해도 돼?", "환경 괜찮아?", "safety check", "DB 확인", "설정 확인", "config check".
tools
PR 리뷰 워크플로우와 체크리스트를 제공하는 스킬. "PR 리뷰해줘", "코드 리뷰 해줘", "이 PR 봐줘", "review this PR" 등 PR 리뷰 요청 시 사용. GitHub/GitLab PR URL 또는 로컬 브랜치 diff를 기반으로 체계적이고 일관된 리뷰를 수행. 코드 품질, 안정성/보안, 성능, 테스트, 문서화 관점에서 건설적인 피드백 제공.
documentation
PR review comments를 체계적으로 처리하는 skill. Use when: (1) PR에 동료의 리뷰가 달렸을 때, (2) 여러 리뷰를 한 번에 처리하고 싶을 때, (3) 수정 후 commit 링크가 포함된 reply를 자동으로 추가하고 싶을 때
tools
PR diff를 받아 코드 리뷰 자동 요약을 생성하는 스킬. 핵심 변경점을 3줄로 요약하고, 변경 파일별로 what changed / why it matters / risk level을 정리. Use when: "PR 요약", "diff 요약", "PR 변경점 정리", "코드 변경 요약", "summarize PR", "PR summary", "diff summary", "what changed in this PR", "변경점 요약해줘", "PR 핵심 정리", "리뷰 요약"