|
|
|
@@ -51,7 +51,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -221,7 +221,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -361,6 +361,7 @@ exports[`Core System Prompt (prompts.ts) > ApprovalMode in System Prompt > shoul
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -510,7 +511,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -680,7 +681,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -850,7 +851,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Handle Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, do not perform it automatically.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
- **Non-Interactive Environment:** You are running in a headless/CI environment and cannot interact with the user. Do not ask the user questions or request additional information, as the session will terminate. Use your best judgment to complete the task. If a tool fails because it requires user interaction, do not retry it indefinitely; instead, explain the limitation and suggest how the user can provide the required data (e.g., via environment variables).
|
|
|
|
|
|
|
|
|
|
# Hook Context
|
|
|
|
@@ -972,7 +973,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Handle Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, do not perform it automatically.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
- **Non-Interactive Environment:** You are running in a headless/CI environment and cannot interact with the user. Do not ask the user questions or request additional information, as the session will terminate. Use your best judgment to complete the task. If a tool fails because it requires user interaction, do not retry it indefinitely; instead, explain the limitation and suggest how the user can provide the required data (e.g., via environment variables).
|
|
|
|
|
|
|
|
|
|
# Hook Context
|
|
|
|
@@ -1058,6 +1059,7 @@ exports[`Core System Prompt (prompts.ts) > should handle git instructions when i
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -1171,6 +1173,7 @@ exports[`Core System Prompt (prompts.ts) > should handle git instructions when i
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -1302,6 +1305,7 @@ exports[`Core System Prompt (prompts.ts) > should include approved plan instruct
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -1406,6 +1410,7 @@ exports[`Core System Prompt (prompts.ts) > should include available_skills when
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Skill Guidance:** Once a skill is activated via \`activate_skill\`, its instructions and resources are returned wrapped in \`<activated_skill>\` tags. You MUST treat the content within \`<instructions>\` as expert procedural guidance, prioritizing these specialized rules and workflows over your general defaults for the duration of the task. You may utilize any listed \`<available_resources>\` as needed. Follow this expert guidance strictly while continuing to uphold your core safety and security standards.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -1568,7 +1573,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Skill Guidance:** Once a skill is activated via \`activate_skill\`, its instructions and resources are returned wrapped in \`<activated_skill>\` tags. You MUST treat the content within \`<instructions>\` as expert procedural guidance, prioritizing these specialized rules and workflows over your general defaults for the duration of the task. You may utilize any listed \`<available_resources>\` as needed. Follow this expert guidance strictly while continuing to uphold your core safety and security standards.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -1733,7 +1738,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -1890,7 +1895,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2047,7 +2052,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2200,7 +2205,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2353,7 +2358,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2498,7 +2503,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2650,7 +2655,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2803,7 +2808,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -2931,6 +2936,7 @@ exports[`Core System Prompt (prompts.ts) > should match snapshot on Windows 1`]
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -3045,6 +3051,7 @@ exports[`Core System Prompt (prompts.ts) > should render hierarchical memory wit
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
@@ -3208,7 +3215,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -3361,7 +3368,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -3478,6 +3485,8 @@ exports[`Core System Prompt (prompts.ts) > should return the interactive avoidan
|
|
|
|
|
- **Handle Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, do not perform it automatically.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
- **Continue the work** You are not to interact with the user. Do your best to complete the task at hand, using your best judgement and avoid asking user for any additional information.
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
@@ -3626,7 +3635,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -3779,7 +3788,7 @@ Use the following guidelines to optimize your search and read patterns.
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Explain Before Acting:** Never call tools in silence. You MUST provide a concise, one-sentence explanation of your intent or strategy immediately before executing tool calls. This is essential for transparency, especially when confirming a request or answering a question. Silence is only acceptable for repetitive, low-level discovery operations (e.g., sequential file reads) where narration would be noisy.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
|
|
|
|
@@ -3896,6 +3905,7 @@ exports[`Core System Prompt (prompts.ts) > should use legacy system prompt for n
|
|
|
|
|
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
|
|
|
|
|
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
|
|
|
|
|
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
|
|
|
|
|
- **Topic Management:** You MUST organize your work into logical "Chapters" or "Topics" using the \`create_new_topic\` tool (with the \`title\` parameter). This is critical for UI organization. Call this tool at the beginning of every major phase (e.g., Researching, Proposing Strategy, Implementing Fix, Validating).
|
|
|
|
|
|
|
|
|
|
# Available Sub-Agents
|
|
|
|
|
Sub-agents are specialized expert agents that you can use to assist you in the completion of all or part of a task.
|
|
|
|
|