CtrlK
BlogDocsLog inGet started
Tessl Logo

delivery-flow

Use when a well-defined engineering task must be carried from approved requirements to a verified, reviewed, PR-ready local change.

61

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/sdlc-router/skills/delivery-flow/SKILL.md

The canonical home for this skill is tessleng/sdlc-router

SKILL.md
Quality
Evals
Security

Quality

Content

92%Weight 40%Scale 1-5

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

The body is a lean, fully directive router: stages are unambiguously sequenced, validation and authorization checkpoints are explicit, and a review-fix feedback loop is defined. Its only weaknesses are small unspecified artifacts (the working-plan format and evidence retention details), which keep actionability at 4.

DimensionReasoningScore

Conciseness

Every line is directive with zero padding — e.g. 'Mentioning a skill or paraphrasing it is not equivalent to loading it' — and no concept the model doesn't already know is explained; every token earns its place.

5 / 5

Actionability

Concrete conditional routing is given throughout ('Load `systematic-debugging` when a test fails', 'If it returns valid findings, load `receiving-code-review`'), and per the rubric's scoring note code absence is not penalized for instruction-only skills; minor gaps remain, such as the expected form of the 'concise working plan' or 'observable evidence'.

4 / 5

Workflow Clarity

Stages 1-6 are clearly sequenced with explicit validation checkpoints ('load `verification-before-completion` before claiming completion') and a feedback loop (findings -> address -> return to verification); destructive operations (push, merge, PR, worktree deletion) are explicitly gated on authorization, matching anchor 5.

5 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external reference material, and is well-organized into two clear sections; the router design loads detail on demand via named sibling skills, which per the rubric guideline earns a 5 for short, well-structured skills.

5 / 5

Total

19

/

20

Passed

Description

50%Weight 40%Scale 1-5

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 a strong, explicit trigger clause with reasonably natural terminology and a distinct delivery-pipeline identity, but it never states what the skill actually does, relying entirely on the when-clause to imply the transformation. It also lacks coverage of common trigger synonyms and specific capability verbs.

Suggestions

Add an explicit what-clause before the trigger, e.g. 'Routes an approved engineering task through planning, TDD, debugging, verification, and code-review stages. Use when...' so the skill's function is stated rather than implied.

Broaden trigger coverage with natural synonyms users would actually say, such as 'implement', 'build', 'ship', or 'finish this task', not just 'well-defined engineering task'.

Include 1-2 concrete capability actions (e.g. 'sequencing the delivery skills, gating push/merge/PR on explicit authorization') to raise specificity beyond naming pipeline endpoints.

DimensionReasoningScore

Specificity

The description names the delivery domain and concrete endpoint artifacts ("approved requirements", "verified, reviewed, PR-ready local change") but lists no operational actions such as planning, testing, or review routing, matching anchor 3 rather than the several-specific-actions of anchor 4.

3 / 5

Completeness

The "Use when..." trigger is explicit, but no standalone statement of what the skill does exists — the what (routing a task through delivery stages) is only weakly implied inside the when-clause, placing this between anchor 2 (when only) and anchor 4 (both explicit).

3 / 5

Trigger Term Quality

Terms like "engineering task", "approved requirements", and "PR-ready" are natural user phrasings, but common variations and synonyms ("implement", "build", "ship", "finish this task") are missing, so coverage falls short of anchor 4.

3 / 5

Distinctiveness Conflict Risk

"Approved requirements to PR-ready local change" is a recognizable niche, but the phrasing would match nearly any implementation request and overlaps with general planning/implementation skills, fitting anchor 3 rather than the mostly-distinct anchor 4.

3 / 5

Total

12

/

20

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.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
tesslio/tessl-eval-demo
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.