weekly-recap

Weekly Recap

A recap is a time-window question, and the graph's semantic search has no sense of time: it ranks by relevance, so asking it for "mentions of me last week" returns the best matches from any month and silently drops the week. The knowledge is in the graph; what is missing is the traversal. This skill is that traversal, written down: pivot from the subject's node to the episodes that mention it, sweep the window with the date filters that do exist, and turn what comes back into a brief a human wants to read — plain language, themed bullets, every line carrying its source and date.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking, and memory-capture owns any durable write; they ship with this plugin. The steps below compose those skills rather than bypass them: subject resolution and the themed sweep run under memory-search's rules, relationship checks under graph-traversal's — only the window-paging of episode lists is native to this skill. Work-tracker access comes from whatever tooling the session surfaces (issue tracker, wiki, or none); names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Resolve the window to absolute datetimes before any call, and print it. The report header states start, end, and timezone. A bare "recap" defaults to the trailing 7 days ending now. A named period means that calendar period in the user's timezone — "last week" is the previous Monday-to-Sunday week, "June" is June 1–30; a named period is never a trailing window. Tool calls take the resolved values; a relative phrase never reaches a parameter.
2. Read-only. No writes to memory or to any external system. If the user wants the recap's outcome persisted, that goes through memory-capture's gate — hand it over rather than writing here.
3. Every line is cited and in-window — each point names its source and date in reader's terms: a meeting or document name, a ticket key, a page title. Keep the underlying ids at hand for drill-down; don't print them through the brief. An item whose timestamp you have not seen does not enter the report. Relevance gate per memory-search: no loosely-matching filler.
4. Use the time filters that exist; never fake the ones that don't. Fact search takes server-side created_after / created_before — use them for the sweep — and by default it returns only facts still valid now, which is the wrong default for a recap: a decision made in the window and reversed after it would silently vanish. Windowed sweeps pass include_invalidated=true, and an item the graph marks as later superseded enters the report labelled so — a reversal is part of the week's story, not noise. Episode listings take no date parameters; paging moves from newest toward oldest — page until the timestamps cross the window start; the stop condition is a date, not a count. The two listings order by different clocks — the per-group listing by event time, the per-entity mention walk by ingestion time — and nothing is ingested before it happens, so either way a page that has crossed the window start ends the walk: nothing deeper can still be in-window. Two cautions: items may present oldest-first inside a page even though pages step newest-to-older, so judge the stop on the page's date range, not its first row; and verify each further page actually advanced — a listing that repeats a page has given all it will give, so stop and let Coverage call the audit partial rather than refetch in a loop. Node search has no date filter at all — it resolves subjects to nodes and answers nothing about "when".
5. Scope is server-decided; default to all of it. A recap wants everything the user is allowed to see, and that is what the search tools deliver when no group filter is passed — so pass none by default, and narrow with group_ids only when the user asks for one slice. Episode listings are the exception: one group per call, and omitting the group does not mean all of them — the server picks one team group, never the personal scope; passing the literal personal as the group id is how that scope gets swept. Name the group per call, taking ids from the groups already present in search results or the session's group listing — never from the user, never invented — and sweep each group you saw; Coverage names any you skipped.
6. Report coverage, not just content. The graph knows only what was ingested: state the episode date range actually observed per group, and report an empty window as "nothing recorded for this window", never as "nothing happened". Mentions come from extraction, not from a raw text scan — say so when a mentions section comes back thin. Content that declares itself test or fixture material stays out of the report, and Coverage names the group it was found in. An exhausted page is a stopping point, not proof of completeness — never present the sweep as exhaustive.
7. Bare tool names, probed with ToolSearch — prefixes vary per install.