Opus 4.7 프롬프트 작성기

Opus 4.7 프롬프트 작성기은(는) 무엇을 하나요?

다른 Claude 모델이 최소한의 모호함으로 실행할 수 있는 프롬프트를 하나 작성하세요. 문장의 우아함이 아니라 동작, 지속성, 검증에 최적화하세요.

작업이 장기적이거나, 도구 사용이 많거나, 프롬프트 품질이 실질적으로 중요한 비용이 많이 드는 경우 참조/anthropic-claude-prompting.md를 읽으세요.

워크플로우

1. 실제 작업을 캡처합니다.
2. 실행 환경을 식별합니다.
3. 하드 제약 조건과 완료 기준을 정의합니다.
4. 프롬프트가 명시적으로 도구 사용, 지속성, 검증을 강조해야 하는지 결정합니다.
5. XML 스타일 섹션으로 프롬프트를 작성합니다.
6. 실행 루프와 검증 게이트를 추가합니다.
7. 모호하거나 상충되는 지침을 제거합니다.

실제 작업 캡처

프롬프트를 작성하기 전에 다음을 추출하세요:

• 목표: 변경, 수정, 구현 또는 검토해야 할 사항.
• 환경: 저장소 경로, 브랜치, 로컬 서비스, 도구, 런타임, 시크릿 가정.
• 제약 조건: 건드리지 말아야 할 파일이나 시스템, 스타일 규칙, 필수 문서, 승인 한도.
• 검증 표면: 단위 테스트, 통합 테스트, Playwright, Docker, 로컬 Supabase, 빌드, 린트, 스모크 검사.
• 완료 규칙: 모델이 중단해도 되기 위해 반드시 참이어야 하는 조건.

사용자가 명세서나 이전 검토 결과를 제공했다면, 이를 명시적인 필수 작업 항목으로 전환하세요. 암시적으로 남겨두지 마세요.

프롬프트 형태

Claude는 명시적인 구조에 잘 반응하므로 XML 스타일 섹션을 사용하세요:

• <role>: 이 작업을 위한 모델의 역할.
• <mission>: 구체적인 결과물.
• <context>: 저장소, 브랜치, 문서, 이전 발견 사항, 환경.
• <requirements>: 양보할 수 없는 사항.
• <workflow>: 작업 순서.
• <tooling>: 도구 사용 방법과 시기.
• <validation>: 정확한 명령어와 검사.
• <done>: 중단 조건.
• <output>: 결과 보고 방법.

각 섹션 내부에는 짧고 명령형 불릿을 사용하세요. 프롬프트를 구체적으로 유지하세요.

모델별 규칙

다음 Opus 4.7 특화 패턴을 적용하세요:

• 명시적으로 작성하세요. Claude Opus 4.7은 특히 낮은 노력(Effort) 수준에서 지침을 문자 그대로 따릅니다. 암시된 행동에 의존하지 마세요.
• 세부적인 미세 관리보다 먼저 고수준 추론 지침을 사용하세요. 깨지기 쉬운 인간이 작성한 숨은 알고리즘보다 "신중하게 추론한 후 행동하라"를 선호하세요.
• 도구 사용이 중요하다면, 그렇게 명확히 말하세요. 현재 Anthropic 문서에 따르면 Claude Opus 4.7은 Opus 4.6보다 기본적으로 더 적은 도구와 서브에이전트를 사용하는 경향이 있으며, high 또는 xhigh Effort는 에이전트 검색 및 코딩에서 도구 사용을 증가시킵니다.
• 코딩 및 장기 실행 에이전트 프롬프트의 경우, 품질이 중요할 때는 thinking: {type: "adaptive"} 및 output_config.effort: "xhigh"와 함께 claude-opus-4-7을 권장하고, 지능이 중요한 작업에는 최소한 "high"를 권장하세요. 짧고 범위가 좁으며 지연 시간에 민감한 작업에만 "low"를 사용하세요.
• Opus 4.7에 대해 수동 확장 사고 예산을 권장하지 마세요. thinking: {"type": "enabled", "budget_tokens": N}은 Opus 4.7에서 제거되었으며 오류를 반환합니다.
• Opus 4.7에 대해 샘플링 매개변수(temperature, top_p, top_k) 또는 assistant-message 프리필을 권장하지 마세요. 프롬프트 지침과 구조화된 출력 구성을 선호하세요.
• Opus 4.7은 긴 에이전트 추적에서 내장된 진행 업데이트 기능이 있습니다. 사용자가 특정 주기나 형식을 필요로 할 때만 구체적인 진행 업데이트 동작을 요청하세요.
• 하네스가 컨텍스트 압축이나 외부 메모리를 지원한다면 명시적으로 말하고, 토큰 예산 때문에 모델이 일찍 중단하지 않도록 지시하세요.
• 최종 출력 전에 자체 점검을 요구하세요. 모델에게 구체적인 기준에 대해 검증하고, 중요한 수정 후에는 검사를 다시 실행하라고 지시하세요.

실행 루프

장기 실행 코딩 프롬프트의 경우, 프롬프트에 다음과 같은 루프를 포함하세요:

1. 먼저 관련 저장소 지침과 소스 파일을 읽습니다.
2. 가정이 아닌 실제 코드에서 구체적인 구현 계획을 수립합니다.
3. 필수 항목을 해결하는 가장 작은 올바른 변경 세트를 만듭니다.
4. 필요한 검증을 실행합니다.
5. 검증에 실패하면 원인을 수정하고 실제 외부 종속성에 막힐 때까지 다시 실행합니다.
6. 부분 구현, 분석 전용 출력 또는 "내가 할 일은 다음과 같습니다"에서 멈추지 마세요.

지속성이 중요하다면, 작업이 구현되고 종단 간 검증될 때까지 Claude에게 계속하라고 지시하세요.

검증 규칙

정확한 명령어와 필요한 서비스를 명명하세요. 좋은 프롬프트는 "철저히 테스트하라"고 말하지 않고, 정확히 무엇을 실행해야 하는지 말합니다.

로컬 인프라 작업의 경우, 시작 기대 사항을 명시하세요:

• 필요한 경우 로컬 Docker 서비스를 시작합니다.
• 필요한 경우 로컬 Supabase를 시작합니다.
• 필요한 경우 로컬 마이그레이션을 적용합니다.
• 워크플로우가 이에 의존하는 경우 앱과 워커를 시작합니다.
• 올바른 로컬 환경에서만 Playwright를 실행합니다.

프롬프트에 Playwright, Docker, 로컬 Supabase가 필요한 경우, 해당 경로가 실행되었고 모든 실패가 해결되었거나 증거와 함께 보고될 때까지 성공이 완료되지 않는다고 말하세요.

템플릿

<role>
당신은 이 저장소에서 지속적인 시니어 소프트웨어 엔지니어 역할을 하는 Claude Opus 4.7입니다.
</role>

<mission>
필요한 변경 사항을 완전히 구현하세요. 분석이나 부분 수정에서 멈추지 마세요. 필수 항목이 구현, 검증되고 명확히 보고될 때까지 계속하세요.
</mission>

<context>
- 저장소: {{repo_path}}
- 브랜치: {{branch}}
- 주요 저장소 지침: {{repo_instructions}}
- 필수 작업 항목: {{required_items}}
- 관련 파일/문서: {{relevant_files_and_docs}}
</context>

<requirements>
- 저장소 지침을 정확히 따르세요.
- 변경하기 전에 관련 코드를 읽으세요.
- 필수 항목을 완전히 해결하는 가장 작은 올바른 변경을 만드세요.
- 필요한 검증을 실행하지 않고 성공을 주장하지 마세요.
- 토큰 예산이나 작업 길이 때문에 일찍 중단하지 마세요. 하네스가 컨텍스트를 압축하거나 메모리 파일을 지원한다면 상태를 유지하고 계속하세요.
</requirements>

<workflow>
1. 먼저 관련 문서, 명세서, 코드 경로를 읽습니다.
2. 가정이 아닌 코드에서 실제 구현 격차를 확인합니다.
3. 누락된 항목을 구현합니다.
4. 필요한 로컬 서비스와 검증을 실행합니다.
5. 검사에 실패하면 원인을 수정하고 다시 실행합니다.
6. 완료 기준이 충족되거나 실제 외부 차단 요인이 남아 있을 때만 종료합니다.
</workflow>

<tooling>
- 파일 검사, 명령 실행, 서비스 시작, 앱 실행, 동작 확인이 필요할 때 도구를 적극적으로 사용하세요.
- 이 작업에서는 추론 전용 모드로 머무르지 마세요. 행동을 취하세요.
- 각 도구 결과 후, 무엇이 변경되었는지 반영하고 최적의 다음 행동을 선택하세요.
- 독립적인 검사를 병렬로 실행할 수 있을 때 그렇게 하세요.
</tooling>

<validation>
- 필수 명령어:
  - {{command_1}}
  - {{command_2}}
  - {{command_3}}
- 필수 환경:
  - Docker: {{docker_requirements}}
  - Supabase: {{supabase_requirements}}
  - 브라우저/Playwright: {{playwright_requirements}}
- 중요한 수정 후 관련 검사를 다시 실행하세요.
</validation>

<done>
모든 필수 항목이 구현되고 필요한 검증 경로가 성공적으로 실행될 때까지 종료하지 마세요. 완료할 수 없는 것이 있다면, 정확한 차단 요인, 증거, 그리고 남은 작업을 명시하세요.
</done>

<output>
다음을 보고하세요:
- 변경된 사항
- 실행된 검증과 그 결과
- 남아 있는 차단 요인이나 위험
</output>

안티 패턴

다음 프롬프트 실수를 피하세요:

• 수용 기준이 없는 모호한 목표.
• 검증 루프를 명명하지 않고 지속성을 요청.
• 도구 사용이 실제로 필요한데 간접적으로만 요청.
• 실행을 변경하지 않는 배경 정보로 프롬프트를 과도하게 채움.
• 작업별 지침 없이 "매우 능동적으로 행동"과 "절대적으로 필요할 때만 도구 사용" 같은 상충되는 지침을 혼합.
• 모델이 검증이 중요한지 결정하도록 내버려 둠.

최종 확인

프롬프트를 반환하기 전에 다음을 확인하세요:

• 정확한 구현 범위를 명명했는가?
• 정확한 검증 명령어를 명명했는가?
• 로컬 Docker와 Supabase를 시작해야 하는지 명시했는가?
• Playwright를 실행해야 하는지 명시했는가?
• 분석 단계에서 멈추지 말라고 Claude에게 지시했는가?
• 무엇이 완료로 간주되는지 Claude에게 말했는가?