request-progress

依頼の進捗

My Workには、人からの依頼ごとに1枚のカードが表示されます。これは人自身のプロンプトをもとに作られます。会話の最初の具体的な依頼が、その後のやり取りをまとめます。エージェントの作業、アクティビティ、進捗は、その下に表示されます。作業がまだ記録されていない場合も同様です。ただし、1つの会話で目標を達成することはほとんどありません。人は/clearを実行したり、ワークツリーを切り替えたり、Codexに引き継いだり、翌日に戻ってきたりします。このスキルは、新しい会話の冒頭の依頼を、プロジェクト内の未完了の依頼と照合して会話を1つの全体的な依頼にまとめ、その後、記憶をもとに各依頼をレビューして開発の経緯を書きます。

${CLAUDE_SKILL_DIR}は、このファイルが置かれているフォルダーです。すべての手順で、1つのCLIを実行します。

CLI="bun ${CLAUDE_SKILL_DIR}/scripts/request-groups.mjs"

~/.claude-mem/claude-mem.dbを読み取り専用で開き、~/.claude-mem/work-view/にのみ書き込みます。My Workには1秒以内に変更が反映されます。まとめられた会話は、最初の依頼から始まる1枚のカードとして表示され、進捗メーターも表示されます。依頼ページには開発の経緯、リリースされた作業がどのように反映されたか（利用状況、価値、デグレード、各変更の理由）、および成果物が表示されます。各カードには、その依頼が役立つオーナーの目標が表示されます。開発の経緯の最初の段落はMy Workの要約として使われ、ストーリーシートにはリリース速度、説明、好みが表示されます。レビューによって、依頼に記録されたステータスが変更されることはありません。

デフォルトの期間は14日間です。ユーザーが指定した期間を使用してください。

1. 会話を全体的なリクエストごとにまとめる

人間からのリクエストは、My Work の最上位レベルです。各会話の冒頭の依頼は、新しいリクエストを開始するか、既存のリクエストを続けます。グループ化は、各会話の最初の本質的な依頼に基づいて一度だけ判断し、すでに台帳に記録された判断は維持します。リクエストは一つのプロジェクトルート内に収めます（最初の / より前のプロジェクトキーを指すため、同じリポジトリのワークツリーではリクエストが共有されます）。会話が別のルートのリクエストに加わることはなく、apply はそのような操作を拒否します。

$CLI grouping-input --days 14

1つのバッチが返されます。台帳でまだ判断されていない会話が最大20件、古い順に含まれ、すべて同じプロジェクト root のものです。それぞれに openingAsk と作業リストが含まれます。また、そのルートの openRequests（タイトル、anchor 会話、anchorAsk、recentAsks。完了済みと放棄済みのリクエストは除外）と、コードがすでに関連付けた proposedLinks（同じ作業状態リストに書き込んだ、または同じ request_id を記録した会話。明らかに汎用的なバケットでない限り、これらのリンクは維持します）も返されます。remaining は、後続のバッチに残っている未判断の会話数です。各バッチを適用した後、conversations が空になるまで grouping-input を再実行します。

バッチ内のすべての会話について判断します。

• continue：openRequests のいずれか（または同じバッチ内の別の会話）のリクエストに該当します。
• new：新たな全体的なリクエストを開始します（1件だけのグループ）。
• ignore：人間の目的ではありません（自動生成された名前のプロンプト、ボットによる開始メッセージ、依頼のない貼り付けられた会話記録）。

continue の根拠として強いものから順に示します。

1. 依頼が以前の作業に言及しています。「これは素晴らしい出来です。次は……できますか」、「X を続けて」、PR 名やブランチ名、引き継ぎの貼り付けなどです。
2. 数日以内の両方の依頼に、同じ名前の成果物（機能、ページ、スキル、リリース、バグ）が登場します。
3. メモリで確認できます。成果物について mem_search を実行すると、両方の会話から同じ変更を説明する観察結果が見つかります。

表現が似ているだけでは根拠にならず、同じリポジトリを共有していることも根拠にはなりません。判断に迷ったら new にします。誤って統合するとカードに作業が表示されなくなりますが、分割したカードは2回表示されるだけです。未完了のリクエストを続ける場合は、まずその anchor を記載し、次に新しい会話を記載します。タイトルは維持し、根拠とともにリンクを追加します。記載するのはバッチ内の会話のみです（未完了のリクエストでは、最初にその anchor を記載します）。

判断を適用します。

$CLI apply - <<'JSON'
{
  "groups": [
    {
      "title": "Live My Work request cards",
      "conversations": ["[\"conversation\",\"claude\",\"<earliest>\"]", "[\"conversation\",\"codex\",\"<later>\"]"],
      "links": [{ "kind": "agent-judgment", "conversations": ["…", "…"], "evidence": "Oct 16 ask: \"this is excellent work, can you now add request cards\" continues the Oct 15 build" }]
    },
    { "title": "Pricing page copy", "conversations": ["[\"conversation\",\"claude\",\"<id>\"]"] }
  ],
  "ignored": [{ "conversation": "[\"conversation\",\"codex\",\"<id>\"]", "reason": "Automated workspace naming prompt" }]
}
JSON

コマンドはエラーがあればすぐに停止します。入力を修正して再実行してください。ルールは次のとおりです。

• conversations は古い順に並べます。最初の会話がグループ ID のアンカーとなるため、後から統合してもレビューが維持されます。
• 2件以上の会話からなるグループには、根拠テキスト付きのリンク（shared-work-list、shared-request-id、agent-judgment のいずれか）が少なくとも1つ必要です。可能であれば、人間の言葉を引用してください。
• title はプロセスではなく、平易な言葉で表した目標です（120文字以内）。
• グループ内のすべての会話は、同じプロジェクトルートのものにします。

次に $CLI pending --days 14 --limit 48 を実行します。ungroupedConversations は 0 である必要があります。groups には、レビュー対象となる全体的なリクエスト（新規、または前回のレビュー以降に更新があったもの）が一覧表示されます。

2. メモリを使ってレビュー対象の各リクエストを確認する

レビュー対象のグループを8件程度ずつのバッチに分け、各バッチを並列でサブエージェントに渡し、次のタスクを実行させます（CLI のパスとグループを記入してください）。

claude-mem メモリから、これらの全体的なリクエストの進捗を確認します。グループごとに、次の手順を実行してください。

1. <CLI> show <groupId> を実行し、各会話、すべての人間からの依頼全文（プロンプト ID と時刻を含む）、各会話固有の観察（ID、時刻、種類、タイトル）、作業リスト、日付、以前のレビューがあればその内容、および reviewBasis を確認します。mode が "amend" の場合、グループの会話は previousReview と同じで、asks には amendSince 以降の依頼のみが含まれます。previousReview を起点とし、amendSince 以降に何が起きたかだけをメモリで検索し、新しい証拠によって変わる項目（状態、割合、日付、要約、新しいマイルストーン、成果、好み）だけを変更します。以前のレビューの残りはそのまま維持してください。mode が "full"（以前のレビューがない場合、または会話が変更された場合）は、最初からレビューします。
2. 成果を確認するため、メモリ（mem_search、timeline、get_observations）を検索します。対象は、マージされた PR、リリース、デプロイ、完了とマークされた作業項目、オーナーが結果を確認または却下した記録、あるいは停止した作業です。一般的な単語ではなく、依頼に記載された成果物を検索します。根拠として使う観察を取得してください。
3. 証拠のみに基づいて判断します。
   • state：shipped（マージされ、リリースまたはデプロイされた、あるいはオーナーが完了を確認した）｜in-progress｜stalled（完了しておらず、3 日以上活動がない）｜abandoned（明示的に取り下げられた、または別のものに置き換えられた）｜unknown（メモリの情報が不十分）。
   • percent：0 未着手 · 10–30 検討または計画中 · 40–70 作成中 · 80–95 レビュー中、PR オープン中、またはリリース待ち · 100 出荷済みのみ。
   • startedAt（最初の依頼）、shippedAt（出荷済みの場合のみ）、lastActivityAt は ISO 日付にします。
   • summary（280 文字以内。依頼者にどのような成果をもたらすか）、narrative（1200 文字以内。方向転換、やり直し、学びを含め、作業の経緯を記述）、milestones（最大 12 件。日付を付け、それぞれの evidence に観察 ID または PR 番号を記載）。
   • 出荷またはリリースされたものがあるリクエストには outcome を含めます（それ以外では省略）。調査したうえで、証拠のみに基づいて回答します。「no-evidence」や「unclear」も正直な回答です。
     • landed：{text, at, evidence}。どこで、どのように出荷されたか（マージされた PR、リリースバージョン、デプロイ、公開ページ）。
     • usage：{level: in-use | some-use | no-evidence | unknown, text, evidence}。オーナーまたはユーザーが後の依頼で再び利用しているか、実行中の観察、分析データやエージェントが確認したログ、報告された不具合などを調べます。
     • value：{level: high | medium | low | unclear, text, evidence}。後続の作業がその成果を土台としているか、オーナーが称賛、依存、または置き換えをしたか、コストや手間が削減されたかを示します。
     • regressions（最大 10 件）：{text, at, fixedBy, evidence}。後続の修正 PR やコミットで言及された不具合、リバート、バグ報告、オーナーによる訂正など、発生させた問題を記載します。未修正の場合、fixedBy は null です。
     • changes（最大 12 件）：意味のある変更ごとに {what, why, at, evidence} を記載します。WHY は、オーナー自身の依頼（引用）、コミットまたは PR のメッセージ、あるいは原因となったインシデントに基づくものとします。引用できない理由を書いてはいけません。
   • preferences（最大 10 件）：show に表示されたオーナー自身の依頼のみから、オーナーがエージェントとの作業で好む方法を記載します。各項目には preference（200 文字以内の記述）、quote（300 文字以内の原文引用）、kind、at を含めます。quote は一字一句そのまま記載します。kind は directive｜correction｜praise｜frustration のいずれかです。貼り付けられたエージェントの文章、秘密情報、キー、トークンは除外してください。
4. 記録します。<CLI> record-progress - <<'JSON' {...} JSON を実行し、groupId、state、percent、日付、summary、narrative、milestones、outcome、preferences、evidence、およびそのグループの show 出力からそのまま転記した reviewBasis を含めます（これはレビュー対象の会話とアクティビティを示します）。JSON はヒアドキュメント経由で渡してください。他のレビュアーも同時に作業しているため、レビュー用ファイルをディスクに書き込んではいけません。拒否された場合は修正して再試行します。サブタスクの完了は、リクエスト全体の出荷を意味するものではありません。

記録したグループと、記録できなかったグループおよびその理由を返してください。

3. 各リクエストを、それが貢献する目標に紐付ける

レビュー後に、ご自身で次の手順を実行します（レビューの要約が必要です）。

1. $CLI align-input を実行します。現在のオーナーの目標（オーナーの目標リストにある、正確な goal キー、タイトル、プロダクト、オーナー自身の引用を含む）、まだ紐付けられていないリクエストグループ（タイトル、最初の依頼、進捗状況、要約。このステップでまだ確認していないグループ、決定後にリクエストが変更されたグループ、または目標が変更された場合はすべてのグループ）、および以前の紐付けが返されます。グループが表示されない場合は、このステップをスキップします。すべてのグループがすでに紐付けられているか、オーナーの目標スキルが実行されておらず、すべてのカードが「Goal not linked yet」のままです。
2. 表示された各グループについて、直接前進させる目標を選びます。通常は1つ、最大3つです。リクエストの実現によって目標が前進する場合、そのリクエストは目標に貢献します。同じプロダクト領域というだけでは不十分です。現在の目標に貢献しないグループは unaligned に入れます。目標またはリクエストが変更されていない限り、以前の紐付けを維持します。
3. 各紐付けには evidence（300文字以内）が必要です。リクエストのどの部分が目標を前進させるのかを、目標またはリクエストの言葉を引用して記述します。
4. 記録します。表示されたすべてのグループを links または unaligned に含める必要があります。表示されなかったグループは、以前の紐付けを維持します。コマンドで検証されるため、拒否された場合は修正して再試行します。

$CLI record-alignment - <<'JSON'
{"links": [{"groupId": "g_…", "goal": "<exact goal key>", "evidence": "…"}], "unaligned": ["g_…"]}
JSON

My Work では、紐付けられた目標が各カードに表示されます。紐付けられていないグループには「No goal」、このステップでまだ確認していないグループには「Goal not linked yet」と表示されます。

4. ビルドストーリーを書く

$CLI story-input を実行します。以前のストーリーがない場合はすべてのレビューが返されます。以前のストーリーがある場合（update: true）は、そのストーリーを書いた後に事実（状態、割合、日付、マイルストーン、好み、結果）が変更されたレビューのみが返されます。レビューが表示されない場合は、このステップをスキップします。ストーリーは引き続き有効です。更新時は、以前のストーリーの章や表現が引き続き適切であれば維持し、表示されたレビューによって変わる部分だけを変更します。次の内容を書きます。

• narrative（Markdown、12000文字以内、空行で区切られたブロック、章には ## 見出しを使用）：時系列のビルドストーリーです。冒頭に出荷速度についての短い段落を置きます（My Work ではこれが要約として表示されます）。その後、何を目指していたか、何がいつ出荷されたか、依頼から出荷までにかかった期間、作業が停滞またはやり直しになった箇所、そこから得られる教訓を記述します。レビューに記載された日付付きの事実のみを使用します。その人のことは「オーナー」または「本人」と呼び、代名詞を推測してはいけません。
• preferences（最大30件）：リクエストごとの好みを、オーナーがエージェントとの作業で好む方法についての、重複のない実行可能な記述にまとめます。supportCount は、その好みが示されたリクエストの数です。日付付きの逐語的な引用は最大3つまで保持します。一度限りの意見は除外します。

$CLI record-story - <<'JSON'
{"narrative": "...", "preferences": [{"preference": "...", "kind": "directive", "supportCount": 3, "quotes": [{"quote": "...", "at": "ISO"}]}]}
JSON

最後に、レビューしたリクエスト数、目標に紐付けたリクエスト数、出荷速度についての2文、および最も強い好みを5つ、ユーザーに伝えます。