Error Remediation Automation Skill🔗
The Error Remediation Automation Skill guides an AI assistant through runtime error investigation and fix proposal delivery using Lightrun MCP. It helps the assistant move from an incident or error report to a validated diagnosis and a pull request or fix proposal.
The skill is available in the lightrun-ai repository as lightrun-error-remediation-automation.
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 Error Remediation Automation Skill when you want an AI assistant to investigate a runtime error, validate the root cause with live evidence, and prepare a fix proposal.
This skill is useful when:
- You have an incident, error report, failing flow, or suspected bug that needs remediation.
- You want runtime evidence before the assistant proposes a code change.
- You want the assistant to preserve investigation state across unattended or resumed sessions.
- You want a PR-first workflow, where the assistant opens a pull request when the diagnosis is conclusive and repository access allows it.
- You need a clear handoff when runtime evidence is still pending or the issue must be reproduced again.
How to use this skill🔗
Start a new AI assistant chat and ask the assistant to use the Error Remediation Automation Skill for the issue you want to remediate.
Use a prompt like this:
Use the Lightrun Error Remediation Automation Skill to investigate and propose a fix for this issue.
Issue:
Checkout requests fail with a null pointer exception when a returning customer applies a loyalty discount.
Target service:
checkout-service in staging.
What I know:
The error appears near DiscountService.applyLoyaltyDiscount. Please validate the runtime behavior before proposing a fix.
The assistant should begin by framing the investigation question, checking for required Lightrun MCP tools, selecting a runtime source, and confirming that persistent state storage is available before scheduling runtime actions.
What the skill does🔗
The skill gives the assistant a structured workflow for moving from a runtime error to a fix proposal:
- It starts with hypotheses before choosing tools.
- It requires a Lightrun MCP preflight check with
get_runtime_sources. - It requires MCP-backed persistent state before scheduling asynchronous runtime actions.
- It gates diagnosis and fix delivery on runtime action results.
- It prefers opening a pull request when the diagnosis is conclusive and repository access allows it.
- It falls back to a local source-code fix proposal only when PR creation is blocked.
This approach helps the assistant avoid unsupported fixes and keeps remediation tied to evidence from the live application.
Expected remediation flow🔗
During a successful remediation workflow, the assistant should:
- Confirm the symptom, impact, expected behavior, and investigation question.
- Check whether the problem is new or already known in the configured persistent state storage.
- List plausible hypotheses and the runtime signal that would confirm or weaken each one.
- Run
get_runtime_sourcesto discover available Lightrun runtime sources. - Select the most relevant runtime target or return a blocker if no defensible target can be selected.
- Confirm that MCP-backed persistent storage is available and writable.
- Create focused runtime actions and persist action identifiers, hypothesis status, and cleanup state.
- Check action status or results once per investigation run.
- If results are not ready, return a
reproduction-requiredhandoff with exact trigger instructions. - When runtime evidence supports a conclusive diagnosis, propose a fix and open a pull request when possible.
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.
Persistent state storage is unavailable🔗
This skill requires MCP-backed persistent storage before scheduling asynchronous runtime actions. Configure an MCP-backed memory, database, task tracker, issue tracker, notebook, wiki, document store, or another durable store that the assistant can read and update.
If no writable persistent store is available, the assistant should stop and return state-storage-unavailable.
Runtime actions are still pending🔗
If runtime action results are not available yet, reproduce the issue using the assistant's handoff instructions. The assistant should keep the required action active, persist its state, and resume after results are available.
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 no defensible target can be selected, provide a clearer service name, environment, tag, agent pool, or custom source.
The assistant cannot create a pull request🔗
Confirm that the assistant has access to the source repository and permission to create a branch and pull request. If PR creation is blocked, the assistant should explain the blocker and provide the smallest useful local source-code fallback.