mcpField
R
reflect

reflect

github.com/potetoAgent 工作流13390 次安装21 周前更新
代码仓库

关于 reflect

这项技能从对话中提炼可复用经验，并将其转为技能更新建议。它规定了何时复盘、如何并行审阅和综合发现，以及经用户批准后如何按指定流程应用修改。

主要功能

  1. 01判断哪些对话值得复盘
  2. 02定位当前会话记录
  3. 03并行开展三路审阅
  4. 04综合发现并检查结构化落实方式
  5. 05按规定路径应用获批修改

适用场景

  1. 01从复杂任务中提炼可复用方法
  2. 02将用户纠正转为技能改进
  3. 03复查失败尝试和可推广工作流

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/poteto/plugins --skill reflect

安装后在 Claude Code 中输入/reflect确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
divergent-reviewer.md
judgment-reviewer.md
synthesizer.md
tooling-reviewer.md

详细介绍

Reflect

从当前对话中提炼可长期复用的经验，并将其用于更新技能。

何时调用

  • 用户说了“reflect”或“/reflect”。
  • 一项复杂任务（调用工具 5 次以上）刚刚顺利完成，且其操作方法值得保留。
  • Agent 遇到了死路，后来找到了可行路径，且该路径具有普适性。
  • 用户在任务过程中纠正了 Agent 的做法。
  • 出现了尚未被任何技能涵盖的非平凡工作流。

如果对话过于简单、偏离主题，或父级 Agent 已正确遵循现有技能，则跳过。一次性经验不值得记录。

流程

1. 定位当前活动的对话记录

父级 Agent 在并行派发任务之前，先找到自己的对话记录文件。系统提示中会注明当前工作区的 agent-transcripts/ 目录；使用该路径。不要在 ~/.cursor/projects/*/ 下搜索。这会越过工作区边界，读取来自无关项目的私密对话。

ls -t <agent-transcripts>/*.jsonl <agent-transcripts>/*/*.jsonl <agent-transcripts>/*/subagents/*.jsonl 2>/dev/null | head -10

对话记录有三种布局：旧版扁平结构（<id>.jsonl）、当前嵌套结构（<id>/<id>.jsonl），以及子 Agent 结构（<parent>/subagents/<child>.jsonl）。

对每个候选文件，读取第一行 JSONL，并检查 message.content[0].text 是否包含本次对话的开场用户提示。使用匹配的路径。如果没有找到匹配路径，则撰写一份简洁的会话摘要，并将其传递过去。

2. 并行派发三位审阅者

在一条消息中调用三次 Task，设置 subagent_type: generalPurpose，并为每个调用显式指定 model:，使用 Agent 模式（readonly: false）。审阅者需要 MCP 访问权限，以便查询上下文（对话记录中提及的工单、聊天线程和可观测性追踪）；readonly 会移除 MCP。提示词禁止写入文件；由父级 Agent 应用编辑。

视角model提示词模板
判断你配置的 reflect-judgment 模型（默认 claude-opus-4-8-thinking-xhigh）references/judgment-reviewer.md
工具你配置的 reflect-tooling 模型（默认 composer-2.5-fast）references/tooling-reviewer.md
发散你配置的 reflect-judgment 模型（默认 claude-opus-4-8-thinking-xhigh）references/divergent-reviewer.md

逐字传递每个模板，并在标记位置替换为对话记录路径或摘要。审阅者会在 Task 响应正文中返回发现。

3. 综合

调用一次 Task，设置 subagent_type: generalPurpose，使用你配置的 reflect-judgment 模型（默认 claude-opus-4-8-thinking-xhigh）和 Agent 模式（readonly: false）。综合者的质量检查包括抽样验证引用，这可能需要 MCP 访问权限；readonly 会移除 MCP。逐字使用 references/synthesizer.md，并在标记位置内联每位审阅者的完整输出。综合者会返回结构化的 Accepted / Rejected / Backlog 列表。

4. 结构化强制执行检查

检查综合者的 Accepted 列表是否合理。对于任何通过 lint 规则、脚本、元数据标记或运行时检查能更可靠地强制执行的事项，将其从 Accepted 移至 Backlog。综合者已应用此标准；这是编辑正式生效前的最后检查。请参阅 encode-lessons-in-structure 原则技能。

5. 应用

应用任何已接受的编辑前，先向用户展示综合器完整的“已接受／已拒绝／待办”输出，并等待用户明确批准。由用户选择要应用的子集，也可以重新指定路由。技能变更会影响组织内所有未来的 Agent；不得自动应用。

将待办项自动提交到团队使用的任何开发体验／待办事项跟踪系统。这些是跟踪系统提交，不是技能编辑。只有“已接受”列表需要等待批准。

对于每个获批的“已接受”项，严格遵循“路由”字段：

  • 对现有技能进行琐碎编辑（一行项目符号、精简一句话、修正过时信息）：由主 Agent 直接处理。
  • 对现有技能进行实质性编辑（新增章节、新增模式表格、超过约 10 行）：交给 Cursor 内置的 create-skill 技能，并执行其起草／测试／迭代流程。
  • tune description: <skill path>（技能存在，但在应触发时未触发）：交给 create-skill，并执行其描述优化流程。
  • new skill via create-skill: <kebab-name>：交由 create-skill 创建。不要临时自行设计结构。

如果你的环境提供 SKILL.md 验证器，在宣布完成前，对每个已修改的技能运行验证器。若没有，则跳过此步骤。

6. 向用户总结

简短列出，不要加开场白：

  • 已应用的编辑：<skill path>。每项变更用一行说明。
  • 新建的技能：<skill path>。每项用一行说明（少见）。
  • 已提交到开发体验跟踪系统的待办：<issue title>（<tags>）。每项用一行说明。
  • 已舍弃：每条被拒绝的发现各列一行，并注明综合器给出的原因。

评论

支持 Markdown