studio-assistant-workflow-guide

name	studio-assistant-workflow-guide
description	Helps design performer teams, role splits, handoff patterns, and connected Act topology in DOT Studio. Use when the user wants a team, workflow, pipeline, role decomposition, or Act structure recommendation.
compatibility	Designed for the DOT Studio built-in assistant projection.

DOT Studio Workflow Guide

Use this skill when the user wants help designing a Performer team or workflow shape.

Build Strategy

• Reuse existing Performers when they already satisfy the role.
• Create only missing Performers, then create or update the Act.
• If the user asked for a workflow or team, do not stop after creating loose Performers.
• When new participants are created in the same reply, prefer participantPerformerRefs directly on createAct.
• Keep dependent actions in cascade order: create Performers, then create/update Act, then optional relation/subscription updates.
• For exact payload fields and ref rules, load studio-assistant-action-surface-guide.

Role Split Heuristics

• Prefer small, legible role splits over large generic teams.
• Give each Performer a distinct responsibility and a clear output or handoff.
• If one Performer can plausibly solve the request, say so instead of forcing an Act.
• If the workflow has stages, mirror those stages in relation order.
• If review, approval, or escalation matters, model it as explicit relations.
• Use separate opposite one-way relations when feedback is materially different from the original handoff.

Relation Heuristics

• Relation direction should match the actual flow of deliverables, decisions, approval, or escalation.
• Relation names should describe what is passed, such as research brief, review notes, or launch handoff.
• Add participant subscriptions only for concrete wake behavior.
• Align subscription tags and shared board keys with the handoffs the user expects.
• For contract field details, load studio-assistant-act-guide.

Common Patterns

• Single expert: one Performer with a clear role.
• Research to writer: Researcher gathers evidence; Writer turns it into polished output.
• Code review loop: Developer produces work; Reviewer returns actionable feedback; use a reverse relation if revision flow matters.
• Small delivery team: Planner/PM, Builder, Reviewer/QA with minimal explicit handoffs.

Response Strategy

• State the intended structure briefly.
• Ask one short clarifying question only when the role split or handoff is materially unclear.
• If roles and workflow shape are already clear, create the concrete structure directly.
• Do not ignore a role the user explicitly requested.
• Do not add Tal, Dance, model, or MCP choices the user explicitly asked to omit.

Anti-Patterns

• Generic Performers with overlapping jobs.
• Unconnected multi-participant Acts for workflow requests.
• One giant graph when a focused Act would do.
• Invented registry assets, MCP names, model ids, or variant ids.