prompt-optimizer

프롬프트 최적화 도구 (Prompt Optimizer)

초안 프롬프트를 분석 및 비판하고, 이를 ECC 생태계 구성 요소와 매칭하여 사용자가 바로 복사해서 실행할 수 있는 완전한 최적화 프롬프트를 출력합니다.

사용 시점

• 사용자가 "이 프롬프트 최적화해줘", "내 프롬프트 좀 개선해줘", "프롬프트 다시 써줘"라고 말할 때
• 사용자가 "...를 위해 프롬프트를 어떻게 쓰는 게 좋을까?"라고 물을 때
• 사용자가 "Claude Code에게 ...라고 요청하는 가장 좋은 방법이 뭐야?"라고 물을 때
• 사용자가 "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"라고 말할 때
• 사용자가 프롬프트 초안을 붙여넣고 피드백이나 강화를 요청할 때
• 사용자가 "이걸 프롬프트로 어떻게 표현해야 할지 모르겠어"라고 말할 때
• 사용자가 "ECC를 ...에 어떻게 활용해야 해?"라고 물을 때
• 사용자가 명시적으로 /prompt-optimize를 호출할 때

사용하지 않는 경우

• 사용자가 작업을 직접 수행하기를 원할 때 (그냥 실행하십시오)
• 사용자가 "코드 최적화", "성능 최적화" 등을 말할 때 — 이것은 리팩터링 작업이지 프롬프트 최적화가 아닙니다.
• 사용자가 ECC 설정에 대해 물을 때 (configure-ecc 사용)
• 사용자가 스킬 목록을 원할 때 (skill-stocktake 사용)
• 사용자가 "그냥 해줘", "just do it" 또는 "直接做"라고 말할 때

작동 방식

조언만 제공하며 사용자의 작업을 직접 실행하지 마십시오.

코드를 작성하거나, 파일을 생성하거나, 명령어를 실행하는 등의 구현 작업을 수행하지 마십시오. 오직 분석 결과와 최적화된 프롬프트만을 출력해야 합니다.

사용자가 "그냥 해", "直接做", 또는 "최적화 말고 그냥 실행해"라고 말한다면, 이 스킬 내부에서 구현 모드로 전환하지 마십시오. 사용자에게 이 스킬은 최적화된 프롬프트만 생성한다고 안내하고, 실행을 원한다면 일반적인 작업 요청을 하라고 지시하십시오.

다음 6단계 파이프라인을 순차적으로 실행하십시오. 결과는 아래의 출력 형식을 사용하여 제시하십시오.

분석 파이프라인

0단계: 프로젝트 감지

프롬프트를 분석하기 전에 현재 프로젝트 컨텍스트를 감지합니다:

1. 작업 디렉토리에 CLAUDE.md가 있는지 확인하고, 프로젝트 규칙을 읽습니다.
2. 프로젝트 파일에서 기술 스택을 감지합니다:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin / Spring Boot
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. 감지된 기술 스택을 3단계와 4단계에서 사용하기 위해 기록합니다.

프로젝트 파일을 찾을 수 없는 경우(예: 프롬프트가 추상적이거나 새 프로젝트를 위한 것인 경우), 감지를 건너뛰고 4단계에서 "기술 스택 알 수 없음"으로 표시합니다.

1단계: 의도 감지

사용자의 작업을 하나 이상의 카테고리로 분류합니다:

카테고리	신호 단어	예시
새 기능	build, create, add, implement, 생성, 구현, 추가	"로그인 페이지 만들어줘"
버그 수정	fix, broken, not working, error, 수정, 오류	"인증 흐름 고쳐줘"
리팩터링	refactor, clean up, restructure, 리팩터링, 정리	"API 레이어 리팩터링해줘"
리서치	how to, what is, explore, investigate, 어떻게, 뭐야	"SSO 추가하는 방법"
테스트	test, coverage, verify, 테스트, 커버리지	"장바구니 테스트 추가해줘"
리뷰	review, audit, check, 리뷰, 검토, 검사	"내 PR 리뷰해줘"
문서화	document, update docs, 문서, 업데이트	"API 문서 업데이트해줘"
인프라	deploy, CI, docker, database, 배포, 데이터베이스	"CI/CD 파이프라인 구축해줘"
설계	design, architecture, plan, 설계, 아키텍처	"데이터 모델 설계해줘"

2단계: 범위 평가

0단계에서 프로젝트가 감지되었다면 코드베이스 크기를 신호로 사용합니다. 그렇지 않으면 프롬프트 설명만으로 추정하고 추정치가 불확실함을 표시합니다.

범위	판단 기준	오케스트레이션
TRIVIAL	단일 파일, 50줄 미만	직접 실행
LOW	단일 컴포넌트 또는 모듈	단일 명령어 또는 스킬
MEDIUM	여러 컴포넌트, 동일 도메인	명령어 체인 + /verify
HIGH	도메인 교차, 5개 이상의 파일	/plan 먼저 실행 후 단계별 실행
EPIC	다중 세션, 다중 PR, 아키텍처 변경	다중 세션 계획을 위해 blueprint 스킬 사용

3단계: ECC 구성 요소 매칭

의도 + 범위 + 기술 스택(0단계에서 획득)을 특정 ECC 구성 요소에 매핑합니다.

의도 유형별

의도	명령어	스킬	에이전트
새 기능	/plan, /tdd, /code-review, /verify	tdd-workflow, verification-loop	planner, tdd-guide, code-reviewer
버그 수정	/tdd, /build-fix, /verify	tdd-workflow	tdd-guide, build-error-resolver
리팩터링	/refactor-clean, /code-review, /verify	verification-loop	refactor-cleaner, code-reviewer
리서치	/plan	search-first, iterative-retrieval	—
테스트	/tdd, /e2e, /test-coverage	tdd-workflow, e2e-testing	tdd-guide, e2e-runner
리뷰	/code-review	security-review	code-reviewer, security-reviewer
문서화	/update-docs, /update-codemaps	—	doc-updater
인프라	/plan, /verify	docker-patterns, deployment-patterns, database-migrations	architect
설계 (MEDIUM-HIGH)	/plan	—	planner, architect
설계 (EPIC)	—	blueprint (스킬로 호출)	planner, architect

기술 스택별

기술 스택	추가할 스킬	에이전트
Python / Django	django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing	python-reviewer
Go	golang-patterns, golang-testing	go-reviewer, go-build-resolver
Spring Boot / Java	springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns	code-reviewer
Kotlin / Android	kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture	kotlin-reviewer
TypeScript / React	frontend-patterns, backend-patterns, coding-standards	code-reviewer
Swift / iOS	swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing	code-reviewer
PostgreSQL	postgres-patterns, database-migrations	database-reviewer
Perl	perl-patterns, perl-testing, perl-security	code-reviewer
C++	cpp-coding-standards, cpp-testing	code-reviewer
기타 / 목록에 없음	coding-standards (범용)	code-reviewer

4단계: 누락된 컨텍스트 감지

프롬프트에서 누락된 중요한 정보를 스캔합니다. 각 항목을 확인하고 0단계에서 자동 감지되었는지 또는 사용자가 제공해야 하는지 표시합니다:

• 기술 스택 — 0단계에서 감지됨, 아니면 사용자가 명시해야 함?
• 대상 범위 — 언급된 파일, 디렉토리 또는 모듈은?
• 수락 기준 (Acceptance criteria) — 작업 완료를 어떻게 알 수 있는가?
• 오류 처리 — 엣지 케이스 및 실패 모드가 고려되었는가?
• 보안 요구 사항 — 인증, 입력 검증, 비밀 정보?
• 테스트 기대치 — 단위, 통합, E2E?
• 성능 제약 — 부하, 지연 시간, 리소스 제한?
• UI/UX 요구 사항 — 디자인 사양, 반응형, 접근성? (프론트엔드인 경우)
• 데이터베이스 변경 — 스키마, 마이그레이션, 인덱스? (데이터 레이어인 경우)
• 기존 패턴 — 따를 참조 파일이나 관례가 있는가?
• 범위 경계 — 하지 말아야 할 것은?

중요 항목이 3개 이상 누락된 경우, 최적화된 프롬프트를 생성하기 전에 사용자에게 최대 3개의 질문을 던져 명확히 하십시오. 그런 다음 답변을 최적화된 프롬프트에 포함시키십시오.

5단계: 워크플로 및 모델 추천

이 프롬프트가 개발 수명 주기의 어느 단계에 해당하는지 결정합니다:

리서치 → 계획 → 구현 (TDD) → 리뷰 → 검증 → 커밋

MEDIUM 이상의 작업은 항상 /plan으로 시작하십시오. EPIC 작업은 blueprint 스킬을 사용하십시오.

모델 추천 (출력에 포함):

범위	추천 모델	근거
TRIVIAL-LOW	Sonnet 4.6	간단한 작업에 빠르고 비용 효율적
MEDIUM	Sonnet 4.6	표준 작업에 가장 적합한 코딩 모델
HIGH	Sonnet 4.6 (메인) + Opus 4.6 (계획)	아키텍처는 Opus, 구현은 Sonnet
EPIC	Opus 4.6 (blueprint) + Sonnet 4.6 (실행)	다중 세션 계획을 위한 깊은 추론

멀티 프롬프트 분할 (HIGH/EPIC 범위인 경우):

단일 세션을 초과하는 작업은 순차적 프롬프트로 나눕니다:

• 프롬프트 1: 리서치 + 계획 (search-first 스킬 사용 후 /plan)
• 프롬프트 2-N: 프롬프트당 한 단계씩 구현 (각각 /verify로 종료)
• 최종 프롬프트: 모든 단계에 대한 통합 테스트 + /code-review
• 세션 간 컨텍스트 유지를 위해 /save-session 및 /resume-session 사용

---

출력 형식

분석 결과를 이 구조에 맞춰 제시하십시오. 사용자의 입력과 동일한 언어로 응답하십시오.

섹션 1: 프롬프트 진단

강점: 원래 프롬프트가 잘하고 있는 점을 나열합니다.

문제점:

문제	영향	수정 제안
(문제점)	(결과)	(수정 방법)

확인 필요 사항: 사용자가 답변해야 할 질문 목록(번호순). 0단계에서 답을 자동 감지했다면 질문하는 대신 감지된 내용을 명시하십시오.

섹션 2: 권장 ECC 구성 요소

유형	구성 요소	목적
명령어	/plan	코딩 전 아키텍처 설계
스킬	tdd-workflow	TDD 방법론 가이드
에이전트	code-reviewer	구현 후 검토
모델	Sonnet 4.6	이 범위에 권장됨

섹션 3: 최적화된 프롬프트 — 전체 버전

완전한 최적화 프롬프트를 단일 코드 블록 안에 제시하십시오. 프롬프트는 그 자체로 완결성이 있어야 하며 바로 복사해서 붙여넣을 수 있어야 합니다. 다음을 포함하십시오:

• 컨텍스트가 포함된 명확한 작업 설명
• 기술 스택 (감지된 것 또는 명시된 것)
• 적절한 워크플로 단계에서의 /명령어 호출
• 수락 기준 (Acceptance criteria)
• 검증 단계
• 범위 경계 (하지 말아야 할 것)

blueprint를 참조하는 항목은 다음과 같이 쓰십시오: "blueprint 스킬을 사용하여..." (/blueprint가 아닙니다. blueprint는 명령어가 아니라 스킬입니다).

섹션 4: 최적화된 프롬프트 — 요약 버전

숙련된 ECC 사용자를 위한 압축 버전입니다. 의도 유형에 따라 다르게 작성하십시오:

의도	빠른 패턴
새 기능	/plan [기능]. /tdd로 구현. /code-review. /verify.
버그 수정	/tdd — [버그]에 대해 실패하는 테스트 작성. 통과하도록 수정. /verify.
리팩터링	/refactor-clean [범위]. /code-review. /verify.
리서치	[주제]에 대해 search-first 스킬 사용. 결과에 기반해 /plan.
테스트	[모듈]에 대한 /tdd. 주요 흐름에 대한 /e2e. /test-coverage.
리뷰	/code-review. 그 후 security-reviewer 에이전트 사용.
문서화	/update-docs. /update-codemaps.
EPIC	"[목표]"를 위해 blueprint 스킬 사용. /verify 게이트와 함께 단계별 실행.

섹션 5: 강화 근거

강화 항목	이유
(추가된 내용)	(그것이 왜 중요한지)

푸터

원하시는 결과가 아닌가요? 조정이 필요한 부분을 말씀해 주시거나, 프롬프트 최적화 대신 구현을 원하신다면 일반적인 작업 요청을 해주세요.

---

예시

트리거 예시

• "ECC를 위해 이 프롬프트 최적화해줘"
• "Claude Code가 올바른 명령어를 사용하도록 이 프롬프트 다시 써줘"
• "帮我优化这个指令"
• "이 작업을 위해 ECC에 어떻게 프롬프트를 작성해야 해?"

예시 1: 모호한 한국어 프롬프트 (프로젝트 감지됨)

사용자 입력:

사용자 로그인 페이지 만들어줘

0단계 감지: package.json (Next.js 15, TypeScript, Tailwind CSS)

최적화된 프롬프트 (전체):

프로젝트의 기존 기술 스택(Next.js 15 + TypeScript + Tailwind CSS)을 사용하여 사용자 로그인 페이지를 구현해줘.

기술 요구 사항:
- 프로젝트의 기존 컴포넌트 구조와 라우팅 규칙을 따를 것
- 폼 검증은 프로젝트에 이미 사용 중인 방식(Zod/Yup 등 확인)을 사용할 것
- 인증 방식: 프로젝트의 기존 인증 스킴을 따를 것 (없다면 기본 JWT 사용)
- 포함 항목: 이메일/비밀번호 로그인 폼, 유효성 검사, 오류 메시지, 로딩 상태, 반응형 레이아웃

워크플로:
1. /plan 을 통해 기존 페이지의 패턴을 참고하여 컴포넌트 구조와 인증 흐름을 먼저 설계할 것
2. /tdd 테스트 선행: 로그인 폼의 단위 테스트와 인증 흐름의 통합 테스트 작성
3. 로그인 페이지와 인증 로직 구현
4. /code-review 를 통해 구현 내용 검토
5. /verify 를 통해 모든 테스트 통과 및 페이지 정상 렌더링 확인

보안 요구 사항:
- 비밀번호 평문 전송 금지
- 무차별 대입 공격 방지 (rate limiting)
- XSS 방어
- CSRF 토큰

수락 기준:
- 모든 테스트 통과, 커버리지 80% 이상
- 모바일 및 데스크톱에서 정상 렌더링
- 로그인 성공 시 대시보드로 이동, 실패 시 오류 메시지 표시

하지 말 것:
- 회원가입 페이지 구현 금지
- 비밀번호 찾기 기능 구현 금지
- 기존 라우팅 구조 수정 금지

... (중략) ...

---

관련 구성 요소

구성 요소	참조 시점
configure-ecc	사용자가 아직 ECC를 설정하지 않았을 때
skill-stocktake	어떤 구성 요소가 설치되어 있는지 감사할 때 (하드코딩된 목록 대신 사용)
search-first	최적화된 프롬프트의 리서치 단계에서
blueprint	EPIC 범위의 최적화된 프롬프트에서 (명령어가 아닌 스킬로 호출)
strategic-compact	긴 세션의 컨텍스트 관리 시
cost-aware-llm-pipeline	토큰 최적화 권장 사항 필요 시