mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-05-14 22:02:59 -07:00
fix(core): address PR feedback on system prompt optimizations
This commit is contained in:
Abhijit Balaji
@@ -24,10 +24,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -39,8 +38,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -212,10 +211,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -227,8 +225,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -521,10 +519,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -536,8 +533,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -709,10 +706,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -724,8 +720,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -793,7 +789,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -895,10 +891,10 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Execute, Test, and Verify:** Whenever possible, consolidate writing/modifying code and running verification commands into the same turn. For tasks requiring multiple sequential edits to the same file or complex multi-step implementations, allow for multi-turn workflows.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -910,8 +906,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -948,7 +944,7 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use \`grep_search\` or \`glob\` directly in parallel. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**. For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use \`grep_search\` or \`glob\` directly in parallel. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -1032,10 +1028,10 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Execute, Test, and Verify:** Whenever possible, consolidate writing/modifying code and running verification commands into the same turn. For tasks requiring multiple sequential edits to the same file or complex multi-step implementations, allow for multi-turn workflows.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -1047,8 +1043,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -1085,7 +1081,7 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -1650,10 +1646,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -1665,8 +1660,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -1747,7 +1742,7 @@ You have access to the following specialized skills. To activate a skill and rec
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -1832,10 +1827,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -1847,8 +1841,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -1916,7 +1910,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2005,10 +1999,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2020,8 +2013,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2089,7 +2082,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2178,10 +2171,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2193,8 +2185,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2262,7 +2254,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2347,10 +2339,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2362,8 +2353,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2431,7 +2422,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2516,10 +2507,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2531,8 +2521,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2602,7 +2592,7 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
|
||||
|
||||
**State Transition Override:** You are now in **Execution Mode**. All previous "Read-Only", "Plan Mode", and "ONLY FOR PLANS" constraints are **immediately lifted**. You are explicitly authorized and required to use tools to modify source code and environment files to implement the approved plan. Begin executing the steps of the plan immediately.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** An approved plan is available for this task. Treat this file as your single source of truth. You MUST read this file before proceeding. If you discover new requirements or need to change the approach, confirm with the user and update this plan file to reflect the updated design decisions or discovered requirements. Once all implementation and verification steps are finished, provide a **final summary** of the work completed against the plan and offer clear **next steps** to the user (e.g., 'Open a pull request').
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2679,10 +2669,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2694,8 +2683,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2763,7 +2752,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use search tools extensively to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.** If the request is ambiguous, broad in scope, or involves architectural decisions or cross-cutting changes, use the \`enter_plan_mode\` tool to safely research and design your strategy. Do NOT use Plan Mode for straightforward bug fixes, answering questions, or simple inquiries.
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use search tools extensively to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.** If the request is ambiguous, broad in scope, or involves architectural decisions or cross-cutting changes, use the \`enter_plan_mode\` tool to safely research and design your strategy. Do NOT use Plan Mode for straightforward bug fixes, answering questions, or simple inquiries.
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -2847,10 +2836,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -2862,8 +2850,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -2931,7 +2919,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -3143,10 +3131,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -3158,8 +3145,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -3227,7 +3214,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -3569,10 +3556,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -3584,8 +3570,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -3653,7 +3639,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -3738,10 +3724,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -3753,8 +3738,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -3822,7 +3807,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -4021,10 +4006,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -4036,8 +4020,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -4105,7 +4089,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
@@ -4190,10 +4174,9 @@ Consider the following when estimating the cost of your approach:
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`run_shell_command\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`run_shell_command\` instead of the \`replace\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to grep_search, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like grep_search to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -4205,8 +4188,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like grep_search and glob with a conservative result count (\`total_max_matches\`) and a narrow scope (\`include_pattern\` and \`exclude_pattern\` parameters).
|
||||
- **Searching and editing:** utilize search tools like grep_search with a conservative result count and a narrow scope. Use \`context\`, \`before\`, and/or \`after\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -4274,7 +4257,7 @@ For example:
|
||||
## Development Lifecycle
|
||||
Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
|
||||
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Use \`grep_search\` and \`glob\` search tools extensively (in parallel if independent) to understand file structures, existing code patterns, and conventions. Use \`read_file\` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
|
||||
2. **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy.
|
||||
3. **Execution:** For each sub-task:
|
||||
- **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
|
||||
|
||||
@@ -210,11 +210,13 @@ Consider the following when estimating the cost of your approach:
|
||||
|
||||
Use the following guidelines to optimize your search and read patterns.
|
||||
<guidelines>
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`${SHELL_TOOL_NAME}\` using shell logic (\`&&\`, \`||\`).
|
||||
- **Execute, Test, and Verify in ONE Turn:** When writing or modifying a script, compile/run it AND run all verification commands (e.g., \`pytest\`, \`ls -l\`) in the SAME turn. NEVER write code in one turn and test or verify it in the next.
|
||||
- **Turn Minimization (CRITICAL):** Consolidate your actions. Instead of executing sequential simple shell commands across multiple turns for discovery, mutation, and testing, combine these into a single comprehensive multi-line script executed via \`${SHELL_TOOL_NAME}\` using shell logic (\`&&\`, \`||\`).${
|
||||
options.interactive
|
||||
? '\n- **Reviewability:** In interactive mode, prioritize clarity for the user. While you should still avoid unnecessary turns, ensure that your command outputs are readable and that major changes are presented in a way that is easy to review.'
|
||||
: "\n- **Execute, Test, and Verify:** Whenever possible, consolidate writing/modifying code and running verification commands into the same turn. For tasks requiring multiple sequential edits to the same file or complex multi-step implementations, allow for multi-turn workflows.\n- **Aggressive Command Chaining:** Use `cat << 'EOF' > file` to write code, followed by compiling, running, and checking logs, all in ONE turn."
|
||||
}
|
||||
- **Ban on Piecemeal Probing:** NEVER probe datasets, logs, or file structures turn-by-turn. If you need to understand large data, write a single profiling script that outputs all necessary statistics, schema information, and sample data in ONE turn.
|
||||
- **Aggressive Command Chaining:** Use \`cat << 'EOF' > file\` to write code, followed by compiling, running, and checking logs, all in ONE turn.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\`, \`awk\`, or \`python\` within a \`${SHELL_TOOL_NAME}\` instead of the \`${EDIT_TOOL_NAME}\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- **Surgical Edits:** For surgical edits in large files, prefer using inline \`sed\` or \`awk\` within a \`${SHELL_TOOL_NAME}\` instead of the \`${EDIT_TOOL_NAME}\` tool to gain more flexible control and avoid 'Content Mismatch' errors.
|
||||
- Combine turns whenever possible by utilizing parallel searching and reading and by requesting enough context by passing context, before, or after to ${GREP_TOOL_NAME}, to enable you to skip using an extra turn reading the file.
|
||||
- Prefer using tools like ${GREP_TOOL_NAME} to identify points of interest instead of reading lots of files individually.
|
||||
- If you need to read multiple ranges in a file, do so parallel, in as few turns as possible.
|
||||
@@ -226,8 +228,8 @@ Use the following guidelines to optimize your search and read patterns.
|
||||
</guidelines>
|
||||
|
||||
<examples>
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v uv python3 gcc\`.
|
||||
- **Python Tooling:** Proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing and no other convention exists, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\` on macOS/Linux, \`brew install uv\`, or standalone installers) if the environment allows; otherwise, fall back to standard \`python3\` and \`pip\`.
|
||||
- **Initial Reconnaissance & Testing:** Run ONE command to gather project context and environment constraints: \`find . -name "*test*" -type f -exec cat {} +; uname -a; command -v <relevant_package_manager> <compiler>\`.
|
||||
- **Python Tooling:** When working on Python projects, proactively check for established project conventions (e.g., \`poetry\`, \`hatch\`, \`pdm\`). If such a tool is used, prefer it. Otherwise, prefer \`uv\` for high-performance environment management (\`uv run\`, \`uv pip\`). If \`uv\` is missing, proactively attempt to install it using officially recommended methods (e.g., \`curl -LsSf https://astral.sh/uv/install.sh | sh\`, \`brew install uv\`) if the environment allows; otherwise, fall back to standard alternatives (e.g., \`python3\`, \`pip\`).
|
||||
- **Searching:** utilize search tools like ${GREP_TOOL_NAME} and ${GLOB_TOOL_NAME} with a conservative result count (\`${GREP_PARAM_TOTAL_MAX_MATCHES}\`) and a narrow scope (\`${GREP_PARAM_INCLUDE_PATTERN}\` and \`${GREP_PARAM_EXCLUDE_PATTERN}\` parameters).
|
||||
- **Searching and editing:** utilize search tools like ${GREP_TOOL_NAME} with a conservative result count and a narrow scope. Use \`${GREP_PARAM_CONTEXT}\`, \`${GREP_PARAM_BEFORE}\`, and/or \`${GREP_PARAM_AFTER}\` to request enough context to avoid the need to read the file before editing matches.
|
||||
- **Understanding:** minimize turns needed to understand a file. It's most efficient to read small files in their entirety.
|
||||
@@ -704,10 +706,10 @@ function workflowStepResearch(options: PrimaryWorkflowsOptions): string {
|
||||
subAgentSearch = ` For **simple, targeted searches** (like finding a specific function name, file path, or variable declaration), use ${toolsStr} directly in parallel.`;
|
||||
}
|
||||
|
||||
return `1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**.${subAgentSearch} Use ${formatToolName(READ_FILE_TOOL_NAME)} to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
|
||||
return `1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements. Utilize specialized sub-agents (e.g., \`codebase_investigator\`) as the primary mechanism for initial discovery when the task involves **complex refactoring, codebase exploration or system-wide analysis**.${subAgentSearch} Use ${formatToolName(READ_FILE_TOOL_NAME)} to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
|
||||
}
|
||||
|
||||
return `1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **Your absolute first action must be to find and read project tests** to anchor yourself to the ground truth and extract requirements.${searchSentence} Use ${formatToolName(READ_FILE_TOOL_NAME)} to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
|
||||
return `1. **Research (CRITICAL):** Systematically map the codebase and validate assumptions. **When implementing features or fixing bugs, prioritize finding and reading project tests** to anchor yourself to the ground truth and extract requirements.${searchSentence} Use ${formatToolName(READ_FILE_TOOL_NAME)} to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**${suggestion}`;
|
||||
}
|
||||
|
||||
function workflowStepStrategy(options: PrimaryWorkflowsOptions): string {
|
||||
|
||||
Reference in New Issue
Block a user