Tune deepwork workflow guidance

src/skills/deepwork/SKILL.md

@@ -23,19 +23,16 @@ Required behavior:
 - draft a plan before implementation;
 - ask `@oracle` to review the plan and revise it until acceptable;
 - create a phased implementation/delegation plan;
-- ask `@oracle` to review that implementation plan before execution;
 - before oracle reviews, add relevant confirmed research findings and file
   references to the deepwork file so oracle can review the plan or phase from
   accepted context instead of redoing discovery;
+- ask `@oracle` to review that implementation plan before execution;
 - after oracle review and before each implementation phase, decide the execution
   path: what can run in parallel, what must be sequential, which specialists to
-  delegate to, and whether to call the same agent multiple times for separate
-  bounded lanes;
-- execute phase by phase with specialist delegation where useful;
-- after each phase, validate, update the deepwork file, ask `@oracle` to review
-  the phase result, fix actionable issues, then continue;
-- ask `@oracle` phase reviews to include simplify/readability feedback alongside
-  correctness, blockers, risks, and plan adherence;
+  delegate to, and whether to split the same agent into multiple bounded lanes;
+- after each phase, validate, update the deepwork file, prepare the plan file
+  for oracle review and ask `@oracle` to review the phase result, fix
+  actionable issues, then continue;
 - finish with final validation and a concise summary.
 
 ## Deepwork File
@@ -65,42 +62,28 @@ work. The file only needs to remain useful as persistent session state and shoul
 capture, as applicable:
 
 - current goal and understanding;
-- confirmed research context from `@librarian`, `@explorer`, docs, code reads,
-  or external references, including source links/paths when available;
-- assumptions, constraints, and decisions;
+- researched, factual context from `@librarian` to avoid oracle doing its own
+  research;
 - plan drafts and oracle review notes;
 - implementation phases and status;
 - validation results;
 - unresolved questions, blockers, and follow-ups.
 
 Update this file after major decisions, valuable specialist research, reviews,
-phase completions, validation results, and scope changes. When `@librarian`,
-`@explorer`, docs, code reads, or external references produce useful information,
-reconcile the result and record the accepted findings here so later planning and
-reviews share the same context instead of rediscovering it.
+phase completions, validation results, and scope changes.
+When `@librarian` docs, code reads, or external references produce useful
+information, reconcile the result and record the accepted findings here so later
+planning and reviews share the same context instead of rediscovering it.
+Don't put actual contents of local files, reference them by path only.
 
 ## Scheduler Discipline
 
-Use the V2 scheduler model throughout:
+Use the scheduler model throughout:
 
-- dispatch `@explorer`, `@librarian`, `@fixer`, `@designer`, `@oracle`, or
-  `@council` lanes as background tasks when useful;
+- follow Orchestrator delegations rules
 - record task/session IDs and ownership boundaries;
 - poll `task_status` before consuming background results;
-- reconcile terminal results before dependent work;
-- keep write scopes separate when parallelizing;
+- avoid blocking Orchestrator lane too long; prefer shorter periodic task waits
+  rather than one long wait;
 - do not advance to the next phase while relevant jobs are running or terminal
   results are unreconciled.
-
-`@oracle` owns review and risk assessment. It should review plans and completed
-phase outputs, not become the default implementer. For phase reviews, explicitly
-ask oracle to use its simplify skill when available and report readability,
-maintainability, and unnecessary-complexity findings separately from blocking
-correctness issues.
-
-## Lightweight Judgment
-
-Deepwork is meant to prevent chaotic long sessions, not create paperwork. Keep
-the markdown concise, batch small related checks when reasonable, and scale the
-number of review gates to the risk of the work. If the task becomes small and
-obvious, finish simply while preserving validation and the final summary.