thinking이 기본. effort high 이하에서는 비활성화 할 수 있지만 추천하지 않음
프롬프트 가이드
기본 응답이 기존 Opus 모델보다 길기 때문에, 짧은 간결성 지시가 효과적
Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.
Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.
산출물의 길이도 기존 모델보다 긴 경우가 많음
문서 포함 시 길이 보정 지시를 명시하는 것이 좋음
Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.
자기가 알아서 검증 하려고 함
검증을 명시적으로 시키는 것은 중복 작업, 효율 떨어짐
요청되지 않은 작업이나 범위로 확장하려고 함
좁은 작업에서는 범위를 명시적으로 제한해야 함
Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.
서브에이전트한테 더 쉽게 위임함
어려운 작업에는 이득이지만, 작고 쉬운 작업에는 비용과 시간이 손해
어떤 상황에 위임할지 명시하거나, 에이전트 수에 상한을 두는 것이 좋음
Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.
자기검증을 기본적으로 잘함
"답을 다시 확인해라" 같은 내용은 같은 작업 두번 하게 되어서 좋지 않음
정정한 내용에 대한 언급을 많이 하니까, 사용자 대상 제품 등 과한 정정 언급이 필요하지 않은 경우는 명확히 적어두기
Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.