CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

implement

基于 spec 或 ticket 集合实现一段工作。

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/engineering/implement/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

86%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 an exemplar of lean orchestration guidance: a coherent, sequenced workflow with explicit checkpoints and no wasted tokens. The only soft spots are the unspecific cadence words ("periodically") and the absence of a failure-handling loop before the final commit.

DimensionReasoningScore

Conciseness

The ~10-line body is lean with zero padding: every line is an instruction (fetch and restate the ticket, invoke tdd at seams, run typechecks and tests, run code-review, commit). It fully assumes Claude's competence and explains nothing the model already knows, matching "Lean and efficient; every token earns its place".

5 / 5

Actionability

Guidance is concrete and executable for an instruction-only skill: "先从 issue tracker 获取它,并在开始前复述它的标题", "调用 Skill 工具并指定 tdd", "调用 Skill 工具并指定 code-review", "提交到当前 branch". It falls short of 5 due to hedged/vague qualifiers such as "定期" (periodically) and "尽可能" (where possible) that leave timing and conditions unspecified.

4 / 5

Workflow Clarity

A clear sequence is present (resolve ticket reference → restate title → implement with tdd at seams → periodic typecheck/test runs → full suite → code-review → commit) with most checkpoints explicit, including ambiguity handling ("如果 reference 有歧义,先询问"). It is not 5 because there is no error-recovery feedback loop (e.g., what to do when the full suite fails before committing).

4 / 5

Progressive Disclosure

The skill is under 50 lines, single-purpose, and needs no external references; the discrete one-step-per-paragraph organization is well-ordered and trivially navigable, and no bundle files exist to reference. Per the rubric's simple-skill guidance, this earns the top score.

5 / 5

Total

18

/

20

Passed

Description

48%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 is concise and names a recognizable domain, but it is thin: one generic action, no trigger guidance, and no keyword variations. It reads closer to a title than a capability description, and its completeness is capped by the missing 'when to use' clause.

Suggestions

Enumerate the concrete actions the skill performs (e.g., fetch tickets from the issue tracker, drive TDD at agreed seams, run typechecks/tests, finish with code review and a commit) so the description shows real capabilities instead of a single generic verb.

Add an explicit trigger clause such as "Use when the user asks to implement a spec, ticket, or set of tickets" to satisfy the 'when should this be used' half of completeness.

Broaden trigger vocabulary with natural synonyms users would say — spec, ticket, issue, ticket ID, backlog item — to improve trigger term coverage.

DimensionReasoningScore

Specificity

"实现一段工作" (implement a piece of work) names the domain (spec/ticket-based implementation) but offers only a single generic action with no concrete capabilities enumerated, matching "Names the domain but actions are minimal or generic". It does not reach 3 because no specific concrete actions (like fetch, restate, review, commit) are listed.

2 / 5

Completeness

The "what" is clear (implement work from a spec or ticket set), but there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. It is not 2 because the what is concrete, and not 4 because the when is entirely absent rather than merely implicit.

3 / 5

Trigger Term Quality

"spec" and "ticket" are natural terms a user would plausibly say, but the description includes no synonyms or variations (issue, ticket ID, backlog, user story). This matches "Some relevant keywords but missing common variations or synonyms" rather than the good coverage of level 4.

3 / 5

Distinctiveness Conflict Risk

The spec/ticket-driven implementation framing carves out a mostly distinct workflow niche with minor overlap risk against general implementation or planning skills. It does not reach 5 because "implement a piece of work" remains broad and the description lacks distinctive trigger phrases.

4 / 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

vinvcn/mattpocock-skills-zh-CN

Path

skills/engineering/implement/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.