CtrlK
BlogDocsLog inGet started
Tessl Logo

he-fix-bugs

Debug and repair validated Harness Engineering defects with bounded scope, reproduction evidence, root-cause notes, regression protection, and validation proof. Use when a bug is already evidenced and the fix should not expand into broad improvement work.

51

Quality

55%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

The risk profile of this skill

Fix and improve this skill with Tessl

tessl review fix ./Plugins/harness-engineering/skills/he-fix-bugs/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

35%Scale 1-3

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

This skill provides a well-structured framework for bug fixing with clear boundaries and safety constraints, but it is almost entirely abstract and procedural rather than actionable. It lacks any concrete code examples, command snippets, or actual output format templates that would make it executable. The workflow is logically sound but would benefit significantly from concrete examples of the structured output, validation commands, and patch patterns.

Suggestions

Add a concrete, complete example of the structured output format (schema_version: 1) showing all required fields like side-effect class, reproduction status, root-cause chain, validation results, etc.

Include at least one executable validation command example rather than just listing tool names (e.g., show what 'strict audit' or 'OpenClaw' commands look like with actual invocations)

Replace the abstract 'Examples' section (which only shows user prompts) with a full worked example showing input evidence → reproduction → root cause → patch → structured output

Fix the duplicate step 6 numbering in the Procedure section and add explicit decision-point markers (e.g., 'IF reproduction blocked THEN → return blocker output, ELSE → proceed to step 3')

DimensionReasoningScore

Conciseness

The skill is moderately efficient but includes several sections that are somewhat verbose or abstract without adding concrete value (e.g., Philosophy, Confidence Reporting, Gotchas). Some sections like 'When Not to Use' and 'Safety Boundaries' overlap. The output schema description is wordy without showing an actual schema example.

2 / 3

Actionability

The skill is almost entirely abstract guidance with no concrete code, commands, or executable examples. The procedure steps describe what to do conceptually ('Patch narrowly', 'Add or name regression protection') but never show how. The examples section shows user prompts, not actual input/output examples of the skill's structured output format.

1 / 3

Workflow Clarity

The procedure provides a numbered sequence with a logical flow (reproduce → inspect → patch → validate), and the validation section mentions fail-fast behavior. However, there's a duplicate step number (two step 6s), validation checkpoints are described abstractly rather than with concrete commands, and the feedback loop is implicit rather than explicit with clear decision points.

2 / 3

Progressive Disclosure

The skill references several external files (contract.yaml, evals.yaml, deferred-context-index.md, various contracts) which is good progressive disclosure structure. However, no bundle files are provided to verify these references exist, the references section is somewhat cluttered, and inline content that could be extracted (like the full output format fields) remains in the body.

2 / 3

Total

7

/

12

Passed

Description

75%Scale 1-3

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 has strong completeness with an explicit 'Use when' clause and excellent distinctiveness through its scoping constraints. However, it could benefit from more concrete action verbs describing what the skill actually does technically, and from broader trigger term coverage using natural language users would employ when reporting bugs.

Suggestions

Add more concrete technical actions like 'analyze stack traces, identify failing code paths, write regression tests, verify fixes' to improve specificity.

Include common natural trigger terms users would say such as 'error', 'broken', 'failing', 'crash', 'issue', or 'not working' alongside the existing 'bug' and 'defect' terms.

DimensionReasoningScore

Specificity

The description names the domain (Harness Engineering defects) and mentions several actions/concepts (debug, repair, reproduction evidence, root-cause notes, regression protection, validation proof), but these read more like process constraints than concrete technical actions. It doesn't list specific operations like 'analyze stack traces' or 'write unit tests'.

2 / 3

Completeness

The description clearly answers both 'what' (debug and repair validated Harness Engineering defects with bounded scope, reproduction evidence, root-cause notes, regression protection, and validation proof) and 'when' (Use when a bug is already evidenced and the fix should not expand into broad improvement work), with an explicit 'Use when' clause that also defines scope boundaries.

3 / 3

Trigger Term Quality

Includes some relevant terms like 'bug', 'debug', 'defect', 'fix', and 'root-cause', which users might naturally say. However, 'Harness Engineering' is very domain-specific jargon, and common variations like 'error', 'issue', 'broken', 'failing test', or 'crash' are missing.

2 / 3

Distinctiveness Conflict Risk

The description is highly distinctive by specifying 'Harness Engineering defects' with 'bounded scope' and explicitly excluding 'broad improvement work.' This creates a clear niche that is unlikely to conflict with general debugging skills or feature development skills.

3 / 3

Total

10

/

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
jscraik/Agent-Skills
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.