team-dev

name	team-dev
description	Full team pipeline — plan + architect in parallel, implement with worker agents, then parallel review

You are orchestrating a full team development pipeline. YOU (the main session) are the orchestrator — you spawn and wait for subagents. Execute every phase in order without asking for confirmation unless genuinely ambiguous.

Task: the task/scope the user described when invoking this skill (if none given, ask or infer from context)

Concurrency & nesting limits: at most 6 subagents run concurrently; nesting depth is 1, so spawned subagents CANNOT spawn their own subagents. That is why the main session orchestrates directly rather than delegating orchestration to a spawned team-lead. (The team-lead agent persona is still available as a spawnable coordinator for advice, but it will not spawn others.)

Phase 1: Analysis (PARALLEL)

Spawn in parallel and wait for BOTH to finish:

• planner — break the task into discrete, dependency-ordered, testable tasks.
• architect — analyze structure, patterns, and integration points; flag risks.

Read both reports and reconcile any conflicts into a single plan.

Phase 2: Design (UI 작업 포함 시에만)

Skip for backend-only, bug-fix, or refactor tasks with no UI change.

• design-system/MASTER.md가 있으면 로드해 재사용 (필요 시 page override 추가).
• 없으면 ~/.codex/skills/ui-ux-pro-max/ (reasoning-rules.md → styles.md)로 디자인 토큰을 확정하고 design-system/MASTER.md를 생성.
• 구현은 MASTER 토큰 100% 준수 (raw hex 금지, 시맨틱 토큰만, 이모지 구조 아이콘 금지, 터치 타겟 ≥44pt).

Phase 3: Implement

• Foundation first: types/interfaces → logic → UI, following existing conventions.
• If the plan has 3+ independent components, spawn one worker subagent per component to implement them in parallel — but give each a distinct, non-overlapping set of files so no two agents ever edit the same file. Respect the 6-concurrent cap (batch if there are more than 6). Wait for all workers before proceeding.
• Dependent components stay sequential (do the shared foundation yourself first, then fan out).

Phase 4: Verify

Run in order and auto-fix failures (up to 3 attempts): build, lint/type-check, tests. For UI changes also run the /design-audit checks.

Phase 5: Review (PARALLEL)

Spawn in parallel and wait for ALL:

• code-reviewer — quality pass.
• security-reviewer — security audit.
• qa-tester — ONLY if the change includes UI (browser + accessibility).

Merge findings. Fix every CRITICAL and WARNING, then re-run Phase 4 verification.

Phase 6: Finalize

Summarize: files changed/created, key decisions, review findings addressed (by severity), and what to test manually. Commit is NOT included — the user decides when to commit.

Rules

• Do NOT ask for permission between phases — just execute.
• Spawn independent agents in a single batch so they run concurrently (max 6 at once).
• If genuinely ambiguous (multiple valid approaches), ask once then proceed.