Update to ReMCP

{
  "description": "Use when the primary task is copying, moving, or backing up files/directories between two paired computers. This skill owns the transfer/chunk/hash workflow; use destructive-operation guidance additionally only when the user explicitly asks to remove or overwrite source/destination data.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 440
    },
    {
      "relative_path": "references/chunking.md",
      "size_in_bytes": 2611
    }
  ],
  "name": "transfer-files-between-machines",
  "skill_md_contents": "---\nname: transfer-files-between-machines\ndescription: Use when the primary task is copying, moving, or backing up files/directories between two paired computers. This skill owns the transfer/chunk/hash workflow; use destructive-operation guidance additionally only when the user explicitly asks to remove or overwrite source/destination data.\n---\n\n# Transfer files between machines\n\nReMCP has no direct machine-to-machine copy: the bytes travel through this conversation, so size\nmatters. Follow the size first, then choose the path.\n\nSelect the actual MCP tool shape at execution time: use standalone `get_file_info`, `read_binary`, `write_binary`, `create_archive`, `extract_archive` and `hash_file` if advertised; otherwise, if the compact `manage_files` tool is advertised, invoke its validated `operation` with its `parameters`. Never assume a grouped alias exists. The chunking reference may use compact examples; adapt them to the live schema. `list_devices` remains direct.\n\n1. `list_devices` and pick the source and the destination. Both must belong to the signed-in\n   account; if the destination is offline, stop and say so.\n2. Size the payload: `get_file_info` on the source path. For a directory, inspect its entries,\n   create an archive, then inspect the archive size; directory metadata is not a total byte count.\n3. Choose the method:\n   - **Small file (a few hundred kilobytes):** `read_binary` on the source, then `write_binary` on\n     the destination with the returned base64 `data` and `mode: \"rewrite\"`.\n   - **Large file:** `read_binary` with `offset_bytes` and `length_bytes`; write the returned\n     `data` using `mode: \"rewrite\"` for the first chunk and `mode: \"append\"` thereafter.\n     Set the next read's `offset_bytes` to `nextOffsetBytes` until `complete` is true.\n     `write_binary` has no offset or encoding parameter. Never truncate a chunk silently.\n   - **Directory or many files:** `create_archive` (tar.gz or zip) on the source, transfer the\n     archive, then `extract_archive` on the destination.\n4. Verify with `hash_file` on both machines and compare the digests. Report both digests; a\n   transfer is not finished until they match.\n5. Clean up only what the user asked you to remove. If you created a temporary archive, say where\n   it is instead of deleting it silently.\n6. Never transfer secrets, private keys, credential stores or browser profiles; if the user asks\n   for one, explain that ReMCP does not move credentials and suggest a secret manager instead.\n\nPass the source `device` id on reads and the destination `device` id on writes. Ask before an\noverwrite unless the user already authorized that exact destination. Do not blindly retry an\nappend after a timeout: the write may already have completed, and a retry would duplicate bytes.\n\nSee [chunked transfer loop](references/chunking.md) for sizes, examples, and recovery.\n"
}