trace-replay

Replay recorded Teams notification trace JSONL events to diagnose grouping and edit decisions.

1|Updated Aug 22, 2025
One-click install
npx skills add https://github.com/interserver/teams-chat-bot --skill trace-replay
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: trace-replay
Source: https://github.com/interserver/teams-chat-bot/tree/main/.claude/skills/trace-replay
Command: npx skills add https://github.com/interserver/teams-chat-bot --skill trace-replay

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Trace replay diagnoses why the notification consumer grouped, edited, redirected, or “fell through” into a new message by reconstructing prior decisions from recorded JSONL traces.

Core Features & Use Cases

  • Replay notification queue history: Reconstructs what happened to a specific dedup key, commit SHA, room, activityId, event, kind, or time window by replaying .logs/notif-trace-YYYY-MM-DD.jsonl.
  • Explain decision outcomes: Interprets trace kind values such as recent_lookup, recent_saved, edit_skipped_no_convref, edit_fell_through, announce_redirect, and batch-related kinds to determine the likely root cause.
  • Supports multiple investigation modes: Uses --mode timeline for chronological story, --mode grouped for activity lifecycle, and --mode raw for field-level inspection when timeline/grouped is insufficient.

Quick Start

Ask the user for the approximate date/time and dedup anchor (dedup key, commit SHA, room, or activityId), confirm the matching trace file exists in .logs/, then run the replay in timeline mode for that window to identify the key kind that caused the behavior.

Frequently Asked Questions about trace-replay

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug why a Teams notification was grouped incorrectly or fell through to a new message?

To debug incorrect Teams notification grouping, replay recorded JSONL trace events to reconstruct the consumer's past decisions. This process maps specific trace kind outcomes to identify the exact root cause of the fall-through behavior.

What is a notification trace kind value and how does it explain edit or redirect decisions?

A notification trace kind value is a recorded event indicator that explains edit or redirect decisions. Values like edit_fell_through, edit_skipped_no_convref, and announce_redirect map directly to consumer logic to determine the root cause of a specific action.

How do I replay notification queue history for a specific commit SHA or dedup key?

To replay notification queue history for a specific commit SHA or dedup key, run the replay script over the matching JSONL trace file. You can use timeline, grouped, or raw modes to investigate the specific time window and dedup anchor.

Does trace replay support live notification queue administration and real-time monitoring?

Trace replay does not support live notification queue administration or real-time monitoring. It specifically targets past incidents by reconstructing prior decisions from recorded JSONL traces rather than handling live queue administration tasks.

When should I use the raw mode instead of the timeline mode for trace replay?

You should use the raw mode for trace replay when the timeline or grouped modes are insufficient for your investigation. Raw mode provides field-level inspection of the JSONL events, allowing deeper analysis of specific notification queue trace attributes.

What's the best way to start diagnosing a past notification queue incident using trace files?

The best way to start diagnosing a past notification queue incident is to confirm the matching JSONL trace file exists in the logs directory, then run the replay script in timeline mode for the approximate date and dedup anchor to identify the key kind that caused the behavior.