| name | follow-up-tracker |
| description | Scan the vault for follow-up callouts (`> [!important] Follow-up due by YYYY-MM-DD`) and standalone `action-item` pages, then surface what's overdue and what's due in the next 60 days, grouped by owner and domain. Load when the user says "what follow-ups are due?", on a weekly sweep, or via `wiki run follow-up-tracker`. Writes one report page per run; pairs with `medical-summary` (which produces visit-specific summaries) and the content-type ingesters that emit the callouts in the first place. |
| license | MIT |
follow-up-tracker
⚠️ Not yet shipped in v2.0.0.dev. This operation runs via
wiki run follow-up-tracker, and wiki run is a stub in
v2.0.0.dev: it prints wiki run: not yet implemented (v2 migration in progress, see RFC-0001). and exits non-zero (see
llm_wiki_kit/cli.py:_cmd_run). The operation runner lands in
Phase D of the v2 migration. Until then, treat this SKILL.md as the
design spec, not an executable playbook. Tracked under
retro-review concern C7 (issue #23).
Reminding operation. Find every follow-up across the vault — inline
callouts on meeting / medical / receipt pages, plus standalone
action-item pages — and produce one report grouped by urgency and
owner. Keeps the household ahead of recheck windows, vehicle service,
home maintenance, and miscellaneous chores.
When to load
- The user asks "what's due?", "what follow-ups are coming?", "anything
overdue?".
wiki run follow-up-tracker runs you with the contract.- A weekly scheduled sweep (typically Sunday morning).
- After an ingester logs a new follow-up — the user may want to see it
in context.
Inputs
From the operation contract:
window_days — how far ahead to look. Defaults to 60. Overdue
items are always surfaced regardless of window.filter — optional restriction. Substring matches against source
path or action_item_owner (e.g. "medical", "jake-doe",
"vehicle").scope — optional subset of content-types to scan.
You also read:
- Every page under
wiki/ for inline > [!important] Follow-up due by YYYY-MM-DD callouts (use wiki-search with --callout or grep —
do not hand-walk the tree).
library/ filtered by --subtype action-item for standalone
action-item pages with action_item_state in
{open, in-progress, blocked}.- Medication reference pages in
library/ for refill due dates.
- Vendor/service nodes in
people/ and any vehicle / appliance pages
for service intervals.
Procedure
- Collect every callout. For each inline callout, capture the
source page (wikilink), the due date, the surrounding paragraph (so
the report can say what the follow-up is about), and the implied
owner (from
meeting_attendees, the medical record's patient, etc.).
- Collect every standalone action-item. Read
action_item_owner,
action_item_due, action_item_state, and action_item_source.
- Compute time-based dues. For receipts that imply a next-service
window (oil change every 5,000 mi, HVAC filter every 90 days),
compute the implied due date.
- Bucket by urgency.
- Overdue —
due < today.
- Due in 30 days —
today <= due <= today + 30.
- Due 30-60 days —
today + 30 < due <= today + window_days.
- Open without a date — surface separately at the bottom.
- Group within each bucket. By owner where applicable, then by
domain (medical, vehicle, home, household, other).
- Apply
filter if provided.
Output
Write outputs/follow-ups/<YYYY-MM-DD>.md (today's date). The page is
versioned per run — the user can compare two runs to see what's been
closed.
Frontmatter:
genre: update
subtype: follow-up-report
status: active
provenance: synthesized
created: <today>
modified: <today>
tags: [follow-ups, <window_days>d]
follow_up_window_days: <window_days>
Sections:
- Synopsis — counts (N overdue, M in next 30, K in 30-60, plus
open-without-date).
- Overdue — most prominent. Each item links to its source page,
shows the due date, and includes a recommended action (call provider,
schedule service, refill).
- Due in 30 days — next-most-prominent.
- Due 30-60 days — looking-ahead view.
- Open without a date — items that may need a due date attached.
- By person / domain — cross-grouped view for the household to
scan by owner.
When the scan finds nothing
If the window is empty (no callouts, no open action items), produce a
minimal page noting "no follow-ups due in the next <window_days> days
as of ". Two reasons this might happen:
- The household is fully caught up. Great.
- Callouts aren't being logged. If ingester history shows medical
records or meetings with no callouts, surface the gap and suggest
"consider adding
> [!important] Follow-up due by YYYY-MM-DD
callouts when ingesting, so this operation can do its job".
Cadence
- Manual: Run weekly on review day.
- Scheduled: A Sunday-morning sweep is a good default; the
household reads the report over coffee before the week begins.
