Kanban Workflow 技能评估
核心用法
Kanban Workflow 是一个 TypeScript 实现的看板式项目管理自动化框架，定位为"代理协作者"（agentic co-worker）。其核心设计围绕标准化阶段模型（stage:backlog → blocked → in-progress → in-review）展开，通过CLI优先的适配器架构对接主流项目管理平台。
架构特点
- Ports & Adapters 模式：核心逻辑与平台实现解耦，适配器作为"智能包装器"调用外部CLI（
gh、plane、linear等） - 事件驱动设计：基于轮询+快照差异（polling/diffing）合成事件，弥补部分平台缺乏Webhook的局限
- 工作流动词体系：
show/next/start/update/ask/complete/create构成完整任务生命周期操作集
关键配置
初始化通过 setup 命令完成，需指定：
- 目标适配器（GitHub/Plane/Linear/Planka之一）
- 四阶段映射规则（
--map-*系列参数） - 平台特定凭证（继承自各CLI的环境变量，如
PLANE_API_KEY、LINEAR_API_KEY）
自动化能力
autopilot-tick：定时轮询模式，可配置Cron表达式runProgressAutoUpdates()：任务执行期间自动进度更新（5分钟间隔）- 多项目监控：默认跨所有可访问项目，单项目需显式限定
显著优点
| 维度 | 优势 |
|------|------|
| **互操作性** | 统一抽象层屏蔽GitHub Projects/Linear/Plane/Planka平台差异 |
| **安全模型** | 不托管凭证，完全依赖外部CLI的认证状态，零密钥持久化风险 |
| **工作流引导** | CLI内置"What next"提示，降低用户认知负担 |
| **阶段一致性** | 强制四阶段模型，避免各平台状态定义混乱 |
| **可扩展性** | 适配器接口清晰，新增平台仅需实现`fetchSnapshot`等核心方法 |
潜在局限
1. 外部依赖刚性：要求预装node、npm及平台特定CLI，环境准备复杂度较高
2. 事件延迟：轮询架构（默认5分钟）相比原生Webhook存在固有延迟
3. 阶段映射摩擦：四阶段强制归一化可能与部分平台原生工作流不完全契合
4. 成熟度风险：Plane/Linear适配器标记为"待完成验证"（Finish and validate），生产稳定性存疑
5. OAuth缺失：不处理交互式授权流，依赖用户预配置CLI会话
适合人群
- 多平台项目管理用户：需在GitHub/Linear/Plane/Planka间保持一致工作流的团队
- 自动化优先团队：希望将看板操作嵌入CI/CD或代理工作流的开发者
- 安全敏感组织：偏好凭证外置、不托管API密钥的合规场景
- TypeScript技术栈团队：便于二次开发和深度定制
常规风险
| 风险类别 | 说明 |
|---------|------|
| **配置漂移** | `config/kanban-workflow.json`缺失或无效时所有命令报错，需严格版本控制 |
| **CLI会话过期** | 依赖的外部CLI认证失效会导致适配器级联失败 |
| **速率限制** | 高频轮询可能触发GitHub/Linear等平台API限流 |
| **权限边界模糊** | `assigned-to-me`过滤依赖平台侧实现，可能存在跨项目可见性泄露风险 |
| **自动化误操作** | `autopilot-tick`在无人工确认下执行状态流转，需配合`ask`模式谨慎使用 |
生态定位
该技能属于OpenClaw技能生态中的工作流编排层，与plane（vaguilera-jinko）、linear（ManuelHettich）等技能存在依赖关系，适合作为上层自动化代理的基础设施组件。