CtrlK
BlogDocsLog inGet started
Tessl Logo

comet-tweak

Use when 用户要进行可收敛为单一 OpenSpec change 的轻量或中等变更,且不需要完整设计;也用于恢复 tweak workflow。

54

Quality

60%

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 ./eval/local/skills/benchmarks/040-beta/comet-tweak/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

66%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 well-structured, actionable preset workflow with explicit sequencing, stage guards, and user decision checkpoints, supported by clear one-level reference paths; its main weakness is repeated escalation/delta-spec guidance that inflates token usage without adding clarity.

Suggestions

Consolidate the escalation/upgrade判定 rules into the single '升级判定' section and have other phases reference it once, removing the repeated delta-spec disclaimers from the open and build steps.

Inline the few critical auto-transition/NEXT commands or move them fully to the reference file so the body does not straddle both; pick one home for each instruction.

Specify the on-verify-failure feedback loop in brief (what '验证失败决策' concretely means) rather than only delegating to comet-verify, since batch/CI-affecting changes warrant an explicit retry path.

DimensionReasoningScore

Conciseness

The body is mostly efficient task-oriented prose with executable commands, but it repeats the same escalation/upgrade guidance and the delta-spec disclaimer several times across '升级判定', the build phase, and the IMPORTANT blocks, which is padded relative to a leaner treatment — matching 'mostly efficient but includes some unnecessary explanation or could be tightened'.

3 / 5

Actionability

It gives concrete, executable commands (node "$COMET_STATE" init/check/set/transition, node "$COMET_GUARD" ... --apply, openspec status/instructions apply --json) and names exact skills to load, with only minor gaps such as placeholder <name>/<change-name> and reliance on sibling skills for full detail — fitting 'mostly executable guidance; concrete code or commands with minor gaps'.

4 / 5

Workflow Clarity

The four phases (open→build→verify→archive) are clearly sequenced with explicit stage-guard checkpoints, validation requirements (tests/format/commit per task), and pause points for user decisions; it falls just short of a 5 because some feedback loops (e.g., what to do on a verify failure) are delegated to sibling skills rather than fully specified, matching 'clear sequence with most checkpoints present; minor validation gaps'.

4 / 5

Progressive Disclosure

The SKILL.md is an overview that signals one-level-deep references via the comet/reference/*.md paths (scripts.md, context-recovery.md, dirty-worktree.md, debug-gate.md, decision-point.md, auto-transition.md) and delegates detail to sibling skills, with only minor organization gaps such as inline repetition that could live in referenced files — fitting 'good structure; most content is appropriately placed; references mostly clear'.

4 / 5

Total

15

/

20

Passed

Description

55%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 provides a clear Use-when trigger and a serviceable niche definition, but its language is heavy on internal Comet/OpenSpec jargon rather than natural user terms and lacks concrete enumerated actions, capping both specificity and trigger-term quality.

Suggestions

Lead the description with concrete user-facing actions (e.g., '调整配置、优化 prompt、文档小改、驱动含 delta spec 的中等变更') rather than the abstract '进行...变更'.

Add natural-language trigger phrases users would actually say (e.g., 'Use when the user wants a quick OpenSpec change without a full design doc') alongside the jargon.

Keep the 'Use when' trigger but rephrase the 'when' half so it does not depend solely on internal terms like 'tweak workflow' and '完整设计' that a user may never utter.

DimensionReasoningScore

Specificity

The description names the domain (OpenSpec change / tweak workflow) and one concrete action scope ('轻量或中等变更'), but the actions themselves are abstract ('进行变更' / '恢复 workflow') with no enumerated concrete capabilities, matching the 'Names domain and 1-2 concrete actions but not comprehensive' anchor.

3 / 5

Completeness

It has an explicit 'Use when' clause answering when to trigger and a rough 'what' (light/medium changes收敛为单一 OpenSpec change, plus restoring the tweak workflow), so both what and when are present, though the 'when' relies on jargon and could be more concrete — fitting 'has both what and when; when could be more explicit or specific'.

4 / 5

Trigger Term Quality

Trigger language is almost entirely internal jargon ('OpenSpec change', 'tweak workflow', '完整设计') rather than natural phrases a user would say; only the generic '轻量或中等变更' hints at a user-side term, aligning with 'one or two generic keywords; missing the natural phrases users say'.

2 / 5

Distinctiveness Conflict Risk

The scope ('单一 OpenSpec change', '不需要完整设计', '恢复 tweak workflow') carves a clear niche distinct from a full /comet flow, with only minor overlap risk against sibling Comet skills, matching 'mostly distinct; minor overlap risk with closely related skills'.

4 / 5

Total

13

/

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
rpamis/comet
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.