CtrlK
BlogDocsLog inGet started
Tessl Logo

openspec-update-change

Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.

70

Quality

86%

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

SKILL.md
Quality
Evals
Security

Quality

Content

72%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-structured workflow body with concrete commands and exact JSON field guidance. Its main costs are repetitive Guardrails restating the Steps and the absence of a post-write validation loop for multi-artifact edits.

Suggestions

Collapse the Guardrails section into only the rules not already stated in the Steps (e.g. drop the repeated "NEVER edit code", "confirm every edit", and "existingOutputPaths vs glob" lines) to remove the conciseness redundancy.

Add an explicit post-write verification step — e.g. re-run `openspec status --change "<name>" --json` or `openspec validate` after edits — to close the feedback loop for batch artifact revisions.

Consider moving the "Store selection" paragraph and the sibling-skill pointer map (step 6 + the core-profile fallback) into a short reference section or bundled file to keep the main workflow sequence leaner.

DimensionReasoningScore

Conciseness

The body is mostly efficient and assumes Claude's competence, but the Guardrails section largely re-states rules already in the Steps ("NEVER edit implementation code", "no new artifacts", "confirm every edit", "never branch on hardcoded artifact names", "existingOutputPaths" vs glob) — a tighten-able redundancy.

2 / 3

Actionability

Provides copy-paste-ready commands (openspec list/status/instructions/store with --json), names the exact JSON fields to read (schemaName, artifacts, isComplete, existingOutputPaths), and specifies which paths to edit vs. avoid — fully executable guidance.

3 / 3

Workflow Clarity

Six clearly sequenced steps with confirm-before-write checkpoints and rejection handling, but for batch edits across multiple artifacts there is no post-write verification/re-validation step (e.g. re-running openspec validate), which caps clarity per the destructive/batch feedback-loop guidance.

2 / 3

Progressive Disclosure

Well-organized into labeled sections (Store selection, Input, Steps, Output, Guardrails) with one-level-deep, clearly signaled cross-references to sibling skills and CLI commands; no nested references and no monolithic reference wall, appropriate for a self-contained workflow skill with no bundle files.

3 / 3

Total

10

/

12

Passed

Description

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description that states concrete capabilities, gives an explicit Use-when trigger with natural phrasings, and draws a clear boundary against code-editing and sibling skills. No fluff or over-claims.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — "revising its existing planning artifacts", "keeping them coherent", "fold new decisions into it", "reconcile its artifacts after an edit", and the "Never edits code" boundary — matching the multiple-specific-actions anchor.

3 / 3

Completeness

Explicitly answers both what ("Update an OpenSpec change by revising its existing planning artifacts...") and when ("Use when the user wants to revise a change's plan..."), with an explicit Use-when trigger clause.

3 / 3

Trigger Term Quality

Natural user phrasings are covered ("revise a change's plan", "fold new decisions into it", "reconcile its artifacts after an edit"); these are the terms an OpenSpec user would actually say, with no overly generic jargon.

3 / 3

Distinctiveness Conflict Risk

Occupies a clear niche (revising existing OpenSpec planning artifacts) distinguished from sibling skills, and the "Never edits code" boundary plus reconcile-vs-create framing make triggering for the wrong skill unlikely.

3 / 3

Total

12

/

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
Fission-AI/OpenSpec
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.