# Workflow Retrospective

> 从当前会话、用户纠正、已查看产物和可定位的项目证据中复盘未遵循工作流的问题，分析最早失效环节，并在当前工作目录生成或更新 `workflow.txt` 交接报告。用于用户要求总结本次工作发现的规范缺口、解释为什么没有遵循、把问题带回 EpiAgentKit 后续改进时；也用于在生成报告前整理多个零散纠正。只记录有来源和置信度的事实、推断及候选调整，不替代当前任务的内容 skill，不直接修改 EpiAgentKit 或正式研究产物；在 EpiAgentKit 中依据报告改规则时改用 `epiagentkit-maintenance`，并以完整仓库核验为准。

- Skill: `kangwang42/workflow-retrospective` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kangwang42/workflow-retrospective`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kangwang42/workflow-retrospective/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: kangwang42 (https://skillmd.com/u/kangwang42)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kangwang42/workflow-retrospective

---


# 工作流问题复盘

把本次工作中已经发生的问题整理成可核验、可交接的原因报告。报告不是道歉、重新承诺、一般任务总结，也不是 EpiAgentKit 完整规范的替代版本。

## 1. 限定本轮工作

- 本项是一个局部产物，只创建或更新用户指定位置的 `workflow.txt`；未指定时使用当前工作目录。
- 不为复盘重跑整个项目，不修改正式数据、代码、结果、论文、表图或项目状态文件。用户同时要求修复产物时，把修复与复盘列为两个工作项，分别使用适用的内容 skill。
- 不把 `workflow.txt` 写入 `BACKLOG.md`、`DECISIONS.md` 或结果唯一来源。它只负责把现场证据交给后续维护会话。
- 若已有 `workflow.txt`，先完整读取。保留旧报告，在末尾新增本次会话的独立部分；只有用户明确要求替换时才覆盖。

## 2. 建立可见证据

只使用当前会话中可见或能够定位的材料：

1. 逐项记录用户指出的问题、用户确认的正确结果和必须保留的行为。
2. 定位实际输出、文件、行号、图片、工具结果或完成说明；没有可定位产物时引用简短的会话事实，不大段复制对话。
3. 核对当时明确加载或可见的规则、skill、reference、执行步骤和验收结果。不能确认当时使用了什么时写“待核验”，不得根据现在安装的 skill 反推当时一定已经加载。
4. 把每项材料标为“用户确认”“直接观察”“可复核推断”或“待核验”。会话经过压缩、原文件不可访问或规则版本不明时，在证据边界中明确说明。
5. 不记录凭证、环境变量、隐私数据、未公开研究结果或与问题无关的完整文件内容；优先使用相对路径和最短必要摘录。

不得声称知道模型未公开的思维过程，也不得用“忘了”“没有注意”“Agent 不够认真”作为根因。原因必须落到可观察的任务分流、制作步骤、规则表达、执行检查、工具条件或完成判定。

### 独立可读要求

假设接收者无法查看当前会话、没有参与原项目，也不知道报告作者省略的主语和指代。每个问题必须明确写出：

- 涉及哪个工作项、产物和制作或验收阶段；
- 在什么条件下应当触发什么 skill 或规则，哪些情况不适用；
- 谁依据什么材料，对什么对象执行什么动作，以什么证据判定完成；
- 实际证据位于哪里，文件名、字段名和 skill 名分别指什么；
- 哪些是用户已经确认的通用要求，哪些只是当前项目偏好或尚待核验的解释。

不用“这里”“这些”“按规范”“适当处理”“必要时修改”“相关 skill”等无法脱离上下文确定含义的说法。必须保留真实文件名、skill 名和最短必要背景；若边界只能由用户决定，直接写明需要确认的问题，不替用户补全。

## 3. 找到最早失效环节

对每个问题依次写清：应当发生什么、实际发生什么、两者最早在哪里分开、现有流程为什么没有阻止、造成了什么影响。

优先检查以下环节，但不把它们当成固定结论：

- 任务范围或 skill 分流错误；
- 适用规则或 reference 没有加载，或者调用条件不清；
- 规则缺失、互相冲突、表述无法执行或把适用范围写得过宽；
- 规则已经明确，但没有进入实际制作步骤；
- 执行或验收只检查了文件可打开、脚本成功等表面条件，没有检查内容规范；
- 异常已经出现但未在安全点停止，或者完成状态被夸大；
- 工具、权限、运行环境或输入材料使规则无法可靠执行；
- 用户提出的是新的项目偏好，原流程并没有声称覆盖该要求。

多个问题若来自同一个更早原因，合并为一个共同原因并保留各自证据，不为每个表象各写一条规则。若存在多个同样合理的解释，分别列出及其缺失证据，不制造虚假的精确结论。

## 4. 形成候选调整

`workflow.txt` 只提出需要在完整 EpiAgentKit 中核验的候选调整，不直接决定修改文件。每项候选调整写清：

- 要改变的可观察行为；
- 最小可执行机制及可能的维护位置；
- 必须保留的旧行为和合法例外；
- 一个过去应继续通过的场景和一个本次问题场景；
- 当前证据的置信度及仍需查看的完整规则。

可能的维护位置包括根规则、skill、reference、模板、脚本、hook、同步器、测试和 README。报告所在项目通常看不到完整体系，因此不得以“建议修改某文件”冒充最终方案；也不得把局部项目习惯、单个措辞偏好或一次工具失败直接升级为通用要求。

## 5. 写入 `workflow.txt`

使用 UTF-8 纯文本，并按以下顺序组织每次会话的独立部分：

```text
工作流问题交接报告
报告时间：
报告范围：

一、结论摘要
二、证据边界
三、问题记录
  问题 WF-001
  涉及的工作项、产物与阶段：
  适用条件、不适用范围与合法例外：
  用户确认的正确结果：
  实际表现：
  证据位置与证据类型：
  当时适用的规则或 skill：
  最早失效环节：
  现有流程未能阻止的原因：
  影响：
  置信度与待核验内容：
四、共同原因
五、交给 EpiAgentKit 核验的候选调整
  目标行为：
  执行主体、动作与完成证据：
  触发条件与不触发条件：
  最小机制与可能位置：
  必须保留：
  旧场景与新场景：
  证据限制：
六、不应升级为通用规则的事项
七、尚缺证据
```

没有内容的部分写“无”，不编造补齐。问题编号在同一文件内连续且稳定；本次会话内更新同一问题时修改原条目，不再创建措辞不同的重复条目。旧报告中的问题再次发生时使用新编号并注明关联，不改写原有证据。

## 6. 完成检查

写入后重新读取并确认：

- 每个用户指出的问题都回答了“为什么现有流程没有阻止”，而不只是复述错误；
- 不查看原会话也能确定每条记录的对象、条件、动作、证据、完成标准和边界；
- 事实、推断、建议和未知信息已经分开；
- 候选调整说明了保留行为和代表性验证，没有预先限定只能改或不能改某类组件；
- 文件中没有敏感内容、隐藏思维过程、泛泛道歉、助手式承诺或无法核验的断言；
- 除 `workflow.txt` 外没有因本项复盘产生正式项目改动。

最后向用户报告文件位置、记录的问题数量、主要共同原因和证据限制。不要声称 EpiAgentKit 已经因此完成修改。