Test & Deploy
End-to-end validation, branch coverage, failure diagnosis, and dev-to-prod publication.
Test and deploy is the bridge from a draft you've built to running production code in a customer's hands. Three skills cover it: one verifies a single automation end-to-end, one verifies a coordinated suite, and one moves tested work from your dev system to prod and out to customer accounts.
Test an automation
Ask Claude to test an automation and it runs the trigger, executes every step against real systems (or live sandbox accounts), and reports back step by step.
For polling triggers and instant triggers with a known payload schema, Claude fires a test execution and waits for it to complete. For webhook triggers without a baked-in sample, Claude tries to replay a payload from the trigger's execution history. If no history exists yet — common on a brand-new webhook — Claude asks you to fire the event from the source app or send a curl against the webhook URL. The API Authentication walkthrough shows that fallback in context.
If something fails, Claude reads the run history step by step and tells you which step errored and why, in plain language. Common cases — empty required field, missing lookup before a detail mapping, format mismatch on a date or phone field — Claude proposes a fix, applies it, commits a new version, and retests. It stops retrying when the same error on the same step has repeated three times, so a stuck fix doesn't burn cycles.
After the run passes, Claude moves to branch coverage. It enumerates every condition in the automation, identifies which TRUE/FALSE branches the test execution actually exercised, and forces the uncovered branches by mutating the run data and restarting from the condition. The final report shows what passed, what was fixed, and which branches still aren't covered.
For diagnosing automations a customer reports as failing — not testing fresh ones — Claude pulls recent failed executions, inspects the step that broke, cross-references the failure against the automation's logic, and explains the root cause before offering a fix.
Test an integration suite
If the deliverable is several automations working together — a two-way sync, a multi-step pipeline, a chain of subroutines — testing them one at a time and calling it done misses the failure modes that only surface at the system level.
Ask Claude to test the integration end-to-end and it runs each automation individually first, then tests the cross-automation behavior: data flowing from one automation's output to the next's trigger, shared state in lookup tables, loop prevention on bidirectional syncs, and subroutine input/output across caller boundaries.
For a two-way sync, Claude walks the full round-trip: create a record in System A, run direction one, verify it appeared in System B, modify it in B, run direction two, then re-run direction one and confirm loop prevention blocks the bounce-back. The report shows each step, the cache and lock state along the way, and any divergence from expected behavior.
Publish and deploy
Once tests pass, ask Claude to publish and deploy. The process has two phases.
Publish moves a folder of automations from your dev system to your prod system. Claude lists the automations in the folder, asks you to confirm, then publishes each one and reports per-automation success.
Deploy pushes the prod template out to customer accounts. Claude lists the candidate accounts with their current versions; you specify which to target (all, all on a specific version, or named accounts), and Claude deploys each one and reports per-account status. First-time deploys may need webhook registration in the external app — Claude calls those out explicitly.
The two phases combine when you ask for both at once: "publish ZoomConnect v4.01 to prod and deploy to all our customer accounts." Claude runs publish first, then deploy.
Deploys are versioned, not destructive. The previous version is preserved on each account. To roll back, ask Claude to redeploy a prior version.
After a successful deploy, Claude offers to monitor the deployed accounts for execution errors over the next several days. You decide whether to start the monitor.
The loop
Most production work is cycles around this loop. Each phase is driven by a plain-English ask in chat.