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.

71

Quality

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Quality

Content

85%

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

A concise, well-sequenced review skill with strong workflow clarity and clear validation checkpoints. The main weakness is progressive disclosure: the References section lists many paths that are not present in the actual bundle, and several 'Read when' cues are detached from the files they describe.

Suggestions

Reconcile the References section with the actual bundle: remove or fix non-existent paths (./Infrastructure/references/contract.yaml, ./finding.md.tmpl, ./assets/icon-*.png) and keep only files that resolve, such as ./references/context-preservation.md.

Attach each 'Read when:' cue directly to the reference line it describes instead of leaving three bare triggers floating after the reference list.

Add one concrete inline finding example (severity, location, impact, minimal fix, confidence) to lift actionability from directive-style to copy-paste-ready.

DimensionReasoningScore

Conciseness

The body is lean throughout — short bulleted sections (Philosophy, When To Use, Inputs, Outputs, Procedure, Validation, Constraints, Anti-Patterns) with no padding or explanation of concepts Claude already knows, and every section earns its tokens.

3 / 3

Actionability

Guidance is specific and concrete (severity levels P0-P3, output fields like location/impact/minimal fix/confidence, distinct feedback_response_plan values), but the Procedure steps are high-level directives ('Review with repo-first evidence and deduplicate findings', 'compare reported behavior... before accepting') rather than precise executable instruction, and no example of a finding is shown inline.

2 / 3

Workflow Clarity

The Procedure is a clearly numbered 6-step sequence with an explicit Validation section serving as checkpoints ('Fail fast: stop at first blocking prerequisite or failed validation gate'), plus a feedback loop for QA reports (compare reported vs expected vs proposed-fix evidence before accepting) and routing-elsewhere guidance.

3 / 3

Progressive Disclosure

Structure is well-organized with a clear overview and a References section pointing to deeper materials, but the references are unevenly signaled and point to paths that do not exist in this bundle (e.g. ./Infrastructure/references/contract.yaml, ./finding.md.tmpl, ./assets/*) while only ./references/context-preservation.md is actually present, and several bare 'Read when:' lines are detached from their reference targets.

2 / 3

Total

10

/

12

Passed

Description

92%

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

A strong description: concrete actions, explicit 'Use when' trigger, and natural trigger terms covering the main input types. Its only soft spot is distinctiveness, since the broad 'review a PR/diff/spec' framing overlaps with general code-review skills even though it carves a pre-implementation-verification niche.

Suggestions

Sharpen distinctiveness by foregrounding the niche that separates it from he-code-review — e.g. lead with 'Verify review feedback or proposed fixes are technically correct before implementation' rather than the broad 'Review diffs, PRs, specs, plans'.

DimensionReasoningScore

Specificity

Lists multiple concrete actions across distinct targets — 'Review diffs, PRs, specs, plans, or review-feedback items and return severity-ranked engineering findings with exact locations' — naming both the input types and the specific output shape.

3 / 3

Completeness

Explicitly answers both what ('Review diffs... return severity-ranked engineering findings with exact locations') and when ('Use when technical risks or feedback correctness must be verified before implementation'), with an explicit 'Use when' trigger clause.

3 / 3

Trigger Term Quality

Covers natural user-facing terms users would actually say ('diffs', 'PRs', 'specs', 'plans', 'review feedback') alongside the trigger phrase 'technical risks or feedback correctness must be verified before implementation'.

3 / 3

Distinctiveness Conflict Risk

The niche of pre-implementation verification of review feedback and domain-language drift is fairly distinct, but the broad framing of 'technical review of a PR/diff/spec' could overlap with general code-review skills, and the body routes elsewhere to 'he-code-review' for broader readiness review.

2 / 3

Total

11

/

12

Passed

Validation

87%

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

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

relative_links

Relative link issues: 6 missing, 3 deeper-than-1-level, 5 suspicious

Warning

Total

14

/

16

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.