Add /marimo-retro-pair skill#40
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new “retro” skill to help marimo team members run structured retrospectives after pairing sessions, capturing friction and turning it into improvements for the marimo-pair skill and/or marimo._code_mode.
Changes:
- Introduces a new
retro-marimo-pairskill with a guided retrospective workflow (analysis → root cause → solutions → apply). - Adds a reference doc snapshotting the
marimo._code_modesurface for use during retros. - Updates plugin marketplace configuration and README to advertise the new retro flow.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| skills/retro-marimo-pair/SKILL.md | New retrospective skill instructions and workflow. |
| skills/retro-marimo-pair/reference/code-mode-surface.md | New reference snapshot of marimo._code_mode APIs and known friction points. |
| README.md | Adds a Contributing section pointing users to the retro command and issues link. |
| .claude-plugin/marketplace.json | Registers the new retro skill in the plugin’s skill list. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| friction and turn it into improvements. The target is always one or both of: | ||
|
|
||
| 1. **The marimo-pair skill** (`~/github/marimo-team/marimo-pair/`) | ||
| 2. **`marimo._code_mode`** — the underlying notebook metaprogramming API |
There was a problem hiding this comment.
This skill hard-codes a local checkout path (~/github/marimo-team/marimo-pair/) in multiple places. Since installs can live anywhere (and the README uses /path/to/skills/... placeholders), consider switching these to repo-relative references (e.g. “this repository’s SKILL.md / reference/ / scripts/”) or a placeholder path to avoid misleading users.
| |-----------|--------|-------| | ||
| | Create cell | `ctx.create_cell(code, ...)` | Adds to graph, auto-compile-checks | | ||
| | Update cell | `ctx.update_cell(cell_id, code, ...)` | Edits existing cell in-place | | ||
| | Delete cell | `ctx.delete_cell(cell_id)` | Confirm with user first | | ||
| | Move cell | `ctx.move_cell(cell_id, ...)` | Reorder in notebook | |
There was a problem hiding this comment.
This doc uses ctx.update_cell(...), but the rest of this repo’s docs consistently reference ctx.edit_cell(...) (e.g. reference/notebook-improvements.md:32 and root SKILL.md:177). If update_cell isn’t a real alias on the context object, this will mislead users—please verify the actual method name and make it consistent across docs.
| | `~/github/marimo-team/marimo-pair/SKILL.md` | Main skill instructions | | ||
| | `~/github/marimo-team/marimo-pair/reference/execute-code.md` | Scratchpad & cell operation recipes | | ||
| | `~/github/marimo-team/marimo-pair/reference/rich-representations.md` | Widget & display patterns | | ||
| | `~/github/marimo-team/marimo-pair/scripts/` | Bundled discovery & execution scripts | |
There was a problem hiding this comment.
i guess i can remove this or make it github://marimo-team/marimo-pair
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
manzt
left a comment
manzt
left a comment
There was a problem hiding this comment.
Looks good. Minor comment but non-blocking and I'll follow up.
| ## Step 3: Brainstorm Solutions | ||
|
|
||
| Based on the root cause, brainstorm concrete next steps. Possible outputs: | ||
|
|
||
| - **Skill edit** — Draft changes to SKILL.md or reference/ files, discuss with | ||
| user, optionally apply (Step 4) | ||
| - **API design sketch** — Propose what a better `_code_mode` API would look | ||
| like for this case, with code examples | ||
| - **Issue draft** — Write up a bug report or feature request for marimo | ||
| (the user decides where to file it) | ||
| - **Pattern/recipe** — Document a new pattern that should be added to the | ||
| skill's reference docs | ||
| - **No action** — Sometimes the discussion itself is the value | ||
|
|
||
| Present options and let the user choose. Multiple outputs are fine. | ||
|
|
||
| ## Step 4: Apply (if agreed) | ||
|
|
||
| ### For skill edits | ||
|
|
||
| 1. Read the target file in `github://marimo-team/marimo-pair` | ||
| 2. Show the proposed diff to the user | ||
| 3. Only apply after explicit sign-off | ||
| 4. After applying, verify SKILL.md stays under 500 lines (reference/ files | ||
| have no limit) | ||
|
|
||
| ### For API proposals or issues | ||
|
|
||
| 1. Write it up clearly with: | ||
| - **Problem:** What happened and why it's painful | ||
| - **Current behavior:** What `_code_mode` does today | ||
| - **Proposed behavior:** What it should do instead | ||
| - **Example code:** Before/after snippets | ||
| 2. Leave it for the user to action — do not auto-file | ||
|
|
There was a problem hiding this comment.
In a follow up, I'll review this section. Do we want our users to always search and suggest a solution? I'd prefer to have the skill diagnose what went wrong and was frustrating, maybe some considerations, but not point them to making a contribution (without first filing an issue/discussion).
This adds @manzt retro pair skill and some contributing guidelines.