CtrlK
BlogDocsLog inGet started
Tessl Logo

lightrun-error-remediation-automation

Guide deterministic runtime investigations in environments using Lightrun MCP tools, with preflight gating, recovery/resume rules, evidence-first diagnosis, PR-first fix proposal delivery, and local source-code fallback only when PR creation is not possible.

60

1.27x
Quality

41%

Does it follow best practices?

Impact

89%

1.27x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/lightrun-error-remediation-automation/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

39%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill defines a thorough and well-structured runtime debugging workflow with strong validation checkpoints and error recovery paths, but it is severely undermined by extreme verbosity and redundancy. The same workflow logic is restated three times (Quick Use Guide, Flow, and checklist), and many constraints are repeated across multiple sections. The lack of any bundle files or progressive disclosure means all ~350+ lines must be loaded into context at once, wasting significant token budget.

Suggestions

Reduce redundancy by consolidating the Quick Use Guide, Flow, and Runtime Quality Checklist into a single authoritative workflow section; remove the other two or move them to separate bundle files.

Extract the State Persistence Discovery Protocol, Action Error Mitigation, Output Contract, and Runtime Quality Checklist into separate referenced files (e.g., STATE_STORAGE.md, ERROR_MITIGATION.md, OUTPUT_CONTRACT.md) to enable progressive disclosure.

Add concrete executable examples of MCP tool calls (e.g., actual `get_runtime_sources` call syntax and expected response format) instead of abstract descriptions like 'choose from currently available tools based on their descriptions'.

Remove repeated constraints (e.g., the 'do not write to local files' rule appears in at least 4 places) and consolidate them into a single Constraints section referenced by other sections.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~350+ lines with massive repetition. The Quick Use Guide, Flow, and Output Contract sections restate the same logic three times. Rules like 'do not write to local files' are repeated across multiple sections. Many instructions describe things Claude already understands (e.g., what JSON key-value pairs are, how to check action status). The state persistence discovery protocol alone is excessively detailed for what amounts to 'use durable storage, not local files.'

1 / 3

Actionability

The skill provides a concrete workflow structure with named tools (e.g., `get_runtime_sources`), specific blocker codes (`state-storage-unavailable`, `reproduction-required`), and an investigation template. However, there are no executable code examples, no concrete MCP tool call syntax, and tool selection is described abstractly ('choose from currently available tools based on their descriptions'). The guidance is structured but not copy-paste ready.

2 / 3

Workflow Clarity

The multi-step workflow is thoroughly sequenced with explicit validation checkpoints (preflight gate, mandatory runtime action result gate, state persistence verification before scheduling). Error recovery paths are well-defined (Missing-MCP Recovery, Action Error Mitigation). Feedback loops are present (check → retrieve or return blocker → persist → stop). The flow includes clear success criteria for each step.

3 / 3

Progressive Disclosure

The entire skill is a monolithic wall of text with no bundle files or external references for detailed content. The Quick Use Guide, Flow section, and Runtime Quality Checklist all repeat the same workflow at different granularities within a single file. Content like the Output Contract, Action Error Mitigation, and State Persistence Discovery Protocol could easily be split into separate referenced files to reduce cognitive load.

1 / 3

Total

7

/

12

Passed

Description

42%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description targets a very specific niche (Lightrun MCP runtime investigations) which gives it strong distinctiveness, but it relies heavily on internal process jargon that users would not naturally use as search terms. It lacks an explicit 'Use when...' clause and fails to include common trigger terms like 'debug', 'troubleshoot', or 'production issue' that would help Claude match user requests to this skill.

Suggestions

Add natural trigger terms users would actually say, such as 'debug', 'troubleshoot', 'production issue', 'runtime error', 'live debugging', 'breakpoint', 'snapshot'.

Add an explicit 'Use when...' clause, e.g., 'Use when the user needs to debug or investigate runtime issues in production using Lightrun, or mentions Lightrun, live debugging, or dynamic instrumentation.'

Replace internal process labels ('preflight gating', 'recovery/resume rules') with concrete actions like 'set dynamic breakpoints', 'capture runtime snapshots', 'analyze application logs', 'propose fixes via pull requests'.

DimensionReasoningScore

Specificity

The description names the domain (Lightrun MCP tools, runtime investigations) and mentions several concepts (preflight gating, recovery/resume rules, evidence-first diagnosis, PR-first fix proposal delivery, local source-code fallback), but these read more like internal process labels than concrete user-facing actions. It doesn't clearly list specific actions like 'set breakpoints', 'capture snapshots', or 'analyze logs'.

2 / 3

Completeness

The 'what' is partially addressed (guide runtime investigations with Lightrun MCP tools), but there is no explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the domain context.

2 / 3

Trigger Term Quality

The description uses highly specialized jargon ('preflight gating', 'recovery/resume rules', 'evidence-first diagnosis', 'PR-first fix proposal delivery') that users would almost never naturally say. Terms like 'Lightrun' and 'MCP tools' are relevant but niche, and common user phrases like 'debug', 'troubleshoot', 'production issue', 'runtime error' are absent.

1 / 3

Distinctiveness Conflict Risk

The description is highly specific to Lightrun MCP tools and a particular investigation workflow, making it very unlikely to conflict with other skills. The niche is clearly defined even if the description has other weaknesses.

3 / 3

Total

8

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
lightrun-platform/lightrun-ai
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.