| name | rhdh-spec-driven-schema |
| description | Owns RHDH's project-local OpenSpec workflow definition — the `rhdh-spec-driven` schema (proposal -> {specs, design} -> tasks -> apply), its four artifact templates, the Canonical Touchpoints rule that ties a change back to `specifications/prd/`, `specifications/adr/`, and `openspec/specs/<capability>/spec.md`, and the shared artifact-creation-loop mechanics every openspec-* skill drives through the `openspec` CLI. Also installs `config.yaml` and `schemas/rhdh-spec-driven/` into a product repo's `openspec/` so the CLI can resolve that schema. Invoked by name from openspec-new-change, openspec-continue-change, openspec-ff-change, and openspec-onboard; not a standalone entry point. Use for "what does the spec-driven schema require", "install the rhdh-spec-driven schema", "what goes in Canonical Touchpoints", "how do I fill in an artifact template", or "why did an artifact instruction reject my capability name". |
| compatibility | openspec CLI on PATH for --schema rhdh-spec-driven. Python 3 for the install helper. |
RHDH spec-driven schema
Give every openspec-* skill one shared place to read the actual RHDH workflow
definition, instead of each restating the schema's rules from memory.
What this skill owns
config.yaml — the project-local schema selection (rhdh-spec-driven), the
RHDH context block (split canonical model, journal obligation), and the
per-artifact house rules.schemas/rhdh-spec-driven/schema.yaml — the authoritative artifact graph:
proposal -> {specs, design} -> tasks -> apply, each artifact's instruction
text, and the apply block's direct-vs-team mode guidance.schemas/rhdh-spec-driven/templates/{proposal,spec,design,tasks}.md — the
structural template for each artifact.- references/artifact-loop.md — the shared
mechanics for driving
openspec instructions <id> --change <name> --json
and turning its response into a written artifact file.
scripts/install_project_schema.py — copies config.yaml and
schemas/rhdh-spec-driven/ into a product repo's openspec/ so the OpenSpec
CLI can resolve the schema there.
Install into the product repo (startup / setup)
OpenSpec loads schemas from the project's openspec/, not from this skill
directory. Before any openspec new change that should use rhdh-spec-driven,
ensure those files are on disk:
python3 scripts/install_project_schema.py
Run that from the product repo (or pass the project root as the first
argument). The helper lives next to this skill — resolve
scripts/install_project_schema.py relative to this skill's install path, not
under the product repo's scripts/. Use --force only when deliberately
replacing a customized copy.
Callers (/openspec-new-change, /openspec-ff-change, /openspec-onboard,
and /setup-rhdh-skills when seeding a product checkout) check for
openspec/config.yaml and openspec/schemas/rhdh-spec-driven/ first and run
this install step only when either is missing. Idempotent: existing files are
kept unless --force is set.
Writing into the product repo is an external write — take it through
/mutation-gate when the caller is in a setup or multi-operation plan; a
single scaffold turn that already creates openspec/changes/ may include this
copy in the same stated set.
Confirm with openspec schemas --json that rhdh-spec-driven is listed, then
omit --schema to take the configured default (or pass
--schema rhdh-spec-driven explicitly).
Canonical Touchpoints, non-negotiable
Every proposal.md states a Canonical Touchpoints section naming every
affected PRD/ADR file under specifications/ and every affected long-lived
capability spec under openspec/specs/, or explicitly None, plus the change
type: product | architecture | feature-spec | migration | workflow-only |
docs-only. design.md and tasks.md carry that same touchpoint set forward —
see schema.yaml's per-artifact instruction field for the exact wording
each artifact requires. A caller skipping this because "it's a small change"
is exactly the case the rule exists for: state None explicitly rather than
omitting the section.
Journal obligation
config.yaml's context block states the turn-bookending discipline (log
turn.start before work, turn.end after, every prompt, inside an active
change) and the apply-phase event set. The mechanics of writing those events
belong to openspec-journal, invoked by name — this skill states when the
obligation applies; openspec-journal states how to satisfy it.
Completion
Complete when the caller has either installed openspec/config.yaml and
openspec/schemas/rhdh-spec-driven/ into the product repo, or read the exact
schema/template/context text it needed for the artifact in front of it —
rather than guessing at wording. A caller citing this skill without reading
schema.yaml's instruction field for that artifact is the failure mode
this skill exists to prevent.
