IxLab Orchestrator

This is the main IxLab workflow skill.

Use it for design work that should result in persisted artifacts under design/.

Read These Files

• config/ixlab.config.md
• agents/ux-researcher.md
• agents/ui-designer.md
• agents/design-critic.md
• templates/entity-ux-analysis.md
• templates/entity-ui-spec.md
• templates/critic-review.md
• templates/design-system.md when design/system.md must be created or updated
• relevant files under references/ when the current phase needs them

Read files selectively, but keep the workflow order intact.

Responsibilities

• identify the correct design entity
• choose the execution mode
• run the phases in the right order
• persist the right artifacts
• avoid unnecessary work when the brief is narrow or the mode is lighter
• preserve a usable fallback path when native subagents are unavailable

Execution Modes

Resolve the mode from config/ixlab.config.md unless the user explicitly overrides it.

If config/ixlab.config.md is missing, default to:

• mode: standard
• critic_between_phases: true
• critic_model: sonnet

In full mode, always force critic gates on even if the config says otherwise.

quick

Use when speed matters more than review depth.

• resolve the design entity
• produce a lean but complete UX artifact
• create the UI artifact
• skip critic passes unless the user asks for them or quality is obviously unsafe

standard

Default working mode.

• run UX Researcher
• run Design Critic when critic_between_phases: true
• run UI Designer
• run Design Critic again when the config still enables it

full

Use for complex, high-stakes, or ambiguous work.

• run UX Researcher
• run Design Critic with a mandatory gate
• fix blocking issues before continuing
• run UI Designer
• run Design Critic with a mandatory gate
• do not finish with a failed review unresolved

Workflow

1. Read config/ixlab.config.md when present.
2. Classify the request:
   • page
   • flow
   • feature
   • component
   • cross-cutting system
3. Resolve the design entity slug.
4. Reuse existing artifacts if they already cover the entity.
5. Run the UX Researcher and write design/entities/{entity}/ux.md, or stop early if the inline feedback gate marks the brief as blocked.
6. If the mode requires critique, run the Design Critic before UI work and honor the configured critic_model when the runtime supports it.
7. If visual work requires a design system and design/system.md is missing or stale, create or update it first with the IxLab design-system skill.
8. Run the UI Designer and write design/entities/{entity}/ui.md, or stop early if its dependency check is blocked.
9. If the mode requires critique, review the UI artifact before finishing and do not continue past a fail verdict in full mode.
10. If the user also wants implementation, hand off to skills/ixlab-engineer/SKILL.md.

Entity Resolution Rules

• Prefer one coherent design entity over several fragmented ones.
• If the request naturally spans multiple entities, propose the split explicitly.
• Do not force everything into a page-level artifact.
• Use hyphenated slugs for artifact paths.
• If the entity spans multiple screens or steps, keep one shared artifact unless there is a strong reason to split it.

Research Rules

• If optional research tools are disabled or unavailable, continue without them.
• If external research is used, keep it tightly scoped and directly relevant.
• Do not block the flow on optional integrations.
• Load reference files progressively instead of dumping the whole references/ directory into context.
• If web search is used, prefer trusted sources and bring back only the insight needed for the current phase.
• If Figma MCP is available, use it only when the design file materially clarifies the entity being designed.
• If docs MCP is available, reserve it for implementation-facing questions or component-library constraints.

Output Contract

• Do not skip the UX artifact when UI work is requested.
• Do not skip the design-system artifact when the UI work depends on missing system decisions.
• Do not skip critic gates in full mode.
• Do not finish with hidden assumptions that the next phase cannot see.

Finish Condition

The orchestration is complete when the user has the artifacts needed for the requested phase, and the output is coherent enough for the next role to consume without guessing.