Skip to content

tool-description-agent-usage-notes.md

Latest commit

 

History

History
38 lines (36 loc) · 3.47 KB

tool-description-agent-usage-notes.md

File metadata and controls

38 lines (36 loc) · 3.47 KB

${TOOL_BASE_DESCRIPTION} ${TOOL_PARAMETERS_DESCRIPTION}

Usage notes:

  • Always include a short description (3-5 words) summarizing what the agent will do${GET_TIER_FN}
  • When the agent is done, it will return a single message back to you. The result returned by the agent is not visible to the user. To show the user the result, you should send a text message back to the user with a concise summary of the result.${!IS_TRUTHY_FN(PROCESS_OBJECT.env.CLAUDE_CODE_DISABLE_BACKGROUND_TASKS)&&!IS_SUBAGENT_CONTEXT_FN()&&!HAS_SUBAGENT_TYPES?`
  • You can optionally run agents in the background using the run_in_background parameter. When an agent runs in the background, you will be automatically notified when it completes — do NOT sleep, poll, or proactively check on its progress. Continue with other work or respond to the user instead.
  • Foreground vs background: Use foreground (default) when you need the agent's results before you can proceed — e.g., research agents whose findings inform your next steps. Use background when you have genuinely independent work to do in parallel.`:""}
  • To continue a previously spawned agent, use ${SEND_MESSAGE_TOOL_NAME} with the agent's ID or name as the to field. The agent resumes with its full context preserved. ${HAS_SUBAGENT_TYPES?"Each fresh Agent invocation with a subagent_type starts without context — provide a complete task description.":"Each Agent invocation starts fresh — provide a complete task description."}
  • The agent's outputs should generally be trusted
  • Clearly tell the agent whether you expect it to write code or just to do research (search, file reads, web fetches, etc.)${HAS_SUBAGENT_TYPES?"":", since it is not aware of the user's intent"}
  • If the agent description mentions that it should be used proactively, then you should try your best to use it without the user having to ask for it first. Use your judgement.
  • If the user specifies that they want you to run agents "in parallel", you MUST send a single message with multiple ${TOOL_OBJECT} tool use content blocks. For example, if you need to launch both a build-validator agent and a test-runner agent in parallel, send a single message with both tool calls.
  • You can optionally set isolation: "worktree" to run the agent in a temporary git worktree, giving it an isolated copy of the repository. The worktree is automatically cleaned up if the agent makes no changes; if changes are made, the worktree path and branch are returned in the result.${IS_SUBAGENT_CONTEXT_FN()?`
  • The run_in_background, name, team_name, and mode parameters are not available in this context. Only synchronous subagents are supported.:IS_TEAMMATE_CONTEXT_FN()?
  • The name, team_name, and mode parameters are not available in this context — teammates cannot spawn other teammates. Omit them to spawn a subagent.`:""}${ADDITIONAL_USAGE_NOTES}${EXTRA_USAGE_NOTES}

${HAS_SUBAGENT_TYPES?SUBAGENT_TYPE_DEFINITIONS:DEFAULT_AGENT_DESCRIPTION}