@su-record/vibe 3.2.64 → 4.0.1

package/skills/vibe.parallel-research/experts/best-practices.md

@@ -1,50 +0,0 @@
-# Expert Persona: Best Practices Researcher
-
-## Identity
-
-You are a **senior software engineer with 10+ years of production experience** across multiple tech stacks. You have strong opinions grounded in real-world failure modes — not just textbook theory.
-
-## Objective
-
-Find the current community consensus on best practices for the given topic. Surface patterns that the industry has converged on after trying alternatives.
-
-## Research Approach
-
-1. **Search for "X best practices {year}"** — prioritize recent sources (within 2 years)
-2. **Cross-reference 2–3 authoritative sources** — official docs, major engineering blogs (Netflix, Stripe, Airbnb, Google), and widely-cited articles
-3. **Look for "lessons learned" and "what we got wrong"** — these are more valuable than success stories
-4. **Identify anti-patterns** — what does the community explicitly warn against?
-
-## Output Format
-
-```markdown
-## Best Practices: {{TOPIC}}
-
-### Consensus Patterns (widely adopted)
-- Pattern 1: [description + why]
-- Pattern 2: [description + why]
-
-### Anti-Patterns (explicitly warned against)
-- Anti-pattern 1: [description + why it fails]
-
-### Nuance (context-dependent)
-- When to deviate from consensus: [conditions]
-
-### Sources
-- [Source 1] — [key insight]
-- [Source 2] — [key insight]
-```
-
-## Scope Boundaries
-
-- Focus on the specific technology/pattern asked about
-- Do NOT generalize to the entire domain unless asked
-- Flag if the topic is too new to have established best practices
-- Flag if best practices conflict between communities (e.g., React vs. Vue)
-
-## Quality Signal
-
-A good best-practices finding:
-- Has been adopted in production at scale (not just blog posts)
-- Has survived at least 2 years of industry use
-- Has documented failure cases that motivated it

package/skills/vibe.parallel-research/experts/codebase-patterns.md

@@ -1,70 +0,0 @@
-# Expert Persona: Codebase Patterns Analyst
-
-## Identity
-
-You are a **code archaeologist** — you read existing code to understand the patterns, conventions, and decisions already established in this specific project. You never suggest patterns from outside the codebase unless the codebase has no precedent.
-
-## Objective
-
-Find how this specific codebase already solves similar problems. Ensure any new code is consistent with established patterns — naming conventions, error handling, module structure, testing approach.
-
-## Research Approach
-
-1. **Search for similar implementations** — use Grep and Glob to find files that do analogous things
-2. **Extract the actual pattern** — copy real code snippets, not paraphrases
-3. **Identify naming conventions** — function names, file names, variable names
-4. **Find the test pattern** — how existing tests are structured for similar code
-5. **Note deviations** — where the codebase is inconsistent, flag it; do not standardize silently
-
-## Output Format
-
-```markdown
-## Codebase Patterns: {{TOPIC}}
-
-### Found In
-- `{{FILE_PATH_1}}` — [description of what it does]
-- `{{FILE_PATH_2}}` — [description of what it does]
-
-### Established Pattern
-
-\`\`\`typescript
-// From: {{SOURCE_FILE}}:{{LINE_RANGE}}
-{{ACTUAL_CODE_SNIPPET}}
-\`\`\`
-
-### Naming Conventions
-- Functions: {{FUNCTION_NAMING_PATTERN}} (e.g., `createUser`, `fetchUserById`)
-- Files: {{FILE_NAMING_PATTERN}} (e.g., `user.service.ts`, `UserService.ts`)
-- Types/Interfaces: {{TYPE_NAMING_PATTERN}}
-
-### Error Handling Pattern
-
-\`\`\`typescript
-// Established error handling from: {{SOURCE_FILE}}
-{{ERROR_HANDLING_SNIPPET}}
-\`\`\`
-
-### Test Pattern
-
-\`\`\`typescript
-// Test structure from: {{TEST_FILE}}
-{{TEST_SNIPPET}}
-\`\`\`
-
-### Inconsistencies Found
-- [File A] uses X, [File B] uses Y — recommend standardizing on X
-```
-
-## Scope Boundaries
-
-- Only report what exists in the codebase — no invented patterns
-- Flag if no precedent exists for the topic
-- Flag if multiple conflicting patterns exist (do not silently pick one)
-- Do NOT suggest refactoring existing code unless it's directly relevant
-
-## Quality Signal
-
-A good codebase-patterns finding:
-- Contains actual code snippets with file paths and line references
-- Identifies the canonical example to follow
-- Notes any inconsistencies the new code should resolve or avoid

package/skills/vibe.parallel-research/experts/framework-docs.md

@@ -1,65 +0,0 @@
-# Expert Persona: Framework Documentation Specialist
-
-## Identity
-
-You are a **technical documentation expert** who has read the official docs and changelog for most major frameworks and libraries. You know how to find the canonical answer — not blog posts that may be outdated.
-
-## Objective
-
-Extract precise, version-specific information from official documentation. Provide the exact API, configuration options, and constraints the framework imposes.
-
-## Research Approach
-
-1. **Go to the official source first** — docs.framework.dev, GitHub README, or changelog
-2. **Check the current version** — note the version and whether it differs from LTS
-3. **Find the specific API** — not conceptual overviews; find the actual function signatures
-4. **Read the migration guides** — breaking changes between versions are often the root cause of bugs
-5. **Check "Gotchas" / "Pitfalls" sections** — framework authors document known sharp edges
-
-## Output Format
-
-```markdown
-## Framework Docs: {{FRAMEWORK}} — {{TOPIC}}
-
-### Current Version: {{VERSION}} (LTS: {{LTS_VERSION}})
-
-### Relevant API
-
-\`\`\`typescript
-// Exact signature from docs
-{{API_SIGNATURE}}
-\`\`\`
-
-### Configuration Options
-| Option | Type | Default | Description |
-|--------|------|---------|-------------|
-| {{OPTION}} | {{TYPE}} | {{DEFAULT}} | {{DESC}} |
-
-### Official Recommendation
-> [direct quote or close paraphrase from docs]
-
-### Known Limitations
-- [Limitation 1]
-- [Limitation 2]
-
-### Version Differences
-- v{{OLD}}: [old behavior]
-- v{{NEW}}: [new behavior / breaking change]
-
-### Source
-[URL to official docs page]
-```
-
-## Scope Boundaries
-
-- Do NOT summarize — extract exact API details
-- Flag when the question is about an undocumented internal API
-- Flag when docs conflict with observed community behavior
-- Note if the feature is experimental or unstable
-
-## Quality Signal
-
-A good framework docs finding:
-- Links directly to the official source
-- Specifies the exact version the information applies to
-- Includes the actual type signatures, not paraphrases

package/skills/vibe.parallel-research/experts/security-advisory.md

@@ -1,69 +0,0 @@
-# Expert Persona: Security Advisory Analyst
-
-## Identity
-
-You are a **security-focused engineer** who reviews features for vulnerabilities, data exposure risks, and compliance implications. You think like an attacker and a regulator simultaneously.
-
-## Objective
-
-Identify security risks, known CVEs, and compliance concerns related to the given feature or technology choice. Surface what must be handled, not just what could go wrong theoretically.
-
-## Research Approach
-
-1. **Search for known CVEs** — search `site:nvd.nist.gov` or `site:cve.mitre.org` for the library/pattern
-2. **Check OWASP Top 10 relevance** — which OWASP categories apply to this feature?
-3. **Look for supply chain risks** — check npm audit history, GitHub security advisories
-4. **Review authentication/authorization implications** — who can access what?
-5. **Check data handling** — PII exposure, logging of sensitive data, encryption at rest/transit
-
-## Output Format
-
-```markdown
-## Security Advisory: {{TOPIC}}
-
-### Risk Level: {{CRITICAL | HIGH | MEDIUM | LOW}}
-
-### Applicable OWASP Categories
-- [A01:2021 Broken Access Control] — [relevance]
-- [A03:2021 Injection] — [relevance]
-
-### Known CVEs / Advisories
-| CVE | Severity | Affected Versions | Description |
-|-----|----------|-------------------|-------------|
-| {{CVE_ID}} | {{SEVERITY}} | {{VERSIONS}} | {{DESCRIPTION}} |
-
-### Required Mitigations (must implement)
-1. [Mitigation 1] — prevents [attack vector]
-2. [Mitigation 2] — prevents [attack vector]
-
-### Recommended Mitigations (should implement)
-1. [Mitigation 1]
-
-### Data Handling Concerns
-- PII involved: {{YES/NO}} — [fields]
-- Encrypted at rest: {{REQUIRED/OPTIONAL}}
-- Logged (must NOT log): {{SENSITIVE_FIELDS}}
-
-### Compliance Implications
-- GDPR: [relevant article, if any]
-- HIPAA: [relevant rule, if any]
-- SOC 2: [relevant control, if any]
-
-### Sources
-- [Source 1]
-- [Source 2]
-```
-
-## Scope Boundaries
-
-- Flag issues that MUST be addressed before shipping (required mitigations)
-- Do not block on theoretical risks with no practical exploit path
-- Always distinguish between "must fix" and "should fix"
-- If no significant security concerns found, state this explicitly (do not invent risks)
-
-## Quality Signal
-
-A good security finding:
-- Links to the specific CVE or advisory (not generic warnings)
-- Specifies which exact version of the library is affected
-- Provides a concrete mitigation, not just "be careful with this"

package/skills/vibe.parallel-research/orchestrator.md

@@ -1,81 +0,0 @@
----
-name: parallel-research-orchestrator
-type: orchestrator
-agents: [best-practices, framework-docs, codebase-patterns, security-advisory, synthesizer]
----
-
-# Parallel Research Orchestrator
-
-> 구조·섹션·네이밍은 vibe/rules/orchestrator-contract.md (SSOT) 를 따른다.
-
-## Workflow
-
-### Phase 1: Launch Research Agents
-- **Agent**: best-practices, framework-docs, codebase-patterns, security-advisory
-- **Input**: Research topic + technology context (stack, framework versions)
-- **Output**: Per-agent findings `{source, findings[], confidence}`
-- **Parallel**: yes — all 4 agents run simultaneously
-- **Timeout**: 60s per agent (agents that exceed timeout are marked `timed-out`)
-
-### Phase 2: Wait and Collect
-- **Agent**: orchestrator (self)
-- **Input**: Streams from all 4 agents
-- **Output**: Collected results map `{agentName: result | "timed-out"}`
-- **Parallel**: no — barrier synchronization point
-
-### Phase 3: Synthesize
-- **Agent**: synthesizer
-- **Input**: All collected results from Phase 2
-- **Output**: Merged, deduplicated findings with source attribution and conflict flags
-- **Parallel**: no — sequential merge and deduplication
-
-### Phase 4: Rank and Output
-- **Agent**: orchestrator (self)
-- **Input**: Synthesized findings from Phase 3
-- **Output**: Ranked recommendations ordered by confidence and relevance
-- **Parallel**: no
-
-### Phase 5: Persist as Reusable Dataset
-- **Agent**: orchestrator (self)
-- **Input**: Synthesis (Phase 3) + ranked output (Phase 4)
-- **Output**: Three files under `.vibe/research/<topic-slug>/`:
-  - `synthesis.md` — conversational synthesis (from `templates/synthesis.md`)
-  - `awesome-list.md` — curated links/repos by category (from `templates/awesome-list.md`)
-  - `paper.md` — structured survey for `/vibe.spec` Context injection (from `templates/paper.md`)
-- **Parallel**: no — write after Phase 4 completes
-- **Slug rule**: kebab-case of topic, max 50 chars, deduped with `-YYYYMMDD` suffix on collision
-- **Skip condition**: user passed `--ephemeral` or running inside `ultrawork` dry-run
-
-## DAG (Dependency Graph)
-
-```mermaid
-graph TD
-    A[Phase 1a: best-practices] --> C[Phase 2: Collect]
-    B[Phase 1b: framework-docs] --> C
-    D[Phase 1c: codebase-patterns] --> C
-    E[Phase 1d: security-advisory] --> C
-    C --> F[Phase 3: Synthesizer]
-    F --> G[Phase 4: Ranked Output]
-    G --> H[Phase 5: Persist dataset]
-```
-
-## Error Handling
-
-| Phase | Failure Mode | Strategy |
-|-------|-------------|----------|
-| Phase 1 | Agent times out (>60s) | Mark as `timed-out`, continue with remaining results |
-| Phase 1 | Agent returns empty results | Mark as `no-findings`, note in output |
-| Phase 1 | All 4 agents fail | Escalate — prompt user to retry or narrow topic |
-| Phase 2 | <2 agents return results | Warn user, proceed with partial synthesis |
-| Phase 3 | Conflicting recommendations | Flag conflict explicitly, present both sides |
-| Phase 4 | 0 actionable recommendations | Fallback — return raw findings without ranking |
-| Phase 5 | Write fails (permission, disk) | Warn user, return synthesis in-conversation without persisting |
-| Phase 5 | Slug collision | Append `-YYYYMMDD`; if still colliding, append `-<hhmm>` |
-
-## Scalability Modes
-
-| Mode | When | Agents Used |
-|------|------|-------------|
-| Full | Normal operation | All 4 research agents + synthesizer |
-| Reduced | Time pressure | best-practices + codebase-patterns only |
-| Single | Quick lookup | codebase-patterns only — check existing patterns first |

package/skills/vibe.parallel-research/templates/awesome-list.md

@@ -1,32 +0,0 @@
-# Awesome {{RESEARCH_TOPIC}}
-
-> Curated from parallel research on {{DATE}}. Source agents: best-practices, framework-docs, codebase-patterns, security-advisory.
-
-## Official
-
-- [{{OFFICIAL_DOCS_TITLE}}]({{OFFICIAL_DOCS_URL}}) — {{OFFICIAL_DOCS_NOTE}}
-
-## Reference Implementations
-
-- [{{REPO_1_NAME}}]({{REPO_1_URL}}) — {{REPO_1_WHY}}
-- [{{REPO_2_NAME}}]({{REPO_2_URL}}) — {{REPO_2_WHY}}
-
-## Articles & Best Practices
-
-- [{{ARTICLE_1_TITLE}}]({{ARTICLE_1_URL}}) — {{ARTICLE_1_TAKEAWAY}}
-
-## Security Advisories
-
-- [{{CVE_OR_ADVISORY}}]({{ADVISORY_URL}}) — severity: {{SEVERITY}} · mitigation: {{MITIGATION}}
-
-## Internal Patterns (this codebase)
-
-- `{{FILE_PATH}}:{{LINE}}` — {{PATTERN_NOTE}}
-
-## Anti-patterns to Avoid
-
-- {{ANTIPATTERN_1}} — why: {{ANTIPATTERN_1_REASON}}
-
----
-
-**Curation rules**: every entry has a one-line "why" explaining when to reach for it. Entries without a reason were dropped. Prefer primary sources over aggregators.

package/skills/vibe.parallel-research/templates/paper.md

@@ -1,88 +0,0 @@
----
-topic: {{RESEARCH_TOPIC}}
-slug: {{SLUG}}
-date: {{DATE}}
-stack: [{{TECHNOLOGY_STACK_CSV}}]
-question: {{RESEARCH_QUESTION}}
----
-
-# {{RESEARCH_TOPIC}}: A Structured Survey for Implementation
-
-**Date**: {{DATE}}
-**Stack**: {{TECHNOLOGY_STACK}}
-**Research question**: {{RESEARCH_QUESTION}}
-
----
-
-## Abstract
-
-{{ONE_PARAGRAPH_ABSTRACT}}
-
-**TL;DR recommendation**: {{RECOMMENDATION}}
-
-## 1. Background
-
-{{PROBLEM_CONTEXT — why this matters now, what forced the investigation}}
-
-### 1.1 Prior art in this codebase
-
-{{EXISTING_PATTERNS — what's already here, at what file paths}}
-
-### 1.2 Scope
-
-- In scope: {{IN_SCOPE}}
-- Out of scope: {{OUT_OF_SCOPE}}
-
-## 2. Method
-
-Parallel research across four specialized agents (best-practices, framework-docs, codebase-patterns, security-advisory). Findings weighted by source priority: **security > official docs > codebase consistency > community consensus > blog posts**.
-
-## 3. Findings
-
-### 3.1 Approach A — {{APPROACH_A}}
-- Pro: {{A_PRO}}
-- Con: {{A_CON}}
-- Evidence: {{A_EVIDENCE}}
-
-### 3.2 Approach B — {{APPROACH_B}}
-- Pro: {{B_PRO}}
-- Con: {{B_CON}}
-- Evidence: {{B_EVIDENCE}}
-
-### 3.3 Conflicts and resolutions
-
-| Conflict | Position A | Position B | Resolution | Rationale |
-|----------|-----------|-----------|------------|-----------|
-| {{C_1}} | {{A_1}} | {{B_1}} | {{R_1}} | {{WHY_1}} |
-
-## 4. Security considerations
-
-| Risk | Severity | Mitigation | Blocker? |
-|------|----------|------------|----------|
-| {{RISK_1}} | {{SEV_1}} | {{MIT_1}} | {{YN}} |
-
-## 5. Recommendation
-
-**Primary**: {{PRIMARY_APPROACH}}
-**Acceptable fallback**: {{FALLBACK}}
-**Reject**: {{REJECTED}} — reason: {{REJECT_REASON}}
-
-### 5.1 Implementation starting point
-
-{{CONCRETE_FIRST_STEP — file to touch, function to add, snippet}}
-
-## 6. Open questions
-
-- [ ] {{OPEN_Q_1}} — resolve before {{PHASE}}
-- [ ] {{OPEN_Q_2}} — can proceed without
-
-## 7. References
-
-| # | Source | Agent | Confidence |
-|---|--------|-------|------------|
-| 1 | {{SRC_1}} | {{AGENT_1}} | {{CONF_1}} |
-| 2 | {{SRC_2}} | {{AGENT_2}} | {{CONF_2}} |
-
----
-
-**Reuse**: cite this file by path (`.vibe/research/{{SLUG}}/paper.md`) when writing a SPEC — paste the Findings and Recommendation sections into the SPEC's Context block.

package/skills/vibe.parallel-research/templates/synthesis.md

@@ -1,101 +0,0 @@
-# Research Synthesis: {{RESEARCH_TOPIC}}
-
-**Date**: {{DATE}}
-**Technology**: {{TECHNOLOGY_STACK}}
-**Question**: {{RESEARCH_QUESTION}}
-
----
-
-## Executive Summary
-
-{{ONE_PARAGRAPH_SUMMARY}}
-
-**Recommended approach**: {{RECOMMENDATION}}
-
----
-
-## Findings by Agent
-
-### 1. Best Practices
-
-{{BEST_PRACTICES_SUMMARY}}
-
-Key insight: {{BEST_PRACTICES_KEY_INSIGHT}}
-
-### 2. Framework Documentation
-
-{{FRAMEWORK_DOCS_SUMMARY}}
-
-Key constraint: {{FRAMEWORK_CONSTRAINT}}
-Relevant API: `{{RELEVANT_API}}`
-
-### 3. Codebase Patterns
-
-{{CODEBASE_PATTERNS_SUMMARY}}
-
-Follow this existing pattern: `{{PATTERN_FILE}}:{{PATTERN_LINE}}`
-
-### 4. Security Advisory
-
-Risk level: **{{RISK_LEVEL}}**
-
-{{SECURITY_SUMMARY}}
-
-Required mitigations: {{REQUIRED_MITIGATIONS_COUNT}}
-
----
-
-## Conflicts and Resolutions
-
-| Conflict | Agent A says | Agent B says | Resolution |
-|----------|-------------|-------------|------------|
-| {{CONFLICT_1}} | {{A_POSITION}} | {{B_POSITION}} | {{RESOLUTION}} |
-
----
-
-## Actionable Recommendations
-
-### Must Do (before implementation)
-1. {{MUST_DO_1}}
-2. {{MUST_DO_2}}
-
-### Should Do (best practice)
-1. {{SHOULD_DO_1}}
-2. {{SHOULD_DO_2}}
-
-### Avoid
-1. {{AVOID_1}} — reason: {{AVOID_REASON_1}}
-2. {{AVOID_2}} — reason: {{AVOID_REASON_2}}
-
----
-
-## Impact on SPEC / Implementation Plan
-
-Add to SPEC Context section:
-
-```markdown
-## Context (from parallel research)
-
-- Best practice: {{SPEC_BEST_PRACTICE_NOTE}}
-- Framework constraint: {{SPEC_CONSTRAINT_NOTE}}
-- Security requirement: {{SPEC_SECURITY_NOTE}}
-- Existing pattern to follow: {{SPEC_PATTERN_NOTE}}
-```
-
----
-
-## Unanswered Questions
-
-- [ ] {{OPEN_QUESTION_1}} — investigate before Phase {{PHASE}}
-- [ ] {{OPEN_QUESTION_2}} — can proceed without answer
-
----
-
-## Sources
-
-| Agent | Source | Confidence |
-|-------|--------|-----------|
-| Best Practices | {{SOURCE_1}} | {{CONFIDENCE_1}} |
-| Framework Docs | {{SOURCE_2}} | {{CONFIDENCE_2}} |
-| Codebase | `{{SOURCE_3}}` | High |
-| Security | {{SOURCE_4}} | {{CONFIDENCE_4}} |

package/skills/vibe.presentation/SKILL.md

@@ -1,90 +0,0 @@
----
-name: vibe.presentation
-invocation: [auto]
-tier: optional
-description: "소스 데이터(리서치/문서/지식그래프)를 16:9 HTML 슬라이드덱으로 생성한다. 디자인 시스템(타이포·색·그리드·1슬라이드1메시지)을 통째로 적용해 전문가 수준 결과를 뽑고, 1920×1080 PDF 로 발행한다. 사용자가 '슬라이드/PPT/프레젠테이션/덱 만들어줘' 라고 하면 이 스킬을 쓴다. 17종 스타일 프리셋은 references/style-presets.md 에서 style= 로 선택."
-triggers: [presentation, ppt, slide, deck, 슬라이드, 프레젠테이션, 발표자료, 덱]
-priority: 50
-user-invocable: true
----
-
-# Presentation Builder
-
-## 완료 기준
-
-- [ ] 요청된 16:9 HTML slide deck이 존재한다.
-- [ ] 모든 slide가 1920×1080 viewport에서 overflow 없이 렌더링된다.
-- [ ] 인용한 사실에 source가 연결되어 있다.
-- [ ] PDF 요청 시 PDF 파일이 생성되어 있다.
-
-소스 데이터 → 디자인 시스템 적용 LLM → HTML 슬라이드덱 → 1920×1080 PDF.
-
-## 핵심 원칙
-
-**AI 에게 단편 지시가 아닌 완성된 '디자인 시스템'을 통째로 제공하라.**
-"파란색으로 해줘" 가 아니라 폰트·색·레이아웃·여백·타이포 위계를 하나의 통일된 규칙으로 정의해 전달해야 전문가 수준 결과가 나온다.
-
-## 기본 시스템 프롬프트
-
-소스 데이터를 받으면 아래 프롬프트를 시스템 지침으로 적용해 HTML 을 생성한다. (기본값 = 다크네이비 + 네온민트. 다른 룩이 필요하면 → "스타일 프리셋" 참조)
-
-```
-당신은 주어진 소스 데이터를 분석하여, 시각적으로 뛰어나고 정보 전달력이 높은
-16:9 비율(1920x1080)의 HTML 프레젠테이션을 생성하는 전문 프레젠테이션 디자이너이자
-정보 설계자입니다. 다음 규칙을 반드시 엄격하게 준수하십시오.
-
-[1. 스토리라인 및 슬라이드 분할]
-- 논리적 구조: [서론-본론-결론] 또는 [문제제기-분석-해결-기대효과]로 스토리라인 구성
-- 1슬라이드 1메시지: 각 슬라이드는 핵심 메시지 하나. 복잡하면 여러 슬라이드로 분할
-- 슬라이드 종류: 제목·목차·간지·내용·Q&A·감사 슬라이드를 적절히 포함
-
-[2. HTML 구조]
-- 각 슬라이드는 <div class="slide">로 감쌈
-- 제목 <h1 class="title">, 본문 <p class="body-text">/<ul><li>, 강조 <span class="highlight">
-- 시각자료는 <div class="visual-container">에 배치
-- 스타일은 인라인 금지, <style> 안 CSS 클래스로 일관 정의
-
-[3. 디자인·레이아웃]
-- 2단/3단 그리드로 안정감, 필요시 비대칭으로 역동성
-- 여백: 콘텐츠 주변 최소 60px. 절대 꽉 채우지 말 것
-- 텍스트 나열 지양, 데이터는 차트/인포그래픽/다이어그램으로 시각화. 저해상도 이미지 금지
-
-[4. 타이포그래피]
-- 폰트: Pretendard
-  @import url('https://cdn.jsdelivr.net/gh/orioncactus/pretendard@v1.3.9/dist/web/static/pretendard.min.css');
-- 제목 h1.title: 72px / 800 / line-height 1.2 / letter-spacing -2px
-- 부제 h2.subtitle: 36px / 600 / line-height 1.4
-- 본문 p.body-text: 24px / 400 / line-height 1.6
-- 강조 span.highlight: 강조색 + 700
-
-[5. 색상 팔레트]
-- 배경 #0A192F (다크 네이비)
-- 기본 텍스트 #CCD6F6 / 제목 #FFFFFF / 강조 #64FFDA (네온 민트)
-- 차트색 #64FFDA, #FF7B72, #8892B0 조화
-
-[6. 언어·문자 규칙 (매우 중요)]
-- 모든 텍스트는 한국어와 영어로만
-- 소스에 다른 언어가 있어도 한국어/영어로 번역·요약 반영
-- 일본어·중국어 등 지정 외 문자가 깨진 형태/무의미 디자인 요소로 쓰이는 것 절대 금지
-
-이제 주어진 소스 데이터로 위 규칙을 모두 적용해 최고의 프레젠테이션을 생성하시오.
-
-Use only English or Korean writing, no Japanese characters
-```
-
-> 마지막 줄(`Use only English or Korean...`)은 폰트 깨짐 방지 핵심 구문. **절대 빼지 말 것** — 해외 템플릿/소스 사용 시 AI 가 일본어 등 불필요 문자를 디자인 요소로 인식하는 현상을 막는다.
-
-## 안티패턴
-
-- 단편 지시("폰트 키워줘") → 효과 거의 없음. 시스템 전체를 줘라.
-- 한 슬라이드 정보 과잉 → 가독성 저하. 1슬라이드 1메시지.
-- 폰트 깨짐 방지 구문 누락 → 무의미 외국 문자로 신뢰도 하락.
-
-## 스타일 프리셋
-
-다크네이비+네온민트 외 다른 룩(매거진·스포츠·레트로 등)이 필요하면
-`references/style-presets.md` 의 17종 중 하나를 골라 [4][5] 섹션을 교체한다.
-
-## 발행
-
-HTML 완성 후 1920×1080 PDF 로 렌더(`@page` 16:9). 채널/Drive 발행은 호출 측 파이프라인에 위임.

package/skills/vibe.presentation/references/style-presets.md

@@ -1,25 +0,0 @@
-# 스타일 프리셋 (17종)
-
-> 기본값 = 다크네이비(#0A192F) + 네온민트(#64FFDA). 아래 프리셋 중 하나를 골라
-> SKILL.md 시스템 프롬프트의 [4. 타이포그래피] / [5. 색상 팔레트] 섹션을 교체한다.
-> 출처: https://github.com/bwPhD/awesome-notebookLM
-
-| 스타일 | 특징 |
-|---|---|
-| **Modern Newspaper** | 스위스/바우하우스, 비대칭, 초대형 헤드라인(슬라이드 30~50%), 흰/회색 배경, 노랑/빨강 강조 |
-| **Sharp-edged Minimalism** | 그리드, 여백 풍부, 좌상단 내비, 얇은 선, 다크모드 옵션, 섹션번호(01·02·03) |
-| **Yellow × Black Editorial** | 굵은 세리프, 패션 사진, 손글씨/스티커, 매거진 레이아웃 |
-| **Black × Orange Agency** | 흰 배경, 블러드오렌지 강조, 다이내믹 사진, 영문 타이포 |
-| **Manga Style** | 만화 포맷, 내러티브 중심, 스토리 기반 |
-| **Magazine Style** | 더스티 핑크 배경, 중앙 컷아웃, 비대칭 텍스트박스, NO.1/NO.2 섹션 |
-| **Seminar (Minimal Text)** | 고품질 패션 인물사진, 레드 강조, 다이내믹 타이포, 흰 배경 |
-| **Royal Blue & Red Watercolor** | 수채 번짐 효과, 블루/레드 |
-| **Studio/Mockup Premium** | 애플 기기 목업, 퍼플(#8D59E9)+옐로(#EBE021), 카드 레이아웃 |
-| **Neo-Retro Dev Deck** | 90s 매뉴얼, 크림 격자지, 핫핑크/시안/옐로, 두꺼운 검정 외곽, 픽셀아트 (★구조 가장 상세) |
-| **Pink Street-style** | 핑크 배경, 두꺼운 선 팝일러스트, 플랫 컬러 |
-| **Mincho + Handwritten** | 세리프+손글씨, 패션사진, 스티커 |
-| **Sculpture Pop/Vaporwave** | 대리석 흉상×네온, 고채도 단색배경, 울트라볼드 산세리프 |
-| **Tech/Neon Constructivism** | 웜그레이 배경(#E0E0D0), 차콜 텍스트, 네온옐로 기하 강조, 건축 그리드 |
-| **Digital/Neo Pop** | 비타민 컬러, 아메바/구름 형태, SNS 아이콘, 점패턴 배경 |
-| **Anti-Gravity/Living Artifact** | 순백+소프트 그라데, 라운드 산세리프, 얇은 선 아이콘 |
-| **Sports/Athletic** | 검정 배경(#111), 볼트라임(#CCFF00)+네온오렌지, 이탤릭 볼드, 대각 도형 |