| name | tacigent-stage-pitch |
| description | Tacigent Stage 7: Pitch. decision-support artifact를 생성한다. 이것이 파이프라인의 마지막 stage다. |
Stage 7: Pitch
이 스킬은 Tacigent 파이프라인의 **마지막 stage**다.
이 스킬의 모든 작업을 완료하면 **clean exit summary**를 작성한다.
중간에 멈추거나 사용자에게 되묻지 않는다. 끝까지 실행한다.
참조 프로토콜
tacigent-method-first — method framing
tacigent-swarm-critique — swarm/critique loop
tacigent-research — research protocol (anti-generic extensions + refresh)
tacigent-evidence-ladder — evidence 판단
tacigent-readiness-gates — readiness 판정
목적
- 팀이 대표에게 제안하는 decision-support artifact를 생성한다
- generic, template-driven, canned presentation이 아니라 audience와 ask에 맞게 tailored된 decision artifact
- recommendation-first: "이렇게 할 것을 제안합니다"가 먼저 오는 구조
입력
artifacts/problem.md — 선택된 problem
artifacts/solution.md — 선택된 solution
artifacts/design.md — design direction
artifacts/build.md — build 결과
artifacts/marketing.md — marketing 전략
artifacts/launch-cells.json — launch cells
workspace/app/ — 실제 구현된 제품 (참조)
RunSpec.inputs.pitch — 사용자의 pitch 직접 입력 (있으면)
이어가기: 이 stage의 artifact가 이미 일부 존재하면, 존재하는 artifact의 step은 건너뛰고 다음 step부터 이어간다.
실행 흐름
Step 1: Method Framing + Meta-Research (Pitch-Specific)
tacigent-method-first 프로토콜을 따르되, pitch-specific method fields 포함:
selectedPitchMethod — 예: pre-read-first executive memo, objection-first board pitch, evidence-led recommendation
artifactMode — pre-read first / deck first / hybrid
audienceHandling — audience profile 구성 방법
evidenceMappingMethod — claim-to-source mapping 방법
synthesisRule
stopCondition
이후의 refresh, narrative module 조합, slide/pre-read 구성은 선택된 pitch method의 실행으로 취급한다.
artifacts/pitch-method-plan.json으로 기록.
Step 2: Late-Bound Refresh & Audience Frame
-
Audience Profile — 이 피치를 누가 읽는가?
- 기본: 대표/의사결정자
- 사용자가 지정한 audience가 있으면 적용
- pitch는 generic demo deck이 아니라 decision maker가 무엇을 승인해야 하는지가 분명한 executive artifact
-
Decision Frame — 어떤 결정을 해야 하는가?
-
Ask Contract — 구체적으로 무엇을 요청하는가? (승인, 예산, 팀, 일정 등)
Step 3: Anti-Generic Research Extensions
tacigent-research 프로토콜의 query families를 아래로 확장:
| Extension Query Family | 용도 |
|---|
generic_deck_complaints | 양산형 deck 불만 탐지 |
buzzword_without_proof | 근거 없는 buzzword 패턴 탐지 |
slide_fatigue | slide overload 패턴 탐지 |
first_three_slides | 첫 3슬라이드 hooks/failures |
competition_template_failure | 경쟁 슬라이드 template 실패 패턴 |
humanized_executive_copy | 인간적 executive writing 패턴 |
bilingual seed queries:
AI-generated pitch deck, generic startup deck, buzzword-heavy executive presentation
AI 티 나는 PPT, IR덱 망하는 이유, 경쟁 슬라이드 매직 쿼드런트
refresh와 final review는 사실 확인뿐 아니라 template-driven rhetoric과 category-marketing filler를 탐지하는 데도 사용한다.
Step 4: Pre-Read First Draft
**pre-read 첫 문단은 recommendation, rationale, decision ask를 즉시 포함해야 한다.**
summary → details → ask 순서가 아니라, **recommendation-first**.
Step 5: Adaptive Narrative Module 조합
기본 순서 (고정 spine이 아니라 adaptive):
- Executive Summary Card — recommendation + rationale + ask
- Problem — narrow customer, one measurable pain, one trigger/change
- Why Now — timing drivers (fresh hot signal 기반)
- Recommended Plan — solution + product + GTM
- Evidence — claim-to-source mapping
- Risks / Alternatives — honest한 위험 고지 + validation debt
- Ask — 구체적 요청 + next steps
- Appendix — 본문 claim 뒷받침용
Step 6: Swarm Exploration (Pitch-Specific)
tacigent-swarm-critique 프로토콜을 따르되, pitch-specific defaults:
- 기본 exploration swarm: 7
- audience, ask, recommendation spine이 이미 강하게 고정되면 5로 downshift (5 미만 금지)
Step 7: Critique (Pitch-Specific Critics)
Pitch-specific critic roles:
- First-Principles Pruner — 불필요한 slide/section 제거, 과장된 claim 축소
- Evidence Critic — 모든 claim이 source에 매핑되는가? missing source 지적
- Objection Critic — stated audience 기준 likely objection 3개에 대한 방어 가능성 점검
- Anchor-Drift Critic — 사용자의 pitch 입력에서 벗어나지 않았는가
- Counterevidence Critic — "이 제품을 진행하지 말아야 할 이유는?"
5회 critique 모두 mandatory다. downshift 금지.
Step 8: Claim & Evidence Mapping
모든 주요 claim은 **stageOutputs 또는 external source에 매핑**:
| Claim | Source | Status |
|---|
| "[주장]" | [artifacts/problem.md + sourceRefs] | verified/supported/inferred/speculative |
Evidence Rule:
- evidence 없는 과장 표현 금지
AI, 플랫폼, 혁신, 시너지, DX, next-gen 같은 buzzword는 같은 block 안에서 metric, example, operating proof 중 하나로 닫아야 한다
- 주요 수치나 market sizing은 source, date, implication이 같이 보이지 않으면 불충분
- build verification과 모순되는 내용은 자동 canonicalization하지 않는다
- 불확실한 주장은
inferred 또는 speculative로 명시
Step 9: Narrative & Slide Rule
**Opening:**
- narrow customer, one measurable pain, one trigger/change를 포함
Slide Titles:
- section label이 아니라 claim headline —
Problem, Solution, Market 같은 제목만 있으면 fail 후보
One-Job-Per-Slide:
- 각 slide는 one decision 또는 one question에 매핑
경쟁 Slide:
- quadrant, petal, magic-map template를 기본값으로 허용하지 않는다
- 사용하려면 axis, status-quo competitor, non-self-serving comparison logic 필요
Visual:
- slide당 dominant visual 최대 1개
- unrelated decorative image 금지
Copy:
- final copy는 humanization pass를 거쳐 abstract filler, repetitive phrasing, boilerplate, category-marketing language를 줄인다
Step 10: Presentation Limits
- primary deck은 8-12 core slides 또는 이에 준하는 compact 구조
- appendix는 본문 claim 뒷받침용
- deck과 pre-read는 같은 recommendation을 중심으로 정렬
- leave-behind artifact는 silent reading 지원
- live deck은 narration 없이는 성립하지 않는 text dump가 되면 안 됨
Step 11: Anti-Template Check
최종 pitch를 아래 기준으로 평가. 해당되면 revision 필요:
- ❌ 같은 구조와 핵심 문장만 유지한 채 회사 이름만 바꾸면 다른 팀에도 그대로 붙는가?
- ❌ generic pitch template의 빈칸만 채운 느낌인가?
- ❌ 이 제품만의 unique story가 없는가?
- ❌ audience의 구체적 관심사가 반영되지 않았는가?
- ❌ proof 없는 buzzword stack이 반복되는가?
- ❌ template competition slide가 비교 logic 없이 들어가는가?
- ❌ decorative visual은 많지만 decision 정보가 줄어드는가?
- ❌ polished하지만 likely objection에 답하지 못하는가?
Step 12: Live Market Refresh & Contradiction Pass
**build readiness가 `not_ready`인 경우:**
- build의 unresolved issues를 Risks / Alternatives 섹션에 명시한다
- 검증되지 않은 기능에 대한 claim은 `inferred` 또는 `speculative`로 표시한다
- recommendation에 build validation debt를 포함하고, ask에 검증 필요 항목을 명시한다
- pitch 전체를 `needs_validation`으로 표시한다
final canonicalization 직전에:
-
Live Market Refresh — why-now와 market signal을 live refresh
tacigent-research의 refresh mode 사용
- time-sensitive data 업데이트
-
Contradiction Pass — 전체 stage 산출물 간 모순 확인:
- problem target ↔ marketing ICP
- solution value proposition ↔ build result
- pitch claim ↔ 실제 제품/source-backed claims
- 모순 발견 시 수정, 제거, 또는 explicit downgrade 결정
Step 13: Final Review (Non-Blocking)
- decision frame, evidence sufficiency, final ask wording은 human approval로 block하지 않는다
- 대신 stated audience 기준 likely objection 3개에 대한 방어 가능성을 점검
- unresolved weakness가 남으면 explicit downgrade, contradiction note,
needs_validation으로 처리
Step 14: Artifact 생성
Primary: Pre-Read (Markdown)
- recommendation-first
- 15분 내 의사결정 가능한 수준
- 각 section에 evidence reference
Secondary: Pitch Deck (HTML)
index.html 단일 파일 (self-contained)
- 핵심 차트, flow diagram, 스크린샷 포함
- desktop-optimized, modern, clean
Output Review Cycles (5회 필수)
ralph-loop의 OUTPUT-REVIEW-CYCLES 프로토콜을 따른다.
pre-read.md + index.html 작성 후, 5회의 제1원칙 리뷰를 수행한다. Pitch-specific 리뷰 기준:
- 첫 문단이 recommendation + ask를 즉시 전달하는가? — 서론/배경 설명으로 시작하면 삭제
- slide 수를 더 줄일 수 있는가? — 같은 메시지를 전달하면서 slide를 합칠 수 있는지
- 모든 claim이 source에 매핑되어 있는가? — 매핑 없는 claim 삭제 또는 inferred로 표시
- anti-template check 재적용 — 회사 이름만 바꿔도 재사용 가능한 부분 제거
- likely objection 3개에 대한 방어가 충분한가? — 방어가 약하면 보강
Stop Condition
- ask contract, recommendation, major claim mapping 중 하나라도 비면 canonicalization 불가
- unresolved contradiction이 남으면 canonicalization 불가
- 5회 산출물 리뷰가 완료되지 않으면 (review-1~5.md) canonicalization 불가
Readiness
tacigent-readiness-gates 프로토콜을 따른다.
not_ready: ask/recommendation/claim mapping 부재, unresolved contradiction
needs_validation: time-sensitive why-now claim에 refresh record 없음
- provisional: validation debt가 크더라도 explicit downgrade와 carry-forward risk가 기록되면 가능
산출물
artifacts/pitch/pre-read.md — primary decision-support document
artifacts/pitch/index.html — visual pitch artifact (self-contained HTML)
artifacts/pitch-method-plan.json — method plan
Failure Modes
- ❌ pitch method를 고르지 않고 deck outline부터 쓰는 경우
- ❌ "예쁜 소개 자료"로 흘러가는 경우
- ❌ decision ask가 없는 경우
- ❌ why-now와 evidence가 분리된 경우
- ❌ marketing/build와 다른 메시지를 반복하는 경우
- ❌ 고정 8장 구조를 지키느라 실제 의사결정 정보를 희생하는 경우
- ❌ problem보다 solution/how 설명이 길어져 opening tension이 약해지는 경우
- ❌ slide 수/text density가 과해 핵심 ask가 묻히는 경우
- ❌ 회사 이름만 바꾸면 다른 category deck으로 재사용 가능한 경우
- ❌ proof 없는 buzzword stack이 반복되는 경우
완료 후: Clean Exit
pitch 산출물 작성이 완료되면, 전체 run의 **Clean Exit Summary**를 작성한다:
# Tacigent Run Complete 🎉
## Product: [productName]
## 생성된 산출물
- ✅ Intake: artifacts/intake.md
- ✅ Problem: artifacts/problem.md
- ✅ Solution: artifacts/solution.md
- ✅ Design: artifacts/design.md + design-contract.json
- ✅ Build: workspace/app/ + build.md
- ✅ Marketing: artifacts/marketing.md + launch-cells.json
- ✅ Pitch: artifacts/pitch/pre-read.md + pitch/index.html
## 핵심 결과
- Problem: [한 줄 요약]
- Solution: [한 줄 요약]
- Product: [실행 방법]
- GTM: [핵심 channel + first launch cell]
- Ask: [recommendation]
## Validation Debt
- [아직 검증하지 못한 것들]
## Next Steps
- [권장 다음 행동]
이것이 Ralph loop의 정상 종료다. 사용자에게 이 요약을 보여준다.