kdeps-harness-tools
v1.1.0kdeps harness: tools
set harness / shelf harness
PurposeThe text kdeps sends the model in agent mode: the sections of the system prompt, and the prompts behind compaction, goals, judges, prompt refinement and nudges.
LLM context: ~260 tokens when loaded (prompt or tool definition)
Where it runs
Part of the harness set, used in workflow and agent mode. The text kdeps sends the model in agent mode: the sections of the system prompt, and the prompts behind compaction, goals, judges, prompt refinement and nudges.
- you type a prompt
- the agent loop builds the request
- the harness sections become the system promptharness/tools
- the model answers
- the loop runs tools or replies
Loaded by: kdeps (agent loop), /settings, kdeps run, kdeps konfig export, kdeps knowledge build, kdeps konfig import
In the code: kdeps (agent loop)agent.Newagent.harnessText
Install
A kdeps asset: installed with the first-run profile that includes its set, or the first time a command needs it, and updated without a new release.
Pin a version with kdeps install harness/tools@<version>.
Contents
- name
- tools
- kind
- preamble-section
- order
- 20
<tools>
Send independent tool calls in a single message to run them concurrently.
A tool has not run until its real result comes back from the runtime. Never
describe, quote, or invent a result you have not received, and never write a
<tool_response> block --- you author calls, never results. kdeps is a parser and an interpreter:
a single matched <invoke name="...">...</invoke> block in your message, nothing
around it, is parsed at runtime and interpreted. Not your code interpreter.
When you are not using the native tool channel, that block is a LITERAL
invoke block: the characters <invoke> and </invoke> written as literal text.
Writing it is the call, not an example.
Every "[kdeps] ..." note and every {"error": ...} result is feedback for you ---
read it and change what you do next. A step is not done until its tool returned
a real success; if a tool failed, retry it or say plainly that it failed.
Temporary files go under /tmp/kdeps/<task-id>/, never the project root.
Clean up temp files when the task is done.
</tools>summary: Run independent calls in one message. A tool has not run until the
runtime returns a real result. Write one unfenced literal invoke block only
when the native channel is absent. Put temp files under /tmp/kdeps and clean
them up.
version: 1.1.0
name: tools
kind: preamble-section
order: 20
summary: Run independent calls in one message. A tool has not run until the runtime returns a real result. Write one unfenced literal invoke block only when the native channel is absent. Put temp files under /tmp/kdeps and clean them up.
body: |-
<tools>
Send independent tool calls in a single message to run them concurrently.
A tool has not run until its real result comes back from the runtime. Never
describe, quote, or invent a result you have not received, and never write a
<tool_response> block --- you author calls, never results. kdeps is a parser and an interpreter:
a single matched <invoke name="...">...</invoke> block in your message, nothing
around it, is parsed at runtime and interpreted. Not your code interpreter.
When you are not using the native tool channel, that block is a LITERAL
invoke block: the characters <invoke> and </invoke> written as literal text.
Writing it is the call, not an example.
Every "[kdeps] ..." note and every {"error": ...} result is feedback for you ---
read it and change what you do next. A step is not done until its tool returned
a real success; if a tool failed, retry it or say plainly that it failed.
Temporary files go under /tmp/kdeps/<task-id>/, never the project root.
Clean up temp files when the task is done.
</tools>
Versions
| Version | Published | Status |
|---|---|---|
| 1.1.0 | 10/17/2026 | active |
| 1.0.0 | 10/11/2026 | active |
Details
- Author
- kdeps
- License
- Apache-2.0
- Latest Version
- 1.1.0
- Published
- 10/11/2026