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

package/dist/index.js

@@ -18972,14 +18972,14 @@ var AGENT_DESCRIPTIONS = {
 - **Delegate when:** Need to discover what exists before planning • Parallel searches speed discovery • Need summarized map vs full contents • Broad/uncertain scope
 - **Don't delegate when:** Know the path and need actual content • Need full file anyway • Single specific lookup • About to edit the file`,
   librarian: `@librarian
-- Lane: External knowledge and library research
-- Role: Authoritative source for current library docs and API references
+- Lane: External knowledge and library research, fast web research
+- Role: Authoritative source for current library docs and API references, web information retrieval
 - Permissions: External docs/search MCPs; no file edits
 - Stats: 10x better finding up-to-date library docs than orchestrator, 1/2 cost of orchestrator
 - Capabilities: Fetches latest official docs, examples, API signatures, version-specific behavior via grep_app MCP
-- **Delegate when:** Libraries with frequent API changes (React, Next.js, AI SDKs) • Complex APIs needing official examples (ORMs, auth) • Version-specific behavior matters • Unfamiliar library • Edge cases or advanced features • Nuanced best practices
+- **Delegate when:** Libraries with frequent API changes (React, Next.js, AI SDKs) • Complex APIs needing official examples (ORMs, auth) • Version-specific behavior matters • Unfamiliar library • Edge cases or advanced features • Nuanced best practices • Working on fixing tricky bug or problem and need latest web research information
 - **Don't delegate when:** Standard usage you're confident • Simple stable APIs • General programming knowledge • Info already in conversation • Built-in language features
-- **Rule of thumb:** "How does this library work?" → @librarian. "How does programming work?" → answer directly.`,
+- **Rule of thumb:** "How does this library work?" → @librarian. "How does programming work?" → answer directly. How does others solve or workaround this tricky issue?" → @librarian.`,
   oracle: `@oracle
 - Lane: Architecture, risk, debugging strategy, and review
 - Role: Strategic advisor for high-stakes decisions and persistent problems, code reviewer
@@ -18990,23 +18990,25 @@ 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, 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
 - **Rule of thumb:** Users see it and polish matters? → @designer. Headless/functional implementation? → schedule @fixer.`,
   fixer: `@fixer
-- Lane: Bounded implementation and test execution
-- Role: Fast execution specialist for well-defined tasks, which empowers orchestrator with parallel, speedy executions
+- Lane: Bounded implementation and test execution.
+- 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
-- **Rule of thumb:** If implementation or tests are needed, schedule @fixer with clear scope. Bigger or lots of edits should be split by ownership and dispatched as parallel background fixer lanes when safe.`,
+- **Rule of thumb:** Implementation are needed, schedule @fixer with clear scope. Bigger or lots of edits should be split by ownership and dispatched as parallel background fixer lanes when safe.`,
   council: `@council
 - Lane: High-stakes multi-model decision support
 - Role: Multi-LLM consensus engine that runs several councillors, synthesizes their views, and returns a structured council report.
@@ -19032,7 +19034,7 @@ var AGENT_DESCRIPTIONS = {
 var VALIDATION_ROUTING = [
   "- Route UI/UX validation and review to @designer",
   "- Route code review, simplification, maintainability review, and YAGNI checks to @oracle",
-  "- Route test writing, test updates, and changes touching test files to @fixer",
+  "- Route implementation to @fixer or multiple @fixer instances for maximum parallel execution",
   "- Route visual/media analysis and interpretation to @observer",
   "- If a request spans multiple lanes, delegate only the lanes that add clear value"
 ];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-opencode-slim",
-  "version": "2.0.0-beta.3",
+  "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.