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.

72

Quality

87%

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

82%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.

A well-constructed instruction skill: an explicit, numbered workflow with concrete CLI commands, JSON fields to parse, confirmation gates, and clear guardrails. The main gaps are the absence of an explicit post-edit validation step and some redundancy between the step-5 tasks rules and the Guardrails restatement.

Suggestions

Add a post-edit validation step to the workflow (e.g., run `openspec validate` on the change after revisions are written) so the sequence ends with an explicit verification checkpoint.

Consolidate the tasks.md delta-edit rules into one place — either step 5 or the Guardrails section — and have the other reference it, removing the current duplication.

Consider moving the detailed tasks.md requirement-coverage and file-less-task rules into a one-level-deep reference file (e.g., references/tasks-rules.md) to keep the main workflow lean.

DimensionReasoningScore

Conciseness

The body is dense and directive throughout — commands, JSON field names, and rules with no padding or explanation of concepts Claude already knows — e.g., "The files to edit are `artifactPaths.<id>.existingOutputPaths`". It is not 5 because the tasks.md delta-edit rules appear twice (step 5 and re-summarized in Guardrails) and the store-selection paragraph could be tightened; it is well above 3 since nearly every sentence is operative.

4 / 5

Actionability

Fully executable guidance: concrete commands (`openspec list --json`, `openspec status --change "<name>" --json`, `openspec instructions <artifact-id> --change "<name>" --json`), the exact JSON fields to parse, and a copy-ready example of the tag syntax ("`- [ ] 3.1 [e2e] Run the full test suite and confirm it passes.`"). Common cases (prompt for change selection, coherence-only request, rejected revision) are all explicitly covered.

5 / 5

Workflow Clarity

A clearly sequenced 6-step workflow with a strong confirmation gate ("Show each proposed revision and why. Write only after the user confirms") and an explicit feedback loop ("If the user rejects a revision, do not write it"), plus an early state check via `openspec status`. It falls short of 5 because there is no explicit post-edit validation step (e.g., running `openspec validate` on the revised artifacts); it stays above 3 because user confirmation before each write provides the checkpoint for this non-destructive, artifacts-only operation.

4 / 5

Progressive Disclosure

The body has clear, well-organized sections (Store selection, Steps, Output, Guardrails) with no references to nonexistent files, and everything is needed at execution time — there is no orphaned or buried reference. It is not 5 because the ~35-line tasks.md delta-rules subsection in step 5 is dense inline content that could plausibly live in a one-level-deep reference file, and the skill exceeds the simple <50-line case the rubric exempts.

4 / 5

Total

17

/

20

Passed

Description

92%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.

A strong description: third-person, concise, and explicit about both what it does and when to use it, with concrete trigger phrases and a clean scope boundary. Its only weakness is slightly limited synonym coverage for the trigger verbs.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — "revising its existing planning artifacts", "keeping them coherent with one another", "fold new decisions into it", "reconcile its artifacts after an edit" — plus an explicit scope boundary ("Never edits code"), giving comprehensive coverage of the skill's domain. It is not below 4 because no meaningful capability of the skill is left unnamed; nothing above 5 exists on the scale.

5 / 5

Completeness

Both questions are answered explicitly: what — "Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent"; when — "Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit". The 'when' clause is concrete and multi-trigger, matching the level-5 anchor exactly; a 4 would require the 'when' to be less specific than it is.

5 / 5

Trigger Term Quality

Good natural-language coverage: "revise a change's plan", "fold new decisions into it", "reconcile its artifacts", "update" — phrasings a user would plausibly say. It stays at 4 rather than 5 because a few natural synonyms (e.g., "modify the spec", "change the design") are absent, and it is not 3 since multiple distinct natural trigger phrases are present rather than just a few generic keywords.

4 / 5

Distinctiveness Conflict Risk

"OpenSpec change" and "planning artifacts" carve out a clear niche with distinct triggers, and "Never edits code" further separates it from implementation skills. It is not 4 because the domain term (OpenSpec) means it would essentially never fire for a non-OpenSpec request.

5 / 5

Total

19

/

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
behindthedash/worktrail
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.