mcpField
R
retro-marimo-pair

retro-marimo-pair

github.com/marimo-teamAgent 工作流4324.7k 次安装6 周前更新
代码仓库

关于 retro-marimo-pair

retro-marimo-pair 是供 marimo 团队成员复盘结对会话的对话式技能。它帮助识别阻碍、讨论原因,并先整理诊断,再考虑提出或实施修复。

主要功能

  1. 01梳理会话中的阻碍与错误
  2. 02与用户讨论问题成因
  3. 03区分诊断与实际修改
  4. 04起草 issue 或讨论内容
  5. 05编辑技能前须获得批准

适用场景

  1. 01复盘结对会话中的工作流阻碍
  2. 02诊断 marimo-pair 指引相关问题
  3. 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 团队成员 回顾一次结对会话,以找出阻碍并将其转化为改进。目标始终是以下一项或两项:

  1. marimo-pair 技能(github://marimo-team/marimo-pair)
  2. 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/讨论之后进行,而不是取而代之。只有在用户明确要求立即起草更改时,才执行以下步骤:

  1. 阅读 github://marimo-team/marimo-pair 中的目标文件
  2. 向用户展示拟议的差异
  3. 仅在用户明确同意后应用
  4. 应用后,确认 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)

评论

支持 Markdown