Find postmortem actions that slipped past the incident
Compare postmortem commitments with the issue tracker and code changes, then prepare a reviewed overdue-action report.
Target user
SRE or engineering leads responsible for preventing repeat incidents.
Trigger
Weekly reliability review or a repeat incident points back to an earlier postmortem action.
Why run it repeatedly
Weekly or before an incident review; actual process cadence varies by team.
What you receive
A list of actions with source postmortem, matching issue/PR, owner, status, due date, and unresolved verification.
Pain evidence
A first-person incident discussion describes actions quietly slipping and recurrence. One community thread does not establish prevalence or the value of another dashboard.
Alternatives and remaining gap
Incident platforms and project trackers can own action items and reminders. A scheduled deterministic report is more reliable; this recipe helps reconcile poorly linked prose records and expose uncertainty.
Execution flow
- Retrieve postmortems in the selected period and extract explicitly recorded actions, owners, and dates.
- Match each action to Linear by linked issue ID first; otherwise report candidate text matches as uncertain.
- For actions claimed complete by a code change, inspect the referenced GitHub issue/PR/file only if directly linked.
- Separate overdue, unassigned, completed-but-unverified, and unmatched items.
- Return a report; do not change issue state or assign work without owner approval.
Required tools
- Notion: notion-search, notion-fetch
- Linear: list_issues, get_issue
- GitHub: issue_read, get_file_contents
Prerequisites and costs
Notion access to postmortems; Linear read scope; GitHub access to referenced repositories; consistent links or names for action tracking.
Run this prompt
Review postmortem actions from [date range]. Match to Linear by explicit issue ID. Use text similarity only to propose candidates, never as a confirmed match. For claimed code completion, inspect directly linked GitHub records. Return overdue, unassigned, unmatched, and completed-but-unverified items with source links. Do not assign, close, or update anything.
Review checkpoints
SRE lead verifies matches, due dates, completion evidence, and whether an action remains relevant. Approval is required before assigning or changing tracker state.
Limitations
This produces an interactive audit, not persistent reminders. Reliable automation requires scheduled execution and run-state outside MCP. Issue text similarity can mis-link unrelated work.
Manual work and missing capabilities
External scheduler for recurring checks, stable postmortem-to-issue links, and human validation of whether a closed issue truly resolved the risk.
Failure handling
Use bounded retries for read failures and mark partial results incomplete. Keep source record IDs and links. Do not guess across missing or conflicting identifiers. Search for an existing target record before any approved write, then retrieve it to verify.
Pilot acceptance criteria
All sampled postmortem actions are accounted for; exact IDs match correctly; fuzzy matches are labeled candidates; no action is closed or reassigned automatically.
Product fit
MCPfolio recipe for one-time audit. If teams validate recurring need, package with scheduled execution and duplicate-safe reminders.
Demo storyboard
Use synthetic postmortems and Linear/GitHub records with one overdue item, one duplicate title, one missing task, and one closed issue lacking a linked change.
Official sources
Pain reported by users; official tool docs/catalog checked; workflow not runtime tested