reflect-and-improve

振り返りと改善

このツールキット内の別のスキルが成果物を生成した後に実行するメタスキルです。次の問いを率直に一つだけ尋ねます。変更によって、目標に照らして論文は本当に良くなったのか、それとも単に違うものになっただけなのか？ 新しい成果物を、（a）目標、（b）論文の .paper-memory/profile.yml、（c）タスクに適した評価基準、（d）過去の .paper-memory/lessons.md と照らして批評します。厳格な予算内で反復し、測定可能なスコアを下げる変更は受け入れず、次の論文に活かせるよう学んだことを記録します。

これはコパイロットであり、パイロットではありません。提案はしますが、決定して編集するのは著者です。

使用するタイミング

• polish-prose、write-rebuttal、write-abstract、preflight-check、tailor-to-venue、draft-related-work、または成果物を生成するその他のスキルの直後に、慎重な二度目の確認をしたい場合。「新しいバージョンは本当に良くなったのか、それとも後退させてしまったのか？」
• 「この書き直しを残す前に、振り返って／批評して／セルフレビューして」
• 「編集は役に立った？」／「良くなった？」／「元に戻すべき？」
• 長く活用できる教訓（「アブストラクトで過剰に留保する傾向がある」など）を記録し、この論文や今後の論文でツールキット全体が同じ間違いを繰り返さないようにしたい場合。

使用しないタイミング（コストを正直に考える）

振り返りには、LLM による追加の処理と著者の注意が必要です。測定可能な目標、または評価基準に基づく目標がある場合にのみ効果があります。次の場合は省略するか、手早く一度だけ確認してください。

• 比較する目標がない場合。純粋に好みでの編集（評価基準なしに「もっと良い響きにする」など）は好みに帰着します。一度読めば十分です。
• 生成に使ったスキルが、変化していない確定的なスコアをすでに出している場合（例：変更前も変更後も preflight に問題がない）。チェックを再実行すること自体が振り返りになります。文章による批評ではなく、そちらを行ってください。
• 成果物が非常に短い場合（一行の修正など）。ループのコストが効果を上回ります。

測定できないものについて振り返りを求められたら、その旨をユーザーに伝え、代わりに一度だけの確認を提案してください。

入力

1. 批評する成果物：新しいテキスト／ファイル（可能であれば置き換え前のバージョンも。そうすれば「良くなったか」を印象ではなく差分で判断できます）。
2. 目標：生成に使ったスキルで達成するよう求められたことを一文で示します（「貢献を損なわずにアブストラクトを200語に短縮する」「R2 の健全性に関する懸念に答える」など）。
3. .paper-memory/profile.yml — 著者と論文の位置づけです。存在しない場合は、まず paper-profile を使うか、以下の最小限の項目を手動で記入して作成してください。位置づけを踏まえない振り返りでは、一般論しか得られません。
4. 測定可能な目標（ある場合）：
   • スクリプトのスコア（preflight のエラー数、polish-prose の読みやすさ／ヘッジ表現の数、投稿先の上限に対するアブストラクトの語数、引用検証の失敗数など）。
   • または references/（もしくは simulate-reviewers/references/rubrics.md）にある評価基準を用いて、変更前と変更後に1～5で採点します。
5. .paper-memory/lessons.md — 批評を個別化し、すでに記録された助言を繰り返さないよう、最初に読んでください。

.paper-memory/の規約

ユーザーの論文作業ディレクトリ内にプロジェクトごとに作成されるディレクトリです（このリポジトリ内には作成しません）。スキルの使用時に作成されます。論文とともに位置付けや教訓をバージョン管理したい場合を除き、ユーザーに.paper-memory/を.gitignoreに追加するよう伝えてください。ローカルに保存され、アップロードされることはありません。

• profile.yml — 分野（systems/theory/applied/empirical/survey/position）、貢献の種類、対象読者と会場のティア、リスク許容度、執筆の好み（match-styleへのリンク）、制約。最小限のスターターはreferences/paper-memory-schema.mdを参照してください。
• lessons.md — 蓄積され、重複が削除された、日付付きの教訓。他のスキル（preflight-check、polish-prose、verify-citations、simulate-reviewers）は、何かに気づいた際にここに追記し、開始時にここを読み込みます。形式と整理のルールについてはスキーマのリファレンスを参照してください。scripts/reflect_log.pyによって適用されます。
• decisions.md — 根拠を添えた会場／トラック／位置付けの決定（select-venue／plan-submissionが記述し、ここでは文脈の把握に使用します）。

プロセス

このループは制約付きのリフレクション／自己改善です。批評 → 修正 → 再採点し、 測定可能な改善があった場合にのみ採用します。反復回数に上限を設け、改善がなければ 停止します。

1. ベースラインを確立する — まず測定します。 批評する前に、成果物が目標に対して 現在どのスコアなのかを記録します。最も低コストで妥当な測定方法を選びます。成果物を 作成したスキルにチェッカーがある場合はそれを再実行するのが望ましく（決定論的なため）、 ない場合は該当するルーブリックを1～5で採点します。記録します。

   python3 scripts/reflect_log.py score --memory .paper-memory \
       --skill polish-prose --metric hedge-count --before 11
   

   測定可能な目標がない場合は、その旨を伝え、定性的な見直しを1回行って停止します。 数値が存在するかのように装ってはいけません。

2. メモリーを読みます。 過去の助言を繰り返したり、既知の後退を再び招いたりしないよう、 繰り返し現れる教訓を確認します。

   python3 scripts/reflect_log.py recurring --memory .paper-memory
   

   profile.ymlを読みます。「すべての文を引き締める」という批評は、文体を重視する ポジションペーパーには不適切です。「さらに曖昧な表現を加える」という批評は、 リスク許容度の高いシステム論文には不適切です。プロフィールに合わせて調整してください。

3. 4つの軸に照らして、具体的かつ指摘ごとに批評します。

   • 目標 — 求められた具体的な内容を、過不足なく実現していますか？
   • プロフィール — 分野、読者、投稿先の格、文体に合っていますか？
   • ルーブリック — 該当する評価項目（妥当性、明瞭さ、新規性の位置づけ、反論への応答性）を、 前のバージョンと比べて1～5で採点します。
   • 教訓 — 記録済みの間違いを繰り返していますか、それとも修正していますか？ 各指摘は「何が後退／改善したか、根拠、最小限の修正」の形式で記述します。

4. 判断します — 後退防止は譲れません。 ベースラインと同じ方法で修正後のスコアを計算し、 比較します。

   python3 scripts/reflect_log.py score --memory .paper-memory \
       --skill polish-prose --metric hedge-count --before 11 --after 6
   

   スクリプトは差分と判定を出力します。測定可能なスコアが低下する変更は、文章が 「より良く感じられる」場合でも決して採用してはいけません。事前チェックエラーの増加、 ルーブリック平均点の低下、語数上限の超過、新たな引用の不備など、測定可能な後退は 感覚よりも優先されます。判定は、KEEP（測定可能な改善あり）／REVERT（測定可能な後退あり。 前のバージョンを推奨）／TIE（測定可能な変化なし。著者の好みに委ね、反復を増やさない）です。

5. 予算内で反復します。 KEEPとなっても目標に達しておらず、反復上限（デフォルトでは 合計3回）に達していない場合は、最重要の指摘だけに対応する修正を行い、手順4に戻ります。 目標を達成したとき、上限に達したとき、または測定可能な改善がない状態が2回連続したときは 停止します（収益逓減を示す、停止すべきという誠実な兆候です）。

6. 長期的に役立つ教訓を追記します。 このループで今後に活かす価値のあるパターンが見つかったら、 重複を除き、日付を付けて記録します。

   python3 scripts/reflect_log.py append --memory .paper-memory \
       --skill polish-prose --scope recurring \
       --issue "abstract over-hedges the contribution" \
       --rec "state the result as a claim once, then qualify in the body"
   

   論文固有のメモには--scope this-paperを、複数の論文にまたがるパターンにはrecurringを 指定します（これらは削除されません）。スクリプトは（skill、issue）を基準に重複を除き、 日付を記録します。

7. 整理します。 定期的に古くなったthis-paperの教訓を整理し、上限を適用します （recurringの教訓は常に保持されます）。

   python3 scripts/reflect_log.py prune --memory .paper-memory \
       --keep 50 --stale-days 365
   

   この実装のパターンとその失敗モード（報酬ハッキング、迎合的な自己承認、振動）については references/reflection-loop.mdを、 ファイル形式についてはreferences/paper-memory-schema.mdを 参照してください。

出力

• 批評：各軸（目標／プロフィール／ルーブリック／教訓）ごとの指摘。それぞれに根拠と最小限の修正を付けます。
• KEEP／REVERT／TIEの判定：感覚ではなく、修正前から修正後への数値で裏付けます。REVERTの場合は、 前のバージョンを推奨し、どの指標が低下したかを説明します。
• .paper-memory/lessons.mdへの教訓の追記（0件以上）。
• 確信度と、リフレクションでは測定できなかった内容についての率直な説明。

分野に合わせて調整する

ループとメモリーは分野を問いません。ルーブリックと指標のみがコンピューターサイエンス寄りです。 ルーブリックには自分の分野の査読フォームを、スクリプト指標には投稿先の長さや形式の制限を、 検証フックには自分の引用スタイルを適用してください。.paper-memory/のスキーマは変更しません。

ガードレール

• 測定可能な退行は決して受け入れないでください。 スコアが下がった場合は、新しいバージョンの出来がどれほど良く感じられても、差し戻します。これこそが、このスキルの目的です。
• 振り返りは無料ではありません。 コストを明示してください。測定可能な目標がない場合はループを省略し、反復を正当化するために指標を作り出すのではなく、1 回だけのパスを提案してください。
• ループには上限を設けます。 反復回数に厳格な上限を設定し、測定可能な向上がなければ停止してください。決して延々と続けないでください。
• 自分に都合のよい評価をしないでください。 自分の以前の出力を既定で承認しないでください。判断基準となるのはベースライン測定であり、以前の自分の推論ではありません。
• スコア、ルーブリックの数値、「改善」を決して捏造しないでください。測定するか、測定できなかったと伝えてください。引用の問題は verify-citations に、形式の不備による不採用は preflight-check に回してください。
• どこにも提出してはいけません。採択を約束してはいけません。.paper-memory/ はローカルに保持し、ユーザーに .gitignore へ追加するよう伝えてください。