프롬프트 최적화 도구

프롬프트 최적화 도구은(는) 무엇을 하나요?

초안 프롬프트를 분석하고, 비판하며, ECC 에코시스템 구성 요소와 매칭한 후, 사용자가 바로 복사하여 실행할 수 있는 완전히 최적화된 프롬프트를 출력합니다.

사용 시기

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

사용하지 말아야 할 때

• 사용자가 작업을 직접 실행하기를 원할 때 (그냥 실행)
• 사용자가 "优化代码", "优化性能", "이 코드 최적화해줘", "성능 최적화해줘" 라고 말할 때 — 이는 리팩토링 작업이지 프롬프트 최적화가 아닙니다.
• 사용자가 ECC 설정에 대해 물어볼 때 (configure-ecc 사용)
• 사용자가 스킬 목록을 원할 때 (skill-stocktake 사용)
• 사용자가 "그냥 해줘" 또는 "直接做" 라고 말할 때

작동 방식

자문 전용 — 사용자의 작업을 실행하지 마십시오.

코드를 작성하거나, 파일을 생성하거나, 명령을 실행하거나, 구현 조치를 취하지 마십시오. 당신의 유일한 출력은 분석과 최적화된 프롬프트입니다.

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

아래 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 (빌드 파일에서 quarkus 확인 → Quarkus, 또는 spring-boot → 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단계: 의도 감지

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

카테고리	신호 단어	예시
신규 기능	만들기, 생성, 추가, 구현, 创建, 实现, 添加	"로그인 페이지 만들기"
버그 수정	수정, 고장, 작동 안 함, 오류, 修复, 报错	"인증 흐름 수정"
리팩토링	리팩토링, 정리, 구조 변경, 重构, 整理	"API 레이어 리팩토링"
연구	방법, 무엇인지, 탐구, 조사, 怎么, 如何	"SSO 추가 방법"
테스트	테스트, 커버리지, 검증, 测试, 覆盖率	"장바구니에 테스트 추가"
검토	검토, 감사, 확인, 审查, 检查	"내 PR 검토"
문서화	문서화, 문서 업데이트, 文档	"API 문서 업데이트"
인프라	배포, CI, 도커, 데이터베이스, 部署, 数据库	"CI/CD 파이프라인 설정"
설계	설계, 아키텍처, 계획, 设计, 架构	"데이터 모델 설계"

2단계: 범위 평가

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

범위	휴리스틱	오케스트레이션
사소함	단일 파일, < 50줄	직접 실행
낮음	단일 컴포넌트 또는 모듈	단일 명령 또는 스킬
중간	여러 컴포넌트, 동일 도메인	명령 체인 + /verify
높음	교차 도메인, 5개 이상 파일	/plan 후 단계별 실행
에픽	다중 세션, 다중 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
설계 (중간-높음)	/plan	—	planner, architect
설계 (에픽)	—	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	java-reviewer
Quarkus / Java	quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns	java-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단계에서 감지되었는가, 아니면 사용자가 지정해야 하는가?
• 대상 범위 — 파일, 디렉토리 또는 모듈이 언급되었는가?
• 수용 기준 — 작업 완료를 어떻게 알 수 있는가?
• 오류 처리 — 엣지 케이스 및 실패 모드가 다루어졌는가?
• 보안 요구 사항 — 인증, 입력 검증, 비밀?
• 테스트 기대 사항 — 단위, 통합, E2E?
• 성능 제약 사항 — 부하, 지연 시간, 리소스 제한?
• UI/UX 요구 사항 — 디자인 사양, 반응형, 접근성? (프론트엔드인 경우)
• 데이터베이스 변경 — 스키마, 마이그레이션, 인덱스? (데이터 레이어인 경우)
• 기존 패턴 — 참조 파일 또는 따라야 할 규칙?
• 범위 경계 — 하지 말아야 할 것은?

3개 이상의 중요 항목이 누락된 경우, 최적화된 프롬프트를 생성하기 전에 사용자에게 최대 3개의 명확화 질문을 합니다. 그런 다음 답변을 최적화된 프롬프트에 통합합니다.

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

이 프롬프트가 개발 수명 주기에서 어디에 위치하는지 결정합니다:

연구 → 계획 → 구현 (TDD) → 검토 → 검증 → 커밋

중간+ 작업의 경우 항상 /plan으로 시작합니다. 에픽 작업의 경우 blueprint 스킬을 사용합니다.

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

범위	추천 모델	근거
사소함-낮음	Sonnet 5	단순 작업에 빠르고 비용 효율적
중간	Sonnet 5	표준 작업에 최적의 코딩 모델
높음	Sonnet 5 (주) + Opus 5 (계획)	아키텍처는 Opus, 구현은 Sonnet
에픽	Opus 5 (청사진) + Sonnet 5 (실행)	다중 세션 계획을 위한 심층 추론

다중 프롬프트 분할 (높음/에픽 범위의 경우):

단일 세션을 초과하는 작업의 경우 순차적 프롬프트로 분할합니다:

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

---

출력 형식

분석을 다음 정확한 구조로 제시하십시오. 사용자 입력과 동일한 언어로 응답하십시오.

섹션 1: 프롬프트 진단

강점: 원본 프롬프트가 잘하는 것을 나열하십시오.

문제점:

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

명확화 필요: 사용자가 답변해야 할 질문의 번호 목록. 0단계에서 답변을 자동 감지한 경우 질문 대신 명시하십시오.

섹션 2: 권장 ECC 구성 요소

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

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

완전한 최적화된 프롬프트를 단일 펜스드 코드 블록 안에 제시하십시오. 프롬프트는 자체 포함되어야 하며 복사하여 붙여넣을 수 있어야 합니다. 포함할 내용:

• 컨텍스트가 포함된 명확한 작업 설명
• 기술 스택 (감지 또는 지정)
• 올바른 워크플로우 단계에서의 /command 호출
• 수용 기준
• 검증 단계
• 범위 경계 (하지 말아야 할 것)

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.
에픽	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로 모든 테스트 통과 및 페이지 정상 렌더링을 확인합니다.

보안 요구 사항:
- 비밀번호는 평문으로 전송되지 않음.
- 무차별 대입 방지 (속도 제한).
- XSS 보호.
- CSRF 토큰.

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

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

예시 2: 중간 수준 영어 프롬프트

사용자 입력:

유효성 검사가 포함된 사용자 프로필 업데이트 REST API 엔드포인트 추가

0단계 감지: go.mod (Go 1.22, Chi router)

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

사용자 프로필 업데이트(PATCH /api/users/:id)를 위한 REST API 엔드포인트 추가.

기술 스택: Go 1.22 + Chi router (프로젝트에서 감지됨)

요구 사항:
- PATCH /api/users/:id — 사용자 프로필의 부분 업데이트
- 다음 필드에 대한 입력 유효성 검사: name, email, avatar_url, bio
- 인증: 유효한 토큰 필요, 사용자는 자신의 프로필만 업데이트 가능
- 성공 시 업데이트된 사용자와 함께 200 반환
- 잘못된 입력 시 유효성 검사 오류와 함께 400 반환
- 인증 실패 시 401/403 반환
- 코드베이스의 기존 API 패턴을 따름

워크플로우:
1. /plan으로 엔드포인트 구조, 미들웨어 체인 및 유효성 검사 로직 계획
2. /tdd — 성공, 유효성 검사 실패, 인증 실패, 찾을 수 없음에 대한 테이블 기반 테스트 작성
3. 기존 핸들러 패턴을 따라 구현
4. /go-review
5. /verify — 전체 테스트 스위트 실행, 회귀 없음 확인

하지 말 것:
- 기존 엔드포인트 수정하지 않음
- 데이터베이스 스키마 변경하지 않음 (기존 사용자 테이블 사용)
- 먼저 기존 종속성을 확인하지 않고 새 종속성 추가하지 않음 (search-first 스킬 사용)

예시 3: 에픽 프로젝트

사용자 입력:

모놀리식을 마이크로서비스로 마이그레이션

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

blueprint 스킬을 사용하여 계획: "모놀리식에서 마이크로서비스 아키텍처로 마이그레이션"

실행 전 blueprint에서 다음 질문에 답하십시오:
1. 현재 모놀리식에는 어떤 도메인 경계가 존재합니까?
2. 어떤 서비스를 먼저 추출해야 합니까 (가장 낮은 결합도)?
3. 통신 패턴: REST API, gRPC 또는 이벤트 기반 (Kafka/RabbitMQ)?
4. 데이터베이스 전략: 처음에는 공유 DB를 사용할지, 아니면 서비스별 데이터베이스를 처음부터 사용할지?
5. 배포 대상: Kubernetes, Docker Compose 또는 서버리스?

blueprint는 다음과 같은 단계를 생성해야 합니다:
- 1단계: 서비스 경계 식별 및 도메인 맵 생성
- 2단계: 인프라 설정 (API 게이트웨이, 서비스 메시, 서비스별 CI/CD)
- 3단계: 첫 번째 서비스 추출 (strangler fig 패턴)
- 4단계: 통합 테스트로 검증, 그런 다음 다음 서비스 추출
- N단계: 모놀리식 폐기

각 단계 = 1 PR, 단계 사이에 /verify 게이트 포함.
단계 사이에 /save-session 사용

---

[번역을 위해 잘림]