Skip to content

Live Runtime Debugging Skill🔗

The Live Runtime Debugging Skill guides an AI assistant through a deterministic investigation of runtime issues using Lightrun MCP. It helps the assistant move from a problem statement to a diagnosis by collecting focused evidence from live applications.

The skill is available in the lightrun-ai repository as lightrun-live-runtime-debugging.

Before using this skill, install the shared Lightrun AI Skills package and complete the requirements in Lightrun AI Skills.

When to use this skill🔗

Use the Live Runtime Debugging Skill when you want an AI assistant to investigate a live runtime issue with evidence from Lightrun MCP.

This skill is useful when:

  • The issue is difficult to reproduce locally.
  • Static code analysis is not enough to explain the behavior.
  • You need to validate a root-cause hypothesis with live expression values, call stacks, execution counts, durations, or custom metrics.
  • You want a structured handoff that includes runtime facts, ruled-out hypotheses, confidence level, and a concrete next action.

How to use this skill🔗

Start a new AI assistant chat and ask the assistant to use the Live Runtime Debugging Skill for the issue you want to investigate.

Use a prompt like this:

Use the Lightrun Live Runtime Debugging Skill to investigate this issue.

Issue:
Users see intermittent checkout failures when applying a discount code.

Target service:
checkout-service in staging.

What I know:
The failure appears near DiscountService.applyDiscount, but I do not know which branch fails.

The assistant should begin by framing the investigation question and listing hypotheses. It should then run the Lightrun MCP preflight check before using any runtime evidence tools.

Watch the demos🔗

The following demo shows how the Live Runtime Debugging Skill guides Claude Code through runtime investigation with Lightrun MCP.

Claude Code demo🔗

What the skill does🔗

The skill gives the assistant a structured workflow for moving from a runtime symptom to a diagnosis:

  • It starts with hypotheses before choosing tools.
  • It requires a Lightrun MCP preflight check with get_runtime_sources.
  • It ties every runtime action to a specific signal that can confirm or weaken a hypothesis.
  • It ends with a diagnosis, confidence level, remaining unknowns, and recommended next action.

This approach helps the assistant avoid broad, low-signal debugging and keeps the investigation tied to evidence from the live application.

Expected investigation flow🔗

During a successful investigation, the assistant should:

  1. Confirm the symptom, impact, expected behavior, and investigation question.
  2. List at least two plausible hypotheses.
  3. Run get_runtime_sources to discover available Lightrun runtime sources.
  4. Select the most relevant runtime target or ask you to choose if several targets match.
  5. Choose runtime evidence tools based on the active hypothesis.
  6. Ask you to reproduce the issue while runtime actions are active.
  7. Summarize each signal and explain which hypothesis it confirms or weakens.
  8. Produce a final handoff with diagnosis, confidence, evidence summary, remaining unknowns, and a concrete fix proposal.

Troubleshooting🔗

The assistant cannot find Lightrun MCP tools🔗

Confirm that Lightrun MCP is installed, enabled, and authenticated in your AI client. Then ask the assistant to list the available Lightrun MCP tools.

For setup instructions, see the MCP quickstart guide.

get_runtime_sources returns no sources🔗

Confirm that the target application is running with the Lightrun agent connected and that your Lightrun user has access to the relevant agent pool, tag, or custom source.

Runtime actions return no hits🔗

Confirm that the selected runtime source matches the code path you are investigating. If the action window expires before the code path is triggered, ask the assistant to use a longer collection window and reproduce the issue again.

The runtime target is unclear🔗

Ask the assistant to compare the available runtime sources and explain which one best matches the service, environment, or expected trigger path. If confidence remains low, choose the source manually.

Last update: May 4, 2026