/request-progress

name: request-progress
description: Group recent conversations into overall requests, review each one's progress from memory, link each to the owner goals it serves, and write the build story, so My Work shows progress meters, shipping velocity and learned working preferences. Use when asked to "group requests", "group by overall request", "review request progress", "refresh progress", "build story", "shipping velocity", or "how do I like to work with agents".

Request Progress

My Work shows one card per **human request**, built from the human's own prompts: a conversation's first substantive ask owns its follow-ups, and agent work, activity and progress sit beneath it, even before any work is recorded. People rarely finish a goal in one conversation, though. They `/clear`, switch worktrees, hand off to Codex, come back the next day. This skill checks each new conversation's opening ask against the open requests in its project to join those conversations into one **overall request**, then reviews each request from memory and writes the build story.

`${CLAUDE_SKILL_DIR}` is the folder holding this file. Every step runs one CLI:

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

It opens `~/.claude-mem/claude-mem.db` read-only and writes only to `~/.claude-mem/work-view/`. My Work picks up changes within a second: grouped conversations show as one card that starts at the earliest ask, with a progress meter; the request page shows the build story, how released work landed (usage, value, regressions, why each change was made) and its work product; each card shows the owner goal it serves; the build story's first paragraph is My Work's recap, and the story sheet shows shipping velocity, the narrative and preferences. A review never changes a request's recorded status.

Default window: 14 days. Use the window the user asks for.

1. Group conversations into overall requests

A human request is the top level of My Work: every conversation's opening ask either starts a request or continues one. Grouping decides **once per conversation**, from its opening substantive ask, and decisions already in the ledger are kept. Requests stay inside one project root (the project key before its first `/`, so worktrees of one repo share requests); a conversation never joins a request from another root, and `apply` refuses one that does.

$CLI grouping-input --days 14

It returns one batch: up to 20 conversations the ledger has not decided yet, earliest first, all from one project `root`, each with its `openingAsk` and work lists; that root's `openRequests` (title, `anchor` conversation, `anchorAsk`, `recentAsks`; shipped and abandoned requests are left out); and `proposedLinks`, conversations code already linked because they wrote to the same work-state list or recorded the same `request_id` (keep these unless the list is obviously a generic bucket). `remaining` counts the undecided conversations left for later batches. Apply each batch, then run `grouping-input` again until `conversations` is empty.

Decide every conversation in the batch:

• **continue**: it serves one of the `openRequests` (or another conversation in the same batch).
• **new**: it starts its own overall request (a group of one).
• **ignore**: it is not a human goal (an automated naming prompt, a bot kickoff, a pasted transcript with no ask).

Evidence for **continue**, strongest first:

1. The ask refers back to earlier work: "this is excellent work, can you now …", "continue the X", a PR or branch name, a pasted handoff. 2. The same named artifact (feature, page, skill, release, bug) appears in both asks within a few days. 3. Memory confirms it: `mem_search` for the artifact finds observations from both conversations describing the same change.

Similar wording alone is not evidence, and neither is sharing a repo. When unsure, make it **new**: a wrongly merged card hides work, a split card only shows up twice. To continue an open request, list its `anchor` first, then the new conversations, keep its title, and add a link with the evidence. List only conversations from the batch (and an open request's anchor first).

Apply the decisions:

$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

The command fails fast; fix the input and rerun. Its rules:

• List `conversations` **earliest first**. The first one anchors the group id, so reviews survive later merges.
• A group of more than one conversation needs at least one link (`shared-work-list`, `shared-request-id` or `agent-judgment`) with evidence text. Quote the human's words where you can.
• `title` is the goal in plain words (≤120 chars), not the process.
• Every conversation in a group comes from one project root.

Then run `$CLI pending --days 14 --limit 48`. `ungroupedConversations` should be 0; `groups` lists the overall requests due for a review (new, or active since their last review).

2. Review each due request from memory

Split the due groups into batches of about 8 and give each batch to a subagent, in parallel, with this task (fill in the CLI path and groups):

> Review the progress of these overall requests from claude-mem memory. For EACH groupId: > > 1. Run `<CLI> show <groupId>` for its conversations, every human ask in full (with prompt ids and times), each conversation's own observations (id, time, type, title), work lists, dates, any previo