oh-my-opencode-slim 2.0.0-beta.4 → 2.0.0-beta.7

package/dist/agents/orchestrator.d.ts

@@ -1,4 +1,4 @@
-import type { AgentConfig } from "@opencode-ai/sdk/v2";
+import type { AgentConfig } from '@opencode-ai/sdk/v2';
 export interface AgentDefinition {
     name: string;
     displayName?: string;

package/dist/index.js

@@ -18990,11 +18990,11 @@ var AGENT_DESCRIPTIONS = {
 - **Don't delegate when:** Routine decisions you're confident about • First bug fix attempt • Straightforward trade-offs • Tactical "how" vs strategic "should" • Time-sensitive good-enough decisions • Quick research/testing can answer
 - **Rule of thumb:** Need senior architect review? → @oracle. Need code review or simplification? → @oracle. Routine coordination or final synthesis? → handle directly.`,
   designer: `@designer
-- Lane: User-facing UI/UX design related edits, polish, and review
+- Lane: UI/UX design, related edits, design polishign, and review
 - Role: UI/UX specialist for intentional, polished experiences
 - Permissions: Read/write files
 - Stats: 10x better UI/UX than orchestrator
-- Capabilities: Visual relevant edits, interactions, responsive layouts, design systems with aesthetic intent, deep UI/UX knowledge.
+- Capabilities: Goot design taste, visual relevant edits, interactions, responsive layouts, design systems with aesthetic intent, deep UI/UX knowledge.
 - Weakness: copywriting, needs Orchestrator control, dictation, reviews
 - **Delegate when:** User-facing interfaces needing polish • Responsive layouts • UX-critical components (forms, nav, dashboards) • Visual consistency systems • Animations/micro-interactions • Landing/marketing pages • Refining functional→delightful • Reviewing existing UI/UX quality
 - **Don't delegate when:** Backend/logic with no visual • Quick prototypes where design doesn't matter yet
@@ -19004,6 +19004,7 @@ var AGENT_DESCRIPTIONS = {
 - Role: Fast execution specialist for well-defined tasks.
 - Permissions: Read/write files
 - Stats: 2x faster code edits, 1/2 cost of orchestrator, 0.8x quality of orchestrator
+- Weakness: design taste
 - Tools/Constraints: Execution-focused—no research, no architectural decisions
 - **Delegate when:** For implementation work, think and triage first. If the change is non-trivial or multi-file, hand bounded execution to @fixer • Writing or updating tests • Tasks that touch test files, fixtures, mocks, or test helpers. Parallelization benefits: Task involves multiple folders and multiple files modificaiton, scoping work per folder and spawning parallel @fixers for each folder.
 - **Don't delegate when:** Needs discovery/research/decisions • Single small change (<20 lines, one file) • Unclear requirements needing iteration • Explaining to fixer > doing • Tight integration with your current work • Sequential dependencies

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-slim",
-  "version": "2.0.0-beta.4",
+  "version": "2.0.0-beta.7",
   "description": "Lightweight agent orchestration plugin for OpenCode - a slimmed-down fork of oh-my-opencode",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/skills/deepwork/SKILL.md

@@ -18,15 +18,21 @@ Required behavior:
 
 - keep OpenCode todos aligned with the active deepwork phase;
 - create and maintain a local markdown progress file under `.slim/deepwork/`;
+- write valuable research findings into that file as confirmed research context
+  when they are received and reconciled;
 - draft a plan before implementation;
 - ask `@oracle` to review the plan and revise it until acceptable;
 - create a phased implementation/delegation plan;
+- 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;
-- 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;
+- 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 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
@@ -56,37 +62,28 @@ work. The file only needs to remain useful as persistent session state and shoul
 capture, as applicable:
 
 - current goal and understanding;
-- 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, reviews, phase completions, validation
-results, and scope changes.
+Update this file after major decisions, valuable specialist research, reviews,
+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.