workflow-creator

工作流创建工具

为需要多个 Agent 和多个阶段协同处理的复杂任务创建多 Agent 编排工作流。

需要更新路由器（重要 — 不要跳过）

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

### {Workflow Name}

**Path:** `.claude/workflows/{category}/{workflow-name}.md`

**When to use:** {Trigger conditions}

**Phases:**

1. **{Phase Name}** - {Description}
   ...

**Agents Involved:**

- `{agent-name}` - {Role in workflow}

验证：

grep "{workflow-name}" .claude/CLAUDE.md || echo "ERROR: CLAUDE.md SECTION 8.6 NOT UPDATED!"

原因：未列入 CLAUDE.md 的工作流绝不会由路由器调用。

---

触发此技能的情形

1. 用户请求复杂编排，需要多个 Agent
2. 可重复的多阶段流程需要标准化
3. 路由器发现工作流缺口，涉及常见任务模式
4. 需要增强或自定义现有工作流

快速参考

操作	方法
检查现有工作流	Glob: .claude/workflows/**/*.md
查看工作流模板	Read .claude/templates/workflows/workflow-template.md
查找相关 Agent	Glob: .claude/agents/**/*.md
查找相关技能	Glob: .claude/skills/*/SKILL.md
创建工作流	写入 .claude/workflows/<category>/<name>.md

工作流类型

类型	位置	用途	示例
企业级	.claude/workflows/enterprise/	复杂的多阶段开发	feature-development、c4-architecture
运维	.claude/workflows/operations/	运行时流程、事件响应	incident-response、deployment
快速	.claude/workflows/rapid/	快速、专注的任务自动化	fix、refactor、review
自定义	.claude/workflows/	项目专属模式	conductor-setup

工作流—Agent 类型参考

创建工作流时，确定哪些 Agent 类型会使用该工作流。请参阅 .claude/docs/@WORKFLOW_AGENT_MAP.md，了解：

• 第 1 节：完整的工作流—Agent 矩阵
• 第 2 节：类型工作流集（路由器/编排器、实现者、审查者、文档编写者、研究者、领域专家）

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

工作流创建流程

步骤 0：存在性检查与更新器委派（强制 — 第一步）

创建任何工作流文件之前，先检查该文件是否已存在：

1. 检查工作流是否已存在：

   test -f .claude/workflows/<category>/<workflow-name>.md && echo "EXISTS" || echo "NEW"
   

2. 如果工作流已存在：

   • 不要继续创建

   • 改为调用 artifact-updater 工作流：

     Skill({
       skill: 'artifact-updater',
       args: {
         name: '<workflow-name>',
         changes: '<description of requested changes>',
         justification: 'Update requested via workflow-creator',
       },
     });
     

   • 返回更新结果并停止

3. 如果工作流是新的：

   • 继续执行下方的步骤 0.5

---

步骤 0.1：智能重复项检测（强制）

继续创建之前，运行三层重复项检查：

const { checkDuplicate } = require('.claude/lib/creation/duplicate-detector.cjs');
const result = checkDuplicate({
  artifactType: 'workflow',
  name: proposedName,
  description: proposedDescription,
  keywords: proposedKeywords || [],
});

处理结果：

• EXACT_MATCH：停止创建。改为调用 workflow-updater 技能：Skill({ skill: 'workflow-updater' })
• REGISTRY_MATCH：警告用户 — 该产物已登记，但文件可能缺失。创建之前先调查，并询问用户确认。
• SIMILAR_FOUND：显示候选项及其分数。询问用户：“存在相似产物。要继续创建新的，还是更新现有产物？”
• NO_MATCH：继续执行步骤 0.5（配套项检查）。

覆盖规则：如果用户明确传入 --force，则完全跳过此项检查。

步骤 0.5：检查配套内容

开始创建前，先运行生态系统配套内容检查：

1. 使用 .claude/lib/creators/companion-check.cjs 中的 companion-check.cjs
2. 调用 checkCompanions("workflow", "{workflow-name}")，识别配套产物
3. 查看配套清单，记下缺少的必需或推荐配套内容
4. 规划在此产物完成后创建或验证缺少的配套内容
5. 在创建后的集成说明中纳入配套检查结果

此步骤仅供参考（不会阻止创建），但可确保考虑到完整的产物生态系统。

---

步骤 1：确认没有现有工作流

# Search for relevant workflows
Glob: .claude/workflows/**/*.md
Grep: "<topic>" in .claude/workflows/

如果已有合适的工作流，请考虑对其进行增强，而不是重复创建。

步骤 2.5：研究工作流模式（必须）

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

1. 检查现有工作流：

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

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

WebSearch({ query: 'best <domain/topic name> agent workflow process 2026' });
WebSearch({ query: 'industry standard <workflow-type> orchestration phases 2026' });

3. 在工作流注释中记录发现的模式

阻止条件：未完成模式研究，不得继续创建工作流。这样可确保工作流遵循既有模式，而不是重新发明解决方案。

步骤 2：确定阶段和 Agent

分析流程并拆分为各个阶段：

问题	决定事项
有哪些不同的阶段？	阶段边界
每个阶段由哪个 Agent 负责？	Agent 分配
哪些阶段可以并行运行？	并行执行机会
哪些输出会传递到下一阶段？	数据流和交接
每个阶段可能出现什么问题？	错误恢复流程

常见阶段模式：

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

步骤 3：定义 Agent 交接

针对每次阶段转换，指定：

### Phase 1 -> Phase 2 Handoff

**Output from Phase 1**: .claude/context/plans/phase1-output.md
**Input to Phase 2**: Read output from Phase 1
**Handoff validation**: [Check output exists and is valid]

步骤 4：生成工作流定义

写入 .claude/workflows/<category>/<workflow-name>.md：

---
name: { workflow-name }
description: { Brief description of workflow purpose }
version: 1.0.0
agents:
  - { agent-1 }
  - { agent-2 }
tags: [{ tag1 }, { tag2 }, workflow]
---

# {Workflow Title}

{Brief description of workflow purpose and when to use it.}

**Extended Thinking**: {Detailed explanation of workflow rationale, approach, and design decisions.}

## Overview

{Detailed description of what this workflow accomplishes.}

## Configuration Options

### {Option Category 1}

- **{value_1}**: {Description}
- **{value_2}**: {Description}

## Phase 1: {Phase Name}

### Step 1: {Step Name}

**Agent**: {agent-name}

**Task Spawn**:

```javascript
Task({
  task_id: 'task-1',
  subagent_type: 'general-purpose',
  description: '{Task description}',
  prompt: `You are the {AGENT_NAME} agent.

## Task
{Task description}

## Instructions
1. Read your agent definition: .claude/agents/{category}/{agent}.md
2. **Invoke skills**: Skill({ skill: "{skill-name}" })
3. {Additional instructions}
4. Save output to: .claude/context/{output-path}

## Context
- {Context item 1}
- {Context item 2}

## Memory Protocol
1. Read .claude/context/memory/learnings.md first
2. Record decisions to .claude/context/memory/decisions.md
`,
});
```

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

阶段 2：{阶段名称}

步骤 2：{步骤名称}（并行）

Agent：{agent-a} + {agent-b}（并行启动）

任务启动：

// Spawn both agents in parallel for efficiency
Task({
  task_id: 'task-2',
  subagent_type: 'general-purpose',
  description: '{Agent A task}',
  prompt: `You are {AGENT_A}...`,
});

Task({
  task_id: 'task-3',
  subagent_type: 'general-purpose',
  description: '{Agent B task}',
  prompt: `You are {AGENT_B}...`,
});

预期输出：{描述}

错误恢复

如果阶段 1 失败

1. {恢复步骤}
2. 重新启动阶段 1

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

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

成功标准

• {标准 1}
• {标准 2}
• 所有 Agent 均已完成各自阶段
• 记忆文件已更新

使用示例

// Router spawning workflow orchestrator
Task({
  task_id: 'task-4',
  subagent_type: 'general-purpose',
  description: 'Orchestrating {workflow-name} workflow',
  prompt: `Execute {workflow-name} workflow.

## Parameters
- {Parameter 1}
- {Parameter 2}

## Instructions
Follow the phased workflow in: .claude/workflows/{category}/{workflow-name}.md
`,
});

### Step 5: Validate Workflow References (BLOCKING)

**Before writing workflow file, verify ALL references are valid:**

| Reference | Validation |
|-----------|-----------|
| Agent files | All agents in `agents:` array exist in `.claude/agents/` |
| Skills | All skills referenced in prompts exist in `.claude/skills/` |
| Output paths | All output directories exist or will be created |
| Context files | All context files referenced are accessible |

**Validation checklist before writing:**

[ ] 所有引用的 Agent 均存在 [ ] 所有引用的技能均存在 [ ] 输出路径有效 [ ] 错误恢复流程完整 [ ] 成功标准可衡量

**BLOCKING**: Do not write workflow file if any reference is invalid.

### Step 5.5: Model and Tool Validation (CRITICAL)

**Model Validation for Agent Spawns (CRITICAL):**

When workflow templates spawn agents via Task tool:
- model field MUST be base name only: `haiku`, `sonnet`, or `opus`
- DO NOT use dated versions like `claude-opus-4-5-20251101`
- Choose model based on task complexity:
  - `haiku`: Quick validation, simple tasks
  - `sonnet`: Standard work (default)
  - `opus`: Complex reasoning, architecture

**Example:**
```javascript
// CORRECT
Task({
  task_id: 'task-5',
  model: 'sonnet',
  // ...
});

// WRONG - causes validation failures
Task({
  task_id: 'task-6',
  model: 'claude-sonnet-4-20250514',
  // ...
});

工具数组验证：

为启动的 Agent 指定 allowed_tools 时：

• 使用标准工具：Read、Write、Edit、Bash、TaskUpdate、TaskList 等
• 除非已在 routing-table.cjs 中列入白名单，否则不要包含 MCP 工具（mcp__*）
• MCP 工具会导致路由器强制执行失败

允许的工具（标准）：

allowed_tools: [
  'Read',
  'Write',
  'Edit',
  'Bash',
  'TaskUpdate',
  'TaskList',
  'TaskCreate',
  'TaskGet',
  'Skill',
];

受限工具（需要明确列入白名单）：

• mcp__Exa__* - 仅限 evolution-orchestrator 使用
• mcp__github__* - 仅限特定 GitHub 操作
• 其他 MCP 工具 - 必须列入 routing-table.cjs 白名单

Agent 启动验证清单：

[ ] Model field uses base name (haiku/sonnet/opus)
[ ] allowed_tools contains only standard tools OR explicitly whitelisted MCP tools
[ ] No dated model versions (e.g., claude-opus-4-5-20251101)

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

此步骤为自动执行且具有阻塞性。切勿跳过。

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

1. 查找第 8.6 节（“企业工作流”）
2. 按以下格式生成工作流条目：

### {Workflow Name}

**Path:** `.claude/workflows/{category}/{workflow-name}.md`

**When to use:** {Trigger conditions - be specific}

**Phases:**

1. **{Phase 1 Name}** - {Brief description}
2. **{Phase 2 Name}** - {Brief description}
   ...

**Configuration Options:**

- {Option category}: `{values}`

**Agents Involved:**

- `{agent-name}` - {Role description}

1. 在适当位置插入（按字母顺序排列，或放在该节末尾）
2. 使用以下内容验证：

grep "{workflow-name}" .claude/CLAUDE.md || echo "ERROR: CLAUDE.md NOT UPDATED - BLOCKING!"

阻塞：如果 CLAUDE.md 更新失败，则工作流创建未完成。请勿继续。

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

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

[WORKFLOW-CREATOR] System Impact Analysis for: <workflow-name>

1. CLAUDE.md UPDATE (MANDATORY)
   - Add entry to Section 8.6 (Enterprise Workflows)
   - Add to Section 3 (Multi-Agent Workflows) if referenced by Router
   - Verify with grep

2. AGENT COORDINATION CHECK
   - Do all agents referenced exist?
   - Do agents need new skills for this workflow?
   - Should any agent's definition reference this workflow?

3. SKILL AVAILABILITY CHECK
   - Are all skills referenced available?
   - Does this workflow need new skills? -> Invoke skill-creator
   - Should existing skills be enhanced?

4. MEMORY INTEGRATION CHECK
   - Does workflow use Memory Protocol?
   - Are output paths writable?
   - Will artifacts be properly persisted?

5. RELATED WORKFLOW CHECK
   - Does this duplicate existing workflow functionality?
   - Should existing workflows reference this one?
   - Are there workflow dependencies to document?

6. WORKFLOW-AGENT MAP UPDATED (MANDATORY)
   - Added new workflow to @WORKFLOW_AGENT_MAP.md Section 1 matrix
   - Determined which agent archetypes use this workflow
   - Updated affected agents' `## Related Workflows` sections
   - Verified: `grep "<workflow-name>" .claude/docs/@WORKFLOW_AGENT_MAP.md || echo "ERROR: Workflow not in agent map!"`

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

# Validate workflow file exists
ls .claude/workflows/<category>/<workflow-name>.md

# Verify all referenced agents exist
for agent in $(grep -oE '\\.claude/agents/[^"]+\\.md' .claude/workflows/<category>/<workflow>.md); do
  [ -f "$agent" ] || echo "BROKEN: $agent"
done

# Verify all referenced skills exist
for skill in $(grep -oE 'skill: "[^"]+"' .claude/workflows/<category>/<workflow>.md | cut -d'"' -f2); do
  [ -f ".claude/skills/$skill/SKILL.md" ] || echo "BROKEN: $skill"
done

# Check CLAUDE.md has workflow entry - MANDATORY
grep "<workflow-name>" .claude/CLAUDE.md || echo "ERROR: Not in CLAUDE.md - WORKFLOW CREATION INCOMPLETE"

完成清单（必须全部勾选）：

[ ] Workflow pattern research completed (Step 2.5)
[ ] Workflow file created at .claude/workflows/<category>/<name>.md
[ ] All referenced agents exist in .claude/agents/
[ ] All referenced skills exist in .claude/skills/
[ ] Model fields use base names only (haiku/sonnet/opus)
[ ] allowed_tools arrays contain only standard or whitelisted tools
[ ] CLAUDE.md Section 8.6 updated
[ ] Workflow entry verified with grep
[ ] Memory Protocol included in all agent prompts

阻塞：如果任何一项未通过，则工作流创建未完成。请先修复所有问题，再继续。

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

此步骤至关重要。 创建工作流产物后，必须在工作流发现系统中注册。

第 3 阶段背景： 第 1 阶段创建工具清单（工具），第 2 阶段创建技能索引（技能），第 3 阶段创建工作流注册表，以便编排器发现并调用工作流。

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

1. 在适当位置创建/更新工作流注册表条目：

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

   {
     "workflows": [
       {
         "name": "{workflow-name}",
         "id": "{workflow-name}",
         "description": "{Brief description from workflow}",
         "category": "{enterprise|core|operations}",
         "version": "1.0.0",
         "triggerConditions": ["{Condition 1}", "{Condition 2}"],
         "participatingAgents": ["{agent-1}", "{agent-2}"],
         "phases": [
           { "name": "{Phase 1 Name}", "description": "{Brief description}" },
           { "name": "{Phase 2 Name}", "description": "{Brief description}" }
         ],
         "filePath": ".claude/workflows/{category}/{workflow-name}.md",
         "orchestratorReferences": []
       }
     ]
   }
   

2. 向相应的编排器注册：

   更新应使用此工作流的编排器：

   • master-orchestrator.md：协调其他工作流的元工作流
   • evolution-orchestrator.md：EVOLVE 阶段工作流（研究、创建、验证）
   • party-orchestrator.md：共识/投票工作流
   • swarm-coordinator.md：协调工作流

   将其添加到编排器的工作流引用中：

   ## Available Workflows
   
   - `{workflow-name}` (.claude/workflows/{category}/{workflow-name}.md)
   

3. 在 .claude/docs/WORKFLOW_CATALOG.md 中记录：

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

   ### {Workflow Title}
   
   **Path:** `.claude/workflows/{category}/{workflow-name}.md`
   
   **When to use:** {Trigger conditions - specific scenarios}
   
   **Participating Agents:**
   
   - {agent-1}: {role in workflow}
   - {agent-2}: {role in workflow}
   
   **Phases:**
   
   1. **{Phase 1 Name}** - {Description}
   2. **{Phase 2 Name}** - {Description}
   
   **Orchestrator Integration:**
   
   - Invoked by: {orchestrator-name}
   - Trigger: {How orchestrator discovers/triggers this}
   

4. 验证工作流的可发现性：

   测试是否能够发现此工作流：

   # Check workflow registry exists and is valid JSON
   node -e "console.log(JSON.stringify(require('./.claude/context/artifacts/catalogs/workflow-registry.json'), null, 2))"
   
   # Verify orchestrator references it
   grep "{workflow-name}" .claude/agents/orchestrators/*-orchestrator.md
   

5. 更新记忆：

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

   ## Workflow: {workflow-name}
   
   - **Purpose:** {Workflow purpose}
   - **Orchestrator:** {Which orchestrator uses it}
   - **Key Pattern:** {Key pattern discovered}
   - **Integration Notes:** {Any special integration considerations}
   

重要原因： 未注册工作流会导致：

• 编排器无法发现可用工作流
• 无法为复杂任务动态选择工作流
• 系统无法掌握工作流网络的全貌
• 出现“不可见产物”模式

第 3 阶段集成： 工作流注册表是第 3 阶段的发现机制，可让编排器查询可用工作流，并为复杂的多 Agent 任务选择合适的工作流。

步骤 9：集成验证（阻塞——切勿跳过）

此步骤用于验证产物是否已正确集成到生态系统中。

在调用 TaskUpdate({ status: "completed" }) 之前，必须运行创建后验证工作流：

1. 运行 10 项集成清单：

   node .claude/tools/cli/validate-integration.cjs .claude/workflows/<category>/<workflow-name>.md
   

2. 确认退出代码为 0（所有检查均已通过）

3. 如果退出代码为 1（一项或多项检查未通过）：

   • 查看错误输出，找出具体失败项
   • 修复每一项失败：
     • 缺少 CLAUDE.md 条目 -> 添加到第 8.6 节
     • 缺少工作流注册表 -> 创建注册表条目（步骤 8）
     • 缺少编排器引用 -> 添加到编排器定义中
     • 缺少记忆更新 -> 更新 learnings.md
   • 重新运行验证，直到退出代码为 0

4. 仅在验证通过后继续

此步骤具有阻塞性。 验证通过前，请勿将任务标记为完成。

重要原因： Party Mode 事件表明，如果遗漏集成步骤，路由器可能无法发现已完整实现的产物。此验证可确保不会出现“不可见产物”模式。

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

---

工作流创建铁律

这些规则不可违背。违反会导致静默失败。

1. NO WORKFLOW WITHOUT AGENT VALIDATION
   - Every agent referenced must exist in .claude/agents/
   - Verify with: ls .claude/agents/<category>/<agent>.md

2. NO WORKFLOW WITHOUT SKILL VALIDATION
   - Every skill referenced must exist in .claude/skills/
   - Verify with: ls .claude/skills/<skill>/SKILL.md

3. NO PARALLEL EXECUTION WITHOUT INDEPENDENCE
   - Only spawn agents in parallel if their work is independent
   - Dependent work must be sequential

4. NO HANDOFF WITHOUT OUTPUT SPECIFICATION
   - Every phase must specify its output location
   - Every phase must specify what it reads from previous phases

5. NO WORKFLOW WITHOUT MEMORY PROTOCOL
   - Every agent prompt must include Memory Protocol section
   - Without it, learnings and decisions are lost

6. NO CREATION WITHOUT CLAUDE.MD UPDATE
   - After creating workflow, add to Section 8.6
   - Unregistered workflows are never invoked by Router

7. NO CREATION WITHOUT SYSTEM IMPACT ANALYSIS
   - Check if new agents are needed
   - Check if new skills are needed
   - Update @WORKFLOW_AGENT_MAP.md with new workflow row (MANDATORY)
   - Update affected agents' Related Workflows sections (MANDATORY)
   - Document all system changes made

8. NO AGENT SPAWN WITHOUT MODEL VALIDATION
   - model field MUST be base name only: haiku, sonnet, or opus
   - DO NOT use dated versions like claude-opus-4-5-20251101
   - Dated versions cause validation failures

9. NO AGENT SPAWN WITH UNRESTRICTED MCP TOOLS
   - Use standard tools: Read, Write, Edit, Bash, TaskUpdate, etc.
   - MCP tools (mcp__*) require explicit whitelisting
   - Unwhitelisted MCP tools cause router enforcement failures

10. NO WORKFLOW WITHOUT PATTERN RESEARCH
    - Research existing workflow patterns before creating new ones
    - Minimum 2 WebSearch queries for domain patterns
    - Document patterns found in workflow comments

---

工作流集成

此技能属于统一的工件生命周期。要了解完整的多 Agent 编排：

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

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

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

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

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

• 安全集成外部工件
• 安全审查和验证阶段

---

交叉引用：创建者生态系统

此技能属于创建者生态系统。创建工作流后，请考虑是否需要配套的创建者：

发现的缺口	所需工件	要调用的创建者	时机
领域知识需要转化为可复用技能	skill	Skill({ skill: 'skill-creator' })	缺口涵盖完整的技能领域
现有技能的覆盖范围不完整	skill update	Skill({ skill: 'skill-updater' })	有相近技能，但覆盖不完整
某项能力需要专用 Agent	agent	Skill({ skill: 'agent-creator' })	需要 Agent 负责该能力
现有 Agent 需要更新能力	agent update	Skill({ skill: 'agent-updater' })	有相近的 Agent，但覆盖不完整
领域需要代码／项目脚手架	template	Skill({ skill: 'template-creator' })	需要可复用的代码模式
行为需要执行前／后的防护机制	hook	Skill({ skill: 'hook-creator' })	需要强制执行行为
流程需要多阶段编排	workflow	Skill({ skill: 'workflow-creator' })	需要多步骤协调
工件需要结构化 I/O 验证	schema	Skill({ skill: 'schema-creator' })	需要用于工件 I/O 的 JSON schema
用户交互需要斜杠命令	command	Skill({ skill: 'command-creator' })	需要面向用户的快捷方式
重复逻辑需要可复用的 CLI 工具	tool	Skill({ skill: 'tool-creator' })	需要 CLI 实用工具
仅限狭窄／单一工件的能力	inline	仅在此工件中记录	过于具体，无法泛化

集成工作流

创建需要额外能力的工作流后：

// 1. Workflow created but needs new agent
Skill({ skill: 'agent-creator' });
// Create the agent, then update workflow's agents: array

// 2. Workflow needs new skill
Skill({ skill: 'skill-creator' });
// Create the skill, then reference in workflow prompts

// 3. Workflow needs hooks for critical steps
// Create hooks in .claude/hooks/workflows/<workflow-name>/
// Reference in workflow's hooks: section

生态系统集成创建后检查清单

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

[ ] Does workflow need agents that don't exist? -> Use agent-creator
[ ] Does workflow need skills that don't exist? -> Use skill-creator
[ ] Does workflow need entry/exit hooks? -> Create hooks
[ ] Does workflow need input validation? -> Create schemas
[ ] Should workflow be part of larger orchestration? -> Update master-orchestrator
[ ] Run post-creation validation -> node .claude/tools/cli/validate-integration.cjs .claude/workflows/<category>/<workflow-name>.yaml

---

示例

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

请求：“创建一个端到端的功能开发工作流”

1. 确定阶段：发现 -> 架构设计 -> 实现 -> 测试 -> 部署
2. 分配 Agent：planner -> architect + security-architect -> developer -> qa -> devops
3. 定义交接：每个阶段的输出都写入 .claude/context/plans/feature-<name>/
4. 参考：参见 .claude/workflows/enterprise/feature-development-workflow.md

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

请求：“创建一个用于生产环境事件响应的工作流”

1. 确定阶段：分诊 -> 调查 -> 解决 -> 事后复盘
2. 分配 Agent：incident-responder -> devops-troubleshooter + developer -> devops -> planner
3. 定义交接：每个阶段的输出都写入 .claude/context/incidents/
4. 创建：.claude/workflows/operations/incident-response.md

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

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

1. 确定阶段：代码分析 -> 组件综合 -> 容器映射 -> 上下文文档编写
2. 分配 Agent：c4-code -> c4-component -> c4-container -> c4-context
3. 定义交接：自底向上，每个层级都基于前一层级的文档
4. 参考：参见 .claude/workflows/enterprise/c4-architecture-workflow.md

---

工作流模板快速参考

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

每个工作流都必须包含以下关键部分：

1. YAML Frontmatter：名称、描述、版本、Agent、标签
2. 概述：用途及使用时机
3. 配置选项：可自定义的参数
4. 阶段：顺序或并行执行的区块
5. 任务生成：包含完整提示词的实际 Task() 调用
6. 错误恢复：阶段失败时的处理方式
7. 成功标准：验证工作流是否成功完成的方法
8. 使用示例：Router 应如何调用工作流

---

架构合规性

文件放置位置（ADR-076）

• 工作流：.claude/workflows/{category}/（core、enterprise、operations、creators）
• 测试：tests/（不要放在 .claude/ 中）
• 相关 Agent：.claude/agents/{category}/
• 相关技能：.claude/skills/{name}/
• 相关模板：.claude/templates/

文档引用（CLAUDE.md v3.1.0）

• 引用文件使用 @ 符号格式：@ENTERPRISE_WORKFLOWS.md、@AGENT_ROUTING_TABLE.md
• 位置：.claude/docs/@*.md
• 参见：CLAUDE.md 第 8.6 节（ENTERPRISE WORKFLOWS 引用）

Shell 安全（ADR-077）

• 工作流生成模板必须为后台任务包含：cd "$PROJECT_ROOT" || exit 1
• 环境变量用于控制校验器（block/warn/off 模式）
• 参见：.claude/docs/SHELL-SECURITY-GUIDE.md
• 适用于：Agent 生成提示词、任务执行示例

近期 ADR

• ADR-075：Router 感知配置的模型选择
• ADR-076：文件放置架构重新设计
• ADR-077：Shell 命令安全架构

---

文件放置与标准

输出位置规则

此技能的输出位置为：.claude/workflows/<category>/

类别：

• core/ - 核心工作流（router-decision、skill-lifecycle）
• enterprise/ - 复杂的多 Agent 流程（feature-development）
• operations/ - 运维流程（incident-response）
• creators/ - 创建者工作流 YAML 文件

必须遵循的引用

• 文件放置位置：参见 .claude/docs/FILE_PLACEMENT_RULES.md
• 开发者工作流：参见 .claude/docs/DEVELOPER_WORKFLOW.md
• 产物命名：参见 .claude/docs/ARTIFACT_NAMING.md

强制执行

文件放置规则由 file-placement-guard.cjs hook 强制执行。 在生产模式下，无效的放置位置会被拦截。

---

记忆协议（强制）

开始前：

cat .claude/context/memory/learnings.md

检查以下内容：

• 之前创建的工作流
• 效果良好的工作流模式
• 现有工作流的问题

完成后：

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

假设工作会中断：你的上下文可能会重置。如果没有记录在记忆中，就等于没有发生。

---

创建后的集成

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

1. 调用 .claude/lib/creators/creator-commons.cjs 中的 runIntegrationChecklist(artifactType, artifactPath)
2. 调用 .claude/lib/creators/creator-commons.cjs 中的 queueCrossCreatorReview(artifactType, artifactPath)
3. 查看影响报告——标记任务完成前，处理所有 mustHave 项
4. 将任何 shouldHave 项记录为后续任务

集成验证：

• 将工作流添加到 @WORKFLOW_AGENT_MAP.md
• 在 CLAUDE.md 中引用工作流（如果是企业工作流）
• 至少为一个 Agent 分配工作流
• 添加工作流目录条目（如适用）

生态系统协同契约（强制）

此创建者技能属于协同运作的创建者生态系统。在此创建的任何产物都必须与相关创建者保持一致，并通过其验证：

• agent-creator：负责归属和执行路径
• skill-creator：负责能力封装和分配
• tool-creator：负责可执行自动化接口
• hook-creator：负责强制执行和防护措施
• rule-creator 和 semgrep-rule-creator：负责策略和静态检查
• template-creator：负责标准化脚手架
• workflow-creator：负责编排和阶段门控
• command-creator：负责用户／操作员命令体验

跨创建者交接（必需）

完成前，验证所有相关交接：

1. 产物路由已添加到 .claude/CLAUDE.md 和相关路由文档中。
2. 已更新发现／注册表条目（目录／索引／注册表，视情况而定）。
3. 已创建配套产物，或明确说明豁免原因。
4. validate-integration.cjs 已通过对所创建产物的验证。
5. 技能元数据更改时，重新生成技能索引。

研究门槛（Exa + arXiv——两者均为强制要求）

对于新的模式、模板或工作流，必须进行研究：

1. 使用 Exa 研究实现方式和生态系统模式：
   • mcp__Exa__web_search_exa({ query: '<topic> 2025 best practices' })
   • mcp__Exa__get_code_context_exa({ query: '<topic> implementation examples' })
2. 搜索 arXiv 上的学术研究（AI／ML、Agent、评估、编排、记忆／RAG、安全相关主题均为强制要求）：
   • 通过 Exa：mcp__Exa__web_search_exa({ query: 'site:arxiv.org <topic> 2024 2025' })
   • 直接调用 API：WebFetch({ url: 'https://arxiv.org/search/?query=<topic>&searchtype=all&start=0' })
3. 在产物引用／文档中记录决策、约束和非目标。
4. 保持更新精简，避免过度设计。

当主题涉及以下内容时，必须搜索 arXiv（不可作为备用选项）： AI Agent、大模型评估、编排、记忆／RAG、安全、静态分析或任何新兴方法论。

安全回归交付

• 对行为更改严格遵循 RED -> GREEN -> REFACTOR。
• 对更改的模块运行针对性测试。
• 对更改的文件运行 lint／format。
• 按关注点划分提交（逻辑／文档／生成的产物）。

可选：评估质量门槛

运行共享评估框架，验证工作流质量：

node .claude/skills/skill-creator/scripts/eval-runner.cjs --skill workflow-creator

工作流产物的评估器断言：

• 阶段覆盖：所有必需阶段（Triage → Design → Implement → Review → Deploy → Document → Reflect）均已包含，或明确跳过并说明理由
• Agent 协调交接：每个阶段均定义 agents、inputs、outputs 和 gates；明确说明阶段间的交接约定
• 可衡量的质量门槛标准：每个门槛都指定通过／失败条件（而非模糊描述）；标明阻塞与非阻塞门槛
• 工作流类型分类：将工作流归入正确的类别（core/、enterprise/、creation/、security/、operations/）
• 注册表条目齐全：将工作流添加到 @ENTERPRISE_WORKFLOWS.md 和 @WORKFLOW_AGENT_MAP.md

完整评估流程以及评估器／分析器 Agent 的用法，请参见 .claude/skills/skill-creator/EVAL_WORKFLOW.md。