deepwork

Deepwork

Deepwork is an orchestrator workflow for heavy coding sessions. Use it only when the work is clearly large or high-risk: multiple dependent phases, cross-cutting architectural change, unsafe-to-partially-ship migration, or sustained coordination across several specialist lanes.

Do not infer Deepwork merely because a task touches multiple files. Do not use it for trivial edits, quick docs changes, simple bug fixes, or routine bounded features.

Core Contract

When deepwork is active, the orchestrator must manage the work as a scheduler, not as the default implementation worker.

Setup and Deepwork State

• create and maintain a local markdown progress file under .slim/deepwork/;
• save code/doc deliverables to project paths (e.g. src/, docs/); reserve .slim/deepwork/ strictly for progress files;

Deepwork File

Create a task-specific file such as:

.slim/deepwork/<short-task-slug>.md

Before creating this file—and before planning or delegation—inspect the existing .gitignore and .ignore. Add only missing entries and do not add duplicates:

# .gitignore
.slim/deepwork/

# .ignore
!.slim/deepwork/
!.slim/deepwork/**

These rules keep deepwork state git-local while allowing OpenCode to read it.

Do not follow a rigid template. Choose whatever markdown structure best fits the work. The file only needs to remain useful as persistent session state and should capture, as applicable:

• current goal and understanding;
• researched, factual context from @librarian to avoid oracle doing its own research;
• plan drafts, Oracle review budget/gates, and review notes;
• implementation phases and status;
• validation results;
• unresolved questions, blockers, and follow-ups.

Update this file after major decisions, accepted research, reviews, phase completions, validation results, and scope changes. Record accepted findings and reference local files by path rather than copying their contents.

Planning