Update prompt to encourage community tool use.

This commit is contained in:
Christian Gunderman
2026-01-29 16:20:01 -08:00
parent 7fe4b92c22
commit 9373cd738d
2 changed files with 3 additions and 3 deletions

View File

@@ -7,7 +7,7 @@
import { describe, expect } from 'vitest';
import { evalTest } from './test-helper.js';
describe('automated_tool_use', () => {
describe('Automated tool use', () => {
/**
* Tests that the agent always utilizes --fix when calling eslint.
* We provide a 'lint' script in the package.json, which helps elicit

View File

@@ -195,7 +195,7 @@ export function renderPrimaryWorkflows(
When requested to perform tasks like fixing bugs, adding features, refactoring, or explaining code, follow this sequence:
${workflowStepUnderstand(options)}
${workflowStepPlan(options)}
3. **Implement:** Use the available tools (e.g., '${EDIT_TOOL_NAME}', '${WRITE_FILE_TOOL_NAME}' '${SHELL_TOOL_NAME}' ...) to act on the plan, strictly adhering to the project's established conventions (detailed under 'Core Mandates').
3. **Implement:** Use the available tools (e.g., '${EDIT_TOOL_NAME}', '${WRITE_FILE_TOOL_NAME}' '${SHELL_TOOL_NAME}' ...) to act on the plan. Prefer using ecosystem tools to perform subtasks automatically (e.g., 'eslint --fix', 'npm init') rather than making manual changes. Strictly adhere to the project's established conventions (detailed under 'Core Mandates').
4. **Verify (Tests):** If applicable and feasible, verify the changes using the project's testing procedures. Identify the correct test commands and frameworks by examining 'README' files, build/package configuration (e.g., 'package.json'), or existing test execution patterns. NEVER assume standard test commands. When executing test commands, prefer "run once" or "CI" modes to ensure the command terminates after completion.
5. **Verify (Standards):** VERY IMPORTANT: After making code changes, execute the project-specific build, linting and type-checking commands (e.g., 'tsc', 'npm run lint', 'ruff check .') that you have identified for this project (or obtained from the user). This ensures code quality and adherence to standards.${workflowVerifyStandardsSuffix(options.interactive)}
6. **Finalize:** After all verification passes, consider the task complete. Do not remove or revert any changes or created files (like tests). Await the user's next instruction.
@@ -230,7 +230,7 @@ ${shellEfficiencyGuidelines(options.enableShellEfficiency)}
## Tool Usage
- **Parallelism:** Execute multiple independent tool calls in parallel when feasible (i.e. searching the codebase).
- **Command Execution:** Use the '${SHELL_TOOL_NAME}' tool for running shell commands, remembering the safety rule to explain modifying commands first.${toolUsageInteractive(options.interactive)}${toolUsageRememberingFacts(options)}
- **Command Execution:** Use the '${SHELL_TOOL_NAME}' tool for running shell commands, remembering the safety rule to explain modifying commands first. When using tools to apply fixes (e.g. \`eslint --fix\`), prefer invoking the executable directly to ensure flags are passed correctly.${toolUsageInteractive(options.interactive)}${toolUsageRememberingFacts(options)}
- **Respect User Confirmations:** Most tool calls (also denoted as 'function calls') will first require confirmation from the user, where they will either approve or cancel the function call. If a user cancels a function call, respect their choice and do _not_ try to make the function call again. It is okay to request the tool call again _only_ if the user requests that same tool call on a subsequent prompt. When a user cancels a function call, assume best intentions from the user and consider inquiring if they prefer any alternative paths forward.
## Interaction Details