Teamwork Skill
This skill enables dynamic team creation and management for executing complex engineering tasks through coordinated AI agents with intelligent model selection, cost optimization, and continuous performance evaluation.
When to Invoke
Invoke this skill when:
- - User requests execution of complex projects requiring multiple specialized roles
- Tasks need to be broken down into coordinated steps (analysis, design, implementation, testing, review)
- User wants to leverage multiple AI models/providers for optimal cost-performance balance
- Projects require structured workflow with quality assurance and iteration
Initialization & Configuration Management
Automatic Initialization
IMPORTANT: This skill includes an autonomous initialization system. When invoked for the first time or when configuration is missing, it will automatically:
- 1. Check Configuration Status
- Verify if
.trae/config/providers.json exists
- Verify if
.trae/config/team-roles.json exists
- Verify if
.trae/data/model_scores.json exists
- 2. Interactive Setup Process
If configuration files are missing or incomplete, the skill will proactively ask the user:
Step 1: Provider Setup
- Ask: "Which AI providers would you like to configure? (e.g., OpenAI, Anthropic, Google, Azure, etc.)"
- For each provider, collect:
- Provider name
- API key (or environment variable name)
- Base URL (if custom endpoint)
Step 2: Model Configuration
For each provider, ask:
- "Which models from [provider] would you like to use?"
- For each model, collect:
- Model name/identifier
- Pricing model type (subscription/tieredusage/payper_use)
- Pricing details based on type:
- Subscription: cost, start date, end date
- Tiered Usage: daily quota, monthly quota, overage rate
- Pay-Per-Use: input cost per 1k tokens, output cost per 1k tokens
- Capabilities (e.g., reasoning, coding, fast-response)
- Maximum concurrent tasks
Step 3: Host Model Selection
- Ask: "Which model should serve as the primary interface (host model)?"
- Present list of configured models
- User selects one as the main interaction point
Step 4: Budget Configuration
- Ask: "What is your monthly budget limit? (optional)"
- Set alert thresholds
- 3. Configuration Persistence
- Save all configurations to
.trae/config/providers.json
- Create default role definitions in
.trae/config/team-roles.json
- Initialize empty scores database in
.trae/data/model_scores.json
- Confirm successful setup with user
Configuration Management Commands
Users can manage their configuration at any time using these commands:
View Configuration
User: "Show me my current provider and model configuration"
Response: Display complete configuration from INLINECODE6
Add Provider
User: "Add a new provider: [provider name]"
Action: Interactive prompts for provider details, then append to configuration
Add Model
User: "Add model [model name] to provider [provider name]"
Action: Interactive prompts for model details, then add to provider's model list
Update Model Pricing
User: "Update pricing for [model name]"
Action: Ask for new pricing details and update configuration
Remove Model
User: "Remove model [model name] from provider [provider name]"
Action: Confirm and remove from configuration
Change Host Model
User: "Change the host model to [model name]"
Action: Update host_model configuration
View Model Scores
User: "Show me the performance scores for all models"
Response: Display current model capability scores from INLINECODE7
Reset Configuration
User: "Reset all configurations to default"
Action: Confirm with user, then reinitialize
Configuration File Structure
Provider Configuration (.trae/config/providers.json)
CODEBLOCK8
Team Roles Configuration (.trae/config/team-roles.json)
CODEBLOCK9
Model Scores Database (.trae/data/model_scores.json)
CODEBLOCK10
Initialization Checklist
Before executing any team task, verify:
- - [ ]
.trae/config/providers.json exists and contains at least one provider - [ ] At least one model is configured
- [ ] Host model is designated
- [ ]
.trae/config/team-roles.json exists with role definitions - [ ]
.trae/data/model_scores.json exists (can be empty initially)
If any checklist item fails, trigger interactive initialization.
Core System Components
1. Model Performance Evaluation System
Multi-Dimensional Scoring
All models are periodically evaluated by peer models across multiple dimensions:
Evaluation Dimensions:
- - Response Speed: How quickly the model responds to requests
- Response Frequency: Rate of successful responses within time windows
- Thinking Depth: Quality of reasoning and problem-solving approach
- Multi-threading Capability: Ability to handle parallel tasks
- Code Quality: Quality of generated code (for coding tasks)
- Creativity: Novelty and innovation in solutions
- Reliability: Consistency in performance across sessions
- Context Understanding: Ability to maintain context over long conversations
Scoring Mechanism:
- - Each model scores other models on a scale (e.g., 1-10) for each dimension
- Scores are aggregated using weighted average
- Evaluations occur after each task completion
- Historical scores are maintained with decay factor for recent performance
- Final capability score = weighted sum of all dimension scores
Score Storage:
CODEBLOCK11
2. Cost Calculation System
Pricing Models
Subscription-Based (订阅制)
- - Fixed cost for unlimited usage during subscription period
- Lowest effective cost per request when fully utilized
- Marked as expired after subscription ends → excluded from team
- Configuration:
CODEBLOCK12
Tiered Usage (阶段用量制)
- - Lower cost with daily/monthly quotas
- Medium cost effectiveness
- Must monitor quota usage daily
- Configuration:
CODEBLOCK13
Pay-Per-Use (用量计费制)
- - Highest cost per request
- No quota limits
- Best for sporadic or overflow usage
- Configuration:
CODEBLOCK14
Cost Score Calculation:
CODEBLOCK15
3. Model Availability Management
Status Tracking:
- -
available: Ready to accept tasks - INLINECODE15 : Currently processing tasks
- INLINECODE16 : Subscription expired
- INLINECODE17 : Daily/monthly quota reached
- INLINECODE18 : Temporarily unavailable due to rate limits
- INLINECODE19 : Provider API unavailable
Busy State Management:
CODEBLOCK16
Task Execution Workflow
Phase 1: User Request & Requirement Analysis
Step 1.1: User submits request to Host Model (主模型)
- - User interacts with designated host model (primary interface)
- Host model receives and acknowledges the request
Step 1.2: Host model decomposes requirements
- - Break down request into phases and subtasks
- Identify dependencies between tasks
- Estimate complexity and required capabilities
- Create initial task tree
Step 1.3: User confirmation
- - Present task breakdown to user
- Clarify ambiguities and refine requirements
- Get explicit approval to proceed
Output:
CODEBLOCK17
Phase 2: Team Assembly Meeting
Step 2.1: Host model convenes all available models
- - Filter models by status (exclude expired, offline, quota_exceeded)
- Check busy models for potential availability
- Send meeting invitation to all eligible models
Step 2.2: Task briefing
- - Host model presents all task content to all models
- Share task breakdown, requirements, and constraints
- Distribute context and background information
Step 2.3: Collaborative role definition
- - All models discuss and agree on required roles
- Define capability requirements for each role
- Estimate workload for each role
- Identify potential bottlenecks
Meeting Output:
CODEBLOCK18
Phase 3: Role Assignment
Step 3.1: Self-nomination
- - Each model evaluates own suitability based on:
- Current cost score
- Current capability score
- Current workload (busy status)
- Role requirements match
- - Models submit role preferences
Step 3.2: Conflict resolution
- - If multiple models want same role: democratic voting
- If role has no candidates: negotiate with best-fit models
- Balance workload distribution across models
- Avoid concentrating all tasks on single model
Step 3.3: Final assignment
- - Confirm role assignments with all models
- Document assignment rationale
- Update model busy status
Assignment Algorithm:
CODEBLOCK19
Combined Score Calculation:
CODEBLOCK20
Phase 4: Herald Selection & Communication Setup
Step 4.1: Select Herald (传令官)
- - Choose fastest responding model (not necessarily most capable)
- Herald acts as central communication hub
- All models communicate through herald
Herald Responsibilities:
- - Relay messages between all team members
- Distribute progress updates
- Broadcast requirements and instructions
- Collect and aggregate results
- Monitor task completion status
- Report status to host model
- Handle timeout and failure notifications
Step 4.2: Communication channels
CODEBLOCK21
Herald Configuration:
CODEBLOCK22
Phase 5: Task Execution
Step 5.1: Parallel execution
- - Assigned models work on their respective tasks
- Regular progress updates to herald
- Herald broadcasts relevant updates to team
Step 5.2: Coordination
- - Herald checks task status periodically
- Identifies blockers and delays
- Facilitates inter-model communication
- Escalates issues to host model
Step 5.3: Progress tracking
CODEBLOCK23
Phase 6: Task Completion & Review Meeting
Step 6.1: Completion notification
- - Herald confirms all tasks completed
- Collects final outputs from all models
- Aggregates results
Step 6.2: Summary meeting
- - Host model convenes all participating models
- Each model presents their contribution
- Discuss challenges and solutions
- Evaluate collaboration effectiveness
Step 6.3: Performance re-evaluation
- - Models rate each other's performance
- Update capability scores based on task execution
- Record role-model fit assessments
- Update model scores database
Evaluation Form:
CODEBLOCK24
Phase 7: Failure Handling & Iteration
Step 7.1: Failure detection
- - Herald detects task failure or timeout
- Collects failure information from relevant models
- Reports to host model with detailed context
Step 7.2: Failure analysis meeting
- - Convene all participating models
- Analyze root cause of failure
- Identify contributing factors
- Propose solutions
Step 7.3: User consultation
- - Host model presents failure analysis to user
- Discuss potential solutions:
- Requirement changes
- Approach modifications
- Team reconfiguration
- Additional resources
- - Get user decision on next steps
Step 7.4: Iteration or termination
- - If user approves changes: restart from appropriate phase
- If user terminates: document lessons learned
- Update model scores based on partial performance
Configuration Files
Provider Configuration (.trae/config/providers.json)
CODEBLOCK25
Team Roles Configuration (.trae/config/team-roles.json)
CODEBLOCK26
Model Scores Database (.trae/data/model_scores.json)
CODEBLOCK27
Best Practices
Model Selection
- - Match model capabilities to task requirements
- Consider cost-effectiveness for routine tasks
- Reserve high-capability models for complex reasoning
- Distribute workload to prevent bottlenecks
Communication
- - Keep messages concise and clear
- Use structured formats for inter-model communication
- Herald should batch non-urgent updates
- Escalate critical issues immediately
Performance Optimization
- - Cache frequently used context
- Batch similar requests when possible
- Monitor quota usage proactively
- Maintain backup models for critical roles
Quality Assurance
- - Always conduct review meetings
- Update scores after each task
- Learn from failures systematically
- Continuously refine role definitions
Error Handling
Provider Failures
- - Retry with exponential backoff
- Switch to backup provider
- Notify team of delays
- Update model availability status
Task Failures
- - Capture detailed error context
- Analyze root cause with team
- Propose remediation strategies
- Consult user for major changes
Communication Failures
- - Herald implements heartbeat checks
- Fallback to direct model-to-model communication
- Reassign herald if unresponsive
- Log all communication issues
Output Format
Final deliverables include:
- - Complete task execution report
- Team composition and role assignments
- Individual model performance metrics
- Cost breakdown and usage statistics
- Updated model capability scores
- Lessons learned and recommendations
Skill Structure & Components
Directory Structure
CODEBLOCK28
Scripts Reference
init.js - Initialization Module
Purpose: Handles skill initialization and configuration loading.
Key Functions:
- -
ensureDirectories() - Create required directories - INLINECODE24 - Verify configuration status
- INLINECODE25 - Create default role definitions
- INLINECODE26 - Initialize empty scores database
- INLINECODE27 - Initialize empty providers config
- INLINECODE28 - Check if initialization is required
- INLINECODE29 - Read JSON configuration file
- INLINECODE30 - Write JSON configuration file
Usage:
CODEBLOCK29
config-manager.js - Configuration Management
Purpose: Manage provider and model configurations.
Key Functions:
- -
addProvider(config, providerInfo) - Add new provider - INLINECODE32 - Add model to provider
- INLINECODE33 - Remove model
- INLINECODE34 - Remove provider
- INLINECODE35 - Update pricing
- INLINECODE36 - Set host model
- INLINECODE37 - Set budget limits
- INLINECODE38 - Get list of available models
- INLINECODE39 - Get model availability status
- INLINECODE40 - Display current configuration
Usage:
CODEBLOCK30
score-manager.js - Performance Score Management
Purpose: Manage model performance evaluation scores.
Key Functions:
- -
initializeModelScore(scores, modelName, provider) - Initialize model scores - INLINECODE42 - Update dimension score
- INLINECODE43 - Calculate weighted overall score
- INLINECODE44 - Update role fit score
- INLINECODE45 - Get top models for a role
- INLINECODE46 - Get models by capability
- INLINECODE47 - Record complete evaluation
- INLINECODE48 - Display all model scores
Usage:
CODEBLOCK31
team-coordinator.js - Team Coordination
Purpose: Coordinate team assembly and task execution.
Key Class: INLINECODE49
Methods:
- -
load() - Load configurations - INLINECODE51 - Get available models list
- INLINECODE52 - Select fastest model as herald
- INLINECODE53 - Assign roles to models
- INLINECODE54 - Calculate selection score
- INLINECODE55 - Create task execution plan
- INLINECODE56 - Generate meeting agenda
- INLINECODE57 - Generate peer evaluation forms
- INLINECODE58 - Generate task report
Usage:
CODEBLOCK32
herald.js - Communication System
Purpose: Manage inter-model communication and coordination.
Key Class: INLINECODE59
Methods:
- -
initializeTeam(team) - Initialize team status tracking - INLINECODE61 - Broadcast message to all
- INLINECODE62 - Send direct message
- INLINECODE63 - Update task progress
- INLINECODE64 - Get current team status
- INLINECODE65 - Check for timeout conditions
- INLINECODE66 - Request status from all members
- INLINECODE67 - Send status report to host
- INLINECODE68 - Notify failure
- INLINECODE69 - Notify completion
- INLINECODE70 - Get overall task progress
Usage:
CODEBLOCK33
Templates Reference
task-report.md - Task Execution Report
Purpose: Document complete task execution details.
Variables:
- -
task_id - Unique task identifier - INLINECODE72 - Report generation time
- INLINECODE73 - Task status (completed/failed/in_progress)
- INLINECODE74 - Executive summary
- INLINECODE75 - Array of team member details
- INLINECODE76 - Array of execution phases
- INLINECODE77 - Performance metrics per model
- INLINECODE78 - Total execution cost
- INLINECODE79 - Array of deliverables
- INLINECODE80 - Lessons learned
- INLINECODE81 - Recommendations
- INLINECODE82 - Model score updates
Usage:
CODEBLOCK34
meeting-minutes.md - Meeting Documentation
Purpose: Document team meeting discussions and decisions.
Variables:
- -
meeting_id - Unique meeting identifier - INLINECODE84 - Type of meeting
- INLINECODE85 - Meeting date
- INLINECODE86 - Meeting duration
- INLINECODE87 - Array of participants
- INLINECODE88 - Meeting agenda
- INLINECODE89 - Voting results (if applicable)
- INLINECODE90 - Action items from meeting
- INLINECODE91 - Next steps to take
failure-report.md - Failure Analysis
Purpose: Document and analyze task failures.
Variables:
- -
task_id - Failed task identifier - INLINECODE93 - Time of failure
- INLINECODE94 - Type of failure
- INLINECODE95 - Failure severity
- INLINECODE96 - Timeline of events
- INLINECODE97 - Root cause
- INLINECODE98 - Contributing factors
- INLINECODE99 - Actions taken for recovery
- INLINECODE100 - Recommendations to prevent recurrence
evaluation-form.md - Model Evaluation
Purpose: Document peer model evaluations.
Variables:
- -
evaluator_model - Evaluating model - INLINECODE102 - Model being evaluated
- INLINECODE103 - Related task
- INLINECODE104 - Role in task
- INLINECODE105 through
context_understanding - Dimension scores - INLINECODE107 - Overall role fit assessment
- INLINECODE108 - Model strengths
- INLINECODE109 - Areas for improvement
Utilities Reference
helpers.js - General Utilities
Functions:
- -
generateId(prefix) - Generate unique identifier - INLINECODE111 - Format date to ISO string
- INLINECODE112 - Format milliseconds to readable duration
- INLINECODE113 - Calculate API cost
- INLINECODE114 - Deep clone object
- INLINECODE115 - Deep merge objects
- INLINECODE116 - Retry with exponential backoff
- INLINECODE117 - Split array into chunks
- INLINECODE118 - Group array by key
- INLINECODE119 - Sort array by key
- INLINECODE120 - Remove duplicates by key
logger.js - Logging System
Classes: INLINECODE121
Log Levels: DEBUG, INFO, WARN, ERROR
Methods:
- -
debug(message, data) - Log debug message - INLINECODE123 - Log info message
- INLINECODE124 - Log warning message
- INLINECODE125 - Log error message
- INLINECODE126 - Set log level
- INLINECODE127 - Set log file path
Usage:
CODEBLOCK35
errors.js - Custom Errors
Error Classes:
- -
ValidationError - Input validation errors - INLINECODE129 - Configuration errors
- INLINECODE130 - Model not found errors
- INLINECODE131 - Provider not found errors
- INLINECODE132 - Task execution errors
- INLINECODE133 - Timeout errors
- INLINECODE134 - Budget exceeded errors
- INLINECODE135 - Quota exceeded errors
- INLINECODE136 - Herald communication errors
Functions:
- -
handleError(error, logger) - Standardized error handling - INLINECODE138 - Check if error is recoverable
API Reference
Quick Start
CODEBLOCK36
Version History
- - v1.0.0 (2026-02-12): Initial release with full feature set
- Multi-provider support
- Three pricing models
- 8-dimension performance evaluation
- Herald communication system
- Complete workflow management
- Template-based reporting
团队协作技能
该技能通过协调的AI代理,实现动态团队创建与管理,以执行复杂的工程任务,并具备智能模型选择、成本优化和持续性能评估功能。
何时调用
在以下情况下调用此技能:
- - 用户请求执行需要多个专业角色的复杂项目
- 任务需要分解为协调步骤(分析、设计、实施、测试、审查)
- 用户希望利用多个AI模型/提供商以实现最佳性价比
- 项目需要结构化工作流程,包含质量保证和迭代
初始化与配置管理
自动初始化
重要提示:此技能包含自主初始化系统。首次调用或配置缺失时,将自动执行以下操作:
- 1. 检查配置状态
- 验证 .trae/config/providers.json 是否存在
- 验证 .trae/config/team-roles.json 是否存在
- 验证 .trae/data/model_scores.json 是否存在
- 2. 交互式设置流程
如果配置文件缺失或不完整,技能将主动询问用户:
步骤1:提供商设置
- 询问:您想配置哪些AI提供商?(例如:OpenAI、Anthropic、Google、Azure等)
- 为每个提供商收集:
- 提供商名称
- API密钥(或环境变量名称)
- 基础URL(如果是自定义端点)
步骤2:模型配置
针对每个提供商,询问:
- 您想使用[提供商]的哪些模型?
- 为每个模型收集:
- 模型名称/标识符
- 定价模型类型(订阅制/阶段用量制/用量计费制)
- 基于类型的定价详情:
- 订阅制:费用、开始日期、结束日期
- 阶段用量制:每日配额、每月配额、超额费率
- 用量计费制:每千token输入成本、每千token输出成本
- 能力(例如:推理、编码、快速响应)
- 最大并发任务数
步骤3:主模型选择
- 询问:哪个模型应作为主要接口(主模型)?
- 展示已配置的模型列表
- 用户选择一个作为主要交互点
步骤4:预算配置
- 询问:您的月度预算上限是多少?(可选)
- 设置告警阈值
- 3. 配置持久化
- 将所有配置保存到 .trae/config/providers.json
- 在 .trae/config/team-roles.json 中创建默认角色定义
- 在 .trae/data/model_scores.json 中初始化空评分数据库
- 向用户确认设置成功
配置管理命令
用户可以随时使用以下命令管理配置:
查看配置
用户:显示我当前的提供商和模型配置
响应:显示来自 .trae/config/providers.json 的完整配置
添加提供商
用户:添加新提供商:[提供商名称]
操作:交互式提示提供商详情,然后追加到配置中
添加模型
用户:向提供商[提供商名称]添加模型[模型名称]
操作:交互式提示模型详情,然后添加到提供商的模型列表
更新模型定价
用户:更新[模型名称]的定价
操作:询问新的定价详情并更新配置
移除模型
用户:从提供商[提供商名称]移除模型[模型名称]
操作:确认并从配置中移除
更改主模型
用户:将主模型更改为[模型名称]
操作:更新 host_model 配置
查看模型评分
用户:显示所有模型的性能评分
响应:显示来自 .trae/data/model_scores.json 的当前模型能力评分
重置配置
用户:将所有配置重置为默认值
操作:与用户确认,然后重新初始化
配置文件结构
提供商配置(.trae/config/providers.json)
json
{
version: 1.0,
last_updated: 2026-02-12T11:00:00Z,
providers: [
{
name: openai,
apikey: ${OPENAIAPI_KEY},
base_url: https://api.openai.com/v1,
models: [
{
name: gpt-4,
pricingmodel: payper_use,
inputcostper_1k: 0.03,
outputcostper_1k: 0.06,
context_window: 128000,
capabilities: [reasoning, coding, analysis],
maxconcurrenttasks: 3
}
]
}
],
host_model: {
provider: openai,
model: gpt-4
},
budget: {
maxmonthlycost: 100.00,
currency: USD,
alert_threshold: 0.8
}
}
团队角色配置(.trae/config/team-roles.json)
json
{
version: 1.0,
last_updated: 2026-02-12T11:00:00Z,
roles: {
project_manager: {
description: 协调团队活动并管理时间线,
required_capabilities: [planning, coordination, communication],
preferredmodeltraits: {
reliability: high,
thinking_depth: medium,
response_speed: medium
}
}
}
}
模型评分数据库(.trae/data/model_scores.json)
json
{
version: 1.0,
last_updated: 2026-02-12T11:00:00Z,
evaluation_interval: 3600,
scores: {}
}
初始化检查清单
在执行任何团队任务之前,请验证:
- - [ ] .trae/config/providers.json 存在且包含至少一个提供商
- [ ] 至少配置了一个模型
- [ ] 已指定主模型
- [ ] .trae/config/team-roles.json 存在并包含角色定义
- [ ] .trae/data/model_scores.json 存在(初始可以为空)
如果任何检查项失败,触发交互式初始化。
核心系统组件
1. 模型性能评估系统
多维度评分
所有模型由同行模型定期在多个维度上进行评估:
评估维度:
- - 响应速度:模型响应请求的速度
- 响应频率:在时间窗口内成功响应的比率
- 思考深度:推理和问题解决方法的深度
- 多线程能力:处理并行任务的能力
- 代码质量:生成代码的质量(针对编码任务)
- 创造力:解决方案的新颖性和创新性
- 可靠性:跨会话的性能一致性
- 上下文理解:在长对话中保持上下文的能力
评分机制:
- - 每个模型对其他模型在每个维度上进行评分(例如1-10分)
- 使用加权平均汇总评分
- 每次任务完成后进行评估
- 历史评分保留,近期表现有衰减因子
- 最终能力评分 = 所有维度评分的加权和
评分存储:
json
{
model_scores: {
gpt-4: {
response_speed: 8.5,
response_frequency: 9.0,
thinking_depth: 9.5,
multi_threading: 7.0,
code_quality: 9.0,
creativity: 8.5,
reliability: 9.5,
context_understanding: 9.0,
overall_score: 8.75,
evaluation_count: 42,
last_updated: 2026-02-12T10:30:00Z
}
}
}
2. 成本计算系统
定价模型
订阅制
- - 订阅期内无限使用的固定成本
- 充分利用时每次请求的有效成本最低
- 订阅结束后标记为过期 → 从团队中排除
- 配置:
json
{
pricing_model: subscription,
cost: 20.00,
currency: USD,
valid_from: 2026-02-01,
valid_until: 2026-03-01,
status: active
}
阶段用量制
- - 每日/每月配额内成本较低
- 中等成本效益
- 必须每日监控配额使用情况
- 配置:
json
{
pricing
model: tieredusage,
daily_quota: 1000,
daily_used: 450,
monthly_quota: 30000,
monthly_used: 12500,
cost: 15