card-schema

Define and validate deck card frontmatter fields, enums, and relationship invariants.

6|Updated May 4, 2026
One-click install
npx skills add https://github.com/zauberzeug/game-of-cards --skill card-schema
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: card-schema
Source: https://github.com/zauberzeug/game-of-cards/tree/main/openclaw-plugin/skills/card-schema
Command: npx skills add https://github.com/zauberzeug/game-of-cards --skill card-schema

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Card Schema defines the formal contract for deck cards, specifying required and optional frontmatter fields, enums, and invariants to keep card semantics consistent and machine-validateable across the system.

Core Features & Use Cases

  • Canonical frontmatter contract: defines name, description, status, stage, contribution, relationships (advances/advanced_by), tags, and DoD references to ensure reliable triage and closure.
  • Reference-driven authoring: the canonical explanation is centralized in this skill, while individual cards can point to structured artifacts via the card bundle pattern.
  • Validation guidance: provides parsing rules and layout conventions used by goc to validate and navigate the deck.

Quick Start

Create or update a card by following the frontmatter contract and referencing the canonical Card Schema guidance.

Frequently Asked Questions about card-schema

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

FAQPage Schema
How do I define frontmatter contracts for deck cards?

Card Schema defines frontmatter contracts for deck cards by specifying required and optional fields, enums, and invariants. This ensures card semantics remain consistent and machine-validateable across the system.

What frontmatter fields are required for validating card status semantics?

Required frontmatter fields for card status semantics validation include name, description, status, stage, contribution, relationships (advances/advanced_by), tags, and DoD references to ensure reliable triage and closure.

How do edge relations work when defining card relationship invariants?

Edge relations define card relationship invariants through advances and advanced_by fields, establishing directional dependencies that maintain structural integrity and enable accurate deck navigation and validation.

Can I use goc to parse and validate frontmatter layout conventions?

Yes, goc uses the parsing rules and layout conventions provided by Card Schema to validate and navigate the deck, ensuring all cards conform to the canonical frontmatter contract and relationship invariants.

What is the best way to structure card state transitions and DoD references?

Structure card state transitions and DoD references by following the canonical Card Schema guidance, which provides reference architecture for headers, DoD, and status semantics to ensure reliable closure and validation.

Why do my deck cards fail validation when using custom frontmatter fields?

Deck cards fail validation when frontmatter fields do not conform to the canonical Card Schema contract, which enforces specific required fields, enums, and relationship invariants necessary for machine-validateable card semantics.