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

80%

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 ./skills/openspec-new-change/SKILL.md

Quality

Content

85%

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, highly actionable instruction skill with concrete commands, a clear sequenced workflow, explicit stop points, and useful guardrails. The only notable weakness is verbosity in the Store selection paragraph, which could be condensed.

Suggestions

Tighten the Store selection paragraph by deferring the full command-flag enumeration to a short list or a reference note, keeping only the core '--store <id>' guidance inline.

Consider moving the detailed store-discovery behavior into a reference file so the main flow stays leaner, once bundle files are supported.

Dimension	Reasoning	Score
Conciseness	The body is mostly lean and free of concept explanations Claude already knows, but the dense "Store selection" paragraph enumerating every command that takes --store is verbose and could be tightened, matching 'mostly efficient but includes some unnecessary explanation or could be tightened' rather than the every-token-earns-its-place level-3 anchor.	2 / 3
Actionability	It provides fully executable, copy-paste-ready commands with concrete arguments (e.g., `openspec new change "<name>"`, `openspec status --change "<name>" --json`) plus a worked naming example, matching the 'fully executable code/commands; specific examples; copy-paste ready' anchor.	3 / 3
Workflow Clarity	A clearly numbered 6-step sequence with explicit STOP gates and guardrails for error cases (invalid name, existing change, do-not-advance) provides the validation checkpoints and feedback the level-3 anchor expects; the skill is non-destructive so no validate->fix->retry loop is required.	3 / 3
Progressive Disclosure	The skill is self-contained with no bundle files and is organized into clearly labeled sections (Store selection, Input, Steps, Output, Guardrails) with no nested or broken references, satisfying the simple-skill allowance for well-organized single-file content.	3 / 3
	Total	11 / 12 Passed

Description

75%

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 clearly communicates what the skill does and when to use it, with an explicit trigger clause and a distinct OpenSpec-specific niche. Its main weakness is a single core action and jargon-heavy domain terms that limit specificity and natural trigger breadth.

Suggestions

Add one or two more concrete actions the skill performs (e.g., scaffolds the change directory, shows artifact status and next-step instructions) to lift specificity toward level 3.

Soften jargon in the trigger clause with more natural user phrasing or synonyms a non-expert would say when starting a structured spec-driven change.

Dimension	Reasoning	Score
Specificity	It names the domain and one core action ("Start a new OpenSpec change using the experimental artifact workflow") but does not enumerate multiple distinct concrete actions, matching the 'names domain and some actions, but not comprehensive' anchor rather than the multi-action level-3 example.	2 / 3
Completeness	It explicitly states 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 with a structured step-by-step approach"), matching the anchor that clearly answers both with an explicit 'Use when...' trigger.	3 / 3
Trigger Term Quality	The trigger clause offers natural phrasing ("create a new feature, fix, or modification"), but the core concept "OpenSpec change" / "experimental artifact workflow" is technical jargon and the set of natural trigger terms is narrow, so it lands at 'some relevant keywords but missing common variations' rather than full coverage.	2 / 3
Distinctiveness Conflict Risk	The description is anchored to a specific tool niche ("OpenSpec change", "artifact workflow", openspec CLI), giving it distinct triggers unlikely to fire for unrelated skills, matching the 'clear niche with distinct triggers; unlikely to conflict' anchor.	3 / 3
	Total	10 / 12 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: Fission-AI/OpenSpec
Path: skills/openspec-new-change/SKILL.md
Commit: 6a5171e

Reviewed: 5 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.