Imported from jeremylongshore/tons-of-skills-marketplace (skills/.curated/lindy-upgrade-migration/SKILL.md). Install upstream with npx skills add jeremylongshore/tons-of-skills-marketplace --skill lindy-upgrade-migration. Copyright stays with the author (MIT).

Lindy Upgrade and Migration

Overview

Plan and verify changes to Lindy workflows through the documented workspace UI. Use Lindy's Version History as the in-place restoration mechanism, the Test Panel for controlled execution, and the Tasks view for run evidence. Do not invent a Lindy SDK, API key, package upgrade, CLI, export endpoint, or control plane.

Use Read to inspect the approved change record and evidence. Use Write or Edit to maintain the migration record without copying secrets or customer data.

Prerequisites

• Authorized access to every source and target workspace in scope.
• A named change owner, approver, rollback owner, and acceptance owner.
• A known-good saved agent version visible in Version History.
• A current inventory of triggers, actions, conditions, integrations, knowledge sources, manual approval steps, owners, and downstream side effects.
• Synthetic inputs and sandboxed destinations for Test Panel runs; its tests can execute real actions and call real external systems.
• Baseline task receipts from the Tasks view and explicit acceptance criteria.
• Current Lindy documentation and workspace evidence for any transfer or feature behavior relied upon by the change.

Instructions

Step 1: Define the change boundary

Record whether this is an in-place configuration change, restoration, template- based recreation, or workspace move. List the exact workflows, integrations, callers, secrets, data stores, approvers, and external side effects in scope.

Treat anything not documented by Lindy or directly observed in the target workspace as NOT VERIFIED. Templates are starting workflows that must be configured, customized, and tested; do not assume they preserve credentials, triggers, knowledge, memories, phone or mail resources, permissions, approval rules, webhook URLs, or other workspace-bound state.

Step 2: Capture a rollback anchor and baseline

1. Save the current working workflow with a descriptive version name.
2. Open Version History, record the rollback version and review its changes.
3. Run approved synthetic cases and retain Tasks-view identifiers, step outcomes, and expected side effects.
4. Record current integration identities, trigger configuration, manual approval gates, and sanitized destination identifiers.

Do not copy OAuth tokens, webhook secrets, full payloads, or customer content into the record.

Step 3: Build the candidate safely

For an in-place change, edit the workflow but keep it inactive or otherwise isolated until testing and approval are complete. For a workspace move, use a documented template installation or recreate the workflow in the target workspace, then verify every target-bound dependency individually.

If the target uses a webhook trigger, inspect its generated URL and secret. The calling application may send that secret only to an HTTPS URL whose hostname is exactly public.lindy.ai and whose path is the expected generated webhook path. If the target URL or secret differs from the source, plan an atomic caller update; do not infer whether copying or installing a template preserves either value.

Reconnect integrations through the target workspace UI. Preserve human-in-the- loop approval by confirming the approval step, reviewer identity or role, timeout behavior, and rejection path in the candidate—not merely by copying visible text.

Step 4: Test with clean inputs

Use the Test Panel with synthetic data and sandboxed destinations. Test every trigger and material condition branch, including malformed input, denied approval, expired or missing authorization, external-action failure, duplicate delivery, and recovery after a worker or downstream interruption.

The Test Panel performs real execution. Confirm each result in the panel and the Tasks view, and reconcile expected side effects at the destination. A green step without the expected destination state is not sufficient evidence.

Step 5: Obtain approval and cut over

Present the evidence bundle and unresolved risks to the named approver. After approval, use an owner-defined cutover method that prevents duplicate side effects. Do not run old and new workflows in parallel against production inputs unless the design proves idempotency and explicitly permits duplicate delivery.

Route a controlled canary where possible, observe Tasks-view results and downstream state, then move remaining traffic. Keep the rollback target intact until the acceptance owner signs off; do not delete it on a fixed timer.

Step 6: Roll back when acceptance fails

For an in-place change, select the known-good entry in Version History, restore it, review the loaded configuration, and save it. Lindy documents that saving a restored configuration creates a new version rather than deleting later history.

For a workspace or endpoint cutover, restore the previously approved routing and workflow state using the recorded change procedure. Revalidate authentication and confirm a clean synthetic task. Rollback is complete only when the Tasks view and destination evidence match the pre-change baseline.

Step 7: Close with retained evidence

Record the final workflow version, task identifiers, approvals, observed outcomes, cutover or rollback timestamps, remaining risks, and follow-up owners. Redact secrets and minimize personal or customer data.

Output

Produce a migration evidence bundle containing:

• change type, source and target workspaces, workflow identifiers, and owners;
• dependency inventory with VERIFIED, FAILED, NOT VERIFIED, or N/A status;
• rollback version and restoration procedure;
• clean-test cases and Tasks-view receipts for happy, failure, and approval paths;
• target integration, trigger, webhook, and destination verification;
• explicit approval and cutover decision;
• production observation and destination reconciliation; and
• final disposition: MIGRATED, ROLLED BACK, or BLOCKED, with open risks.

Examples

In-place configuration change

# Change LND-42

- Boundary: prompt and one condition branch; no new integrations
- Rollback anchor: Version History entry "pre-LND-42"
- Clean tests: happy, denied approval, malformed input, destination failure
- Task receipts: task-a, task-b, task-c, task-d
- Human approval: VERIFIED -- reviewer role and rejection branch exercised
- Destination effects: VERIFIED against sandbox records
- Decision: MIGRATED

Correct workspace-move decision

If a template installs but the target integration identity or approval path cannot be verified, record that dependency as NOT VERIFIED and choose BLOCKED. Template installation alone is not migration evidence.

Error Handling

Resources

• Lindy Version History
• Lindy Test Panel
• Lindy Tasks
• Lindy Human in the Loop
• Lindy Templates
• Lindy Workspaces
• Lindy Webhooks
• Detailed migration evidence guide