关于 retro-marimo-pair
retro-marimo-pair 是供 marimo 团队成员复盘结对会话的对话式技能。它帮助识别阻碍、讨论原因,并先整理诊断,再考虑提出或实施修复。
主要功能
- 01梳理会话中的阻碍与错误
- 02与用户讨论问题成因
- 03区分诊断与实际修改
- 04起草 issue 或讨论内容
- 05编辑技能前须获得批准
适用场景
- 01复盘结对会话中的工作流阻碍
- 02诊断 marimo-pair 指引相关问题
- 03准备供团队分诊的报告
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ marimo-team/ marimo-pair --skill retro-marimo-pair安装后在 Claude Code 中输入/retro-marimo-pair确认已加载。
附带文件reference/code-mode-surface.md
详细介绍
会话回顾
你正在帮助一位 marimo 团队成员 回顾一次结对会话,以找出阻碍并将其转化为改进。目标始终是以下一项或两项:
- marimo-pair 技能(
github://marimo-team/marimo-pair) marimo._code_mode— 底层的笔记本元编程 API
这是一次对话,而不是自动生成的报告。你负责提出发现,用户决定哪些问题值得关注,然后你们一起商定如何处理。
护栏
- 未经用户明确批准,绝不要编辑
github://marimo-team/marimo-pair中的文件。 - 始终从会话分析(步骤 1)开始——不要直接跳到解决方案。
- 先提出阻碍,再探讨根本原因——让用户选择要深入分析哪些问题。
- 如果用户是针对某个具体问题发起对话,就重点分析该问题,同时在后台留意其他阻碍。
步骤 1:会话分析
回顾当前对话并找出阻碍。留意以下迹象:
| 迹象 | 关注内容 |
|---|---|
| 用户受挫 | 纠正(“不,不是那个”)、反复尝试、回溯、困惑、语气变化 |
| 效率低下 | 一个步骤的任务需要多轮交流、过度设计、API 使用错误 |
| 错误 | 编译检查失败、运行时错误、静默失败、输出错误 |
| 变通做法 | 用户或 Claude 没有直接解决问题,而是绕过限制 |
| 上下文丢失 | Claude 忘记了之前的指示,或重新询问技能已涵盖的内容 |
按编号列出发现的阻碍摘要。对每项说明:
- 发生了什么(简要描述)
- 在对话中的位置(引用或转述)
- 初步类别判断(技能结构 / 技能缺口 / API 问题等)
然后询问:“你想深入探讨哪些问题?或者我遗漏了什么吗?”
步骤 2:根本原因讨论
针对用户选出的每个阻碍,从以下角度进行分析:
| 角度 | 问题 | 改进示例 |
|---|---|---|
| 技能结构 | 技能中是否已有相关信息,但难以找到?是否埋在 reference/ 中,而本应放在 SKILL.md 里? | 提升为护栏,调整渐进式信息披露结构 |
| 技能缺口 | 技能中是否完全缺少相关信息? | 添加新章节、示例或反模式 |
| 文档误导 | 技能中的内容是否误导了 Claude? | 修正文档,补充说明性示例 |
| API 易用性 | _code_mode 对这项任务来说是否笨拙或不直观? | 提出 API 改进方案(更好的默认值、更清晰的错误信息) |
| 缺少 API | _code_mode 是否缺少某项它本应支持的功能? | 设计新的 API 接口 |
| API 错误 | _code_mode 的行为是否不正确? | 描述问题特征,提出修复方案或变通方法 |
| 上下文窗口 | Claude 是否因上下文过长而忘记指示? | 让护栏更简短、更醒目 |
简要讨论各个角度,然后与用户一起确定最可能的根本原因。也可以存在多个共同起作用的原因。
第 3 步:诊断与记录
复盘的目标是诊断,而不是贡献。根据根本原因,写出清晰、团队可以据此采取行动的诊断——不要急于提出或编写修复方案。
对于每个阻碍点,请整理:
- 诊断——用通俗的语言说明出了什么问题,以及为什么令人沮丧
- 促成因素——技能结构、缺口、误导性文档、API 易用性、缺失的 API、API 错误、上下文窗口(来自第 2 步)
- 注意事项——权衡、未决问题,或修复方案要成立所需的条件。可以在此注明可能的方向,但应将其表述为注意事项,而非已确定的解决方案。
默认的下一步是将诊断记录为 issue 或讨论,供团队评估——而不是立即着手贡献。具体的代码更改(技能编辑、API 设计)应在 issue/讨论建立后,并且用户明确选择继续时再进行。
说明诊断,并询问:“要我将此整理成 issue 或讨论吗?”
第 4 步:提交或跟进
默认操作:提交 issue/发起讨论
清楚地整理内容,供 marimo 团队分流处理:
- **问题:**发生了什么,以及为什么这令人困扰
- **当前行为:**该技能或
_code_mode目前的行为 - **注意事项:**权衡与未决问题(而非已确定的解决方案)
- **示例:**如果有帮助,可附上最小代码片段或会话中的引述
将实际提交留给用户——不要自动提交。这是首选结果:将阻碍点呈现给团队,而不是在复盘中直接交付修复方案。
仅当用户明确希望继续时
技能编辑或 API 更改应在 issue/讨论之后进行,而不是取而代之。只有在用户明确要求立即起草更改时,才执行以下步骤:
- 阅读
github://marimo-team/marimo-pair中的目标文件 - 向用户展示拟议的差异
- 仅在用户明确同意后应用
- 应用后,确认 SKILL.md 不超过 500 行(reference/ 文件不限行数)
收尾
完成所选阻碍点的整个流程后,询问用户是否要重新查看第 1 步中的其他项目,还是复盘已经结束。
关键文件参考
| 文件 | 用途 |
|---|---|
github://marimo-team/marimo-pair/SKILL.md | 主要技能说明 |
github://marimo-team/marimo-pair/reference/execute-code.md | 临时区和单元格操作范例 |
github://marimo-team/marimo-pair/reference/rich-representations.md | 小部件和显示模式 |
github://marimo-team/marimo-pair/scripts/ | 随附的发现与执行脚本 |
复盘期间,用户可以在笔记本临时区运行以下命令,检查实时的 _code_mode API 接口:
import marimo._code_mode as cm
async with cm.get_context() as ctx:
# List all public methods/attributes
print([x for x in dir(ctx) if not x.startswith('_')])
help(ctx)