workflow-improvement

工作流改进

适用场景

在运行命令或完成一段较短的会话后，如果执行过程缓慢、令人困惑、重复繁琐或脆弱，可使用此技能。

此技能侧重改进相关的工作流资产（技能、Agent、命令、钩子），而非功能开发本身。

不适用场景

• 实现功能时——优先专注于功能开发

必需的进度项

1. fix-workflow:context-gathered
2. fix-workflow:slice-captured
3. fix-workflow:workflow-recreated
4. fix-workflow:improvements-generated
5. fix-workflow:plan-agreed
6. fix-workflow:changes-implemented
7. fix-workflow:validated
8. fix-workflow:lesson-stored

步骤 0：收集改进背景（context-gathered）

在分析当前会话之前，先收集现有的改进数据：

0.1：检查技能执行历史

查询 memory-palace 日志，查找近期的性能问题：

# Recent failures (last 7 days)
/skill-logs --failures-only --last 7d

# Performance metrics for involved plugins
pensive:skill-review --plugin sanctum --recommendations

记录：

• stability_gap > 0.3 的技能
• 近期的失败模式和错误消息
• 性能退化趋势

0.2：查询知识库

搜索此前记录的工作流经验：

# If memory-palace review-chamber is available
/review-room search "workflow improvement" --room lessons
/review-room search "efficiency" --room patterns

查找：

• 过去 PR 中的类似工作流问题
• 工作流失败中的反复出现的模式
• 影响工作流的架构决策

0.3：检查 Git 历史

通过提交模式识别反复出现的问题：

git log --oneline --grep="improve\|fix\|optimize" --since="30 days ago" \
  -- plugins/sanctum/skills/ plugins/sanctum/commands/

# Look for unstable components (frequent fixes)
git log --oneline --since="30 days ago" --follow \
  -- plugins/sanctum/skills/workflow-improvement/

提取：

• 频繁修复错误的组件（不稳定性信号）
• 改进类提交消息中的模式
• 反复出现的问题主题

输出格式：

## Improvement Context

### Skill Performance Issues
- sanctum:workflow-improvement: stability_gap 0.35 (5 failures in 7 days)
- Error pattern: "Missing validation in Step 2"

### Knowledge Base Lessons
- PR #42 lesson: "Workflow validation should happen at start, not end"
- Pattern: Early validation reduces iteration time by 30%

### Git History Insights
- workflow-improvement skill: 8 commits in 30 days (instability signal)
- Recurring theme: "Add missing prerequisite checks"

步骤 1：记录会话片段（slice-captured）

识别当前上下文窗口中最近的命令或会话片段并记录：

• 触发因素：启动它的命令／请求（如有，包含原样的 /command）
• 目标：对用户而言，什么才算“完成”
• 涉及的资产：技能、Agent、命令、钩子（名称和文件路径）
• 证据：表明效率低下的关键工具调用／错误／重试
• 步骤 0 中的背景：引用改进背景中的相关模式

如果无法明确界定片段，请选择最近一次完整的尝试，并说明所选的确切边界。

步骤 2：重现工作流（workflow-recreated）

将工作流重构为 5 至 20 个编号步骤，指出输入、决策分支，以及文件变更或状态修改等输出。在重构过程中，找出降低效率的具体摩擦点。这类问题通常包括重复步骤或冗余的工具调用，以及验证发生过晚或前置条件不明确等缺失的防护措施。其他常见问题还包括本应脚本化的任务缺少自动化，以及命名约定令人困惑导致的可发现性不足。

与步骤 0 的背景交叉比对：

• 摩擦点是否与已知失败模式相符？
• 重复步骤是否与 Git 历史中的主题一致？
• review-chamber 的经验中是否提到了缺失的防护措施？

步骤 3：提出改进方案（improvements-generated）

提出 3 至 5 种不同的改进方案，并分别从影响、复杂度、可逆性以及与现有 sanctum 模式的一致性方面评分。评分应明确说明改动能否防止步骤 0 中识别出的模式再次发生。优先处理稳定性差距较高（大于 0.3）的组件，或 Git 历史中发现的反复问题。还应纳入 review-chamber 的经验，并力求减少技能日志中发现的失败模式。优先考虑小而实用的改动，例如收紧技能的退出条件、添加缺失的命令选项、改进钩子防护以提升可观测性，或将负载过重的命令拆分为更清晰的阶段。

步骤 4：商定计划（plan-agreed）

选择 1 种方法并明确：

• 验收标准（“实质性差异”）
• 要修改的文件
• 要运行的验证命令
• 暂缓处理的范围外事项

控制计划范围：目标是修改 ≤ 5 个文件，除非工作流确实涉及更多文件。

步骤 5：实施（changes-implemented）

按照 sanctum 约定应用更改：

• 在 commands/、agents/、skills/、hooks/ 之间保持命名一致
• 如果主要问题是存在歧义，优先改进文档
• 如果行为发生变化，请在 plugins/sanctum/tests/ 中添加或调整测试

步骤 6：验证实质性改进（validated）

验证至少应包括以下 2 项：

• 插件验证器 / 单元测试通过（针对性测试）
• 重新运行最小工作流复现，步骤更少或手动工作更少
• 故障模式明显减少（例如，更早验证、选项更清晰）

将前后对比记录为指标，而不是文字描述：

• 步骤数减少
• 工具调用次数减少
• 避免的错误（之前会出现哪些错误）
• 耗时改善（如可测量）

指标比较模板

## Validation Results

### Before Improvement
- Step count: 15
- Tool calls: 23
- Failure points: 3
- Duration: ~8 minutes
- Manual interventions: 5

### After Improvement
- Step count: 11 (-4, -27%)
- Tool calls: 17 (-6, -26%)
- Failure points: 0 (-3, -100%)
- Duration: ~5 minutes (-37%)
- Manual interventions: 2 (-3, -60%)

### Verification
[E1] Command: `python3 plugins/sanctum/scripts/test_workflow.py`
Output: All tests passed (0.5s)

[E2] Command: `/validate-plugin sanctum`
Output: No issues found

步骤 7：完成闭环（存储经验）

验证完成后，记录改进，以供日后参考：

7.1：更新 Git 历史

使用描述性提交消息，以便将来搜索时能找到：

git add <changed-files>
git commit -m "improve(sanctum): <component> - <specific fix>

Addresses recurring issue: <pattern from Step 0>
Reduces <metric> by <percentage>

Evidence: stability_gap reduced from 0.35 to 0.12"

不要添加 AI 署名尾注。plugins/imbue/hooks/vow_no_ai_attribution.py 会在 PreToolUse 阶段阻止署名和生成者尾注中出现 AI 模型名称，因此，如果模板中带有此类尾注，Agent 会得到一个自己的工具链不接受的提交。

7.2：将工具相关经验发布到 Discussions（首选）

关于 night-market 工具的观察（技能行为、Agent 协作、钩子时机、命令 UX）应发布到 https://github.com/athola/claude-night-market/discussions， 而不是存入本地记忆。无论当前正在处理哪个仓库，始终以 night-market 仓库为目标。

使用 plugins/sanctum/commands/fix-pr-modules/steps/6-complete.md 子步骤 6.7 中的 GraphQL 模式。它通过 ID 解析 night-market 仓库和 Learnings 分类，并将 athola/claude-night-market 硬编码为目标，因此可在任何仓库中使用。

此处不要使用 plugins/abstract/scripts/post_learnings_to_discussions.py。它不接受参数：它会解析 LEARNINGS.md 并发布汇总后的每日日志，这与在工作流中途记录的单条观察属于不同产物。

仓库特定的经验留在当前仓库。工具相关的经验始终发布到 https://github.com/athola/claude-night-market/discussions 以便改进框架。

7.3：在 Memory Palace 中记录经验（可选，仅限本地）

如果改进针对的是仓库特定模式（而非工具），请在本地存储：

# Store in review-chamber lessons
/review-room capture --room lessons --title "Workflow: <pattern name>"

7.4：更新改进指标

跟踪改进的影响：

# Check post-improvement stability
pensive:skill-review --skill sanctum:<component> --recommendations

这样便形成了反馈闭环，未来运行 /fix-workflow 和 /update-plugins 时会参考这条经验。

记录经验教训（决策日志）

如果这项工作涉及返工、失败的方法或阻碍，请将其记录到 docs/lessons-learned.md，确保这一经验在会话结束后仍能留存（先起草并确认）：

• 如果已安装 leyline，请调用 Skill(leyline:decision-journal) 并追加一条经验记录（what_happened、what_didnt_work、root_cause、action；将 phase 设为 review）。展示草稿；确认后再追加。
• 备用方案（未安装 leyline）：使用文件内的 ENTRY TEMPLATE 追加到 docs/lessons-learned.md；分配下一个 LL-NNN ID。

支持模块

• 自动创建 issue - 自动根据暂缓处理的事项创建 GitHub issue 的模式

退出标准

• 已记录会话片段，并说明其边界、触发条件、目标和涉及的产物
• 已提出并评分至少 3 种不同的改进方案
• 已选定一种方案，并制定验收标准和范围明确的文件列表（<= 5 个文件，除非有充分理由）
• 验证记录包含前后指标（步骤数、工具调用次数或故障点），而非文字描述
• 如果该片段涉及返工、失败方案或阻碍，则通过决策日志将经验记录到 docs/lessons-learned.md

故障排除

常见问题

如果找不到命令，请确认已安装所有依赖项，并且它们可通过 PATH 访问。对于权限错误，请检查文件系统权限，并使用适当的权限运行命令。如果遇到意外行为，请使用 --verbose 标志启用详细日志记录，以捕获更详细的执行数据。