[rig-claude] Improve Claude dynamic-workflow compatibility for rig

[github-actions]

Compatibility gap addressed

The call.json row in the primitive mapping table stated schema is s.object({ ... }), implying only object schemas are accepted. In practice call.json accepts any s.* value — s.enum, s.array, s.literal, etc. Anyone porting a Claude dynamic workflow that passes a non-object { schema } (e.g. { schema: { type: "string", enum: [...] } }) would incorrectly assume they had to wrap it in an object.

Sample 360-parallel-branch-analysis-workflow.md — which demonstrates exactly this pattern (call.json returning s.enum) alongside named agents and parallel(thunks) — was also missing from the example programs table in claude-workflow-conversion.md, making it undiscoverable.

Why this improves transfer

• Removes a misleading constraint in the most-referenced porting table so readers don't invent unnecessary wrapper objects.
• Surfaces sample 360 in the conversion guide, giving users a concrete starting point for the parallel fan-in + named-agent pattern without scanning the full sample directory.

Files changed

• skills/rig/references/claude-workflow-conversion.md
  • Updated call.json note: "any s.* value (s.object, s.enum, s.array, ...)"
  • Added row for 360-parallel-branch-analysis-workflow.md to the Example programs table

Validation run

npm run sample -- --testNamePattern="skill markdown samples typecheck"
# 1 passed, 462 skipped

Remaining intentional differences

No API changes; the intentional behavior differences documented in the "Behavior differences to keep in mind" section are unchanged.

Generated by Daily Rig Claude Dynamic Workflow Compatibility · sonnet46 49.3 AIC · ⌖ 8.1 AIC · ⊞ 5.4K · ◷