CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

implement-task

Implement a task step by step with automated LLM-as-Judge verification at the end of each phase

Quality

67%

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 ./antigravity/skills/implement-task/SKILL.md

The canonical home for this skill is implement-task in NeoLabHQ/context-engineering-kit

SKILL.md
Quality
Evals
Security

Quality

Content

70%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 delivers exceptionally clear, executable orchestration guidance with strong validation and feedback loops — its workflow and actionability are best-in-class. Its weaknesses are structural: massive rule repetition inflates it well past a reasonable token budget, and with zero bundle files everything lives in one monolithic document, making it hard to navigate despite good in-file anchoring.

Suggestions

State each core rule (threshold-blindness, MODEL_OVERRIDE precedence, [REVIEWED-SKIPPED] semantics, --strict interactions) exactly once in Configuration Rules and reference it by anchor link elsewhere; delete the duplicated restatements in the Iteration Discretion Rule, dispatch blocks, and Checklist.

Move the eight usage examples, Appendix A, and the Error Handling catalog into a references/ file (e.g. references/examples.md, references/artifacts.md) linked one level deep from the body, cutting SKILL.md to the core workflow.

Drop one of the two ASCII workflow diagrams (the Execution Flow Diagram duplicates the Complete Workflow Overview) and trim examples 5-8 to their distinguishing behavior rather than full session logs.

DimensionReasoningScore

Conciseness

The ~1,700-line body restates its core rules many times over — threshold-blindness of the code-reviewer, MODEL_OVERRIDE precedence, [REVIEWED-SKIPPED] semantics, and the --strict/--skip-reviews interactions each appear 3-5 times across Configuration Rules, Execution & Evaluation Rules, the Iteration Discretion Rule, the dispatch blocks, the closing Checklist, and the examples; two ASCII diagrams depict the same workflow and eight full session-log examples overlap heavily. This is 'noticeably verbose; several padded sections' (anchor 2) — below anchor 3 because the redundancy is pervasive rather than occasional, above anchor 1 because it never explains concepts Claude already knows and all content is operational.

2 / 5

Actionability

Guidance is fully executable throughout: copy-paste dispatch prompts for implementation agents and the code-reviewer, exact git/bash commands with fallbacks, a precise 4-input reviewer contract plus an explicit must-not-pass list, concrete reject/re-run rules, and two fully worked anchor cases with concrete scores and model choices. Copy-paste ready with the common cases covered.

5 / 5

Workflow Clarity

Workflow Phases 0-5 are explicitly sequenced with pervasive validation checkpoints: orchestrator-level threshold application shown as pseudocode, the Iteration Discretion Rule with a fixed floor, MAX_ITERATIONS feedback loops, a pre-DoD verification checklist, Definition-of-Done fix→re-verify cycles, and a dedicated Error Handling section. Clear sequence, explicit validation, feedback loops, and checklists — anchor 5.

5 / 5

Progressive Disclosure

No bundle files exist and none are referenced; everything — eight usage examples, the Appendix A artifact documentation, the full closing checklist, and two flow diagrams — is inlined in a single very large file. Internal section headers and anchor links are well done, but substantial content that clearly belongs in separate reference files (examples, appendix, extended mode documentation) is inline, matching anchor 3 ('some structure but content that should be separate is inline') rather than anchor 4, which presumes most content is appropriately split across files.

3 / 5

Total

15

/

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 states a concrete, coherent capability but is bare-minimum: it answers 'what' in only two actions, gives no 'when to use' guidance, and carries few of the natural trigger terms that would route a user to this skill over a generic implementation skill. It is functional but leaves routing and scope decisions underdetermined.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to implement an SDD task from .specs/tasks/, continue an interrupted implementation, or re-verify phases after manual fixes (--continue/--refine)'.

Enumerate more of the skill's concrete actions in the description (dispatch one agent per step, one phase-level code review, threshold-gated iteration, Definition-of-Done verification, final report) to raise specificity and distinctiveness.

Include natural synonyms users would actually say — 'run the implementation', 'resume the task', 'phase review', 'quality gate' — to improve trigger-term coverage.

DimensionReasoningScore

Specificity

The description names the domain ("Implement a task step by step") and two concrete actions ("automated LLM-as-Judge verification at the end of each phase"), but omits the skill's other capabilities such as per-step agent dispatch, phase-level review gates, Definition-of-Done verification, and the --continue/--refine modes. This matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) rather than anchor 4's 'several specific actions'.

3 / 5

Completeness

The 'what' is clear (step-by-step implementation with automated LLM-as-Judge verification per phase), but there is no 'Use when...' clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3. It is not anchor 2 because the 'what' is concrete, and not anchor 4 because 'when' is entirely absent rather than merely implicit.

3 / 5

Trigger Term Quality

Some relevant natural keywords are present ("implement a task", "step by step", "verification", "phase"), but common variations and synonyms are missing — nothing about continuing an interrupted task, re-verifying changes, task files, or the .specs workflow. Fits anchor 3 ('some relevant keywords but missing common variations'), not anchor 4's 'good keyword coverage'.

3 / 5

Distinctiveness Conflict Risk

"Implement a task step by step" is broad and overlaps with generic implementation/orchestration skills, though "automated LLM-as-Judge verification at the end of each phase" carves out a moderately specific niche. Somewhat specific but still able to collide with similar development-workflow skills — anchor 3.

3 / 5

Total

12

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (1685 lines); consider splitting into references/ and linking

Warning

Total

15

/

16

Passed

Repository

NeoLabHQ/context-engineering-kit

Path

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