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

[github-actions]

Compatibility gap addressed

The claude-workflow-conversion.md reference described how to port args, phase, log, parallel, pipeline, and call into a workflow({ body }), but never explained how to do a minimal first-step port for flat Claude dynamic workflow scripts — those whose orchestration code runs at the module top-level using injected globals (call, pipeline, parallel) rather than inside a body function.

A developer porting such a script had no clear path to rig/globals, which provides exactly those ambient proxies.

Why this improves transfer from Claude dynamic workflows to rig

Claude dynamic workflows inject call/pipeline/parallel as globals. The equivalent in rig is rig/globals, but it was only mentioned in dynamic-workflows.md and SKILL.md — not in the conversion reference a migrating developer would consult first.

This PR:

1. Updates claude-workflow-conversion.md to document rig/globals as the minimal migration path for flat scripts — with a short inline example showing the pattern — and notes that body destructuring is preferred for new programs.

2. Adds sample 340-flat-workflow-port.md showing a side-by-side Claude flat workflow → rig minimal port, with an explicit "Step 2" pointer to the fully idiomatic body form (310-workflow-audit-verify.md). This closes the missing two-step migration sample.

3. Adds the new sample to the Example programs table in the conversion reference so it's discoverable alongside the other ports.

Files changed

• skills/rig/references/claude-workflow-conversion.md — added rig/globals section with inline example; added 340 to the example programs table
• skills/rig/samples/340-flat-workflow-port.md — new sample showing flat Claude-style port via rig/globals with pointer to idiomatic form

Validation run

npm run sample -- --testNamePattern="skill markdown samples typecheck"

All 464 tests passed (1 typecheck test run, 463 skipped).

Remaining intentional differences

None introduced. The behavior differences table in claude-workflow-conversion.md is unchanged.

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

[github-actions]

🧠 Matt Pocock Skills Reviewer has completed the skills-based review. ✅

[github-actions]

Skills-Based Review 🧠

Applied /grill-with-docs — two minor suggestions, no blocking issues.

📋 Key Themes & Highlights

Key Themes

• Discoverability: The rig/globals path is introduced in prose below the primitive mapping table. Developers consulting the table for call/pipeline/parallel will find only the body-destructured rig equivalents, with no in-table pointer to the flat-script path.
• Implicit body pattern: Both the inline example and sample 340 use body: async () => preComputedValue without comment. This is correct but non-obvious — the closured value was computed at module load time inside the active run.

Positive Highlights

• ✅ The two-step migration narrative (flat rig/globals → idiomatic body) is exactly the right pattern and clearly communicated
• ✅ Explicit "Step 2" pointer to 310 in sample 340 prevents dead-ends
• ✅ Sample numbering (340) is consistent with neighboring workflow-port samples
• ✅ All 464 tests passing as reported

🧠 Reviewed using Matt Pocock's skills by Matt Pocock Skills Reviewer · sonnet46 35.3 AIC · ⌖ 2.62 AIC · ⊞ 6.3K
_{Comment /matt to run again}

Comments that could not be inline-anchored

skills/rig/references/claude-workflow-conversion.md:21

[/grill-with-docs] The new section is placed between the "Globals" paragraph and "Schema conversion", which makes it hard to discover when following the primitive mapping table — a developer consulting the table for call/pipeline/parallel will find the rig equivalents pointing to body-destructured forms only, with no hint that a flat-script path exists. Consider adding a row to the mapping table (e.g. injected call/pipeline/parallelat top level | import from"rig/globals"``…

skills/rig/samples/340-flat-workflow-port.md:50

[/grill-with-docs] body: async () => verdicts.filter(...).length returns a pre-computed closure value — the real work happened at top-level before workflow() was declared. Without a comment, a reader might ask: why

skills/rig/samples/340-flat-workflow-port.md:50

[/grill-with-docs] body: async () => verdicts.filter(...).length returns a pre-computed closure value — the real work happened at top-level before workflow() was called. A reader might ask: "why is body async if it does nothing async?" A brief inline comment would make the flat-port pattern explicit.

<details>
<summary>💡 Suggested micro-annotation</summary>

  // body returns the pre-computed top-level result (flat-port pattern; Step 2 moves this inside body)
  body: async () …

</details>