원클릭으로 Manus에서 모든 스킬 실행

시작하기

prompt-engineering

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

Manus에서 실행

스타0

포크0

업데이트2026년 6월 1일 07:47

출처

storm-credit

storm-credit/askanything_video_generator

GitHub 저장소 열기 Creator 저장소 보기

설치 명령

다운로드

Manus에서 실행

유용한 대상SOC

기술 작가예술, 디자인, 엔터테인먼트, 스포츠, 미디어직27-3042L4

SKILL.md

readonly

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 컨텍스트 주입 순서

transcript (있으면 먼저)
fact_context (있으면)
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 스킬과 일관성 유지

이 저장소의 다른 Skills

같은 저장소

memory-query

storm-credit/askanything_video_generator

agent_memory 조회 — 실패 패턴/바이럴 시그널/훅 성과 4채널 비교

2026-06-010

watch

storm-credit/askanything_video_generator

Watch a video (URL or local path). Downloads with yt-dlp, extracts auto-scaled frames with ffmpeg, pulls the transcript from captions (or Whisper API fallback), and hands the result to Claude so it can answer questions about what's in the video.

2026-06-010

auto-debug

storm-credit/askanything_video_generator

자동 디버깅 — 에러 로그 → 원인 파일/라인 추적, Docker/Python traceback 분석

2026-06-010

auto-refactor

storm-credit/askanything_video_generator

자동 리팩토링 — 긴 함수 분리, 중복 제거, import 정리

2026-06-010

auto-test

storm-credit/askanything_video_generator

자동 테스트 — 변경 파일 syntax/import/smoke test 일괄 검증

2026-06-010

alert-engine

storm-credit/askanything_video_generator

경보 엔진 — 아웃라이어/하락/바이럴 감지 + Telegram 알림

2026-05-030

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 컨텍스트 주입 순서

transcript (있으면 먼저)
fact_context (있으면)
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 스킬과 일관성 유지