Lindy Upgrade MigrationSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: lindy-upgrade-migration
description: 'Manage Lindy agent configuration changes, platform updates, and migrations.

  Use when reconfiguring agents, handling platform changes,

  or migrating agents between workspaces.

  Trigger with phrases like "upgrade lindy", "lindy migration",

  "lindy reconfigure", "update lindy agents", "lindy workspace migration".

  '
allowed-tools: Read, Write, Edit
version: 1.20.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags:
- saas
- lindy
- migration
compatibility: Compatible with AI coding agents that can read and edit Markdown evidence records
---
# 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 c

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.