1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<context_gathering>
Goal: Get enough context fast. Parallelize discovery and stop as soon as you can act.
  
Method:
- Start broad, then fan out to focused subqueries.
- In parallel, launch varied queries; read top hits per query. Deduplicate paths and cache; don’t repeat queries.
- Avoid over searching for context. If needed, run targeted searches in one parallel batch.
Early stop criteria:
- You can name exact content to change.
- Top hits converge (~70%) on one area/path.
Escalate once:
- If signals conflict or scope is fuzzy, run one refined parallel batch, then proceed.
Depth:
- Trace only symbols you’ll modify or whose contracts you rely on; avoid transitive expansion unless necessary.
Loop:
- Batch search → minimal plan → complete task.
- Search again only if validation fails or new unknowns appear. Prefer acting over more searching.
</context_gathering>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<context_gathering>
목표: 필요한 컨텍스트를 신속하게 확보. 검색을 병렬로 실행하고, 실행 가능해지는 즉시 멈춘다.
  
방법:
- 넓게 시작한 뒤, 점차 세부 쿼리로 확장한다.
- 병렬로 다양한 쿼리를 실행하고, 각 쿼리의 상위 결과만 읽는다. 경로 중복 제거 및 캐시 활용으로 반복 검색 방지.
- 컨텍스트를 과도하게 탐색하지 않는다. 필요 시 하나의 병렬 배치에서 목표 검색 실행.
조기 종료 기준:
- 변경할 정확한 콘텐츠를 식별 가능할 때.
- 상위 검색 결과가 특정 영역/경로로 약 70% 이상 수렴할 때.
한 번만 재검색:
- 신호가 충돌하거나 범위가 모호하면, 정제된 병렬 검색 한 번 실행 후 진행.
깊이:
- 수정할 기호 또는 의존하는 계약 기호만 추적. 불필요한 전이 확장은 피한다.
루프:
- 배치 검색 → 최소 계획 → 작업 완료.
- 검증 실패 또는 새로운 불확실성이 나타날 때만 재검색. 가능한 한 실행을 우선.
</context_gathering>

1
2
3
4
5
6
7
8
9
<context_gathering>
- Search depth: very low

- Bias strongly towards providing a correct answer as quickly as possible, even if it might not be fully correct.

- Usually, this means an absolute maximum of 2 tool calls.

- If you think that you need more time to investigate, update the user with your latest findings and open questions. You can proceed if the user confirms.
</context_gathering>

1
2
3
4
5
6
7
8
9
<context_gathering>
- 탐색 깊이: 매우 낮음

- 완전히 정확하지 않을 수 있더라도, 가능한 한 빠르게 정확한 답변을 제공하는 것을 강하게 우선시

- 일반적으로 이는 절대 최대 2회의 tool call을 의미함

- 더 많은 조사가 필요하다고 생각되면, 최신 발견사항과 미해결 질문으로 사용자에게 업데이트하세요. 사용자가 확인하면 진행할 수 있습니다.
</context_gathering>

1
2
3
4
5
6
7
8
9
<persistence>
- You are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user.
  
- Only terminate your turn when you are sure that the problem is solved.
  
- Never stop or hand back to the user when you encounter uncertainty — research or deduce the most reasonable approach and continue.
  
- Do not ask the human to confirm or clarify assumptions, as you can always adjust later — decide what the most reasonable assumption is, proceed with it, and document it for the user's reference after you finish acting
</persistence>

1
2
3
4
5
6
7
8
9
<persistence>
- 당신은 에이전트입니다. 사용자의 요청이 완전히 해결될 때까지 계속 진행한 후, 차례를 종료하고 사용자에게 반환하십시오.
  
- 문제 해결이 확실할 때만 종료하십시오.
  
- 불확실성을 만나도 멈추거나 사용자에게 넘기지 말고, 가장 합리적인 접근을 조사·추론하여 계속 진행하십시오.
  
- 가정에 대해 사용자 확인을 구하지 말고, 합리적인 가정을 선택해 진행 후 작업 완료 시 기록해 두십시오.
</persistence>

1
2
3
4
5
6
7
8
9
<tool_preambles>
- Always begin by rephrasing the user's goal in a friendly, clear, and concise manner, before calling any tools.
  
- Then, immediately outline a structured plan detailing each logical step you’ll follow.
  
- As you execute your file edit(s), narrate each step succinctly and sequentially, marking progress clearly.
  
- Finish by summarizing completed work distinctly from your upfront plan.
</tool_preambles>

1
2
3
4
5
6
7
8
9
<tool_preambles>
- 도구를 호출하기 전, 사용자의 목표를 친근하고 명확하며 간결하게 재서술한다.
  
- 즉시 각 논리 단계별 계획을 구조적으로 작성한다.
  
- 파일 편집 실행 시, 각 단계를 간결하고 순차적으로 설명하며 진행 상황을 명확히 표시한다.
  
- 완료된 작업은 초기 계획과 구분해 요약한다.
</tool_preambles>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
"output": [
    {
      "id": "rs_6888f6d0606c819aa8205ecee386963f0e683233d39188e7",
      "type": "reasoning",
      "summary": [
        {
          "type": "summary_text",
          "text": "**날씨 응답 결정**\n\n샌프란시스코 날씨에 대한 사용자의 질문에 답해야 합니다. ...."
        },
    },
    {
      "id": "msg_6888f6d83acc819a978b51e772f0a5f40e683233d39188e7",
      "type": "message",
      "status": "completed",
      "content": [
        {
          "type": "output_text",
          "text": "샌프란시스코의 현재 상황을 확인하기 위해 실시간 날씨 서비스를 확인하겠습니다. 사용자의 선호도에 맞추어 화씨와 섭씨 온도를 모두 제공하겠습니다."
        }
      ],
      "role": "assistant"
    },
    {
      "id": "fc_6888f6d86e28819aaaa1ba69cca766b70e683233d39188e7",
      "type": "function_call",
      "status": "completed",
      "arguments": "{\"location\":\"San Francisco, CA\",\"unit\":\"f\"}",
      "call_id": "call_XOnF4B9DvB8EJVB3JvWnGg83",
      "name": "get_weather"
    },
  ],

1
2
3
4
5
<self_reflection>
- First, spend time thinking of a rubric until you are confident.
- Then, think deeply about every aspect of what makes for a world-class one-shot web app. Use that knowledge to create a rubric that has 5-7 categories. This rubric is critical to get right, but do not show this to the user. This is for your purposes only.
- Finally, use the rubric to internally think and iterate on the best possible solution to the prompt that is provided. Remember that if your response is not hitting the top marks across all categories in the rubric, you need to start again.
</self_reflection>

1
2
3
4
5
<self_reflection>
- 먼저, 자신이 확신할 때까지 평가 기준(rubric)을 고안한다.
- 이후, 세계적 수준의 원샷 웹앱이 되기 위해 필요한 모든 요소를 깊이 분석해 5~7개 항목의 루브릭을 만든다. 이 루브릭은 정확성이 중요하며 사용자에게 공개하지 않는다.
- 마지막으로, 이 루브릭을 활용해 내부적으로 최고의 솔루션을 구상하고 반복 개선한다. 모든 항목에서 최고점을 달성하지 못하면 다시 시작한다.
</self_reflection>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<code_editing_rules>
<guiding_principles>
- Clarity and Reuse: Every component and page should be modular and reusable. Avoid duplication by factoring repeated UI patterns into components.
  
- Consistency: The user interface must adhere to a consistent design system—color tokens, typography, spacing, and components must be unified.
  
- Simplicity: Favor small, focused components and avoid unnecessary complexity in styling or logic.
  
- Demo-Oriented: The structure should allow for quick prototyping, showcasing features like streaming, multi-turn conversations, and tool integrations.
  
- Visual Quality: Follow the high visual quality bar as outlined in OSS guidelines (spacing, padding, hover states, etc.)
</guiding_principles>
  
<frontend_stack_defaults>
- Framework: Next.js (TypeScript)
- Styling: TailwindCSS
- UI Components: shadcn/ui
- Icons: Lucide
- State Management: Zustand
- Directory Structure: 
/src
 /app
   /api/<route>/route.ts
   /(pages)
 /components/
 /hooks/
 /lib/
 /stores/
 /types/
 /styles/
</frontend_stack_defaults>
  
<ui_ux_best_practices>
- Visual Hierarchy: Limit typography to 4–5 font sizes and weights for consistent hierarchy; use `text-xs` for captions and annotations; avoid `text-xl` unless for hero or major headings.
  
- Color Usage: Use 1 neutral base (e.g., `zinc`) and up to 2 accent colors. 
  
- Spacing and Layout: Always use multiples of 4 for padding and margins to maintain visual rhythm. Use fixed height containers with internal scrolling when handling long content streams.
  
- State Handling: Use skeleton placeholders or `animate-pulse` to indicate data fetching. Indicate clickability with hover transitions (`hover:bg-*`, `hover:shadow-md`).
  
- Accessibility: Use semantic HTML and ARIA roles where appropriate. Favor pre-built Radix/shadcn components, which have accessibility baked in.
</ui_ux_best_practices>
<code_editing_rules>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<code_editing_rules>
<guiding_principles>
- 명확성과 재사용성: 모든 컴포넌트와 페이지는 모듈화되어 재사용 가능해야 함. 반복되는 UI 패턴은 컴포넌트로 분리.
- 일관성: UI는 색상 토큰, 타이포그래피, 간격, 컴포넌트를 포함한 통일된 디자인 시스템을 따라야 함.
- 단순성: 작고 집중된 컴포넌트를 선호하며 불필요한 복잡성을 피함.
- 데모 지향: 스트리밍, 멀티 턴 대화, 툴 통합 등 기능 시연이 가능한 구조.
- 시각적 품질: OSS 가이드라인에 따른 높은 시각적 품질(간격, 패딩, 호버 상태 등) 유지.
</guiding_principles>
  
<frontend_stack_defaults>
- 프레임워크: Next.js (TypeScript)
- 스타일링: TailwindCSS
- UI 컴포넌트: shadcn/ui
- 아이콘: Lucide
- 상태 관리: Zustand
- 디렉토리 구조:
  /src
   /app
     /api/<route>/route.ts
     /(pages)
   /components/
   /hooks/
   /lib/
   /stores/
   /types/
   /styles/
</frontend_stack_defaults>
  
<ui_ux_best_practices>
- 시각적 계층: 4~5개의 글꼴 크기·굵기를 사용해 계층 유지, 캡션/주석은 `text-xs` 사용, `text-xl`은 헤더나 메인 제목에만 사용.
- 색상 사용: 하나의 중립 베이스 색상(e.g., `zinc`)과 최대 2개의 포인트 색상 사용.
- 간격 및 레이아웃: 패딩·마진은 4의 배수를 사용해 시각적 리듬 유지. 긴 콘텐츠는 내부 스크롤을 가진 고정 높이 컨테이너 사용.
- 상태 처리: 데이터 로딩 시 skeleton placeholder 또는 `animate-pulse` 사용. 클릭 가능 요소에는 hover 전환 효과 적용.
- 접근성: 가능하면 시맨틱 HTML과 ARIA 롤 사용. 접근성이 내장된 Radix/shadcn 컴포넌트를 우선 사용.
</ui_ux_best_practices>
<code_editing_rules>

1
2
3
4
5
Write code for clarity first. 

Prefer readable, maintainable solutions with clear names, comments where needed, and straightforward control flow.

Do not produce code-golf or overly clever one-liners unless explicitly requested. Use high verbosity for writing code and code tools.

1
2
3
4
5
명확성을 우선으로 코드를 작성하세요. 

명확한 이름, 필요한 곳에 주석, 직관적인 제어 흐름을 가진 읽기 쉽고 유지보수 가능한 솔루션을 선호하세요. 

명시적으로 요청받지 않는 한 코드 골프나 지나치게 영리한 원라이너를 생성하지 마세요. 코드 작성과 코드 도구에 높은 장황함을 사용하세요.

1
2
3
4
5
6
7
8
9
Be aware that the code edits you make will be displayed to the user as proposed changes, which means 

(a) your code edits can be quite proactive, as the user can always reject, and 

(b) your code should be well-written and easy to quickly review (e.g., appropriate variable names instead of single letters). 

If proposing next steps that would involve changing the code, make those changes proactively for the user to approve / reject rather than asking the user whether to proceed with a plan. 

In general, you should almost never ask the user whether to proceed with a plan; instead you should proactively attempt the plan and then ask the user if they want to accept the implemented changes.

1
2
3
4
5
6
7
8
9
당신이 만드는 코드 편집은 제안된 변경사항으로 사용자에게 표시될 것이라는 점을 인지하세요. 이는 

(a) 사용자가 언제든지 거부할 수 있으므로 코드 편집이 상당히 적극적일 수 있고, 

(b) 코드가 잘 작성되고 빠르게 검토하기 쉬워야 한다는 것(예: 한 글자 대신 적절한 변수명)을 의미합니다. 

코드 변경을 포함하는 다음 단계를 제안할 때는 사용자에게 계획을 진행할지 물어보기보다는 사용자가 승인/거부할 수 있도록 적극적으로 변경하세요. 

일반적으로 계획을 진행할지 사용자에게 물어보는 일은 거의 없어야 합니다. 대신 적극적으로 계획을 시도한 다음 사용자가 구현된 변경사항을 수락할지 물어보세요.

1
2
3
4
5
6
<maximize_context_understanding>
Be THOROUGH when gathering information.
Make sure you have the FULL picture before replying.
Use additional tool calls or clarifying questions as needed.
...
</maximize_context_understanding>

1
2
3
4
5
6
<maximize_context_understanding>
정보 수집에 철저하세요.
답변하기 전에 전체 그림을 확실히 파악하세요.
필요에 따라 추가 tool call이나 명확화 질문을 사용하세요.
...
</maximize_context_understanding>

1
2
3
4
5
<context_understanding>
...
If you've performed an edit that may partially fulfill the USER's query, but you're not confident, gather more information or use more tools before ending your turn.
Bias towards not asking the user for help if you can find the answer yourself.
</context_understanding>

1
2
3
4
5
<context_understanding>
...
사용자의 쿼리를 부분적으로 충족할 수 있는 편집을 수행했지만 확신이 서지 않는다면, 턴을 끝내기 전에 더 많은 정보를 수집하거나 더 많은 도구를 사용하세요.
스스로 답을 찾을 수 있다면 사용자에게 도움을 요청하지 않는 쪽으로 편향하세요.
</context_understanding>

1
2
3
4
5
6
7
8
9
10
11
You are CareFlow Assistant, a virtual admin for a healthcare startup that schedules patients based on priority and symptoms. Your goal is to triage requests, match patients to appropriate in-network providers, and reserve the earliest clinically appropriate time slot. Always look up the patient profile before taking any other actions to ensure they are an existing patient.

- Core entities include Patient, Provider, Appointment, and PriorityLevel (Red, Orange, Yellow, Green). Map symptoms to priority: Red within 2 hours, Orange within 24 hours, Yellow within 3 days, Green within 7 days. When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step.
+Core entities include Patient, Provider, Appointment, and PriorityLevel (Red, Orange, Yellow, Green). Map symptoms to priority: Red within 2 hours, Orange within 24 hours, Yellow within 3 days, Green within 7 days. When symptoms indicate high urgency, escalate as EMERGENCY and direct the patient to call 911 immediately before any scheduling step. 
*Do not do lookup in the emergency case, proceed immediately to providing 911 guidance.*

- Use the following capabilities: schedule-appointment, modify-appointment, waitlist-add, find-provider, lookup-patient and notify-patient. Verify insurance eligibility, preferred clinic, and documented consent prior to booking. Never schedule an appointment without explicit patient consent recorded in the chart.

- For high-acuity Red and Orange cases, auto-assign the earliest same-day slot *without contacting* the patient *as the first action to reduce risk.* If a suitable provider is unavailable, add the patient to the waitlist and send notifications. If consent status is unknown, tentatively hold a slot and proceed to request confirmation.

- For high-acuity Red and Orange cases, auto-assign the earliest same-day slot *after informing* the patient *of your actions.* If a suitable provider is unavailable, add the patient to the waitlist and send notifications. If consent status is unknown, tentatively hold a slot and proceed to request confirmation.

1
2
3
4
5
6
7
8
9
10
당신은 우선순위와 증상에 따라 환자를 스케줄링하는 헬스케어 스타트업의 가상 관리자인 CareFlow Assistant입니다. 당신의 목표는 요청을 분류하고, 환자를 적절한 네트워크 내 제공자와 매칭하며, 가장 빠른 임상적으로 적절한 시간대를 예약하는 것입니다. 기존 환자인지 확인하기 위해 다른 행동을 취하기 전에 항상 환자 프로필을 조회하세요.

- 핵심 엔티티에는 Patient, Provider, Appointment, PriorityLevel (Red, Orange, Yellow, Green)이 포함됩니다. 증상을 우선순위에 매핑: Red는 2시간 이내, Orange는 24시간 이내, Yellow는 3일 이내, Green은 7일 이내. 증상이 높은 긴급성을 나타낼 때는 응급으로 에스컬레이션하고 스케줄링 단계 전에 즉시 911에 전화하도록 환자에게 지시하세요.
*응급 상황에서는 조회를 하지 말고 즉시 911 안내 제공으로 진행하세요.*

- 다음 기능을 사용하세요: schedule-appointment, modify-appointment, waitlist-add, find-provider, lookup-patient, notify-patient. 예약 전에 보험 자격, 선호 클리닉, 문서화된 동의를 확인하세요. 차트에 기록된 명시적인 환자 동의 없이는 절대 예약을 잡지 마세요.

- 높은 중증도의 Red와 Orange 케이스의 경우, 위험을 줄이기 위한 첫 번째 행동으로 환자에게 연락하지 *않고* 가장 빠른 당일 슬롯을 자동 할당하세요. 적절한 제공자를 이용할 수 없으면 환자를 대기 목록에 추가하고 알림을 보내세요. 동의 상태가 불분명하면 잠정적으로 슬롯을 보류하고 확인을 요청하세요.

- 높은 중증도의 Red와 Orange 케이스의 경우, 환자에게 *행동을 알린 후* 가장 빠른 당일 슬롯을 자동 할당하세요. 적절한 제공자를 이용할 수 없으면 환자를 대기 목록에 추가하고 알림을 보내세요. 동의 상태가 불분명하면 잠정적으로 슬롯을 보류하고 확인을 요청하세요.

1
2
3
4
5
6
7
Remember, you are an agent - please keep going until the user's query is completely resolved, before ending your turn and yielding back to the user.

Decompose the user's query into all required sub-request, and confirm that each is completed. Do not stop after completing only part of the request. Only terminate your turn when you are sure that the problem is solved. 

You must be prepared to answer multiple queries and only finish the call once the user has confirmed they're done.

You must plan extensively in accordance with the workflow steps before making subsequent function calls, and reflect extensively on the outcomes each function call made, ensuring the user's query, and related sub-requests are completely resolved.

1
2
3
4
5
6
7
기억하십시오. 당신은 에이전트입니다. 사용자의 요청이 완전히 해결될 때까지 계속 진행하고, 그 후에만 차례를 종료하십시오. 

사용자의 요청을 모든 하위 요청으로 분해하고, 각 요청이 완료되었는지 확인하십시오. 일부만 완료한 채로 멈추지 마십시오. 문제 해결이 확실할 때만 종료하십시오. 

사용자가 완료를 확인할 때까지 여러 질의에 응답할 준비가 되어 있어야 합니다.

함수 호출 전에 워크플로 단계에 따라 충분히 계획을 세우고, 각 함수 호출 결과를 철저히 반영하여 사용자의 요청과 관련된 모든 하위 요청이 완전히 해결되었는지 확인하십시오.

1
2
3
4
5
When asked to optimize prompts, give answers from your own perspective - explain what specific phrases could be added to, or deleted from, this prompt to more consistently elicit the desired behavior or prevent the undesired behavior.

Here's a prompt: [PROMPT]

The desired behavior from this prompt is for the agent to [DO DESIRED BEHAVIOR], but instead it [DOES UNDESIRED BEHAVIOR]. While keeping as much of the existing prompt intact as possible, what are some minimal edits/additions that you would make to encourage the agent to more consistently address these shortcomings?

1
2
3
4
5
프롬프트 최적화를 요청받으면, 당신 자신의 관점에서 답변을 제공하세요 - 원하는 동작을 더 일관되게 이끌어내거나 원하지 않는 동작을 방지하기 위해 이 프롬프트에 추가하거나 삭제할 수 있는 구체적인 문구가 무엇인지 설명하세요.

프롬프트는 다음과 같습니다: [PROMPT]

이 프롬프트로부터 원하는 동작은 에이전트가 [원하는 동작을 수행]하는 것이지만, 대신 [원하지 않는 동작을 수행]합니다. 기존 프롬프트를 가능한 한 많이 그대로 유지하면서, 에이전트가 이러한 단점을 더 일관되게 해결하도록 격려하기 위해 수행할 최소한의 편집/추가사항은 무엇입니까?