CtrlK
BlogDocsLog inGet started
Tessl Logo

comet-open

仅在用户明确调用 /comet-open,或由 Comet 根 Skill/runtime 路由到 open 阶段时使用;创建或恢复 OpenSpec change,并补齐 proposal/design/tasks/.comet.yaml。

59

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 ./assets/skills-zh/comet-open/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

77%

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 strongly actionable, well-sequenced workflow with concrete commands, JSON field handling, and explicit validation checkpoints throughout. Its main weaknesses are repetitive blocking-point language that bloats token use and the absence of actual bundle reference files, with a large inline split-precheck section that could be externalized.

Suggestions

Consolidate the repeated blocking-point protocol into a single shared callout (e.g., a '## Blocking decision points' section) referenced from 1a/1b/1c/5 instead of restating it verbatim each time.

Move the detailed PRD split-precheck rules (1a) into a reference file under references/ and link to it from the body, reducing inline length and improving progressive disclosure.

Add the actual referenced files (decision-point.md, scripts.md, auto-transition.md) to a references/ bundle so the signaled links resolve to real content.

DimensionReasoningScore

Conciseness

The body is procedural and avoids explaining concepts Claude already knows, but the blocking-point protocol language ('必须按 comet/reference/decision-point.md 的协议暂停并等待用户...') is restated near-verbatim across 1a/1b/1c/5 and the PRD split-precheck is elaborated at length, so it could be tightened.

2 / 3

Actionability

It gives fully executable commands with exact flags (openspec status/instructions, node "$COMET_STATE" init/check/next, node "$COMET_GUARD" ... --apply), an exact artifact file tree, and field-level JSON handling (dependencies/template/instruction/context/rules/resolvedOutputPath), making it copy-paste ready.

3 / 3

Workflow Clarity

Steps are clearly sequenced (0→1→1a→1b→1c→2→3→4→5→exit→auto-transition) with explicit validation checkpoints at every blocking point, status refreshes after each artifact, entry-state verification, file-existence checks, idempotency rules, and a guard-based exit gate with feedback loops on failure.

3 / 3

Progressive Disclosure

External paths (comet/reference/decision-point.md, scripts.md, auto-transition.md) are clearly signaled and one level deep, but no bundle files actually exist under references/scripts/assets, and the lengthy inline PRD split-precheck (1a) is content that could be externalized into a reference.

2 / 3

Total

10

/

12

Passed

Description

57%

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 clear explicit 'Use when' trigger and a highly distinctive niche, but the stated capabilities are only implied and the trigger terms are narrow domain jargon rather than broad natural variations. Strengthening it by adding explicit capability verbs and a few common natural-language variations would raise specificity and trigger quality.

Suggestions

Add an explicit 'what this does' clause naming concrete actions (e.g., creates the change skeleton, initializes .comet.yaml, drafts proposal/design/tasks) so both what and when are clearly answered.

Broaden trigger terms beyond Comet jargon with natural-language variations a user might actually say (e.g., 'start a new spec', 'set up a change', 'missing change artifacts').

Lead with the primary capability before the 'Use when' clause so the description reads as action-first third person.

DimensionReasoningScore

Specificity

Names the concrete domain (OpenSpec/Comet) and specific artifacts (proposal/design/tasks/.comet.yaml) but does not list multiple distinct concrete actions like extract/fill/merge, so it stops at 'names domain and some actions'.

2 / 3

Completeness

The 'when' is explicit and strong ('Use when Comet 需要...或 active change 缺少...'), but the 'what this does' is only implied through the trigger rather than stated as a clear capability, so it does not clearly answer both what AND when.

2 / 3

Trigger Term Quality

It opens with an explicit 'Use when' clause and uses terms a Comet user would say ('创建新的 OpenSpec change', 'active change 缺少...产物'), but the keywords are bound to Comet/OpenSpec jargon and lack common natural variations, matching 'some relevant keywords but missing common variations'.

2 / 3

Distinctiveness Conflict Risk

The trigger names Comet, OpenSpec change, and specific artifacts (.comet.yaml, proposal/design/tasks), forming a clear niche with distinct triggers that is unlikely to conflict with other skills.

3 / 3

Total

9

/

12

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.

Validation16 / 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.