CtrlK
BlogDocsLog inGet started
Tessl Logo

he-technical-review

Review diffs, PRs, specs, plans, or review-feedback items and return severity-ranked engineering findings with exact locations. Use when technical risks or feedback correctness must be verified before implementation.

50

Quality

54%

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/fixtures/budget-archive/2026-04-21/deferred-store/skills/code_quality_review/he-technical-review/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

42%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 is well-organized with strong progressive disclosure and clear routing/reference structure, but it suffers significantly from lack of actionability—there are no concrete examples of output format, no executable commands, and the procedure steps are too abstract to follow without interpretation. The workflow has a reasonable sequence but lacks integrated validation checkpoints and feedback loops.

Suggestions

Add a concrete example of the structured findings output (e.g., a JSON or markdown block showing a P0 finding with severity, location, impact, minimal fix, and confidence fields populated with realistic values).

Make procedure steps actionable by specifying concrete actions—e.g., step 1 could say 'Run `git diff main..HEAD` or read the PR diff; if no diff is available, ask the user for the target' instead of 'Resolve mode and target; stop if unusable'.

Integrate validation checkpoints directly into the procedure steps rather than having a separate Validation section—e.g., after step 2, add 'Verify each finding has all required fields (severity, location, impact, minimal fix, confidence); if any field is missing, revisit the evidence before continuing'.

Provide at least one complete input→output example showing a sample diff snippet and the corresponding findings-first review output to make the expected behavior unambiguous.

DimensionReasoningScore

Conciseness

The skill is reasonably structured but includes some unnecessary verbosity—e.g., the 'Examples' section lists natural-language prompts that don't add much actionable value, and some sections like 'Anti-Patterns' and 'Philosophy' could be tightened. However, it mostly avoids explaining concepts Claude already knows.

2 / 3

Actionability

The skill provides no concrete code, commands, or executable examples. The procedure is described at a high level ('Resolve mode and target; stop if unusable') without specifying how to do any of it. The output schema is described but not shown. The 'Examples' section contains only natural-language trigger phrases, not input/output pairs demonstrating the expected behavior.

1 / 3

Workflow Clarity

The procedure has a numbered sequence (steps 1-6) and the validation section includes some checkpoint-like gates ('Fail fast: stop at first blocking prerequisite'). However, the steps are abstract and lack explicit validation checkpoints between them—e.g., there's no 'if X fails, do Y' feedback loop within the procedure itself, and the validation section is separate rather than integrated into the workflow.

2 / 3

Progressive Disclosure

The skill has a clear overview structure with well-signaled one-level-deep references to contract.yaml, evals.yaml, task-profile.json, finding.md.tmpl, domain-model-routing.md, qa-intake-routing.md, and subagent routing files. The 'Read when' annotations provide clear navigation signals for when to consult each reference.

3 / 3

Total

8

/

12

Passed

Description

67%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 good structural completeness with both 'what' and 'when' clauses clearly stated, and it identifies a meaningful output format (severity-ranked findings with exact locations). However, it covers a very broad set of input types which reduces distinctiveness, and the trigger terms could be more natural and comprehensive to match how users actually phrase review requests.

Suggestions

Add more natural trigger terms users would say, such as 'code review', 'pull request review', 'audit my changes', 'check for bugs', or 'review my implementation'.

Narrow the scope or clarify what distinguishes this from general code review or PR summary skills—e.g., emphasize the severity-ranking and risk-assessment angle more explicitly to reduce conflict risk.

DimensionReasoningScore

Specificity

It names several input types (diffs, PRs, specs, plans, review-feedback items) and describes the output (severity-ranked engineering findings with exact locations), but the actions themselves are somewhat vague—'review' is broad and the specific concrete operations beyond ranking findings are not enumerated.

2 / 3

Completeness

Clearly answers both 'what' (review diffs/PRs/specs/plans and return severity-ranked findings with exact locations) and 'when' (when technical risks or feedback correctness must be verified before implementation), with an explicit 'Use when' clause.

3 / 3

Trigger Term Quality

Includes some relevant terms like 'diffs', 'PRs', 'specs', 'review-feedback', and 'technical risks', but misses common natural variations users might say such as 'code review', 'pull request', 'design review', 'audit', or 'check my code'. The phrase 'feedback correctness must be verified' is somewhat unnatural.

2 / 3

Distinctiveness Conflict Risk

The scope is fairly broad—reviewing diffs, PRs, specs, and plans could overlap with general code review skills, PR summary skills, or spec analysis skills. The combination of severity-ranking and exact locations adds some distinctiveness, but the breadth of inputs creates potential conflict with multiple other skills.

2 / 3

Total

9

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

10

/

11

Passed

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.