dsh-sisyphus-presets

DSH Sisyphus Presets

DeepSeek Harness agent presets: Sisyphus (orchestrator) and Sisyphus Oracle (read-only consultant), ported from the oh-my-openagent (OMO) Sisyphus workflow.

中文说明

This is a derivative work of oh-my-openagent's Sisyphus persona and workflow philosophy, licensed under SUL-1.0 (see LICENSE).

---

What's new (2026-09-02)

• Persona rewritten and compressed (~55% smaller): the same decision framework (intent gate, delegation protocol, validation loop, red lines) with mechanism re-explanation removed, plus a new FIXED ULTRAWORK MODE: mandatory planning tiers, scenario contracts with binary pass conditions, TDD with dual RED/GREEN evidence, a triggered reviewer gate, and a durable notepad.
• MCP visibility switch (sisyphus/mcp-switch.js, new): blender/playwright MCP tool sets (~50 schemas) are hidden by default on sisyphus sessions to keep every request's prompt small; mcp_enable / mcp_disable reveal/hide them on demand. GitHub tools stay always visible.
• Oracle mask auto-lift (sisyphus-oracle/restrict.js): the read-only tool mask is now tracked per session and lifted automatically when the session switches to a preset other than sisyphus-oracle (e.g. a router preset) — fixes first-turn assembly for presets that need a platform shell.
• command-goal row added (human /goal command + model-facing goal tool over one persisted goal domain); bash/pwsh rows restored to one-shot shells (persistent PTY shells dropped run_in_background).
• lane-models.js comment block fixed (was mojibake) and kept fully portable: all lanes default to null = inherit the session model (see Model policy for pinning).
• Version floor raised: this release needs DSH ≥ 0.1.2-alpha.3 — mcp-switch.js registers tools with the 0.1.2-alpha.3 output contract, restrict.js uses the disposer-based mask API (agent-preset/selected), and command-goal ships inside the app package. Built and verified on 0.1.2-alpha.4; the older 0.1.0-rc.x line lacks these APIs (see Prerequisites).

---

Table of Contents

• What's new (2026-09-02)
• Features
• Comparison with official presets
• Comparison with oh-my-openagent (OMO)
• Installation
• Deploying & using the presets
• AI-assisted deployment prompt
• Prerequisites
• Model policy
• Sisyphus (orchestrator)
• Sisyphus Oracle (read-only consultant)
• Verification
• FAQ
• License

---

Features

Sisyphus — orchestrator with six expert delegation lanes

• Intent gate: classifies every request (explain / implement / investigate / evaluate / fix / refactor) before acting; never implements for a question.
• Three modes: Orchestrate (default), Advise (questions), Execute (trivial single-file work).
• Six read-only, continuable subagent lanes (background-capable, send_message continuation):

• Planning loop: METIS → plan → MOMUS → revise → user approval (skipped for small tasks).
• Parallel execution discipline: fires 2–5 background subagents for multi-angle work; never duplicates delegated searches.
• Validation loop: grounding, lsp diagnostics, tests, build, manual QA, independent verification of delegated work.
• Hard invariants: no type-error suppression, no empty catch blocks, no destructive git, no fake citations/verification.
• Category routing: workflow + team-orchestration skill's category-router.js template routes units to different models at runtime by task domain (visual → multimodal, hard logic → heavy model, trivial → cheap model).
• MCP visibility switch: blender/playwright MCP tool schemas (~50, sisyphus/mcp-switch.js) are hidden by default to keep every request's prompt small; mcp_enable / mcp_disable reveal/hide them on demand. GitHub tools always visible.

Sisyphus Oracle — read-only consultant

• Read-only enforced at three layers:
  1. restrict.js plugin — listens on agent/created, applies tools.restrict({allow: [...]}) on the agent's own scope, masking every inherited global tool (MCP github/playwright/blender, write/edit, bash/pwsh, schedule, goals, jobs). Masks are tracked per session and lifted automatically when the session switches to a non-oracle preset (agent-preset/selected).
  2. Persona hard constraints (never edit, never run side-effect commands).
  3. Host approval policy (ask).
• Tools kept: read, read_image, glob, grep, lsp, web_search, ask_user_question (+ harmless agent-scoped schedule_*).
• Model: follows the user's current session model (see Model policy).

---

Comparison with official presets

DSH ships four official presets. Here is how sisyphus / sisyphus-oracle relate to them:

How to choose:

• standard — clean baseline for everyday coding.
• code — same as standard, but batch multi-step work through run_code.
• cordis — when you want the agent to author/modify DSH presets itself (self-referential toolset + authoring skill).
• minimal — fixed prompt, two persistent tools, maximum determinism, no agent machinery.
• sisyphus — when you want orchestration: intent gating, six expert lanes, METIS→plan→MOMUS loop, parallel delegation, category routing. Superset of standard's tools plus LSP/session-recall/run_code/cordis.
• sisyphus-oracle — when you want consultation with a hard guarantee of zero side effects (registry-level tool masking).

---

Comparison with oh-my-openagent (OMO)

sisyphus is a port of OMO's Sisyphus workflow to the DSH platform. It shares the orchestration philosophy but differs in mechanisms:

What OMO has that DSH Sisyphus does not:

• Dynamic prompt generation per model family (OMO bakes different prompt bodies for kimi/gpt/claude families).
• Live environment injection (persona literally lists the session's real available agents/tools/skills).
• Native category parameter on task() (DSH needs a workflow script for the equivalent).

What DSH Sisyphus has that OMO does not:

• Native workflow engine, ralph loop, run_code, tool-cordis self-modification.
• Registry-level read-only enforcement (restrict.js).
• Declarative preset files that install by copying a directory (no build step).

1. Install the presets

Copy each preset directory into your DSH user preset root ($DSH_HOME/.agent-presets/):

# from this repository
Copy-Item .\sisyphus        <DSH_HOME>\.agent-presets\sisyphus        -Recurse
Copy-Item .\sisyphus-oracle <DSH_HOME>\.agent-presets\sisyphus-oracle -Recurse

The presets appear in the web UI's preset picker under the names "Sisyphus" and "Sisyphus Oracle".

2. Install the team-orchestration skill (recommended)

sisyphus's persona references the team-orchestration skill for workflow templates (hyperplan, security research, parallel exploration, category routing):

Copy-Item .\skills\team-orchestration <DSH_HOME>\skills\team-orchestration -Recurse

3. Restart DSH

Stop and start your harness instance (however you normally restart DSH — the launcher command, a service manager, or the web UI's restart action). A fresh session will pick up the new presets.

---

Deploying & using the presets

Where the files must live

DSH_HOME is the harness home directory (the launcher sets it; on this repo's reference machine it is D:\DeepSeek Harness\home). Keep the whole directory, not just the files inside — the preset directory carries its own lane-models.js, mcp-switch.js and restrict.js siblings that the composition references by relative path.

Making a preset the default

To make sisyphus the default preset for all new sessions, set it in settings.yaml:

agent-presets:
  default: sisyphus

The value is read per session creation — no restart needed for this change alone. You can also keep the official default and pick a preset per session instead.

Using the presets

• Web UI: open the preset picker when creating a new session; choose Sisyphus or Sisyphus Oracle.
• API: pass "agentPreset": "sisyphus" (or "sisyphus-oracle") in session.create:

$body = '{"type":"client-request","rpcId":"t","method":"session.create","payload":{"workspaceId":"<ws-id>","agentPreset":"sisyphus"}}'
Invoke-WebRequest -Uri "http://127.0.0.1:3080/api/session.create" -Method POST -ContentType "application/json" -Body $body -UseBasicParsing

• Switching a blank session: a session that has not produced any turns yet can switch presets via agentPreset.select (a session that has run is locked to its preset).
• Restart note: changing lane-models.js (pinned lane models) or any file inside a preset directory requires a DSH restart — the composition is read at preset mount. settings.yaml changes (default preset, model provider) apply without restart.

Post-deployment checklist

1. Both presets mount: create a session with each — expect ok: true.
2. Oracle session shows only read-only tools (see Verification).
3. Sisyphus session exposes all six lanes (subagent_explore/oracle/vision/librarian/metis/momus) plus workflow, ralph, run_code, cordis_*.
4. Lane models resolve: ask an oracle subagent to self-report {{model}} — should match your session model (or the lane-models.js pin).

---

AI-assisted deployment prompt

If you want an AI coding assistant (Claude Code, opencode, Cursor, etc.) to deploy these presets for you, paste the prompt below. It is written to be self-contained: it tells the AI exactly what to copy, where, and how to verify — no further context needed.

Prompt: deploy the presets

Deploy the DSH Sisyphus presets to a DeepSeek Harness installation.

Context:
- The presets are in this repository: the `sisyphus/` and `sisyphus-oracle/`
  directories (each is an agent preset = a directory with agent.cordis.yml
  plus sibling files), and the `skills/team-orchestration/` directory
  (a DSH skill with a SKILL.md and references/).
- DSH_HOME is the harness home directory. On Windows it is typically
  D:\DeepSeek Harness\home; on Linux/macOS it is $HOME/.dsh. Find the real
  one by checking the launcher scripts for the DSH_HOME environment
  variable, or look for the `profiles/` and `sessions/` directories.

Steps:
1. Copy the whole `sisyphus/` directory to <DSH_HOME>\.agent-presets\sisyphus\
   (copy the directory itself, not just its files).
2. Copy the whole `sisyphus-oracle/` directory to
   <DSH_HOME>\.agent-presets\sisyphus-oracle\.
3. Copy the whole `skills/team-orchestration/` directory to
   <DSH_HOME>\skills\team-orchestration\.
4. Restart DSH (stop then start the harness using whatever restart
   procedure this deployment normally uses).

Verification (required, report the results):
- Create a session with agentPreset "sisyphus": expect ok:true and no
  "failed to mount" error.
- Create a session with agentPreset "sisyphus-oracle": expect ok:true.
- In the oracle session, prompt "List every tool name in your catalog" —
  the visible tools must be exactly: read, read_image, glob, grep, lsp,
  web_search, ask_user_question, schedule_create, schedule_delete,
  schedule_list. There must be NO write/edit/pwsh/mcp__* tools.
- In the sisyphus session, verify the six subagent lanes exist:
  subagent_explore, subagent_oracle, subagent_vision, subagent_librarian,
  subagent_metis, subagent_momus.

Constraints:
- Do NOT modify any file inside the preset directories after copying.
- Do NOT create a git repo, do not push anything.
- If a copy target already exists, report it and stop rather than
  overwriting.

Prompt: verify an existing deployment

Verify that the DSH Sisyphus presets are correctly deployed on this
DeepSeek Harness installation.

Check:
0. DSH version is ≥ 0.1.2-alpha.3 (check the app package version / `npm ls @deepseek-ai/dsh`);
   note this release does NOT run on 0.1.0-rc.x builds.
1. <DSH_HOME>\.agent-presets\sisyphus\ exists and contains
   agent.cordis.yml + lane-models.js + mcp-switch.js (plus preset.yml).
2. <DSH_HOME>\.agent-presets\sisyphus-oracle\ exists and contains
   agent.cordis.yml + restrict.js (plus preset.yml).
3. <DSH_HOME>\skills\team-orchestration\ exists with SKILL.md and
   references/ (hyperplan.js, security-research.js,
   parallel-exploration.js, category-router.js).
4. The presets mount: call session.create with each preset id and report
   ok:true / any mount errors.
5. sisyphus-oracle tool restriction is active: in an oracle session, ask
   "List every tool name in your catalog" and confirm only read-only tools
   are visible (no write/edit/pwsh/mcp__*).
6. Lane model config is wired: check that sisyphus/agent.cordis.yml lane
   rows reference lane-models.js via agentOptions !!js expressions, and
   that lane-models.js has entries for all six lanes.

Report a pass/fail table for each check with the evidence you found.

Tip: the second prompt is also useful after a DSH upgrade — preset compositions and restrict.js live in the harness home, so an upgrade that rewrites the app directory does not touch them, but re-verifying is cheap.

---

Prerequisites

---

Model policy

Both presets do NOT pin a model. All subagent lanes and the Oracle preset inherit the parent agent's model route, snapshotted at session/agent creation — the model selected when the session started (defaulting to your deployment default). This keeps the presets portable across deployments: no provider or model names are hardcoded, so they work on any DSH installation regardless of which LLM providers are configured.

⚠️ Switching the session model mid-flight does NOT re-route subagents. Subagents inherit parent.options.model at delegation time (verified: after session.selectModel to a heavier model, the parent's own requests switch but already-delegated lanes keep the creation-time model). The Oracle preset's top-level agent does follow a session switch (its requests resolve the current session model); its subagent lanes do not.

Lane model resolution priority

1. lane-models.js pinned { provider, model }   ← explicit per-lane override
2. otherwise: parent agent's model at creation  ← default (session's model when session started)

Customize per-lane models — edit lane-models.js, no YAML editing

Each lane's model is resolved from sisyphus/lane-models.js (a plain JS module that travels with the preset). null = inherit the session model (default); { provider, model } = pin that lane. Edit the file, then restart DSH:

// sisyphus/lane-models.js
// Replace <your-provider> with a key from YOUR settings.yaml -> llm-pi-ai.providers.
module.exports = {
  explore:   null,                                                          // inherit
  oracle:    { provider: '<your-provider>', model: '<heavy-reasoning-model>' },  // pinned example
  vision:    { provider: '<your-provider>', model: '<multimodal-model>' },  // read_image needs multimodal
  librarian: null,
  metis:     null,
  momus:     null,
};

• provider must be a key in your settings.yaml → llm-pi-ai.providers.
• The six lanes in agent.cordis.yml read their entry from this file via the loader's !!js + createRequire mechanism — you never edit the YAML structure.
• Changing a pinned lane requires a DSH restart (config is read at preset mount).

⚠️ Vision lane caveat: read_image only works when the routed model declares image input. If the session model is text-only, either switch the session to an image-capable model or pin subagent_vision via lane-models.js to a multimodal model.

Runtime category routing (workflow)

For multi-domain tasks, the workflow tool's agent(prompt, { provider, model }) supports runtime model overrides. The team-orchestration skill ships references/category-router.js — a template that routes each unit to the model its category deserves.

The shipped route table is fully portable: every category defaults to null = inherit the current session model, with zero hardcoded provider/model names. To enable per-domain routing, edit the CATEGORY_ROUTE table in category-router.js (a workflow script — the table must stay inline because workflow scripts run in a sandbox without require). Example configuration:

Why these two JS files exist (model indirection)

You may wonder: why not just write the model into agent.cordis.yml directly? Three reasons force an indirection layer — a JS file that maps lanes/categories to actual models:

1. Presets are declarative, not executable. agent.cordis.yml is a static YAML declaration read once at preset mount. It cannot compute, read config, or branch — so a model choice that should follow the deployment's providers cannot be expressed in the YAML itself.

2. Hardcoded model names break portability. A preset that says model: deepseek-v4-pro fails on any deployment whose settings.yaml does not define that model or whose provider key differs. By keeping the mapping in a JS file that ships with defaults of null (inherit the session model), the preset runs anywhere; the user only edits one small file to opt into fixed routing.

3. The two mechanisms live in two different execution environments: