CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

openspec-apply-change

Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.

Quality

72%

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 ./.zcode/skills/openspec-apply-change/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

68%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 is highly actionable and clearly sequenced, with concrete CLI commands, JSON field contracts, and output templates covering every end state. Its weaknesses are redundancy between the steps and guardrails sections and the absence of validation checkpoints in the batch task-implementation loop.

Suggestions

Add a verification checkpoint inside the task loop, e.g., after implementing each task, run tests or `openspec status --change "<name>" --json` to confirm progress before marking `- [x]`.

Deduplicate the context/operationGuidance handling: state the contract once in step 3 and reduce the three repeating guardrail bullets to a single cross-reference.

Move the three output templates into a referenced file (e.g., references/output-templates.md) to shrink the always-loaded body.

DimensionReasoningScore

Conciseness

The body is operational rather than padded, but repeats itself: the context/operationGuidance contract is explained at length in step 3 and restated as three guardrail bullets, pause conditions appear in both step 6 and the guardrails, and "keep changes minimal" is duplicated — it could be tightened.

3 / 5

Actionability

Guidance is fully executable: copy-paste-ready commands with flags (`openspec status --change "<name>" --json`, `openspec instructions apply --change "<name>" --json`), concrete JSON fields to parse (schemaName, contextFiles, state), exact checkbox syntax `- [ ]` → `- [x]`, and complete output templates for every end state.

5 / 5

Workflow Clarity

Steps 1-7 are clearly sequenced with state handling (blocked/all_done) and pause conditions, but the task loop is a batch operation with no per-task validation checkpoint — no verification that an implementation works (tests, re-running status, `openspec validate`) before marking a task complete — so it sits at the sequence-present-but-checkpoints-missing anchor.

3 / 5

Progressive Disclosure

A single ~186-line file with well-labeled sections (store selection, steps, three output templates, guardrails, fluid workflow) that is easy to navigate, but everything is inline with no reference split — the output templates and guardrail material could live in separate files — leaving minor organization gaps.

4 / 5

Total

15

/

20

Passed

Description

62%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 concise, third-person, and correctly structured with a what plus an explicit Use-when clause, but it undersells the skill's capabilities and misses key trigger synonyms (especially "apply"). It is functional yet sits noticeably below the exemplar descriptions in both specificity and trigger coverage.

Suggestions

Enumerate the concrete actions in the what-clause, e.g., "Implement tasks from an OpenSpec change: check status, read context artifacts, apply code changes, and mark tasks complete."

Add "apply" and "execute" as trigger synonyms, e.g., "Use when the user wants to apply, start implementing, or continue implementing an OpenSpec change."

Mention OpenSpec changes inside the when-clause so the triggers are domain-anchored and cannot fire on generic task work.

DimensionReasoningScore

Specificity

"Implement tasks from an OpenSpec change" names the domain and a single concrete action but does not enumerate the several specific actions the skill performs (check status, read artifacts, mark tasks complete, suggest archive), matching the 1-2-concrete-actions anchor rather than the several-actions anchor.

3 / 5

Completeness

It has a clear what ("Implement tasks from an OpenSpec change") and an explicit "Use when..." clause, but the when could be more specific — the trigger phrases never mention OpenSpec changes themselves, so it stops short of the fully concrete-trigger anchor.

4 / 5

Trigger Term Quality

The trigger phrases "start implementing, continue implementation, or work through tasks" are natural but omit common variations users would say, most notably "apply"/"apply the change" (the skill's own name) and "execute tasks", fitting the anchor for some relevant keywords with missing variations.

3 / 5

Distinctiveness Conflict Risk

"OpenSpec change" establishes a clear niche with minimal conflict risk, but the bare trigger "work through tasks" is generic enough to overlap with general task-execution skills, leaving minor overlap risk rather than the minimal-risk anchor.

4 / 5

Total

14

/

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

partme-ai/full-stack-skills

Path

.zcode/skills/openspec-apply-change/SKILL.md

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.