名称: 工作流创建器描述: ‘为复杂任务创建多代理协调工作流。处理企业工作流、操作流程和自定义协调模式。在用户需要自动化多阶段流程并协调代理时使用。’ 版本: 2.1.0 模型: sonnet 调用者: 两者用户可调用: true 工具: [读取, 写入, 编辑, Bash, Glob, Grep]

阶段1集成: 所有工具已根据.claude/config/tool-manifest.json验证

当工作流生成代理时，代理从基于清单的工具集接收工具

单一事实来源: .claude/config/tool-manifest.json

最佳实践:

定义清晰的阶段边界
明确指定代理交接
包括错误恢复程序
文档化并行与顺序执行错误处理: 优雅流式传输: 支持输出位置: .claude/workflows/ 已验证: false 最后验证时间: 2026-02-19T05:29:09.098Z

工作流创建器技能

为需要跨多个代理和阶段协调的复杂任务创建多代理协调工作流。

路由器更新要求（关键 - 勿跳过）

创建任何工作流后，必须更新CLAUDE.md第8.6节“企业工作流”:

### {工作流名称}

**路径:** `.claude/workflows/{类别}/{工作流名称}.md`

**何时使用:** {触发条件}

**阶段:**

1. **{阶段名称}** - {描述}
   ...

**涉及的代理:**

- `{代理名称}` - {在工作流中的角色}

验证:

grep "{工作流名称}" .claude/CLAUDE.md || echo "错误: CLAUDE.md第8.6节未更新！"

原因: 未在CLAUDE.md中列出的工作流将永远不会被路由器调用。

何时触发此技能

用户请求复杂协调，需要多个代理
可重复的多阶段流程需要标准化
路由器识别工作流缺口用于常见任务模式
现有工作流需要增强或定制

快速参考

操作	方法
检查现有工作流	`Glob: .claude/workflows/*/.md`
查看工作流模板	读取 `.claude/templates/workflows/workflow-template.md`
查找相关代理	`Glob: .claude/agents/*/.md`
查找相关技能	`Glob: .claude/skills/*/SKILL.md`
创建工作流	写入到 `.claude/workflows/<类别>/<名称>.md`

工作流类型

类型	位置	目的	示例
企业	`.claude/workflows/enterprise/`	复杂多阶段开发	功能开发, C4架构
操作	`.claude/workflows/operations/`	运行时程序、事件响应	事件响应、部署
快速	`.claude/workflows/rapid/`	快速、聚焦的任务自动化	修复、重构、评审
自定义	`.claude/workflows/`	项目特定模式	指挥器设置

工作流-代理原型参考

创建工作时，确定哪些代理原型将使用该工作流。参见 .claude/docs/@WORKFLOW_AGENT_MAP.md 以获取：

第1节: 完整的工作流-代理矩阵
第2节: 原型工作流集（路由器/协调器、实施者、评审者、文档者、研究者、领域）

创建工作流后，必须将其添加到矩阵中，并更新受影响代理的## 相关工作流部分。

工作流创建流程

步骤0: 存在性检查和更新器委托（强制 - 第一步）

创建任何工作流文件前，检查是否已存在:

检查工作流是否已存在:

test -f .claude/workflows/<类别>/<工作流名称>.md && echo "存在" || echo "新建"

如果工作流已存在:

不要继续创建

调用工件更新器工作流代替:

Skill({
  技能: 'artifact-updater',
  参数: {
    名称: '<工作流名称>',
    更改: '<请求的更改描述>',
    理由: '通过工作流创建器请求更新',
  },
});

返回更新器结果并停止

如果工作流是新建的:
- 继续下面的步骤0.5

步骤0.5: 伴侣检查

在继续创建前，运行生态系统伴侣检查：

使用 .claude/lib/creators/companion-check.cjs 中的 companion-check.cjs
调用 checkCompanions("workflow", "{工作流名称}") 以识别伴侣工件
查看伴侣检查清单 — 注意哪些必需/推荐的伴侣缺失
计划在此工件完成后创建或验证缺失的伴侣
在创建后集成笔记中包括伴侣发现

此步骤是信息性的（不阻止创建），但确保考虑完整的工件生态系统。

步骤1: 验证无现有工作流

# 搜索相关工作流
Glob: .claude/workflows/**/*.md
Grep: "<主题>" in .claude/workflows/

如果存在合适的工作流，考虑增强它而不是创建重复项。

步骤2.5: 工作流模式研究（强制）

创建工作流前，研究现有模式。

1. 检查现有工作流:

Glob: .claude/workflows/**/*.md

2. 研究工作流模式（至少2个查询）：

WebSearch({ 查询: '[工作流类型] 协调最佳实践' });
WebSearch({ 查询: '[领域] 多代理工作流模式' });

3. 在工作流评论中记录找到的模式

阻塞: 如果没有模式研究，工作流创建无法进行。这确保工作流遵循既定模式而不是重新发明解决方案。

步骤2: 识别阶段和代理

分析过程以分解为阶段:

问题	确定
什么是不同的阶段？	阶段边界
哪个代理处理每个阶段？	代理分配
任何阶段可以并行运行吗？	并行执行机会
什么输出馈入下一阶段？	数据流和交接
每个阶段可能出什么问题？	错误恢复程序

常见阶段模式:

模式	阶段	何时使用
发现 -> 设计 -> 评审 -> 实现	功能开发
分析 -> 修复 -> 测试 -> 部署	错误修复工作流
探索 -> 计划 -> 评审	计划工作流
分类 -> 调查 -> 解决 -> 文档	事件响应
代码 -> 组件 -> 容器 -> 上下文	C4架构文档

步骤3: 定义代理交接

对于每个阶段转换，指定：

### 阶段1 -> 阶段2 交接

**来自阶段1的输出**: .claude/context/plans/phase1-output.md
**输入到阶段2**: 读取阶段1的输出
**交接验证**: [检查输出存在且有效]

步骤4: 生成工作流定义

写入到 .claude/workflows/<类别>/<工作流名称>.md:

---
名称: { 工作流名称 }
描述: { 工作流目的的简要描述 }
版本: 1.0.0
代理:
  - { 代理-1 }
  - { 代理-2 }
标签: [{ 标签1 }, { 标签2 }, workflow]
---

# {工作流标题}

{工作流目的和何时使用它的简要描述。}

**扩展思考**: {工作流原理、方法和设计决策的详细解释。}

## 概述

{此工作流完成什么的详细描述。}

## 配置选项

### {选项类别1}

- **{值_1}**: {描述}
- **{值_2}**: {描述}

## 阶段1: {阶段名称}

### 步骤1: {步骤名称}

**代理**: {代理名称}

**任务生成**:

```javascript
任务({
  任务_id: 'task-1',
  子代理类型: 'general-purpose',
  描述: '{任务描述}',
  提示: `你是{代理名称}代理。

## 任务
{任务描述}

## 指令
1. 读取你的代理定义: .claude/agents/{类别}/{代理}.md
2. **调用技能**: 技能({ 技能: "{技能名称}" })
3. {附加指令}
4. 保存输出到: .claude/context/{输出路径}

## 上下文
- {上下文项1}
- {上下文项2}

## 内存协议
1. 首先读取 .claude/context/memory/learnings.md
2. 记录决策到 .claude/context/memory/decisions.md
`,
});
```

预期输出: {预期输出的描述}

阶段2: {阶段名称}

步骤2: {步骤名称} (并行)

代理: {代理-A} + {代理-B} (并行生成)

任务生成:

// 并行生成两个代理以提高效率
任务({
  任务_id: 'task-2',
  子代理类型: 'general-purpose',
  描述: '{代理A任务}',
  提示: `你是{代理A}...`,
});

任务({
  任务_id: 'task-3',
  子代理类型: 'general-purpose',
  描述: '{代理B任务}',
  提示: `你是{代理B}...`,
});

预期输出: {描述}

错误恢复

如果阶段1失败:

{恢复步骤}
重启阶段1

如果阶段2评审发现阻塞:

{恢复步骤}
重新运行评审

成功标准

[ ] {标准1}
[ ] {标准2}
[ ] 所有代理完成其阶段
[ ] 内存文件已更新

使用示例

// 路由器生成工作流协调器
任务({
  任务_id: 'task-4',
  子代理类型: 'general-purpose',
  描述: '协调{工作流名称}工作流',
  提示: `执行{工作流名称}工作流。

## 参数
- {参数1}
- {参数2}

## 指令
遵循分阶段工作流: .claude/workflows/{类别}/{工作流名称}.md
`,
});


### 步骤5: 验证工作流引用（阻塞）

**在写入工作流文件前，验证所有引用有效:**

| 引用 | 验证 |
|-----------|-----------|
| 代理文件 | `代理:` 数组中的所有代理存在于 `.claude/agents/` 中 |
| 技能 | 提示中引用的所有技能存在于 `.claude/skills/` 中 |
| 输出路径 | 所有输出目录存在或将被创建 |
| 上下文文件 | 所有引用的上下文文件可访问 |

**写入前验证清单:**

[ ] 所有引用的代理存在 [ ] 所有引用的技能存在 [ ] 输出路径有效 [ ] 错误恢复程序完整 [ ] 成功标准可测量


**阻塞**: 如果任何引用无效，不要写入工作流文件。

### 步骤5.5: 模型和工具验证（关键）

**代理生成的模型验证（关键）:**

当工作流模板通过任务工具生成代理时：
- 模型字段必须仅使用基本名称：`haiku`、`sonnet` 或 `opus`
- 不要使用带日期版本，如 `claude-opus-4-5-20251101`
- 根据任务复杂性选择模型：
  - `haiku`: 快速验证、简单任务
  - `sonnet`: 标准工作（默认）
  - `opus`: 复杂推理、架构

**示例:**
```javascript
// 正确
任务({
  任务_id: 'task-5',
  模型: 'sonnet',
  // ...
});

// 错误 - 导致验证失败
任务({
  任务_id: 'task-6',
  模型: 'claude-sonnet-4-20250514',
  // ...
});

工具数组验证:

当指定生成代理的allowed_tools时：

使用标准工具：读取、写入、编辑、Bash、TaskUpdate、TaskList等。
不要包括MCP工具（mcp__*），除非在routing-table.cjs中已列入白名单
MCP工具导致路由器强制执行失败

允许的工具（标准）:

allowed_tools: [
  '读取',
  '写入',
  '编辑',
  'Bash',
  'TaskUpdate',
  'TaskList',
  'TaskCreate',
  'TaskGet',
  '技能',
];

受限制的工具（需要明确白名单）:

mcp__Exa__* - 仅用于进化协调器
mcp__github__* - 仅用于特定GitHub操作
其他MCP工具 - 必须在routing-table.cjs中列入白名单

代理生成的验证清单:

[ ] 模型字段使用基本名称（haiku/sonnet/opus）
[ ] allowed_tools仅包含标准工具或明确白名单的MCP工具
[ ] 无带日期模型版本（例如，claude-opus-4-5-20251101）

步骤6: 更新CLAUDE.md第8.6节（强制 - 阻塞）

此步骤自动且阻塞。勿跳过。

工作流文件写入后，必须更新CLAUDE.md：

找到第8.6节（“企业工作流”）
生成工作流条目，格式如下：

### {工作流名称}

**路径:** `.claude/workflows/{类别}/{工作流名称}.md`

**何时使用:** {触发条件 - 具体}

**阶段:**

1. **{阶段1名称}** - {简要描述}
2. **{阶段2名称}** - {简要描述}
   ...

**配置选项:**

- {选项类别}: `{值}`

**涉及的代理:**

- `{代理名称}` - {角色描述}

插入到适当位置（按字母顺序或在节末）
验证:

grep "{工作流名称}" .claude/CLAUDE.md || echo "错误: CLAUDE.md未更新 - 阻塞！"

阻塞: 如果CLAUDE.md更新失败，工作流创建不完整。不要继续。

步骤7: 系统影响分析（阻塞）

创建任何工作流后，分析并更新系统范围影响。

[工作流创建器] 系统影响分析：<工作流名称>

1. CLAUDE.md更新（强制）
   - 添加条目到第8.6节（企业工作流）
   - 如果路由器引用，添加到第3节（多代理工作流）
   - 用grep验证

2. 代理协调检查
   - 所有引用的代理是否存在？
   - 代理是否需要新技能用于此工作流？
   - 任何代理的定义应引用此工作流吗？

3. 技能可用性检查
   - 所有引用的技能是否可用？
   - 此工作流是否需要新技能？ -> 调用技能创建器
   - 应增强现有技能吗？

4. 内存集成检查
   - 工作流使用内存协议吗？
   - 输出路径可写吗？
   - 工件会正确持久化吗？

5. 相关工作流检查
   - 此工作流是否重复现有工作流功能？
   - 现有工作流应引用此工作流吗？
   - 有工作流依赖需要文档化吗？

6. 工作流-代理映射已更新（强制）
   - 添加新工作流到@WORKFLOW_AGENT_MAP.md第1节矩阵
   - 确定哪些代理原型使用此工作流
   - 更新受影响代理的`## 相关工作流`部分
   - 验证: `grep "<工作流名称>" .claude/docs/@WORKFLOW_AGENT_MAP.md || echo "错误: 工作流不在代理映射中！"`

验证清单（每次创建后运行） - 阻塞

# 验证工作流文件存在
ls .claude/workflows/<类别>/<工作流名称>.md

# 验证所有引用的代理存在
for agent in $(grep -oE '\\.claude/agents/[^"]+\\.md' .claude/workflows/<类别>/<工作流>.md); do
  [ -f "$agent" ] || echo "损坏: $agent"
done

# 验证所有引用的技能存在
for skill in $(grep -oE '技能: "[^"]+"' .claude/workflows/<类别>/<工作流>.md | cut -d'"' -f2); do
  [ -f ".claude/skills/$技能/SKILL.md" ] || echo "损坏: $技能"
done

# 检查CLAUDE.md有工作流条目 - 强制
grep "<工作流名称>" .claude/CLAUDE.md || echo "错误: 不在CLAUDE.md中 - 工作流创建不完整"

完成清单（所有必须勾选）：

[ ] 工作流模式研究完成（步骤2.5）
[ ] 工作流文件创建于 .claude/workflows/<类别>/<名称>.md
[ ] 所有引用的代理存在于 .claude/agents/
[ ] 所有引用的技能存在于 .claude/skills/
[ ] 模型字段仅使用基本名称（haiku/sonnet/opus）
[ ] allowed_tools数组仅包含标准或白名单工具
[ ] CLAUDE.md第8.6节已更新
[ ] 工作流条目已验证
[ ] 所有代理提示中包括内存协议

阻塞: 如果任何项失败，工作流创建不完整。在继续前修复所有问题。

步骤8: 创建后工作流注册（阶段3集成）

此步骤关键。 创建工作流工件后，必须在工作流发现系统中注册它。

阶段3上下文: 阶段1创建工具清单（工具），阶段2创建技能索引（技能），阶段3创建工作流注册，使工作流可以被协调器发现和调用。

工作流文件写入并验证后：

在适当位置创建/更新工作流注册条目:

如果注册不存在，创建 .claude/context/artifacts/catalogs/workflow-registry.json:

{
  "工作流": [
    {
      "名称": "{工作流名称}",
      "id": "{工作流名称}",
      "描述": "{来自工作流的简要描述}",
      "类别": "{enterprise|core|operations}",
      "版本": "1.0.0",
      "触发条件": ["{条件1}", "{条件2}"],
      "参与代理": ["{代理-1}", "{代理-2}"],
      "阶段": [
        { "名称": "{阶段1名称}", "描述": "{简要描述}" },
        { "名称": "{阶段2名称}", "描述": "{简要描述}" }
      ],
      "文件路径": ".claude/workflows/{类别}/{工作流名称}.md",
      "协调器引用": []
    }
  ]
}

向适当协调器注册:

更新应使用此工作流的协调器：
- master-orchestrator.md: 协调其他工作流的元工作流
- evolution-orchestrator.md: 进化阶段工作流（研究、创建、验证）
- party-orchestrator.md: 共识/投票工作流
- swarm-coordinator.md: 协调工作流
添加到协调器的工作流引用：
```
## 可用工作流

- `{工作流名称}` (.claude/workflows/{类别}/{工作流名称}.md)
```

文档化在 .claude/docs/WORKFLOW_CATALOG.md:

如果目录不存在，创建它。添加条目：

### {工作流标题}

**路径:** `.claude/workflows/{类别}/{工作流名称}.md`

**何时使用:** {触发条件 - 具体场景}

**参与代理:**

- {代理-1}: {在工作流中的角色}
- {代理-2}: {在工作流中的角色}

**阶段:**

1. **{阶段1名称}** - {描述}
2. **{阶段2名称}** - {描述}

**协调器集成:**

- 由调用: {协调器名称}
- 触发: {协调器如何发现/触发此工作流}

验证工作流可发现性:

测试工作流可被发现：

# 检查工作流注册存在且是有效JSON
node -e "console.log(JSON.stringify(require('./.claude/context/artifacts/catalogs/workflow-registry.json'), null, 2))"

# 验证协调器引用它
grep "{工作流名称}" .claude/agents/协调器/*-orchestrator.md

更新内存:

追加到 .claude/context/memory/learnings.md:

## 工作流: {工作流名称}

- **目的:** {工作流目的}
- **协调器:** {哪个协调器使用它}
- **关键模式:** {发现的关键模式}
- **集成笔记:** {任何特殊集成考虑}

为何重要: 没有工作流注册：

协调器无法发现可用工作流
工作流无法为复杂任务动态选择
系统失去对工作流网络的可见性
出现“隐形工件”模式

阶段3集成: 工作流注册是阶段3的发现机制，使协调器能查询可用工作流并为复杂多代理任务选择适当工作流。

步骤9: 集成验证（阻塞 - 勿跳过）

此步骤验证工件已正确集成到生态系统中。

在调用 TaskUpdate({ 状态: "已完成" }) 前，必须运行创建后验证工作流：

运行10项集成清单:

node .claude/tools/cli/validate-integration.cjs .claude/workflows/<类别>/<工作流名称>.md

验证退出代码为0（所有检查通过）
如果退出代码为1（一项或多项检查失败）：
- 读取错误输出以获取具体失败
- 修复每个失败：
  - 缺少CLAUDE.md条目 -> 添加到第8.6节
  - 缺少工作流注册 -> 创建注册条目（步骤8）
  - 缺少协调器引用 -> 添加到协调器定义
  - 缺少内存更新 -> 更新learnings.md
- 重新运行验证直到退出代码为0
仅当验证通过时继续

此步骤阻塞。 在验证通过前，不要标记任务完成。

为何重要: 事件模式显示，如果缺少集成步骤，完全实现的工件可能对路由器不可见。此验证确保无“隐形工件”模式。

参考: .claude/workflows/core/post-creation-validation.md

工作流创建的钢铁法则

这些规则不可违反。违反会导致无声失败。

1. 无无代理验证的工作流
   - 每个引用的代理必须存在于 .claude/agents/
   - 验证: ls .claude/agents/<类别>/<代理>.md

2. 无无技能验证的工作流
   - 每个引用的技能必须存在于 .claude/skills/
   - 验证: ls .claude/skills/<技能>/SKILL.md

3. 无无独立性的并行执行
   - 仅当工作独立时并行生成代理
   - 依赖工作必须顺序执行

4. 无无输出规格的交接
   - 每个阶段必须指定其输出位置
   - 每个阶段必须指定从先前阶段读取什么

5. 无无内存协议的工作流
   - 每个代理提示必须包括内存协议部分
   - 没有它，学习和决策会丢失

6. 无无CLAUDE.md更新的创建
   - 创建工作流后，添加到第8.6节
   - 未注册的工作流永远不会被路由器调用

7. 无无系统影响分析的创建
   - 检查是否需要新代理
   - 检查是否需要新技能
   - 使用新工作流行更新@WORKFLOW_AGENT_MAP.md（强制）
   - 更新受影响代理的相关工作流部分（强制）
   - 文档化所有系统更改

8. 无无模型验证的代理生成
   - 模型字段必须仅使用基本名称: haiku, sonnet, 或 opus
   - 不要使用带日期版本，如 claude-opus-4-5-20251101
   - 带日期版本导致验证失败

9. 无无限制MCP工具的代理生成
   - 使用标准工具: 读取, 写入, 编辑, Bash, TaskUpdate等。
   - MCP工具（mcp__*）需要明确白名单
   - 未白名单的MCP工具导致路由器强制执行失败

10. 无无模式研究的工作流
    - 创建新工作流前研究现有工作流模式
    - 至少2个WebSearch查询用于领域模式
    - 在工作流评论中记录找到的模式

工作流集成

此技能是统一工件生命周期的一部分。为了完整的多代理协调：

路由器决策: .claude/workflows/core/router-decision.md

路由器如何发现和调用此技能的工件

工件生命周期: .claude/workflows/core/skill-lifecycle.md

发现、创建、更新、弃用阶段
版本管理和注册更新
CLAUDE.md集成要求

外部集成: .claude/workflows/core/external-integration.md

外部工件的安全集成
安全评审和验证阶段

交叉参考: 创建者生态系统

此技能是创建者生态系统的一部分。创建工作流后，考虑是否需要伴侣创建者：

创建者	何时使用	调用
agent-creator	工作流需要不在`.claude/agents/`中的代理	`Skill({ 技能: 'agent-creator' })`
skill-creator	工作流需要不在`.claude/skills/`中的技能	`Skill({ 技能: 'skill-creator' })`
hook-creator	工作流需要入口/出口钩子	创建于 `.claude/hooks/`
template-creator	工作流需要代码模板	创建于 `.claude/templates/`
schema-creator	工作流需要验证模式	创建于 `.claude/schemas/`

集成工作流

创建需要附加功能的工作流后：

// 1. 工作流创建但需要新代理
Skill({ 技能: 'agent-creator' });
// 创建代理，然后更新工作流的代理数组

// 2. 工作流需要新技能
Skill({ 技能: 'skill-creator' });
// 创建技能，然后在工作流提示中引用

// 3. 工作流需要关键步骤的钩子
// 在 .claude/hooks/workflows/<工作流名称>/ 中创建钩子
// 在工作流的钩子部分引用

生态系统集成的创建后清单

工作流完全创建并验证后：

[ ] 工作流需要不存在的代理吗？ -> 使用代理创建器
[ ] 工作流需要不存在的技能吗？ -> 使用技能创建器
[ ] 工作流需要入口/出口钩子吗？ -> 创建钩子
[ ] 工作流需要输入验证吗？ -> 创建模式
[ ] 工作流应是更大协调的一部分吗？ -> 更新主协调器
[ ] 运行创建后验证 -> node .claude/tools/cli/validate-integration.cjs .claude/workflows/<类别>/<工作流名称>.yaml

示例

示例1: 创建功能开发工作流

请求: “为端到端功能开发创建工作流”

识别阶段: 发现 -> 架构 -> 实现 -> 测试 -> 部署
分配代理: 规划者 -> 架构师 + 安全架构师 -> 开发者 -> 质量保证 -> 开发运维
定义交接: 每个阶段输出到 .claude/context/plans/feature-<名称>/
参考: 见 .claude/workflows/enterprise/feature-development-workflow.md

示例2: 创建事件响应工作流

请求: “为生产事件响应创建工作流”

识别阶段: 分类 -> 调查 -> 解决 -> 事后分析
分配代理: 事件响应者 -> 开发运维故障排除者 + 开发者 -> 开发运维 -> 规划者
定义交接: 每个阶段输出到 .claude/context/incidents/
创建: .claude/workflows/operations/incident-response.md

示例3: 创建C4架构工作流

请求: “创建使用C4模型记录系统架构的工作流”

识别阶段: 代码分析 -> 组件合成 -> 容器映射 -> 上下文文档
分配代理: C4-代码 -> C4-组件 -> C4-容器 -> C4-上下文
定义交接: 自底向上，每个级别基于先前文档构建
参考: 见 .claude/workflows/enterprise/c4-architecture-workflow.md

工作流模板快速参考

使用模板 .claude/templates/workflows/workflow-template.md 以保持一致结构。

每个工作流必须有的关键部分:

YAML前置部分: 名称, 描述, 版本, 代理, 标签
概述: 目的和何时使用
配置选项: 可自定义参数
阶段: 顺序或并行执行块
任务生成: 带完整提示的实际任务()调用
错误恢复: 阶段失败时做什么
成功标准: 如何验证工作流成功完成
使用示例: 路由器应如何调用工作流

架构合规

文件放置 (ADR-076)

工作流: .claude/workflows/{类别}/ (核心, 企业, 操作, 创建者)
测试: tests/ (不在 .claude/)
相关代理: .claude/agents/{类别}/
相关技能: .claude/skills/{名称}/
相关模板: .claude/templates/

文档引用 (CLAUDE.md v2.2.1)

引用文件使用@符号: @ENTERPRISE_WORKFLOWS.md, @AGENT_ROUTING_TABLE.md
位于: .claude/docs/@*.md
见: CLAUDE.md第8.6节（企业工作流参考）

Shell安全 (ADR-077)

工作流生成模板必须包括: cd "$PROJECT_ROOT" || exit 1 用于后台任务
环境变量控制验证器（块/警告/关闭模式）
见: .claude/docs/SHELL-SECURITY-GUIDE.md
应用于: 代理生成提示、任务执行示例

文件放置和标准

输出位置规则

此技能输出到: .claude/workflows/<类别>/

类别:

核心/ - 基本工作流（路由器决策、技能生命周期）
企业/ - 复杂多代理流（功能开发）
操作/ - 操作程序（事件响应）
创建者/ - 创建者工作流YAML文件

强制引用

文件放置: 见 .claude/docs/FILE_PLACEMENT_RULES.md
开发者工作流: 见 .claude/docs/DEVELOPER_WORKFLOW.md
工件命名: 见 .claude/docs/ARTIFACT_NAMING.md

执行

文件放置由 file-placement-guard.cjs 钩子执行。在production模式下，无效放置将被阻止。

内存协议（强制）

开始前:

cat .claude/context/memory/learnings.md

检查：

先前创建的工作流
工作流模式运行良好
现有工作流的问题

完成后:

新工作流创建 -> 追加到 .claude/context/memory/learnings.md
工作流问题发现 -> 追加到 .claude/context/memory/issues.md
架构决策 -> 追加到 .claude/context/memory/decisions.md

假设中断: 你的上下文可能重置。如果不在内存中，它就没发生。

创建后集成

创建完成后，运行生态系统集成清单：

从 .claude/lib/creators/creator-commons.cjs 调用 runIntegrationChecklist(artifactType, artifactPath)
从 .claude/lib/creators/creator-commons.cjs 调用 queueCrossCreatorReview(artifactType, artifactPath)
查看影响报告 — 在标记任务完成前解决所有mustHave项
记录任何shouldHave项作为后续任务

集成验证:

[ ] 工作流已添加到@WORKFLOW_AGENT_MAP.md
[ ] 工作流在CLAUDE.md中引用（如果是企业工作流）
[ ] 工作流分配给至少一个代理
[ ] 工作流目录条目已添加（如果适用）

生态系统对齐合同（强制）

此创建者技能是协调创建者生态系统的一部分。此处创建的任何工件必须对齐并验证相关创建者：

agent-creator 用于所有权和执行路径
skill-creator 用于能力打包和分配
tool-creator 用于可执行自动化表面
hook-creator 用于强制执行和护栏
rule-creator 和 semgrep-rule-creator 用于策略和静态检查
template-creator 用于标准化脚手架
workflow-creator 用于协调和阶段门控
command-creator 用于用户/操作员命令UX

跨创建者握手（必需）

完成前，验证所有相关握手：

工件路由存在于 .claude/CLAUDE.md 和相关路由文档中。
发现/注册条目已更新（目录/索引/注册，如适用）。
伴侣工件已创建或明确放弃并说明理由。
validate-integration.cjs 为创建的工作件通过。
技能技能索引在技能元数据更改时重新生成。

研究门（Exa优先，arXiv后备）

对于新模式、模板或工作流，研究是强制性的：

首先使用Exa获取实现和生态系统模式。
如果Exa不足，使用 WebFetch 加arXiv引用。
在工件引用/文档中记录决策、约束和非目标。
保持更新最小，避免过度工程。

回归安全交付

对行为更改遵循严格的RED -> GREEN -> REFACTOR。
为更改的模块运行目标测试。
在更改的文件上运行lint/format。
按关注点限定提交范围（逻辑/文档/生成的工件）。