openspec-integration

Route OpenSpec change requests to spec-driven workflow boundaries.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/meisijiya/ohMeisijiyaCode --skill openspec-integration
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openspec-integration
Source: https://github.com/meisijiya/ohMeisijiyaCode/tree/main/skills/openspec-integration
Command: npx skills add https://github.com/meisijiya/ohMeisijiyaCode --skill openspec-integration

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents confusion between OpenSpec and Superpowers by telling the model when a task should follow spec-driven change workflows versus ordinary brainstorming, planning, review, or branch-finishing flows.

Core Features & Use Cases

  • Two-layer routing: Uses strong keyword triggers and semantic intent checks to decide whether OpenSpec should be used immediately or only suggested to the user.
  • Workflow boundary protection: Preserves the role of Superpowers for daily coding work while reserving OpenSpec for change proposals, apply, sync, and archive operations.
  • Failure-safe guidance: Explains what to do when OpenSpec CLI is missing, the project is not initialized, or a target change is invalid or damaged.
  • Use case: A developer says they want to propose, apply, or archive a change, and this Skill routes the request correctly instead of sending it into the wrong workflow.

Quick Start

Ask the assistant to determine whether your task should use OpenSpec or Superpowers, and let it route the workflow before any implementation begins.

Frequently Asked Questions about openspec-integration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I route spec-driven change requests to the correct workflow?

Spec-driven change requests are routed using two-layer detection: strong keyword triggers and semantic intent checks. This evaluates whether a task requires immediate spec-driven operations like propose, apply, or archive, or if it belongs in general development assistance.

When do I need spec-driven development workflows instead of general coding assistance?

You need spec-driven development workflows for multi-step changes, cross-spec impact analysis, and brownfield change tracking. Workflow boundary protection reserves these operations for formal change proposals, sync, and archive tasks, separating them from daily brainstorming or branch-finishing.

What happens if OpenSpec CLI is missing or my project is not initialized?

Failure-safe guidance provides fallback instructions when OpenSpec CLI is missing, the project is not initialized, or a target change is invalid. It explains the necessary steps to resolve these environmental issues before proceeding with workflow routing.

How does workflow boundary control prevent misclassification of spec-driven tasks?

Workflow boundary control prevents misclassification by applying keyword-trigger detection and semantic intent evaluation. This ensures operations like propose, explore, apply, sync, and archive are strictly isolated from ordinary planning or review flows.

Can I use workflow routing for brownfield change tracking and cross-spec impact?

Yes, workflow routing specifically applies to brownfield change tracking and cross-spec impact analysis. It evaluates the semantic intent of these multi-step changes to ensure they follow the correct spec-driven workflow boundaries.

What is the best way to manage spec-driven operations alongside daily development work?

The best way to manage spec-driven operations alongside daily work is using a two-layer routing system. It preserves general development assistance for routine coding while reserving strict workflow boundaries for formal change proposals, sync, and archive operations.