Validates that a DAG node's output matches its declared JSON schema before passing to downstream nodes. The glue that makes multi-agent DAGs reliable. Use when checking output contract compliance, generating validation schemas from descriptions, or debugging contract mismatches between nodes. Activate on "validate output", "output contract", "schema validation", "contract mismatch", "output doesn't match". NOT for content quality assessment (use dag-quality), skill grading (use skill-grader), or general JSON schema work outside DAG context.
npx skills add https://github.com/curiositech/some_claude_skills --skill output-contract-enforcer
Validates that a DAG node's output matches its declared JSON schema before passing to downstream nodes. The glue that makes multi-agent DAGs reliable. Without this, downstream nodes receive unpredictable input and the DAG breaks.
✅ Use for:
❌ NOT for:
dag-quality)skill-grader)flowchart TD
O[Node output] --> P[Parse as JSON]
P -->|Parse error| E1[FAIL: Not valid JSON]
P -->|Valid JSON| S[Check against schema]
S --> R{Required fields?}
R -->|Missing| E2[FAIL: Missing required field X]
R -->|Present| T{Type check?}
T -->|Wrong type| E3[FAIL: Field X expected string, got number]
T -->|Correct| C{Constraints?}
C -->|Violated| E4[FAIL: Field X violates constraint Y]
C -->|Met| V[PASS: Contract satisfied]
| Check | Example | Failure Message |
|-------|---------|----------------|
| JSON parseable | {broken json | "Output is not valid JSON" |
| Required fields | status missing | "Missing required field: status" |
| Field types | status: 42 (expected string) | "Field 'status' expected string, got number" |
| Enum values | status: "maybe" | "Field 'status' must be one of: pass, warn, fail" |
| String constraints | summary: "" (minLength: 1) | "Field 'summary' must have minLength 1" |
| Number constraints | score: 1.5 (maximum: 1.0) | "Field 'score' must be ≤ 1.0" |
| Array constraints | items: [] (minItems: 1) | "Field 'items' must have at least 1 item" |
| Nested objects | Missing sub-field | "Field 'metadata.cost' is required" |
Every DAG node should produce output matching this base schema (fields can be extended):
{
"type": "object",
"required": ["status", "summary"],
"properties": {
"status": {
"type": "string",
"enum": ["pass", "warn", "fail"]
},
"summary": {
"type": "string",
"minLength": 1,
"description": "1-3 sentence description of what was produced"
},
"artifacts": {
"type": "array",
"items": { "type": "string" },
"description": "List of files created or modified"
},
"data": {
"type": "object",
"description": "Node-specific output data (schema varies per node)"
},
"risks": {
"type": "array",
"items": { "type": "string" },
"description": "Remaining risks or assumptions"
}
}
}
When connecting Node A's output to Node B's input, verify:
Node A output: { status: string, recommendations: string[] }
Node B input: { status: string, recommendations: string[], priority: number }
Result: INCOMPATIBLE — Node B requires 'priority' but Node A doesn't produce it.
Fix: Add 'priority' to Node A's output, or add a transformer node between A and B.
When a node description says "produces a list of recommendations with priorities," generate:
{
"type": "object",
"required": ["status", "summary", "data"],
"properties": {
"status": { "type": "string", "enum": ["pass", "warn", "fail"] },
"summary": { "type": "string", "minLength": 1 },
"data": {
"type": "object",
"required": ["recommendations"],
"properties": {
"recommendations": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"required": ["text", "priority"],
"properties": {
"text": { "type": "string" },
"priority": { "type": "integer", "minimum": 1, "maximum": 5 }
}
}
}
}
}
}
}
Wrong: Nodes produce free-form text with no schema.
Why: Downstream nodes can't reliably parse the input. The DAG is fragile.
Right: Every node declares its output schema. Every output is validated before passing downstream.
Wrong: Requiring exact character counts, specific formatting, or field values that depend on runtime context.
Right: Constrain structure (types, required fields), not content. Let dag-quality handle content assessment.
Wrong: Treating all fields as required.
Right: Use required only for fields that downstream nodes absolutely need. Mark everything else as optional.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
Replace with description of the skill and when Claude should use it.
Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Take curiositech/output-contract-enforcer from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.