Lightrun

---
name: lightrun-live-runtime-debugging
description: >-
  Guide deterministic runtime investigations in live environments using Lightrun
  MCP tools, with preflight gating, recovery/resume rules, evidence-first
  diagnosis, and explicit blocker/handoff outputs.
---

# Goal

Provide a repeatable live runtime debugging workflow that helps QA and engineers investigate incidents to a diagnosis with focused, high-signal runtime evidence.

# Preconditions

- User can access the target service source path and line location.
- Lightrun MCP server is installed and authenticated.
- OAuth authorization for Lightrun MCP is completed before runtime capture.

# MCP Preflight

Before collecting runtime evidence, run:

- `lightrun__get_runtime_sources`

Pass criteria:

- At least one valid agent pool is returned.
- A concrete target is selected: `agentNames`, `customSourceName`, or `tagNames`.

Fail criteria:

- Tool is unavailable, call fails, or source list is empty.

# Workflow

1. Frame the investigation question.
2. List top hypotheses and expected signals.
3. Run `lightrun__get_runtime_sources`.
4. Select the best runtime source target.
5. Choose the smallest useful set of Lightrun MCP tools for evidence collection.
6. Capture focused runtime evidence.
7. Update hypothesis status after each signal.
8. Produce a diagnosis with confidence, uncertainty, and next action.

# Runtime evidence strategy

Use Lightrun MCP tools to collect focused evidence, such as:

- expression values
- call stacks
- execution duration
- execution duration samples
- execution counts
- numeric runtime metrics
- numeric metric samples

Start with hypotheses first, then choose the tool that can confirm or falsify each hypothesis.

# Missing MCP recovery

If Lightrun MCP is unavailable:

1. Ask the user to install or enable Lightrun MCP.
2. Ask the user to complete OAuth authorization.
3. Ask the user to verify access to the expected environment or agent pool.
4. Re-run `lightrun__get_runtime_sources`.
5. Continue only after preflight succeeds.

# Output format

Return:

- investigation question
- selected runtime target
- hypothesis matrix
- signals collected
- evidence summary
- leading diagnosis
- confidence level
- ruled-out hypotheses
- remaining unknowns
- concrete code-fix proposal
- validation plan
- recommended next step