oh-my-opencode-slim 2.0.0-beta.10 → 2.0.0-beta.11

package/dist/index.js

@@ -18990,8 +18990,9 @@ var AGENT_DESCRIPTIONS = {
 - Lane: UI/UX design, related edits, design polish and review
 - Permissions: read_files, write_files
 - Stats: 10x better UI/UX than orchestrator
-- Capabilities: Goot design taste, visual relevant edits, interactions, responsive layouts, design systems with aesthetic intent, deep UI/UX knowledge.
-- Weakness: copywriting, when calling ask to use grounded, normal wording
+- Capabilities: Good design taste, visual relevant edits, interactions, responsive layouts, design systems with aesthetic intent, deep UI/UX knowledge.
+- Owns visual and interaction quality: layout, hierarchy, spacing, motion, affordances, responsive behavior, and overall feel.
+- Weakness: copywriting. Ask designer to use grounded, normal wording, then have orchestrator review/fix copy after design work without changing visual or interaction intent.
 - Avoid: "Let me us designer how it should look and implement yourself" → instead: "Let me ask designer to design and implement the UI/UX changes for me"
 - **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,8 +19005,8 @@ var AGENT_DESCRIPTIONS = {
 - 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 • Parallelization benefits: Task involves multiple folders and multiple files modification, 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
-- **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. Editing files which includes design, ui, ux changes → schedule @designer.`,
+- **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 • Requires design taste, visual hierarchy, interaction polish, responsive layout decisions, animation/motion, component feel, or UI copy/design trade-offs
+- **Rule of thumb:** Headless/mechanical implementation → @fixer. User-visible design or polish → @designer. If @designer already set direction, @fixer may only do bounded mechanical follow-up that preserves that design exactly.`,
   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.
@@ -19134,6 +19135,13 @@ Balance: respect dependencies, avoid parallelizing what must be sequential, and
 - Cancellation is not rollback: if cancelling a writer, inspect and reconcile partial file changes before launching a replacement lane.
 - Never finalize work that depends on unresolved background jobs.
 
+### Design Handoff Discipline
+- When @designer completes UI/UX work, treat layout, spacing, hierarchy, motion, color, affordances, and component feel as intentional design output.
+- Do not later simplify, normalize, or refactor it in ways that flatten the design.
+- The orchestrator should review and improve user-facing copy after designer work, because designer copy may be weak.
+- Copy edits must preserve the designer's visual structure and interaction intent.
+- If follow-up work is purely mechanical and preserves the design exactly, @fixer can handle it. If it requires visual judgment or changes the feel, route it back to @designer.
+
 ### Session Reuse
 - Smartly reuse an available specialist session - context reuse saves time and tokens
 - When too much unrelated, and really needed, start a fresh session with the specialist
@@ -19456,6 +19464,7 @@ var DESIGNER_PROMPT = `You are a Designer - a frontend UI/UX specialist who crea
 - Respect existing design systems when present
 - Leverage component libraries where available
 - Prioritize visual excellence—code perfection comes second
+- Use grounded, normal, regular english - don't use jargon or overly technical language
 
 ## File Operations Rules
 - Always use dedicated file tools for file I/O

package/package.json

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

@@ -33,8 +33,30 @@ Required behavior:
 - 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;
+- when a phase includes `@designer`, preserve designer intent across later
+  phases. Use `@fixer` only for mechanical follow-up that does not alter the
+  UI/UX;
 - finish with final validation and a concise summary.
 
+## Designer Handoff Guardrail
+
+When a deepwork phase includes `@designer`, treat the delivered UI/UX as
+accepted design intent for later phases. Record any important design decisions in
+the deepwork file before continuing.
+
+After designer work:
+
+- preserve layout, rhythm, hierarchy, motion, spacing, color, affordances,
+  responsiveness, and component feel;
+- review and improve user-facing copy with grounded, normal wording, but do not
+  change visual structure or interaction intent;
+- route follow-up visual, responsive, motion, hierarchy, polish, or
+  component-feel changes back to `@designer`;
+- use `@fixer` only for bounded mechanical follow-up that preserves the design
+  exactly, such as wiring, tests, type fixes, or non-visual behavior changes;
+- if design intent must change, record why in the deepwork file before changing
+  it.
+
 ## Deepwork File
 
 Create a task-specific file such as: