_shared

Document shared SDD conventions for Engram and OpenSpec artifact persistence.

2|Updated Jul 29, 2025
One-click install
npx skills add https://github.com/kurojs/EnderDots --skill shared-kurojs
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: _shared
Source: https://github.com/kurojs/EnderDots/tree/main/.config/opencode/skills/_shared
Command: npx skills add https://github.com/kurojs/EnderDots --skill shared-kurojs

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill provides shared reference documentation for SDD (Spec-Driven Development) workflows so phase skills use consistent artifact naming, persistence behavior, and protocol conventions.

Core Features & Use Cases

  • Shared SDD conventions: Documents standardized artifact naming and storage expectations for Engram and OpenSpec modes.
  • Pipeline protocol support: Includes common phase and skill-loading protocols used by other skills.
  • Not invokable support module: Clearly marked as a support package to prevent accidental direct execution.

Quick Start

Reference the _shared documentation indirectly by running the real SDD skills (for example, sdd-propose or sdd-spec) that consume these conventions.

Frequently Asked Questions about _shared

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

FAQPage Schema
What is Spec-Driven Development and how do shared artifact conventions work?

Spec-Driven Development uses shared artifact conventions to standardize naming and storage expectations across Engram and OpenSpec modes, ensuring consistent phase execution rules and deterministic workflow behavior.

How do I standardize artifact persistence protocols across multiple SDD workflow skills?

You standardize artifact persistence by referencing shared SDD documentation that defines common phase and skill-loading protocols, ensuring deterministic behavior and naming conventions across all consuming skills.

Can I execute the _shared reference package directly to run SDD pipeline protocols?

No, the _shared reference package explicitly disables direct invocation to prevent misuse. It supplies required conventions that are consumed indirectly by running actual SDD skills like sdd-propose or sdd-spec.

When do I need shared reference documentation for Engram or OpenSpec workflows?

You need shared reference documentation when your Spec-Driven Development workflows require deterministic Engram or OpenSpec behavior, standardized artifact naming, and consistent phase execution rules across multiple skills.

Why does my SDD skill fail to maintain workflow consistency across different phases?

SDD skills lose workflow consistency without shared reference documentation defining artifact conventions and pipeline protocols. Applying shared conventions ensures deterministic phase execution and standardized storage behavior.