workflow

Files (1)

• SKILL.md

SKILL.md (first lines)

# Workflow — 统一任务入口

收到任务后，执行以下流水线。每一步必须输出结果，不得跳过。

## Step 1: Concrete Signal Gate

检查任务是否包含至少一个 concrete signal：

- 文件路径、函数名、组件名、接口名
- issue、错误日志、复现步骤、测试命令
- 验收标准、影响范围、明确的非目标

**缺信号** → 标记为"信息不足"，询问用户补全，不继续分级。

## Step 2: 治理分级

根据以下矩阵判断级别：

| 条件 | 级别 |
|------|------|
| 单 commit + 方案明确（有文件路径/函数名/错误日志）+ 不改接口/存储 + 非调试 | **Patch** |
| 1-5 文件 + 边界清晰 + 无架构变更 | **Change** |
| >5 文件 或 跨模块 或 需求模糊 或 有架构影响 | **Initiative** |

例外：
- >5 文件但单一关注面（样式替换、批量重命名）且无跨模块契约影响 → Change
- 调试类任务允许先走 /investigate 调查，初始标注"临时 Change"

输出格式：
```
治理级别: Patch / Change / Initiative
判定依据: [1-3 条理由]
```

## Step 3: Solo / Team

| 级别 | 执行形态 |
|------|---------|
| Patch | 默认 **solo**，禁止 team |
| Change | 默认 **solo**；仅当存在 2+ 独立子任务、文件所有权不重叠、契约已冻结时可用 team |
| Initiative | 必须评估 team；若不用 team 需说明原因 |

输出：
```
执行形态: solo / team
```

## Step 4: 路由

| 任务类型 | 路由到 |
|----------|--------|
| Patch 实现 | 直接实现 → 定向验证 |
| Change 实现 | OpenSpec Light（proposal + tasks）→ 实现 → QA |
| Initiative 实现 | OpenSpec Full（proposal + design + APPROVED + tasks）→ TDD |
| 架构/设计评审 | /plan-eng-review |
| 调试/排查 | /investigate |
| 安全审计 | /cso |
| 设计咨询 | /design-consultation |

## Step 5: State Gate（Change / Initiative）

Change 且预计 >10 分钟、或 Initiative：创建 `.agent/current-task.json`。

```json
{
  "governance": "Patch|Change|Initiative",
  "phase": "classified",
  "execution_shape": "solo|team",
  "next_step": "..."
}
```

## Step 6: 执行

按 Step 4 的路由启动对应流程。Initiative 必须满足门禁（design.md → /plan-eng-review → APPROVED.md → tasks.md）后才开始编码。

## 用户确认规则

以下情况必须确认：
- 需求/目标/偏好不明确
- 多个方案影响架构/成本/数据模型
- 危险操作（rm -rf、DROP、force-push）
- Initiative 的 design review / APPROVED

以下情况自动继续：
- Patch 实现（除 commit 外）
- Change 的 proposal/tasks 创建
- 验证循环（失败后修复重试）

From cxh0312/workflow-kit, MIT.

More from cxh0312/workflow-kit