deepseek-harness/examples/coding-agent/cordis.yml

# The coding-agent plugin tree: the REPL agent demo. The two swappable
# backends — the DeepSeek adapter and the local bash executor — plus `hmr` for
# the dev/demo reload loop, then the stdio chat app (@deepseek-ai/dsh-stdio-
# agent), which bundles the whole agent-core spine (timer, llm, sessions,
# system-prompt, tools, agents, invariants, tool-bash, agent-loop), the console
# logger, JSONL persistence, the readline UI, and a pre-created `main` agent.
#
# `hmr` is a leaf entry (not baked into dsh-stdio-agent): it is a Loader-only
# dev plugin that needs `--expose-internals` — the `demo:repl` script passes
# it. Requires DEEPSEEK_API_KEY (and optionally DEEPSEEK_BASE_URL) in the
# environment — the dsh-stdio-agent bin loads the gitignored repo-root .env
# first. cordis.yml reads them via the `!!js` tag.

# Hot-module reload for the dev/demo loop (needs `node --expose-internals`).
- id: hmr
  name: '@cordisjs/plugin-hmr'
  config:
    root: ['.']

# The DeepSeek adapter. Swap to '@deepseek-ai/dsh-llm-pi-ai' for the pi-ai-backed
# twin (same config shape; `reasoning: high` replaces thinking/reasoningEffort).
- id: llm-deepseek
  name: '@deepseek-ai/dsh-llm-deepseek'
  config:
    apiKey: !!js process.env.DEEPSEEK_API_KEY
    baseURL: !!js process.env.DEEPSEEK_BASE_URL
    models:
      - deepseek-v4-pro
      - deepseek-v4-flash

# Local bash executor for agent-core's tool-bash schema.
# FIXME(config-comments): keep this executor note from implying bash is the
# whole tool set; filesystem, subagent, and todo_write are loaded below.
- id: bash
  name: '@deepseek-ai/dsh-bash-local'
  config:
    timeoutMs: 60000

# The stdio chat app: the whole spine + front-door cluster, configured for a
# REPL agent demo driving a pre-created `main` agent.
- id: stdio-agent
  name: '@deepseek-ai/dsh-stdio-agent'
  config:
    model: deepseek-v4-flash
    # Set RESUME_SESSION_ID to continue a prior persisted session (the ids live
    # under ./.sessions); unset starts a fresh session each run.
    resumeSessionId: !!js process.env.RESUME_SESSION_ID
    persistenceRoot: './.sessions'
    welcome: 'agent REPL ready. Give it a coding task (its tools are read, write, edit, bash, subagent, workflow, and todo_write).'
    systemPrompt: |
      You are coding-agent, a CLI coding assistant.

      Your tools are read/write/edit for file operations, bash (plus
      bash_output/bash_kill for background tasks), and subagent. Use read to
      inspect UTF-8 text files, write to create or replace files, and edit for
      targeted literal replacements. Use bash for shell commands, tests,
      searches, and operations that are not ordinary file reads or edits. Each
      bash call runs in a fresh shell — pass workdir instead of cd, and never
      rely on shell state between calls.

      Use the subagent tool to delegate a focused, self-contained subtask
      to a fresh child agent (it works in its own context and returns only
      its final result) — give it a complete, standalone instruction. Use
      subagent_fork instead when the subtask needs THIS conversation's
      context: the child inherits the log so far.

      Use the workflow tool ONLY when the user explicitly asks for a
      workflow or for large multi-agent orchestration: you write a
      JavaScript script (its description documents the exact format) that
      fans work out across many subagents with phases and structured
      results. For one or two delegations, prefer plain subagent calls.

      Check the [exit code: N] marker on every command; investigate
      failures before moving on. Verify your work by running the code or
      tests. Keep answers brief and factual.

      For multi-step work, use the todo_write tool to track a task list:
      send the WHOLE list each call (it replaces the previous one), keep at
      most one task in_progress (exactly one while work remains), and mark a
      task completed as soon as it is done. Skip it for trivial single-step
      tasks.

# Automatic context compaction: when the derived history approaches the model's
# context window, summarize an older range into a checkpoint so a long-running
# or tool-heavy session keeps fitting. A leaf entry (needs ctx.llm + the
# agent-loop's `agent/pre-step` seam from the app above).
- id: compact-basic
  name: '@deepseek-ai/dsh-compact-basic'
  config:
    contextWindow: 128000
    thresholdRatio: 0.8
    retainTokens: 20480
    summarizationModel: ''
    maxTokens: 8192
    compactionRetries: 1

# The subagent seam + BOTH in-process backends + two model-facing tools, as leaf
# entries after the app (which provides ctx.agents/ctx.tools). spawn (a fresh
# child) and fork (a child seeded with the parent's completed-turn prefix) are
# independent backends over the shared dsh-subagent-inprocess driver. Exposing
# both transports is pure config: load each backend, then load dsh-tool-subagent
# once per backend with a distinct toolName (the tool registry rejects a
# duplicate name) — no code change.
- id: subagent
  name: '@deepseek-ai/dsh-subagent'

- id: subagent-spawn
  name: '@deepseek-ai/dsh-subagent-spawn'
  config:
    providerName: spawn

- id: subagent-fork
  name: '@deepseek-ai/dsh-subagent-fork'
  config:
    providerName: fork

- id: tool-subagent
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: spawn
    toolName: subagent

- id: tool-subagent-fork
  name: '@deepseek-ai/dsh-tool-subagent'
  config:
    provider: fork
    toolName: subagent_fork


# Dynamic workflows: the node:vm engine (ctx.workflows) over the spawn subagent
# backend above, plus the model-facing `workflow` tool. The model writes a
# JavaScript orchestration script (meta + body); the engine runs it in-process
# and fans agent() calls out as spawn children.
- id: workflow-vm
  name: '@deepseek-ai/dsh-workflow-vm'
  config:
    provider: spawn

- id: tool-workflow
  name: '@deepseek-ai/dsh-tool-workflow'
# The model-facing todo_write tool: whole-list task tracking written to the
# session log (todo/write), rendered as a stdio checklist / ACP plan.
- id: tool-todo
  name: '@deepseek-ai/dsh-tool-todo'

# Filesystem capability stack: local provider, read-before-write/edit policy
# gate, then the model-facing read/write/edit tools. stdio-agent is a single
# session, so relative paths resolve from the process cwd (the workspace).
- id: fs-local
  name: '@deepseek-ai/dsh-fs-local'
  config:
    cwd: !!js process.cwd()

- id: fs-policy
  name: '@deepseek-ai/dsh-fs-policy'

- id: tool-fs
  name: '@deepseek-ai/dsh-tool-fs'