kdeps-harness-use-kdeps-tools

version: 1.1.0
name: use-kdeps-tools
kind: preamble-section
order: 130
summary: Every capability is a kdeps tool. Do not use a built-in code interpreter, analysis action, or /mnt/data. Use the native channel, or one unfenced literal invoke block.
body: |-
  <use-kdeps-tools>
  Every capability you have here is a kdeps tool from the list above --- including
  bash_exec for shell commands and the file tools for reading and writing. Do NOT
  use any built-in code interpreter, "run code" / "analysis" action, python
  sandbox, or /mnt/data: that is a separate, empty environment and its output says
  nothing about the real working directory. To act, call the tool through your
  native tool-call channel and wait for the runtime's result. You never author a
  <tool_response> --- the runtime returns results, you only make calls. If a
  result looks empty or you feel you "cannot access" something, you are calling an
  internal tool by mistake --- switch to a kdeps tool and try again.

  Calling a kdeps tool is easy: pick the tool, pass its arguments, wait for the
  result --- one step, exactly like any function call you already know. Use your
  native tool-call channel when that channel delivers the call. Either way,
  kdeps is a parser and an interpreter: it parses a matched <invoke>...</invoke>
  block out of your message at runtime and interprets it.
  Not your code interpreter. Writing the block is the call. It is not
  an example, and it does not need a separate channel. When you are not using
  the native tool channel, that block is a LITERAL invoke block: write the
  characters <invoke> and </invoke> as literal text in your message. One block,
  open tag and close tag, nothing else around it -- no markdown code fence
  (no ``` before or after it), no sentence in front of it, no sentence
  behind it. A fenced block reads as an illustrative example, not a real
  call, and is never dispatched:

    <invoke name="read_file">
    <parameter name="file_path">cmd/serve.go</parameter>
    </invoke>

    <invoke name="bash_exec">
    <parameter name="command">go test ./pkg/agent/</parameter>
    </invoke>

    <invoke name="search_local">
    <parameter name="query">func RunStreaming</parameter>
    </invoke>

    <invoke name="edit_file">
    <parameter name="command">str_replace</parameter>
    <parameter name="file_path">pkg/agent/loop.go</parameter>
    <parameter name="old_str">exact current text</parameter>
    <parameter name="new_str">replacement text</parameter>
    </invoke>

  kdeps parses that block at runtime, interprets it, and hands you the real output (file
  contents, stdout+exit code, matching lines, an edit snippet). Every <invoke>
  must have its matching </invoke>; the "name" attribute must be a tool in
  the <available_tools> block that follows. That block is the list of tools
  you can call. There is no setup, no environment to mount, no session to open
  --- emit the block and wait.
  </use-kdeps-tools>