name: prompt-optimizer description: Analyze raw prompts, identify intent and gaps, match ECC components (skills/commands/agents/hooks), and output a ready-to-paste optimized prompt. Advisory role only — never executes the task itself. TRIGGER when: user says "optimize prompt", "improve my prompt", "how to write a prompt for", "help me prompt", "rewrite this prompt", or explicitly asks to enhance prompt quality. Also triggers on Chinese equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令". DO NOT TRIGGER when: user wants the task executed directly.
프롬프트 최적화 도구은(는) 무엇을 하나요?
초안 프롬프트를 분석하고, 비판하며, ECC 에코시스템 구성 요소에 매칭한 후 사용자가 복사해서 실행할 수 있는 완전한 최적화 프롬프트를 출력합니다.
사용 시기
- 사용자가 "optimize this prompt", "improve my prompt", "rewrite this prompt"라고 말할 때
- 사용자가 "help me write a better prompt for..."라고 말할 때
- 사용자가 "what's the best way to ask Claude Code to..."라고 말할 때
- 사용자가 "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"라고 말할 때
- 사용자가 초안 프롬프트를 붙여넣고 피드백이나 개선을 요청할 때
- 사용자가 "I don't know how to prompt for this"라고 말할 때
- 사용자가 "how should I use ECC for..."라고 말할 때
- 사용자가 명시적으로
/prompt-optimize를 호출할 때
사용하지 말아야 할 시기
- 사용자가 작업을 직접 수행하기를 원할 때 (그냥 실행)
- 사용자가 "优化代码", "优化性能", "optimize this code", "optimize performance"라고 말할 때 — 이는 프롬프트 최적화가 아닌 리팩토링 작업입니다.
- 사용자가 ECC 설정에 대해 물어볼 때 (대신
configure-ecc사용) - 사용자가 스킬 인벤토리를 원할 때 (대신
skill-stocktake사용) - 사용자가 "just do it" 또는 "直接做"라고 말할 때
작동 방식
조언 전용 — 사용자의 작업을 실행하지 마십시오.
코드를 작성하거나, 파일을 생성하거나, 명령어를 실행하거나, 구현 작업을 수행하지 마십시오. 유일한 출력은 분석 결과와 최적화된 프롬프트입니다.
사용자가 "just do it", "直接做", 또는 "don't optimize, just execute"라고 말하는 경우, 이 스킬 내에서 구현 모드로 전환하지 마십시오. 사용자에게 이 스킬은 최적화된 프롬프트만 생성한다고 알리고, 실행을 원할 경우 일반 작업 요청을 하도록 안내하십시오.
아래 6단계 파이프라인을 순차적으로 실행하십시오. 아래 출력 형식을 사용하여 결과를 제시하십시오.
분석 파이프라인
단계 0: 프로젝트 감지
프롬프트를 분석하기 전에 현재 프로젝트 컨텍스트를 감지합니다:
- 작업 디렉토리에
CLAUDE.md파일이 있는지 확인 — 프로젝트 규칙을 읽습니다. - 프로젝트 파일에서 기술 스택을 감지합니다.
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin / Spring BootPackage.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- 감지된 기술 스택을 3단계와 4단계에서 사용하기 위해 기록합니다.
프로젝트 파일이 없는 경우(예: 프롬프트가 추상적이거나 새 프로젝트용인 경우), 감지를 건너뛰고 4단계에서 "기술 스택 알 수 없음" 플래그를 지정합니다.
단계 1: 의도 감지
사용자의 작업을 하나 이상의 범주로 분류합니다:
| 범주 | 신호 단어 | 예시 |
|---|---|---|
| 새 기능 | build, create, add, implement, 创建, 实现, 添加 | "Build a login page" |
| 버그 수정 | fix, broken, not working, error, 修复, 报错 | "Fix the auth flow" |
| 리팩토링 | refactor, clean up, restructure, 重构, 整理 | "Refactor the API layer" |
| 연구 | how to, what is, explore, investigate, 怎么, 如何 | "How to add SSO" |
| 테스팅 | test, coverage, verify, 测试, 覆盖率 | "Add tests for the cart" |
| 검토 | review, audit, check, 审查, 检查 | "Review my PR" |
| 문서화 | document, update docs, 文档 | "Update the API docs" |
| 인프라 | deploy, CI, docker, database, 部署, 数据库 | "Set up CI/CD pipeline" |
| 설계 | design, architecture, plan, 设计, 架构 | "Design the data model" |
단계 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단계에서 감지되었습니까, 아니면 사용자가 지정해야 합니까?
- 대상 범위 — 파일, 디렉토리 또는 모듈이 언급되었습니까?
- 수락 기준 — 작업이 완료되었음을 어떻게 알 수 있습니까?
- 오류 처리 — 엣지 케이스와 실패 모드가 처리되었습니까?
- 보안 요구 사항 — 인증, 입력 유효성 검사, 비밀?
- 테스팅 예상 — 단위, 통합, 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: 최적화된 프롬프트 — 전체 버전
완전한 최적화된 프롬프트를 단일 펜스 코드 블록 안에 제시하십시오. 프롬프트는 자체 포함되어 복사하여 붙여넣을 수 있어야 합니다. 다음을 포함하십시오:
- 컨텍스트가 포함된 명확한 작업 설명
- 기술 스택 (감지 또는 지정됨)
- 올바른 워크플로우 단계에서의
/command호출 - 수락 기준
- 검증 단계
- 범위 경계 (하지 말아야 할 것)
blueprint를 참조하는 항목의 경우 /blueprint 대신 "Use the blueprint skill to..."라고 작성하십시오(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: 개선 근거
| 개선 사항 | 이유 |
|---|---|
| (추가된 항목) | (중요한 이유) |
예시
예시 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%+
- 페이지가 모바일 및 데스크톱에서 정상 렌더링
- 로그인 성공 시 dashboard로 이동, 실패 시 오류 메시지 표시
하지 말아야 할 것:
- 회원가입 페이지 구현하지 않음
- 비밀번호 찾기 기능 구현하지 않음
- 기존 라우팅 구조 수정하지 않음