multi-agent-designlisted

# Multi-Agent Design You are designing the agent topology for a feature. Determine the feature name from the user's request; if it is not provided, ask before proceeding. Run this skill before `/architecture-preflight` whenever `eval_criteria.yaml` declares `multi_agent: true`. ## Inputs to read - `features/<feature_name>/nfrs.md` — understand scope and constraints - `features/<feature_name>/acceptance.feature` — understand required outcomes - `features/<feature_name>/eval_criteria.yaml` — confirm `multi_agent: true` - `docs/backend/architecture/AGENT_ARCHITECTURE.md` Section 17 — architecture rules - `docs/backend/architecture/TECH_STACK.md` — approved model aliases ## Step 1: Justify multi-agent Answer these questions before proceeding. If the answers do not justify multiple agents, recommend a single-agent design and stop. - What workflow step genuinely benefits from specialization? - Would a single agent with tool calls achieve the same outcome? If yes, prefer that. - Is the expected output quality meaningfully better with specialized agents? ## Step 2: Define the Orchestrator - What decision does the orchestrator make? - What is its routing strategy (e.g., classify first, then route)? - System prompt file path: `src/agents/orchestrator/system_prompt.md` - Which LLM model alias does it use? ## Step 3: Define each Specialist Agent For each specialist, specify: - Role: one sentence - Input state fields: name and type for each field received from the graph state -