openspec-new-change

Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./eval/local/skills/benchmarks/dependency/openspec/openspec-new-change/SKILL.md

Quality

Content

78%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 content delivers fully executable commands in a clearly sequenced workflow with sensible guardrails and a well-organized single-file layout. Its one notable inefficiency is the redundant repetition of the --schema rule, and its workflows lack an explicit failure-path feedback loop.

Suggestions

State the --schema rule once (e.g., only in step 2) and drop the repetitions in step 3 and the Guardrails section to tighten conciseness.

Add a brief failure-path instruction, such as checking the output of "openspec new change" and asking the user how to proceed if the command errors, to complete the feedback loop.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean with concrete commands, but the --schema default rule is repeated four times ("Use a different schema only if the user mentions", "Otherwise: Omit --schema", "Add --schema <name> only if the user requested", "Pass --schema if using a non-default workflow"), which could be tightened to a single statement.	3 / 5
Actionability	Commands are copy-paste ready ("openspec new change \"<name>\"", "openspec status --change \"<name>\"", "openspec instructions <first-artifact-id> --change \"<name>\"") and a concrete name-derivation example ("add user authentication" → add-user-auth) covers the common case.	5 / 5
Workflow Clarity	A clear six-step sequence with an explicit STOP checkpoint and guardrails for error recovery (invalid name, existing change), but there is no guidance for handling command failures (e.g., if "openspec new change" errors).	4 / 5
Progressive Disclosure	A single-file, single-purpose skill with no bundle files; content is well organized into Input, Steps, Output, and Guardrails sections with nothing that belongs in a separate file.	5 / 5
	Total	17 / 20 Passed

Description

70%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 third-person, concise, and answers both what and when with a proper "Use when" clause. Its main weaknesses are limited action coverage (a single core action) and a trigger clause that is broad enough to create overlap risk with general feature-request skills.

Suggestions

Enumerate the concrete capabilities of the skill (e.g., scaffolds the change directory, selects a workflow schema, surfaces the first artifact template) so specificity lists several distinct actions instead of one.

Tie the when-clause to OpenSpec contexts (e.g., "Use when the user wants to start, propose, or scaffold an OpenSpec change or feature") to reduce conflict with general feature/fix requests.

Add natural trigger synonyms users would actually say, such as "bug", "add", or "new change", to broaden keyword coverage.

Dimension	Reasoning	Score
Specificity	"Start a new OpenSpec change" names the domain and one concrete action, with the remainder ("create a new feature, fix, or modification") merely elaborating that same action rather than listing several distinct capabilities.	3 / 5
Completeness	Both "what" ("Start a new OpenSpec change using the experimental artifact workflow") and "when" ("Use when the user wants to create a new feature, fix, or modification") are explicit, but the when-clause is generic and not tied to OpenSpec-specific contexts.	4 / 5
Trigger Term Quality	"create a new feature, fix, or modification" captures natural user phrasing, but common synonyms such as "bug", "add", or "change" are missing.	4 / 5
Distinctiveness Conflict Risk	"OpenSpec change" carves out a clear niche, yet the broad trigger phrase "create a new feature, fix, or modification" could plausibly fire on general development requests unrelated to OpenSpec.	4 / 5
	Total	15 / 20 Passed

Validation

100%

Warnings & errors only

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
Path: eval/local/skills/benchmarks/dependency/openspec/openspec-new-change/SKILL.md
Commit: 899d1fb

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

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.