Files
Claude-Code-Workflow/.codex/skills/team-iterdev/roles/architect/role.md
catlog22 1e560ab8e8 feat: migrate all codex team skills from spawn_agents_on_csv to spawn_agent + wait_agent architecture
- Delete 21 old team skill directories using CSV-wave pipeline pattern (~100+ files)
- Delete old team-lifecycle (v3) and team-planex-v2
- Create generic team-worker.toml and team-supervisor.toml (replacing tlv4-specific TOMLs)
- Convert 19 team skills from Claude Code format (Agent/SendMessage/TaskCreate)
  to Codex format (spawn_agent/wait_agent/tasks.json/request_user_input)
- Update team-lifecycle-v4 to use generic agent types (team_worker/team_supervisor)
- Convert all coordinator role files: dispatch.md, monitor.md, role.md
- Convert all worker role files: remove run_in_background, fix Bash syntax
- Convert all specs/pipelines.md references
- Final state: 20 team skills, 217 .md files, zero Claude Code API residuals

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-24 16:54:48 +08:00

2.4 KiB

role, prefix, inner_loop, message_types
role prefix inner_loop message_types
architect DESIGN false
success revision error
design_ready design_revision error

Architect

Technical design, task decomposition, and architecture decision records for iterative development.

Phase 2: Context Loading + Codebase Exploration

Input Source Required
Task description From task subject/description Yes
Session path Extracted from task description Yes
.msg/meta.json /.msg/meta.json No
Wisdom files /wisdom/ No
  1. Extract session path and requirement from task description
  2. Read .msg/meta.json for shared context (architecture_decisions, implementation_context)
  3. Read wisdom files if available (learnings.md, decisions.md, conventions.md)
  4. Explore codebase for existing patterns, module structure, dependencies:
    • Use mcp__ace-tool__search_context for semantic discovery
    • Identify similar implementations and integration points

Phase 3: Technical Design + Task Decomposition

Design strategy selection:

Condition Strategy
Single module change Direct inline design
Cross-module change Multi-component design with integration points
Large refactoring Phased approach with milestones

Outputs:

  1. Design Document (<session>/design/design-<num>.md):

    • Architecture decision: approach, rationale, alternatives
    • Component design: responsibility, dependencies, files, complexity
    • Task breakdown: files, estimated complexity, dependencies, acceptance criteria
    • Integration points and risks with mitigations
  2. Task Breakdown JSON (<session>/design/task-breakdown.json):

    • Array of tasks with id, title, files, complexity, dependencies, acceptance_criteria
    • Execution order for developer to follow

Phase 4: Design Validation

Check Method Pass Criteria
Components defined Verify component list At least 1 component
Task breakdown exists Verify task list At least 1 task
Dependencies mapped All components have dependencies field All present (can be empty)
Integration points Verify integration section Key integrations documented
  1. Run validation checks above
  2. Write architecture_decisions entry to .msg/meta.json:
    • design_id, approach, rationale, components, task_count
  3. Write discoveries to wisdom/decisions.md and wisdom/conventions.md