# Xellos1010 Sdlc Visual Workflow Workspace Agent Team Builder > Agent Team Builder - Skill: `tomevault-io/xellos1010-sdlc-visual-workflow-workspace-agent-team-builder` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/xellos1010-sdlc-visual-workflow-workspace-agent-team-builder` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/xellos1010-sdlc-visual-workflow-workspace-agent-team-builder/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/xellos1010-sdlc-visual-workflow-workspace-agent-team-builder --- # Agent Team Builder Design a Claude Code agent team for a specific initiative. Gather all inputs via interview, then generate team config, work orders, and launch artifacts saved to `.foundry/staging//`. Agent teams require `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in the environment. Each teammate is an independent Claude Code session. The lead coordinates via a shared task list and direct messaging. See `references/agent-teams-primer.md` for architecture details. ## Interview Protocol Run all five phases in order. Ask only what you don't already know from context — if the user described the initiative before invoking this skill, extract answers from that description. --- ### Phase 1 — Initiative Definition Gather: 1. **Name** — short human-readable title (e.g. "TypeScript → Rust Migration") 2. **Slug** — kebab-case identifier used for file paths (e.g. `ts-react-rust-migration`) 3. **Objective** — one or two sentences: what will be materially different when this initiative is done? 4. **Scope** — which files, modules, apps, or systems are in play? Be specific (e.g. `apps/night-agent-runner/src/`) If the user hasn't named it, suggest a slug based on what they described. --- ### Phase 2 — SDLC Placement Determine where in the lifecycle this initiative starts. Default to the `.foundry` cycle used in this repo: ``` discover → define → visualize → architect → plan → implement → verify → release → operate → diagnose → improve ``` Ask: "Which phase are we starting at?" If unclear, suggest based on the objective: - New idea with no design: `discover` - Design exists, building now: `implement` - Code exists, validating: `verify` - Migration or porting work: `implement` (with analysis as first task) Check `.foundry/projects//current-task.json` — if it exists, we may be **resuming**, not starting fresh. If resuming, read the current phase from `currentPhase.id` and `sdlcPhase` and confirm with the user. See `references/sdlc-phases.md` for phase entry/exit criteria. --- ### Phase 2.5 — Single Team vs Pipeline Before designing work streams, decide the initiative shape: **Use a single team** when: - Total work fits in 3–6 independent streams - All streams can start simultaneously or have simple dependencies **Use a pipeline** (multiple teams in sequence) when: - More than ~6 independent streams needed - Work naturally divides into phases where one phase produces artifacts the next consumes - File count is large enough that one analyzer or porter per-subsystem is insufficient (500+ files is a clear signal) If pipeline: design each team stage independently, with each stage producing a concrete output artifact the next stage depends on. Save to `pipeline/NN-/team-config.json`. Create a `pipeline.json` at the initiative root to track stage order and status. Stages 2–5 can be offered to run concurrently if they share only the stage-1 output (not each other's output). --- ### Phase 3 — Work Stream Design Work streams become teammates. Each stream must be: - **Independent** — can make progress without waiting on other streams - **Bounded** — owns a specific set of files or concerns - **Deliverable** — produces a clear artifact or state change For each stream, collect: | Field | What to ask | |-------|-------------| | `name` | Short role label (e.g. `analyzer`, `porter-tui`, `verifier`) | | `objective` | One sentence: what does this teammate accomplish? | | `scope` | File paths, glob patterns, or system names this teammate owns | | `subagentType` | Which subagent definition to use (see `references/role-catalog.md`) | | `model` | `haiku`, `sonnet`, or `opus` — suggest based on task class | | `planApprovalRequired` | true/false — require plan review before implementation? | | `dependsOn` | Names of other streams that must complete first (empty if independent) | **Suggest streams** based on the initiative type. For TS→Rust migrations specifically, suggest: 1. `analyzer` — ts-react-rust-analyzer, runs first on all source, broadcasts findings 2. `porter-` (one per subsystem) — rust-porter, ports a bounded file set 3. `verifier` — rust-migration-verifier, verifies each ported slice after porter completes Keep the team to 3–6 teammates. More than 6 creates coordination overhead that outweighs parallel benefit. If the scope is larger, structure work so each teammate has 4–6 tasks rather than spawning more teammates. --- ### Phase 4 — Acceptance Criteria Gather 3–7 specific, testable done criteria. Each should be verifiable by running a command or checking a file. Examples: - "All Nx typecheck, test, and build targets pass for apps/agent-runner-rust" - "rust-migration-verifier reports PASS for all ported modules" - "No TS source files remain unanalyzed in scope" These become the `doneCriteria` array in continuity state and the final task in the team's work order list. --- ### Phase 5 — Generate Artifacts Once all inputs are gathered, produce four files in `.foundry/staging//`: #### 5.1 — `team-config.json` ```json { "initiative": { "name": "", "slug": "", "objective": "", "sdlcCycle": "monorepo/.foundry", "startingPhase": "", "createdAt": "", "status": "ready" }, "team": { "planApprovalRequired": , "teammates": [ { "name": "", "objective": "", "subagentType": "", "model": "", "scope": [""], "dependsOn": [""], "planApprovalRequired": } ] }, "doneCriteria": [""], "workOrdersPath": ".foundry/staging//work-orders.md", "leadPromptPath": ".foundry/staging//lead-prompt.md", "continuityPath": ".foundry/projects//current-task.json" } ``` #### 5.2 — `work-orders.md` One work order per teammate stream, following the scope-chunker format: ```markdown ## Work Order: WO-- - **Initiative**: - **Lifecycle Stage**: - **Agent Role**: - **Subagent Type**: - **Model**: - **Scope**: - **Depends On**: - **Objective**: - **Acceptance Criteria**: - [ ] - **Verification**: - `` - **Plan Approval Required**: yes/no ``` Add a final work order `WO--DONE` assigned to the lead for final acceptance criteria check. #### 5.3 — `lead-prompt.md` The exact prompt to paste to Claude when starting or resuming the team. It must contain: 1. The `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` reminder 2. The initiative objective 3. The SDLC cycle reference (`.foundry` path) 4. Each teammate's name, subagent type, scope, model, and dependency order 5. Plan approval instructions (if required) 6. Coordination rules: - Which teammate runs first - How they share findings (broadcast vs direct message) - When verifiers engage - How to update continuity state after each phase transition - Cleanup instructions when done 7. Reference to `work-orders.md` path Format: ```markdown # Team Lead Prompt — ## Environment Ensure `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` is set before launching. ## Objective ## SDLC Context Cycle: `.foundry` (discover → define → visualize → architect → plan → implement → verify → release → operate → diagnose → improve) Current phase: Continuity state: `.foundry/projects//current-task.json` ## Team Structure Spawn the following teammates: ### 1. (subagent: , model: ) **Scope**: **Objective**: **Depends on**: **Instructions**: ... ## Coordination Rules ## Acceptance Gate Before marking the initiative complete, verify: ## Work Orders Full work order tree: `.foundry/staging//work-orders.md` ``` #### 5.4 — Initial `current-task.json` Create `.foundry/projects//current-task.json` (or update if resuming) using the schema at `.foundry/schemas/task-state.schema.json`. Set: - `sdlcPhase`: starting phase - `currentPhase.status`: `"in_progress"` - `doneCriteria`: the criteria from Phase 4 - `nextCommandSet`: first verification step or "Launch team with lead-prompt.md" --- ## After Generation Tell the user: 1. Where the artifacts were saved 2. To invoke `/agent-team-launcher` to select and start the team 3. That `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` must be set (show how) If the team is for a **TS→Rust migration** specifically, also remind them to run `/ts-react-rust-analyzer` on the scope first if an `analyzer` teammate isn't included — analysis before porting is non-negotiable. --- > Source: [Xellos1010/sdlc-visual-workflow-workspace](https://github.com/Xellos1010/sdlc-visual-workflow-workspace) — distributed by [TomeVault](https://tomevault.io).