Harnesskdeps asset
kdeps-harness-use-kdeps-tools
v1.0.0kdeps harness: use-kdeps-tools
Install
A kdeps asset: kdeps installs it on first run and updates it without a new release.
kdeps update harness/use-kdeps-tools
Pin a version with kdeps update harness/use-kdeps-tools@<version>.
Contents
- name
- use-kdeps-tools
- kind
- preamble-section
- order
- 130
<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>
version: 1.0.0
name: use-kdeps-tools
kind: preamble-section
order: 130
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>
Versions
| Version | Published | Status |
|---|---|---|
| 1.0.0 | 10/11/2026 | active |
Details
- Author
- kdeps
- License
- Apache-2.0
- Latest Version
- 1.0.0
- Published
- 10/11/2026
Tags
kdepsharness