retro-marimo-pair

セッションの振り返り

marimo チームメンバーがペアリングセッションを振り返り、摩擦を見つけて改善につなげるのを支援します。対象は常に、次のいずれか一方または両方です。

1. marimo-pair スキル（github://marimo-team/marimo-pair）
2. marimo._code_mode — 基盤となるノートブックのメタプログラミング API

これは会話であり、自動生成されたレポートではありません。問題点を提示し、ユーザーが重要なものを選び、双方で対処方法を決めます。

ガードレール

• 明示的なユーザーの承認なしに、github://marimo-team/marimo-pair 内のファイルを絶対に編集しないでください。
• 必ずセッション分析（ステップ 1）から始めてください。解決策に飛びつかないでください。
• 根本原因より先に摩擦点を提示してください。どの問題を掘り下げるかはユーザーに選んでもらいます。
• ユーザーが特定の不満を挙げて呼び出した場合は、その点に分析の焦点を当てつつ、バックグラウンドでほかの摩擦も確認してください。

ステップ 1：セッション分析

現在の会話を振り返り、摩擦を特定してください。次の点に注目します。

シグナル	確認する内容
ユーザーの不満	訂正（「違う、そうじゃない」）、試行の繰り返し、後戻り、混乱、口調の変化
非効率性	1 ステップで済む作業に何度もやり取りする、過剰な設計、誤った API の使い方
エラー	コンパイルチェックの失敗、ランタイムエラー、気づかれないままの失敗、誤った出力
回避策	制限に対して直接対処せず、ユーザーや Claude が回避策を講じている
コンテキストの喪失	Claude が以前の指示を忘れる、スキルに記載されている内容を再度質問する

見つかった摩擦点を番号付きで要約して提示してください。それぞれについて、次の内容を記載します。

• 何が起きたか（簡潔に）
• 会話のどこで起きたか（引用または言い換え）
• 初期のカテゴリの推測（スキルの構成／スキルの不足／API の問題など）

続けて、次のように尋ねてください。「どれを掘り下げましょうか？ それとも、見落としていることはありますか？」

ステップ 2：根本原因の検討

ユーザーが選んだ摩擦点ごとに、次の観点から検討してください。

観点	問い	改善例
スキルの構成	必要な情報はスキルにあったものの、見つけにくかったでしょうか？ SKILL.md に記載すべき情報が reference/ に埋もれていたでしょうか？	ガードレールに昇格する、段階的に情報を提示できるよう再構成する
スキルの不足	スキルに情報がまったく記載されていなかったでしょうか？	セクション、例、またはアンチパターンを追加する
誤解を招くドキュメント	Claude が誤った方向に進むような記述がスキルにあったでしょうか？	ドキュメントを修正し、補足例を追加する
API の使いやすさ	このタスクにおいて、_code_mode は扱いにくい、または直感的でなかったでしょうか？	API の改善を提案する（より適切なデフォルト、わかりやすいエラー）
API の不足	_code_mode ではできないものの、できるべきことがあるでしょうか？	新しい API の設計
API のバグ	_code_mode は誤った動作をしたでしょうか？	バグの特性を明らかにし、修正または回避策を提案する
コンテキストウィンドウ	長いコンテキストのために、Claude が指示を忘れたでしょうか？	ガードレールを短くし、より目立つ位置に配置する

それぞれの観点を簡潔に検討し、ユーザーとともに最も可能性の高い根本原因を絞り込んでください。複数の要因が関与している場合もあります。

ステップ 3：診断と記録

振り返りの目的は、貢献ではなく診断です。根本原因に基づいて、チームが対処できる明確な診断をまとめます。修正案の提案や作成に飛びつかないでください。

各問題点について、以下を作成します。

• 診断 — 何が問題だったのか、なぜ不便だったのかを平易な言葉で説明します
• 要因 — スキルの構成、ギャップ、誤解を招くドキュメント、API の使いやすさ、API の不足、API のバグ、コンテキストウィンドウ（ステップ 2 から）
• 検討事項 — トレードオフ、未解決の質問、修正を妥当なものにするために必要な条件を記載します。考えられる方向性には触れてもかまいませんが、確定した解決策ではなく、検討事項として示してください。

次のステップとしては、診断をイシューまたはディスカッションとして記録するのが基本です。チームが検討できるようにし、すぐに貢献へ進まないでください。具体的なコード変更（スキルの編集、API の設計）は、イシューまたはディスカッションが作成され、ユーザーが明示的に先へ進むことを選んだ後に行います。

診断を提示し、次のように尋ねます。「これをイシューまたはディスカッションとして下書きしますか？」

ステップ 4：起票またはフォローアップ

基本：イシュー／ディスカッションを起票する

marimo チームがトリアージできるよう、明確にまとめます。

• 問題： 何が起きたのか、なぜ不便なのか
• 現在の動作： 現在、スキルまたは _code_mode がどのように動作するか
• 検討事項： トレードオフや未解決の質問（確定した解決策ではありません）
• 例： 参考になる場合は、セッションから抜粋した最小限のスニペットまたは引用

実際の起票はユーザーに任せます。自動で起票しないでください。これが望ましい結果です。振り返りから修正を出荷するのではなく、問題点をチームに伝えます。

ユーザーが明示的に先へ進むことを望んだ場合のみ

スキルの編集や API の変更は、イシューまたはディスカッションの後に行い、それらに置き換わるものではありません。ユーザーが今すぐ変更案を作成するよう明示的に求めた場合に限り、次の手順に従います。

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)