Task Development Workflow

核心用法

本技能定义了一套结构化的软件开发工作流，适用于需要高质量交付的团队协作项目。工作流程分为七个阶段：

1. 需求澄清阶段：在编码前必须充分理解业务需求、UI/UX流程、架构决策和技术约束，明确模糊点后才能继续
2. 规划审批阶段：将任务拆分为小而专注的子任务，提交详细计划并等待明确批准，未经批准不得开始实现
3. 任务追踪设置：使用Trello看板管理任务状态（Backlog → To Do → In Progress → Review → Done）
4. TDD实现阶段：严格执行测试驱动开发——先写测试（应失败）、再实现功能、再验证测试通过；每个任务完成后提交代码
5. 分支与PR策略：禁止直接推送main分支，必须为每个任务创建特性分支，PR描述中需包含Trello任务链接
6. PR反馈循环：收到代码审查意见后，将任务移回In Progress，修复问题后通知审查者重新审查，循环直至批准
7. 合并门禁：当前PR合并后才能选取下一个任务

显著优点

• 质量保障：TDD在开发早期捕获缺陷，减少后期返工成本
• 流程透明：看板可视化任务流转，状态清晰可追溯
• 风险控制：规划审批和合并门禁防止方向性错误和代码污染
• 协作规范：强制通知审查者、关联Trello与PR，减少沟通摩擦
• 小步快跑：任务粒度小，代码审查负担轻，合并冲突少

潜在缺点与局限性

• 启动成本：前期需求澄清和规划审批可能延缓项目启动，不适合探索性原型开发
• 流程刚性：测试跳过需显式批准，紧急修复场景可能受限
• 工具依赖：深度绑定Trello，使用其他项目管理工具时需要适配
• 审查瓶颈：PR反馈循环可能成为阻塞点，审查者响应不及时时影响吞吐
• 单线程限制：必须等PR合并才能开始下一任务，无法并行处理多个任务

适合人群

• 追求代码质量的中小型开发团队
• 需要严格质量门禁的协作项目（如开源贡献、外包交付）
• 采用TDD实践的敏捷团队
• 远程协作团队，需要异步透明的工作流

常规风险

• 流程形式化：团队可能机械执行流程而忽视实际价值，沦为"为了流程而流程"
• 审查疲劳：频繁的PR往返可能导致审查者倦怠，降低审查质量
• 上下文切换：任务在In Progress和Review间反复移动，开发者需频繁切换注意力
• 工具同步失效：Trello状态与Git状态可能不一致，需额外维护成本

核心用法

该 Skill 是一套完整的敏捷开发工作流指南，通过八个阶段规范软件开发全周期：需求澄清 → 计划审批 → 看板设置 → TDD 实现 → 分支管理 → PR 审查 → 合并上线 → 迭代下一任务。用户只需告知 Agent 启动工作流，它将自动引导完成每个环节——包括创建 Trello 看板、执行测试先行开发、遵循 Git 分支策略、建立 PR 反馈循环等。Skill 特别强调「无审批不实施」原则，每个关键节点需人工确认后才继续。

显著优点

流程标准化：强制 TDD（测试驱动开发）和代码审查，从源头减少缺陷；质量门禁机制：明确划分 Clarify/Plan/Approve 三个阶段，避免需求蔓延和返工；可视化追踪：集成 Trello 看板，任务状态透明可追溯；小步快跑：要求任务拆分为小而专注的单元，降低合并冲突和审查负担；零代码风险：纯 Markdown 文档型 Skill，无可执行代码、无外部依赖、无 API 调用，安全性极高。

潜在缺点与局限

工具绑定较紧：默认预设 Trello 作为看板工具，若团队使用 Jira/Notion 等需手动调整；流程刚性较强：「必须等待显式批准」「测试不可跳过」等规则可能降低灵活性，紧急迭代场景或有摩擦；无自动化集成：需人工操作 Git 命令、PR 创建、Trello 卡片移动，Agent 仅提供流程指导而非自动执行；单人维护来源：T3 可信度，无企业背书，长期更新保障存疑。

适合的目标群体

初创技术团队：需快速建立规范流程而无需引入复杂 DevOps 工具；全栈开发者个人项目：希望用轻量级方式实践 TDD 和代码审查；技术导师/教练：作为教学模板向学员演示标准开发流程；远程协作团队：依赖看板和 PR 链接保持异步沟通透明。不适合：已成熟运行的 CI/CD 流水线团队、追求极致自动化的大型工程组织。

使用风险

该 Skill 本身安全无虞（S+/T3），但需关注操作边界风险：Agent 可能建议执行 git push、创建 PR、修改看板等操作，若未明确限制仓库权限，存在误操作生产代码的可能；流程理解偏差：Agent 对「显式批准」的判断可能不够严谨，需用户主动把控关键节点；工具链依赖：Trello 等第三方服务稳定性影响工作流体验，建议提前确认网络与账号权限。