042-planning-openspec

Use when creating or updating OpenSpec change artifacts from an issue, implementation plan, approved design, ADRs, existing OpenSpec artifacts, or a valid combination. The workflow assesses whether the scope is one change or multiple changes, records sources and derivation direction, and prevents silent synchronization. This should trigger for requests such as Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes. Part of Plinth Toolkit

Quality

88%

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

Quality

Content

77%

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

The body offers a clear, well-gated workflow and clean progressive disclosure via one real reference file, but artifact-creation steps are abstract rather than executable and the 'What is covered' list partly duplicates later sections.

Suggestions

Replace the abstract step 4 ('Create or update proposal, design, specification deltas, and tasks') with the concrete OpenSpec commands or file paths a user would actually run.

Trim or merge the 'What is covered in this Skill?' bullet list, which largely restates the Constraints and Workflow sections.

Add a one-line example of an accepted input (e.g., an issue title and its sanitized summary) so the authority-recording step is unambiguous.

Dimension	Reasoning	Score
Conciseness	The body is reasonably lean and mostly avoids explaining concepts Claude already knows, but the 'What is covered' bullet list largely restates the constraints and workflow that follow, adding token weight without new information.	2 / 3
Actionability	Concrete commands appear ('openspec --version', 'openspec init', 'openspec validate --all') but the artifact-creation steps stay abstract ('Create or update proposal, design, specification deltas, and tasks') without showing the actual commands or file layouts a user would run.	2 / 3
Workflow Clarity	A six-step workflow is clearly sequenced with explicit validation checkpoints ('Run openspec --version' upfront, 'Run openspec validate --all' to close) and approval gates for change maps and archival.	3 / 3
Progressive Disclosure	The body is a concise overview with a single one-level-deep, clearly signaled reference (references/042-planning-openspec.md, verified present in references/), and sections are well-organized for navigation.	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.

The description is concrete, uses natural trigger phrases, covers both what and when explicitly, and occupies a distinct niche. It is third-person throughout and free of vague fluff.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions and artifact types—'creating or updating OpenSpec change artifacts from an issue, implementation plan, approved design, ADRs, existing OpenSpec artifacts'—and enumerates specific trigger requests.	3 / 3
Completeness	Explicitly answers what ('creating or updating OpenSpec change artifacts') and when ('This should trigger for requests such as...'), with a clear 'Use when' clause plus worked examples.	3 / 3
Trigger Term Quality	Natural user phrasings are quoted verbatim ('Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes'), matching how users actually phrase these requests.	3 / 3
Distinctiveness Conflict Risk	Scoped to a clear niche (OpenSpec change artifacts from authoritative inputs) with distinctive triggers unlikely to collide with generic planning or doc skills.	3 / 3
	Total	12 / 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: jabrena/plinth
Path: skills/042-planning-openspec/SKILL.md
Commit: a8e5189

Reviewed: about 23 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.