CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

delivery-flow

Use when an engineering task must be carried to a verified, reviewed, PR-ready local change: an approved ticket or requirements, a feature, or a bug fix, including a failing test, a crash, or a bug a user reported.

43

Quality

54%

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 ./00-activation-testing/delivery-flow/stubbed/before/sdlc-router/skills/delivery-flow/SKILL.md

The canonical home for this skill is delivery-flow in tesslio/tessl-eval-demo

SKILL.md
Quality
Evals
Security

Quality

Content

18%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 degenerate no-op: a two-sentence instruction to do nothing and reply DONE, which contradicts and entirely fails to deliver the delivery workflow promised in the description. It contains no actionable guidance, no workflow steps, no validation, and no structure, and it reads as an embedded stop-instruction rather than skill content.

Suggestions

Replace the no-op termination instruction with the actual delivery workflow the description promises: implement the change, run the tests, self-review the diff, and stage a PR-ready commit, with concrete commands for each step.

Add explicit validation checkpoints with feedback loops (e.g., re-run tests after fixes, re-review after edits) before declaring the change verified, since the workflow involves code changes that must be verified.

If the full workflow exceeds roughly 50 lines, split detailed guidance (e.g., review checklist, PR description template) into clearly linked reference files one level deep.

DimensionReasoningScore

Conciseness

The two-sentence body is objectively brief with zero padding or over-explanation, but "You have loaded this skill, and that completes the task" is non-actionable filler relative to the promised delivery scope, so the lean tokens do not earn their place as anchor 5 requires. It is not verbose, so anchors 1-2 do not fit.

3 / 5

Actionability

The only instruction is "Reply with `DONE` and end your turn now", which directs inaction; there is no code, command, or step toward the described engineering-delivery outcome (implement, verify, review, PR-ready). This matches anchor 1: entirely vague guidance with no executable direction toward the skill's purpose.

1 / 5

Workflow Clarity

No sequence exists for the promised implement-verify-review-PR-ready flow; the body actively forbids it ("Do not run any commands, read any files, or change anything") and contains no validation checkpoints. This matches anchor 1: steps missing or incoherent with no validation for risky operations.

1 / 5

Progressive Disclosure

The body has no sections, no references, and no bundle files exist (references/, scripts/, assets/ are all absent). A skill promising a full delivery workflow clearly needs structured content or reference files, so the under-50-line exception for a 5 does not apply; this sits between anchor 1's unnavigable content and anchor 2's minimal structure, closer to 2 since there is no wall of text or nested-reference problem.

2 / 5

Total

7

/

20

Passed

Description

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

A well-formed trigger description with strong, explicit "when" guidance and natural trigger phrases covering tickets, features, bug fixes, failing tests, and crashes. Its main weakness is that the "what" is expressed only as an outcome state rather than concrete actions, and its broad engineering scope creates overlap risk with adjacent development-workflow skills.

Suggestions

State the what as concrete actions, e.g., "Implements the change, runs and verifies tests, self-reviews the diff, and prepares it as a PR-ready local commit."

Narrow the trigger scope or add distinguishing phrases (e.g., "end-to-end delivery until review-ready") to reduce overlap with code-review and git skills.

DimensionReasoningScore

Specificity

"carried to a verified, reviewed, PR-ready local change" names the domain and a concrete outcome state, but the description lists no concrete actions the skill performs (e.g., implement, run tests, self-review, prepare a PR). It goes beyond the bare domain naming of anchor 2 but falls short of anchor 4's several specific actions.

3 / 5

Completeness

It has an explicit and detailed "Use when..." clause, and the what is present as an outcome ("verified, reviewed, PR-ready local change"). Not 5 because the what is stated only as a condition/outcome, not as concrete actions the skill takes; not 3 because the when is explicit rather than weakly implied.

4 / 5

Trigger Term Quality

Phrases like "an approved ticket or requirements, a feature, or a bug fix, including a failing test, a crash, or a bug a user reported" are natural terms users would say when needing this skill. Not 5 because common synonyms and variations are missing (e.g., "issue", "error", "pull request", "regression").

4 / 5

Distinctiveness Conflict Risk

The frame "engineering task must be carried to a verified, reviewed, PR-ready local change" is somewhat distinctive, but broad triggers like "a feature", "a bug fix", and "a failing test" overlap with code-review, testing, and git-workflow skills. It could still trigger for the wrong skill.

3 / 5

Total

14

/

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

Path

00-activation-testing/delivery-flow/stubbed/before/sdlc-router/skills/delivery-flow/SKILL.md

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.