核心功能
Kanban Workflow 是一个为 AI Agent 设计的项目管理协作框架，采用看板方法论中的四个标准阶段（backlog/blocked/in-progress/in-review）作为核心状态机，实现跨平台项目管理能力的统一抽象。
架构设计：采用"端口-适配器"模式，核心层定义平台无关的实体（WorkItem、Project、Comment、Stage）和事件模型，适配器层通过调用外部 CLI（gh、planka-cli、plane、linear）完成具体平台集成。这种设计使得 GitHub Issues、Plane、Linear、Planka 等不同系统可以共享同一套业务逻辑和自动化规则。
工作流动词：提供标准化的命令动词——show（查看任务）、next（获取下一任务）、start（开始处理）、update（更新进度）、ask（请求澄清）、complete（完成任务）、create（创建任务），形成完整的任务生命周期管理。每个命令执行后都会输出 "What next" 提示，引导用户遵循最佳实践流程。
自动化能力：支持轮询+差异检测（polling/diffing）的事件合成机制，即使平台原生不支持特定事件类型也能捕获状态变更；同时提供自动进度更新功能，每 5 分钟在 in-progress 阶段任务下发布状态评论。
集成方式：通过环境变量继承外部 CLI 的认证信息（如 PLANE_API_KEY、LINEAR_API_KEY），自身不管理 OAuth 流程或持久化密钥，安全性依赖底层工具。
显著优势
- 平台抽象统一：四阶段状态机简化了多平台差异，降低心智负担
- CLI 优先设计：基于成熟 CLI 工具集成，复用现有认证体系，无需额外配置
- 自动化友好：轮询+差异检测机制弥补了部分平台事件能力的不足
- 强引导性：内置 "What next" 工作流提示，确保协作规范性
局限性与风险
- 成熟度风险：Plane 和 Linear 适配器尚处于待完成状态，ClawHub 外部技能的接口稳定性存在不确定性
- 轮询开销：依赖轮询而非原生 webhook，高频场景下可能产生 API 调用压力和延迟
- 平台覆盖有限：当前仅支持四种平台，Jira、Asana 等主流工具未纳入
- 阶段映射刚性：强制四阶段模型可能与某些团队的实际流程不完全匹配
适用场景
适合需要跨多个项目管理平台统一工作流的技术团队，特别是已将 CLI 工具纳入日常开发工作流、希望为 AI Agent 赋予结构化任务执行能力的组织。对已有成熟 Jira/Asana 流程的企业迁移成本较高。