CtrlK
BlogDocsLog inGet started
Tessl Logo

he-spec

Create bounded, evidence-backed Harness Engineering specs from approved intent. Use when a selected issue, milestone, reframe phase, or execution slice needs acceptance criteria, traceability, risk gates, and validation boundaries before planning or implementation.

53

Quality

60%

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-spec/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 is a highly specialized, process-heavy internal engineering specification workflow that suffers from excessive verbosity and dense jargon. While it demonstrates thoughtful validation gates and a structured procedure, the content reads more like an internal process document than a concise, actionable skill for Claude. The ratio of meta-process description to concrete, executable guidance is heavily skewed toward the former.

Suggestions

Dramatically reduce verbosity by removing framework jargon explanations (stage arcs, persona lenses, blackboard deltas, boundary contracts) from the main body and moving them entirely to referenced files — the SKILL.md should be a lean overview.

Add a concrete, minimal example of what a produced spec artifact looks like (even a truncated template with key sections filled in) to make the output format actionable rather than just listing field names.

Simplify the 9-step procedure into clearer, shorter steps with explicit decision points, and move conditional routing logic (mode selection, gate triggering) to a referenced decision tree document.

Consolidate the Validation section into a clear checklist format with explicit fix-and-retry loops rather than prose paragraphs describing what to block on.

DimensionReasoningScore

Conciseness

The skill is extremely verbose and dense with internal jargon, process-heavy ritual language, and extensive references to internal contracts and boundary documents. Much of the content describes meta-process (stage arcs, boundary contracts, persona lenses, blackboard deltas) that could be dramatically condensed. It explains its own framework concepts at length rather than trusting Claude to follow concise instructions.

1 / 3

Actionability

The procedure section provides a numbered sequence and there are concrete script paths (e.g., `check_bluf_structure.py`, `check_generated_artifact_shape.py`) and specific output field names. However, there is no executable code example, no concrete spec template snippet, and the guidance is heavily abstract/process-oriented rather than showing exactly what a produced spec looks like or how to construct one step by step.

2 / 3

Workflow Clarity

The 9-step procedure provides a sequence with some validation checkpoints (steps 5-6 mention blocking, step 9 mentions handoff conditions), and the Validation section includes specific script-based checks with pass/fail/blocked gates. However, the steps are dense and interleaved with conditional routing logic that makes the actual workflow hard to follow. Validation is present but the feedback loop for fixing failures is implicit rather than explicit.

2 / 3

Progressive Disclosure

The References section provides extensive links to external contracts and documents with conditional 'Read when' triggers, which is a good pattern. However, the main body itself is monolithic and dense — much of the process-heavy content (boundary contracts, persona lenses, stage arc details) could be moved to reference files. Without bundle files to verify, the numerous relative path references cannot be validated, and the sheer volume of inline detail undermines the overview nature SKILL.md should have.

2 / 3

Total

7

/

12

Passed

Description

85%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.

This is a well-structured description that clearly communicates both what the skill does and when to use it, with an explicit 'Use when' clause and multiple concrete deliverables listed. Its main weakness is reliance on proprietary/framework-specific jargon that may not match natural user language, which could reduce discoverability if users aren't familiar with the Harness Engineering terminology.

Suggestions

Add common synonyms or natural language variations alongside the domain-specific terms, e.g., 'requirements', 'specification', 'definition of done', 'technical spec' to improve trigger term coverage.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: creating specs, acceptance criteria, traceability, risk gates, and validation boundaries. The description clearly names the domain (Harness Engineering specs) and enumerates distinct deliverables.

3 / 3

Completeness

Clearly answers both 'what' (create bounded, evidence-backed specs with acceptance criteria, traceability, risk gates, and validation boundaries) and 'when' (explicit 'Use when' clause specifying triggers: selected issue, milestone, reframe phase, or execution slice needing these artifacts before planning or implementation).

3 / 3

Trigger Term Quality

Includes some relevant domain-specific terms like 'acceptance criteria', 'risk gates', 'validation boundaries', 'specs', but relies heavily on proprietary jargon ('Harness Engineering', 'reframe phase', 'execution slice') that users may not naturally say. Missing more common variations like 'specification', 'requirements', 'definition of done'.

2 / 3

Distinctiveness Conflict Risk

Highly distinctive due to the specific 'Harness Engineering' framework context and the precise scope of creating specs from approved intent. The combination of domain-specific terminology and clear phase positioning (after intent approval, before planning) makes it unlikely to conflict with other skills.

3 / 3

Total

11

/

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.