workflow-monitor

不适用场景

• 值得直接调试的一次性故障（使用 superpowers:systematic-debugging）
• 重写工作流的资源（使用 sanctum:workflow-improvement）

工作流监控器

监控工作流执行中的错误和低效之处，并自动在检测到的 Git 平台（GitHub/GitLab）上创建改进问题。检查会话上下文中的 git_platform:，并使用 Skill(leyline:git-platform) 映射 CLI 命令。

理念

工作流应随时间不断改进。系统地记录执行问题，有助于持续改进。此技能会挂接到工作流执行中，以检测问题并提出修复建议。

快速入门

手动调用

# After a failed workflow
/workflow-monitor --analyze-last

# Monitor a specific workflow execution
/workflow-monitor --session <session-id>

# Analyze efficiency of recent workflows
/workflow-monitor --efficiency-report

自动监控（通过钩子）

启用后，workflow-monitor 会观察执行情况并标记：

• 命令失败（退出代码 > 0）
• 超时事件
• 重复重试模式
• 上下文耗尽
• 工具使用低效

检测模式

错误检测

模式	信号	严重性
命令失败	退出代码 > 0	高
超时	超出超时限制	高
重试循环	同一命令 >3 次	中
上下文耗尽	已使用 >90% 的上下文	中
工具误用	任务使用了错误的工具	低

效率检测

模式	信号	阈值
输出冗长	命令输出 >1000 行	建议 500 行
重复读取	同一文件读取 >2 次	最多读取 2 次
串行与并行	独立任务按顺序运行	应并行处理
过度获取	需要片段时却读取整个文件	使用 offset/limit

工作流

阶段 1：捕获（workflow-monitor:capture-complete）

1. 记录执行事件 - 命令、输出、耗时
2. 标记异常 - 失败、超时、低效之处
3. 存储证据 - 以便复现

阶段 2：分析（workflow-monitor:analysis-complete）

1. 对问题分类 - 错误类型、严重性、范围
2. 确定根本原因 - 问题的触发因素
3. 提出修复建议 - 如何防止问题再次发生

阶段 3：报告（workflow-monitor:report-generated）

1. 生成问题正文 - 结构化格式
2. 分配标签 - workflow、bug、enhancement
3. 关联证据 - 命令输出、会话信息

阶段 4：创建问题（workflow-monitor:issue-created）

1. 检查重复项 - 搜索现有问题
2. 如果是唯一问题则创建 - 通过 gh CLI
3. 关联会话 - 以便追溯

问题模板

## Background

Detected during workflow execution on [DATE].

**Source:** [workflow name] session [session-id]

## Problem

[Description of the error or inefficiency]

**Evidence:**

[失败或效率低下的命令] [输出摘录]

## Suggested Fix

[What should change to prevent this]

## Acceptance Criteria

- [ ] [Specific fix criterion]
- [ ] Tests added for new behavior
- [ ] Documentation updated

---
*Created automatically by workflow-monitor*

配置

# .workflow-monitor.yaml
enabled: true
auto_create_issues: false  # Require approval before creating
severity_threshold: "medium"  # Only report medium+ severity
efficiency_threshold: 0.7  # Flag workflows below 70% efficiency

detection:
  command_failures: true
  timeouts: true
  retry_loops: true
  context_exhaustion: true
  tool_misuse: true

efficiency:
  verbose_output_limit: 500
  max_file_reads: 2
  parallel_detection: true

防护措施

1. 不得创建重复问题 - 创建前检查现有问题
2. 需要批准 - 除非设置了 auto_create_issues: true
3. 需要证据 - 每个问题都必须提供可复现的证据
4. 速率限制 - 每个会话最多创建 5 个问题

必需的 TodoWrite 项

1. workflow-monitor:capture-complete
2. workflow-monitor:analysis-complete
3. workflow-monitor:report-generated
4. workflow-monitor:issue-created（如果创建了问题）

集成点

• imbue:proof-of-work：捕获执行证据
• sanctum:fix-workflow：实施建议的修复
• 钩子：可由会话钩子触发，实现自动监控

输出格式

效率报告

## Workflow Efficiency Report

**Session:** [session-id]
**Duration:** 12m 34s
**Efficiency Score:** 0.72 (72%)

### Issues Detected

| Type | Count | Impact |
|------|-------|--------|
| Verbose output | 3 | Medium |
| Redundant reads | 2 | Low |
| Sequential tasks | 1 | Medium |

### Recommendations

1. Use `--quiet` flags for npm/pip commands
2. Cache file contents instead of re-reading
3. Parallelize independent file operations

### Create Issues?

- [ ] Issue 1: Verbose output from npm install
- [ ] Issue 2: Redundant file reads in validation

相关技能

• imbue:proof-of-work：证据捕获方法
• sanctum:fix-workflow：工作流改进命令

---

状态： 骨架实现。需要：

• 集成钩子以实现自动监控
• 效率评分算法
• 重复项检测逻辑

退出标准

• 所有 4 个 TodoWrite 阶段均已完成：capture-complete、 analysis-complete、report-generated，以及（如果创建了问题） issue-created
• 提交的每个问题都包含可复现的证据：失败或效率低下的确切 命令，以及一段输出摘录
• 创建任何问题前，均通过 gh issue list --search 运行重复项检查； 若存在重复项，则不再提交，并改为报告已有问题的 URL
• 无论检测到多少异常，每个会话创建的问题不得超过 5 个；须强制执行速率限制