prompt-engineering

name	prompt-engineering
description	프롬프트 설계 — system/user 분리, few-shot 기준, 토큰 효율 vs 정확도
user_invocable	true

/prompt-engineering — 프롬프트 설계 도우미

LLM 프롬프트를 처음 설계할 때 사용. (기존 prompt-review는 작성된 프롬프트를 검증)

사용법

/prompt-engineering design <task>  → 새 프롬프트 설계 (system/user 분리)
/prompt-engineering fewshot <task> → few-shot 예시 필요 여부 판단
/prompt-engineering token <prompt> → 토큰 사용량 추정 + 절감안
/prompt-engineering schema <task>  → JSON output 스키마 설계

역할 분리 (vs prompt-review)

스킬	시점	목적
prompt-engineering	작성 전	어떻게 만들지 설계
prompt-review	작성 후	만든 것 검증

설계 원칙

1. system vs user 분리

• system: 변하지 않는 역할/규칙/포맷 (캐싱 대상)
• user: 매번 다른 입력 (주제, 데이터, 컨텍스트)
• Gemini는 system 캐싱 자동, OpenAI는 prompt caching 명시 필요

2. few-shot 사용 기준

• ✅ 출력 포맷이 복잡 (JSON 스키마, 마크다운 구조)
• ✅ 도메인 특화 톤이 필요 (채널별 훅 스타일)
• ❌ 토큰 비용 vs 정확도 1.1배 미만이면 zero-shot
• 예시는 2~3개, 다양성 우선 (단순/복합/엣지케이스)

3. 토큰 효율 vs 정확도

• 저비용 모델 (Flash/4o-mini): 명시적 규칙 + few-shot
• 고비용 모델 (Pro/5.4): 간결한 지시 + 추론 신뢰
• 동일 작업 반복 호출 → 캐싱 가능한 구조로 설계
• 출력 길이 제한 명시 (max_output_tokens 또는 "20자 이내" 같은 in-prompt 지시)

4. JSON 출력 스키마

• 필드명은 snake_case 통일
• nullable 필드는 docstring으로 명시
• 배열 + 객체 중첩은 2단계까지만
• output_format 예시를 system 프롬프트 끝에 첨부

5. 안전장치 (HARD FAIL vs SOFT GUARD)

• HARD FAIL: 포맷 자체가 무너지는 위반 (컷 수, 필수 태그)
• SOFT GUARD: 권장이지만 LLM이 판단할 여지 (감정 태그 위치)
• 코드 검증과 프롬프트 검증을 동기화 (quality.py ↔ 프롬프트)

패턴 라이브러리

A. 4채널 분기 패턴

_CHANNEL_INSTRUCTIONS = {
    "askanything": "친근한 반말, 호기심 자극",
    "wonderdrop": "다큐멘터리 권위, calm authority",
    "exploratodo": "에너지 LATAM, 빠른 리듬",
    "prismtale": "다크 미스터리, 시네마틱",
}
prompt += f"\n[Channel Style] {_CHANNEL_INSTRUCTIONS[channel]}"

B. 포맷별 시스템 프롬프트 주입

system_prompt = base_prompt + format_fragments[format_type][lang]

C. RAG 컨텍스트 주입 순서

1. transcript (있으면 먼저)
2. fact_context (있으면)
3. channel_hook_rules (마지막 — LLM이 가장 강하게 반영)

담당 파일

• modules/gpt/prompts/ — 시스템 프롬프트 본체
• modules/gpt/prompts/formats/ — 포맷별 fragment
• modules/gpt/cutter/verifier.py — 검증 프롬프트
• modules/gpt/cutter/enhancer.py — 비주얼/폴리시 프롬프트

통합 지점

• 작성 후 /prompt-review로 검증
• /cost-aware-llm-pipeline과 토큰 사용량 교차 검토
• 채널별 톤은 polisher 스킬과 일관성 유지