Name: openspec-archive-change
Rating: 62.4 (1 reviews)
Author: Draculabo

openspec-archive-change

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Quality

72%

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

The canonical home for this skill is openspec-archive-change in Draculabo/AntigravityManager

Quality

Content

75%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 body is an efficient, actionable playbook: concrete CLI commands, explicit confirmation checkpoints before the destructive move, and a clean summary template. Remaining gaps are duplicated guardrail text, undefined delta-spec comparison mechanics, and unhandled edge-failure paths.

Suggestions

Trim Guardrails entries that restate steps 1 and 4, keeping only the new facts (e.g., '.openspec.yaml' preservation and using artifact-graph status).

Make step 4 concrete: specify how to diff delta specs against openspec/specs/<capability>/spec.md (e.g., what to grep or compare) or point to the exact section/command in openspec-sync-specs that performs it.

Add edge-case handling: what to do when 'openspec list --json' shows no active changes, when the change directory doesn't exist before 'mv', and how to verify the archive succeeded after the move.

Dimension	Reasoning	Score
Conciseness	The body is command-first and free of concepts Claude already knows, with every step carrying operational detail. The Guardrails section partially reiterates steps 1 and 4 ('Always prompt for change selection if not provided', 'If delta specs exist, always run the sync assessment...'), which could be trimmed.	4 / 5
Actionability	Most steps give copy-ready commands ('openspec list --json', 'openspec status --change "<name>" --json', 'mkdir -p openspec/changes/archive', the dated 'mv'), plus a concrete output template. Step 4's delta-spec comparison and the sync handoff ('use the openspec-sync-specs skill') lack executable mechanics, keeping it below anchor 5.	4 / 5
Workflow Clarity	A clearly sequenced 6-step workflow with real validation checkpoints: artifact status, task counts, sync assessment, a target-exists check before the destructive 'mv', and AskUserQuestion confirmations, so the destructive-operation cap at 3 does not apply. It misses anchor 5 because edge-failure paths (no active changes, change directory missing, failed move) and a fix-and-retry loop are not addressed.	4 / 5
Progressive Disclosure	A single well-organized file with clear section headers and a one-level, clearly-named reference to the openspec-sync-specs skill; no bundle files exist to split further. The delegated sync skill is referenced by name only without signaling what it covers, a minor organization gap versus anchor 5.	4 / 5
	Total	16 / 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 concise, third-person, and correctly pairs a clear capability statement with an explicit 'Use when...' clause. Its main weaknesses are thin action coverage and a when-clause that mirrors the what rather than enumerating distinct trigger phrases.

Suggestions

Expand the what-clause with 2-3 concrete sub-actions, e.g., 'Checks artifact and task completion, syncs delta specs, and moves the change to a dated archive directory.'

Broaden the when-clause with trigger variations users would actually say, such as 'Use when the user says a change is done, wants to close out or finalize a change, or asks to archive a completed openspec change.'

Dimension	Reasoning	Score
Specificity	"Archive a completed change in the experimental workflow" names the domain and exactly one concrete action, with no mention of the sub-capabilities (status checks, spec syncing, dated archiving). It is more concrete than anchor 2's generic actions but far less comprehensive than anchor 4's list of several specific actions.	3 / 5
Completeness	Both the what ("Archive a completed change in the experimental workflow") and an explicit "Use when the user wants to finalize and archive a change after implementation is complete" clause are present. The when-clause largely restates the action rather than supplying multiple concrete trigger contexts, so it does not reach anchor 5.	4 / 5
Trigger Term Quality	Natural trigger phrases like "archive a change", "finalize", and "after implementation is complete" would be said by users needing this skill. Coverage falls short of anchor 5 because common synonyms ("close out a change", "done with a change", "openspec") are absent.	4 / 5
Distinctiveness Conflict Risk	"experimental workflow" change archiving is a clearly-scoped niche with distinct triggers. There is minor overlap risk with closely related openspec skills (e.g., openspec-sync-specs), keeping it below anchor 5.	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: Draculabo/AntigravityManager
Path: .codex/skills/openspec-archive-change/SKILL.md
Commit: ccea788

Reviewed: 13 hours 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.