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

[github-actions]

Compatibility gap addressed

Every Claude dynamic-workflow primitive had a sample demonstrating how to port it to rig — except for the final step: running the ported workflow against Claude using anthropicEngine() and selecting Claude model tiers per-call. This left a discoverable gap for Claude dynamic-workflow users who completed porting but had no concrete example of the last step.

Why this improves transfer from Claude dynamic workflows to Rig

Claude dynamic workflows run on Claude by default; rig requires explicitly selecting an engine. A user completing a port needs to:

1. Call configureAgent(anthropicEngine())
2. Switch from short model aliases ("sonnet", "haiku") to full Claude model IDs ("claude-sonnet-4-5", "claude-haiku-3-5")
3. Override the model per-call for tier selection

The existing conversion doc had a code snippet for this, but no dedicated standalone sample that someone would land on when searching anthropicEngine, claude-sonnet, or ANTHROPIC_API_KEY.

Files changed

• skills/rig/samples/411-anthropic-engine-workflow.md — new sample showing configureAgent(anthropicEngine()) at program top-level, a two-phase workflow (Triage + Plan), per-call model overrides (claude-haiku-3-5 for cheap classification, claude-sonnet-4-5 for fix planning), and a model tier table in the preamble.
• skills/rig/references/claude-workflow-conversion.md — added the new sample to the Example programs table.

Validation

npx vitest run scripts/run-sample.test.ts --testTimeout=120000 --testNamePattern="skill markdown samples typecheck"
# Tests  1 passed | 535 skipped

Remaining intentional differences

• No effort option; model tier selection is explicit (use claude-opus-4-5 over claude-haiku-3-5 when quality matters).
• No agentType: "Explore" — expressed through prompt wording and a narrow tools list.
• No sandbox restrictions, resume journal, or worktree isolation — these are Claude Code runtime features, not API surface.

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

[github-actions]

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

[github-actions]

Skills-Based Review 🧠

Applied /codebase-design — requesting one change on pipeline stage convention.

📋 Key Themes & Highlights

Issue

• Pipeline stage signature mismatch: Both pipeline stage lambdas use (issue: string) => — a single argument — but PipelineStage passes (prev, item, index). For a first-stage this silently works (since prev === item), but it contradicts the documented shape and misleads readers who extend the sample to a second stage. Sample 401 demonstrates the correct form: (_prev: string, issue: string) =>.

Positive Highlights

• ✅ Clean model-tier table and concise preamble — exactly the kind of orientation a porting user needs
• ✅ configureAgent(anthropicEngine()) placement and RIG_ENGINE=anthropic env-var note are both documented
• ✅ Reference table entry in claude-workflow-conversion.md is precise and well-linked
• ✅ Both pipeline stages use label: for progress tracking — good habit

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

[github-actions]

[/codebase-design] The pipeline stage lambdas use (issue: string) => but the PipelineStage contract is (prev, item, index) — for stage 1 prev === item so it works at runtime, but it teaches the wrong convention and breaks the mental model if a second stage is added.

💡 Suggested fix

Match the canonical three-argument form shown in sample 401:

const triaged = await pipeline(input.issues,
  (_prev: string, issue: string) =>
    call.json(
      `Classify the priority of this issue: "${issue}"`,
      s.object({ priority: s.enum("high", "medium", "low") }),
      { model: "claude-haiku-3-5", label: issue.slice(0, 32) },
    ));

_prev (or _p) signals "first stage; prev === item" and keeps the shape readable for anyone extending to multi-stage.