← AmpleCONTENT HISTORY

Update to Ample

Snapshot Nov 3, 2026 · 00:13 UTC · version 0.2.2

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save Ample and check future changes in Following.

Up to 10 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Plan and perform an explicitly requested migration of one or more components (compute, PostgreSQL, object storage, CDN) to Ample using a verified migration recipe with inventory, compatibility checks, backup, validation, cutover and rollback. Use when the user asks to move an app or database from a named source such as Vercel, Heroku, Supabase or S3. Never promises full provider replacement and never deletes the source.",
  "included_files": [
    {
      "relative_path": "references/compatibility-and-backup.md",
      "size_in_bytes": 815
    },
    {
      "relative_path": "references/cutover-and-data-validation.md",
      "size_in_bytes": 642
    },
    {
      "relative_path": "references/rollback.md",
      "size_in_bytes": 574
    },
    {
      "relative_path": "references/source-inventory.md",
      "size_in_bytes": 976
    }
  ],
  "name": "migrate-app-components",
  "skill_md_contents": "---\nname: migrate-app-components\ndescription: Plan and perform an explicitly requested migration of one or more components (compute, PostgreSQL, object storage, CDN) to Ample using a verified migration recipe with inventory, compatibility checks, backup, validation, cutover and rollback. Use when the user asks to move an app or database from a named source such as Vercel, Heroku, Supabase or S3. Never promises full provider replacement and never deletes the source.\n---\n\n# Migrate app components\n\nScope: the components the user explicitly asked to move. Auth, edge functions,\nrealtime, queues and other services that Ample does not offer are inventoried\nand reported, not migrated. Source deletion is a separate, user-authorized step\nthat this skill never performs.\n\n## Workflow\n\n1. **Inventory the source.** List the components in scope and out of scope with\n   the user's authorized access (`references/source-inventory.md`).\n2. **Search.** `ample recipe search \"migrate <source> <framework|component>\"`;\n   migration recipes live under `/migrate/<source>/<component>`.\n3. **Inspect one contract** and `references/compatibility-and-backup.md`.\n4. **Report fit.** Verified matches, mismatches, missing inputs, unknowns. A\n   migration recipe with `executionStatus: unbound` is documentation only.\n5. **Plan** the Ample side with `ample recipe plan ...` (side-effect-free) and\n   show resource changes, cost and limitations. Wait for approval.\n6. **Execute in stages** after approval: deploy on Ample (existing flow), copy\n   data with a verified backup first, validate, then cut over\n   (`references/cutover-and-data-validation.md`). Each stage is reported before\n   the next starts.\n7. **Verify and keep rollback ready** (`references/rollback.md`).\n\n## Boundaries\n\n- No destructive change to the source without the user's explicit, scoped\n  approval and validated migration evidence; even then the deletion is the\n  user's action, not this skill's.\n- Do not claim full replacement of a provider from a component recipe.\n- Unknown facts (regions, compliance, data residency) stay unknown.\n\n## Ample plugin\n\nThe Ample plugin uses Ample's hosted MCP server. The person links their Ample account in the browser when the host asks; never call `ample_auth_signup`, and never request or print credentials. Use the plugin's tools, not a shell `ample` CLI, which may be signed in to a different account.\n\nTo deploy: create a workspace with `ample_workspace_create`, put the project in it (`ample_workspace_upload` with a tar.gz as `data_base64`, `ample_workspace_write` per file, or `ample_workspace_import` for a public Git URL), run `ample_plan` with `workspace_id`, `path: \".\"` and `write: true`, then `ample_deploy` with the same `workspace_id`. Every call needs a fresh `execution_key`; reuse one only to retry the same call after a disconnect. Deployment is synchronous: call it once and read the result; never redeploy to poll. Show the person their apps or a deploy's progress with `ample_ui_open` (pass the `execution_id` of the deploy, or a `deployment_id`). To set things up yourself instead, create a server (`ample_server_create` with a template such as node-22), fetch and build with `ample_server_exec` (for example `git clone` of the person's repository), and run it with `ample_service_start`, which returns its URL.\n"
}

SHA-256 of public snapshot: 943694b3141e06baf1d388404249ea1b6373a4289031c0733ba16fd4d84a85e6