skills/output-contract-enforcer/SKILL.md
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 skillsauth add curiositech/windags-skills output-contract-enforcerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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.
This skill produces:
tools
Building resilient distributed systems with circuit breakers, retries with full-jitter exponential backoff, retry budgets (per-request 3-attempt + per-client 10% ratio per Google SRE), deadline propagation, and the cascading-failure math (4 layers × 3 retries = 64x amplification). Grounded in Resilience4j, Microsoft Cloud Patterns, AWS Architecture Blog (Marc Brooker), and Google SRE Book.
testing
Designing HTTP cache headers that work correctly across browsers, CDNs, and shared proxies — `Cache-Control` directives per RFC 9111, `stale-while-revalidate` and `stale-if-error` per RFC 5861, the Vary header for varying responses, and surrogate keys for tag-based purging. Grounded in IETF RFCs and Cloudflare/Fastly docs.
development
Use when designing or fixing a Content Security Policy on a real site, choosing between nonce-based and hash-based CSP, adding strict-dynamic, debugging "Refused to execute inline script" errors, deploying CSP in report-only mode first, configuring report-to / report-uri, or auditing an existing policy for unsafe-inline / unsafe-eval / wildcards. Triggers: "CSP blocks legitimate inline script", strict-dynamic, nonce-{RANDOM}, sha256-{HASH}, object-src none, base-uri none, frame-ancestors, Trusted Types, X-Content-Security-Policy obsolete, report-only vs enforced. NOT for general HTTP security headers (HSTS, COOP/COEP), Trusted Types deep dive, CORS configuration, or building a WAF.
tools
Choosing and operating an HTTP API versioning strategy that doesn't break clients — Stripe's date-based pinned versions, the Deprecation/Sunset header pair (RFC 9745 + RFC 8594), URI vs header vs media-type approaches, and the version-transformer pattern. Grounded in Stripe's published architecture and IETF RFCs.