| name | deepwork |
| description | Start or continue DeepWork workflows using MCP tools |
DeepWork Workflow Manager
Execute multi-step workflows with quality gate checkpoints.
Terminology
A job is a collection of related workflows. For example, a "code_review" job
might contain workflows like "review_pr" and "review_diff". Users may use the terms
"job" and "workflow" somewhat interchangeably when describing the work they want done —
use context and the available workflows from get_workflows to determine the best match.
IMPORTANT: Use the DeepWork MCP server tools. All workflow operations
are performed through MCP tool calls and following the instructions they return,
not by reading instructions from files.
How to Use
- Call
get_workflows to discover available workflows
- Call
start_workflow with goal, job_name, and workflow_name
- Follow the step instructions returned; use the
session_id from begin_step for all subsequent calls
- Call
finished_step with your outputs when done
- Handle the response:
needs_work, next_step, or workflow_complete
Creating New Jobs
You MUST create new DeepWork jobs by starting the `new_job` workflow via the DeepWork
MCP tools. Follow the guidance from the DeepWork MCP server as you go through the
workflow — it will walk you through each step.
To create a new job, use the MCP tools:
- Call
get_workflows to confirm the deepwork_jobs job is available
- Call
start_workflow with:
job_name: "deepwork_jobs"
workflow_name: "new_job"
goal: a description of what the new job should accomplish
- Follow the instructions returned by the MCP tools as you progress through the workflow
Quality Gates
Steps may have quality criteria. When you call finished_step:
- Outputs are evaluated against review criteria
- If any fail, you get
needs_work with feedback — fix issues and call finished_step again
- After passing, you get the next step or completion
Nested Workflows and Navigation
- Starting a workflow while one is active pushes onto a stack. Check the
stack field in responses.
- Use
abort_workflow with an explanation if a workflow cannot be completed.
- Use
go_to_step to revisit an earlier step — clears progress from that step onward.
Tips
- Create all expected outputs before calling
finished_step — check step_expected_outputs for what's required
- Provide clear, specific goals when starting — they're used for context throughout the workflow
- Read quality gate feedback carefully before retrying — it tells you exactly what to fix
- Don't leave workflows in a broken state — use
abort_workflow if you can't complete
Intent Parsing
When the user invokes /deepwork, parse their intent:
- ALWAYS: Call
get_workflows to discover available workflows
- Based on the available flows and what the user said in their request, proceed:
- Explicit workflow:
/deepwork <a workflow name> → start the <a workflow name> workflow
- General request:
/deepwork <a request> → infer best match from available workflows
- No context:
/deepwork alone → ask user to choose from available workflows
Special case: /deepwork learn after /deepwork:record
If the user invokes /deepwork learn and /deepwork:record was used earlier in this
conversation, the session captured a new workflow from scratch — there is no existing job
to learn from. Instead of starting the learn workflow, start the new_job workflow
(job_name: "deepwork_jobs", workflow_name: "new_job") with a goal summarizing the
workflow the user recorded. Use the conversation history as the primary input for defining
the job's steps, inputs, and outputs.