名称: 可组合原语 描述: 设计可组合的代理原语用于灵活的工作流。在创建可重用的工作流构建块、设计SDLC原语或构建可以不同方式组合的代理操作时使用。 允许工具: 读取, Grep, Glob
可组合原语技能
指导设计可组合的代理原语用于灵活的工作流创建。
何时使用
- 设计新的代理工作流
- 为特定需求定制SDLC
- 将问题类别映射到原语
- 构建组织特定的组合
秘诀
“战术性代理编码的秘诀在于，它根本与软件开发生命周期无关。它是关于你可以用来解决任何工程问题类别的可组合代理原语。”
核心原语
| 原语 | 目的 | 输入 | 输出 |
|---|---|---|---|
| 分类 | 分类输入 | 问题/任务 | 分类 |
| 计划 | 创建实现规范 | 问题 | 计划文件 |
| 构建 | 实现计划 | 计划文件 | 代码变更 |
| 测试 | 验证功能 | 代码变更 | 通过/失败 |
| 审查 | 验证对齐 | 规范 + 代码 | 问题列表 |
| 修补 | 修复特定问题 | 问题描述 | 针对性修复 |
| 文档 | 生成文档 | 代码变更 | 文档文件 |
| 部署 | 部署到生产 | 已验证代码 | 部署状态 |
| 分支 | 创建隔离上下文 | 分类 | 分支名称 |
| 提交 | 保存检查点 | 变更 | 提交哈希 |
组合工作流
步骤1: 识别问题类别
工作类型？
- 琐事（简单，低风险）
- 错误（中等复杂性，明确标准）
- 功能（复杂，完整SDLC）
- 热修复（紧急，最小流程）
- 文档（仅内容）
步骤2: 选择原语
基于问题类别，选择原语：
| 问题类别 | 原语 |
|---|---|
| 琐事 | 分类 -> 构建 -> 测试 -> 部署 |
| 错误 | 分类 -> 计划 -> 构建 -> 测试 -> 审查 -> 部署 |
| 功能 | 完整SDLC |
| 热修复 | 修补 -> 测试 -> 部署 |
| 文档 | 文档 -> 审查 -> 部署 |
步骤3: 按依赖关系排序
确保正确的序列：
- 计划在构建之前（构建需要计划）
- 构建在测试之前（测试需要代码）
- 测试在部署之前（部署需要验证）
步骤4: 添加验证点
失败应在何处停止管道？
计划 -> 构建 -> [测试门] -> 审查 -> [审查门] -> 部署
步骤5: 定义入口/出口
- 入口：什么触发此工作流？
- 出口：什么信号完成？
标准组合
完整SDLC
分类 -> 计划 -> 构建 -> 测试 -> 审查 -> 文档 -> 部署
ZTE（零接触）
分类 -> 计划 -> 构建 -> 测试 -> 审查 -> 文档 -> 部署
| |
[门] [门]
快速修复
分类 -> 修补 -> 测试 -> 部署
审查驱动
审查 -> 修补 -> 测试 -> 部署
自定义组合设计
组织因素
考虑：
- 测试要求（强制端到端？）
- 审查流程（谁审查？）
- 文档标准（自动生成？）
- 部署管道（手动批准？）
- 合规需求（审计跟踪？）
示例：合规性强
分类 -> 计划 -> [合规审查] -> 构建 -> 测试 ->
[安全扫描] -> 审查 -> 文档 -> [批准] -> 部署
示例：快速迭代
构建 -> 测试 -> 部署（小变更无需计划）
关键记忆参考
- @可组合原语.md - 详细原语文档
- @模板工程.md - 作为原语定义的模板
- @ADW解剖.md - ADW作为组合框架
输出格式
提供组合设计：
## 工作流组合
**问题类别：** {类型}
**入口触发器：** {触发器}
**出口标准：** {标准}
### 所选原语
1. 分类 - 分类任务
2. 计划 - 创建实现规范
3. 构建 - 实现变更
4. 测试 - 验证功能
5. 部署 - 部署到生产
### 组合流程
分类 -> 计划 -> 构建 -> 测试 -> 部署 | [门：必须通过]
### 验证门
- 测试后：如果测试失败则中止
- 审查后：基于信心的可选
### 自定义
- [组织特定添加]
反模式
- 僵化的SDLC思维（必须做所有步骤）
- 过度组合（原语太多）
- 不足组合（缺少关键步骤）
- 忽略失败路径（无门）
- 一刀切（所有问题类别相同）
版本历史
- v1.0.0 (2025-12-26): 初始发布
最后更新
日期： 2025-12-26 模型： claude-opus-4-5-20251101