potpie-change-timeline

Potpie Change Timeline

Use this skill when the user asks what changed, when debugging a possible regression, or when ingesting source history from GitHub, Linear, Jira, docs, or deployment records.

Fast Path

Share one discovery pass with other skills; reuse current reads and hook context for the same task, pot, and scope instead of repeating resolve. For an ordered-history question the timeline read below is the answer, so run it directly; resolve can run concurrently when the task also needs broader context. An untyped search-entities lookup for a named entity with an unknown key can run alongside; only an entity-scoped timeline must wait for that key. For code changes, scoped preferences are independent too. Use a known explicit pot selector; resolve ambiguous routing first and check returned pot IDs before combining results. Stop when the requested history and supporting evidence are covered.

A pot is the project boundary and can contain multiple repos, so do not narrow to the current repo unless the user asks. Take the window from the question and read once; do not start at seven days and widen.

For the context around a change — the services involved, who owns them — resolve infers the operations intent from words like changed / recent / since / when and returns timeline rows as activity TOUCHED service · fact:

potpie resolve "<the question, e.g. what changed in checkout in the last month>"

For the full ordered list, one bounded read with the window the question implies — no hint means 30 days. --detail full keeps each fact whole; compact rows cut it at about 120 characters, where the root cause usually sits:

potpie graph read --subgraph recent_changes --view timeline --format table --detail full --time-window 30d --limit 50

Use the user's exact dates when provided:

potpie graph read --subgraph recent_changes --view timeline --format table --detail full --since 2026-06-01 --until 2026-06-15 --limit 50