openspec-quick-path

name	openspec-quick-path
description	Use when working with OpenSpec in Hermes: run the recommended default OpenSpec flow end to end from idea to verified implementation, with optional archive.
version	1.0.0
author	TheSmuks + Hermes Agent
license	MIT
platforms	["windows","macos","linux"]
metadata	{"hermes":{"category":"software-development","tags":["openspec","sdd","spec-driven-development","hermes","workflow"],"homepage":"https://github.com/Fission-AI/openspec"}}

openspec-quick-path

This is the single-skill version of OpenSpec's recommended default path. Use it when the user wants Hermes to handle the full normal OpenSpec flow instead of manually invoking propose, apply, verify, and optionally archive.

Flow: propose -> apply -> verify -> archive when safe or requested

Ground rules

• Work from the user's project root. If unknown, inspect the current directory first.
• Ensure OpenSpec exists with openspec --version. If missing, install it with npm install -g @fission-ai/openspec@latest.
• If openspec/ is missing, initialize with openspec init --tools none.
• Use OpenSpec CLI state as source of truth: openspec list --json, openspec status --change <id> --json, openspec instructions <artifact> --change <id> --json, openspec validate <id>.
• Do not stop at a plan. Create artifacts, implement code, run checks, update task checkboxes, and report real command output.
• Ask only when a real decision changes the work. Otherwise choose the recommended default and proceed.

Procedure

1. Convert the user's request into a focused kebab-case change name.
2. Initialize OpenSpec if needed: openspec init --tools none.
3. Proposal/planning stage:
   • Create or reuse the change with openspec new change <name> --description "..." --json.
   • Repeatedly call openspec status --change <name> --json.
   • For every missing ready artifact, call openspec instructions <artifact> --change <name> --json, read dependencies, and write the artifact.
   • For the default spec-driven schema this means proposal, specs, design, and tasks.
4. Validate planning: openspec validate <name>.
5. Implementation stage:
   • Call openspec instructions apply --change <name> --json.
   • Read proposal, specs, design, and tasks.
   • Implement tasks one by one.
   • Mark each completed task in tasks.md with [x] only after code is changed and exercised.
6. Verification stage:
   • Run project tests/build/lint relevant to the change.
   • Run openspec validate <name>.
   • Search code for evidence that each requirement/scenario is implemented.
7. Archive policy:
   • If the user asked for a complete end-to-end flow, or if all tasks pass verification with no critical issues, run openspec archive <name> --yes.
   • If there are warnings or ambiguity, do not archive silently. Report issues and leave the change active.
8. Finish with a concise summary: artifacts created, code changed, checks run, archive status, and remaining issues.

When to use instead of individual skills

Use this skill for normal feature/bug work where the user wants the recommended path automated. Use individual skills only when the user wants manual review between stages.