Update to Ando - Team messaging

{
  "description": "Assess and carry out a bounded move from another messaging platform into Ando, selecting a maintained importer, history API adapter, or attributed forwarding route. Use when no dedicated platform migration skill applies.",
  "included_files": [],
  "name": "ando-migrate-messaging",
  "skill_md_contents": "---\nname: ando-migrate-messaging\ndescription: Assess and carry out a bounded move from another messaging platform into Ando, selecting a maintained importer, history API adapter, or attributed forwarding route. Use when no dedicated platform migration skill applies.\n---\n\n# Migrate from another messaging platform\n\nRead the [shared migration workflow](../../references/migration-workflow.md).\nFor Slack use [Migrate from Slack](../ando-migrate-slack/SKILL.md); for Buzz use\n[Migrate from Buzz](../ando-migrate-buzz/SKILL.md). Identify the exact source\nproduct, workspace, supported export/API, and desired history or live-sync\noutcome before choosing a route. Verify source-provider export restrictions\nand permissions through current official documentation.\n\n## Pick the route by the required result\n\n- **Maintained importer:** prefer a documented platform-specific importer when\n  it meets the requested coverage and fidelity.\n- **History import API:** use the current\n  [import contract](https://docs.ando.so/developers/api-reference#import-history)\n  for original authors, timestamps, and import behavior. A source adapter is\n  required; the existence of the API does not mean one already exists for this\n  platform. If adapter work is needed, explain it and implement only within\n  the user's requested scope.\n- **Attributed forwarding:** use the\n  [other messaging platforms guide](https://docs.ando.so/docs/other-messaging-platforms)\n  for a bounded backfill or ongoing bridge when ordinary messages are acceptable.\n  `send_message` creates messages as the authenticated sender at the current\n  time; attribution text does not preserve original authorship or timestamps\n  as native message metadata. It may notify people or create unread state.\n\nDo not silently downgrade a requested history import to forwarding. Explain\nthe observable difference and resolve the choice before executing the writes.\n\n## History import\n\nInspect the current OpenAPI schemas, limits, required owner/admin role, and\n`imports:write` scope. Preserve stable source-workspace and record IDs. Import\nin dependency order: members, conversations, messages with thread roots before\nreplies, then reactions. Verify source-to-target IDs and original timestamps\ninstead of reconstructing them from display text.\n\nFor uploaded attachments, verify `files:write`, complete the supported upload\nlifecycle, and attach ready file IDs under the current import schema. Retain\nsource file IDs for deduplication. Check skipped records and readback before\nmarking an import complete. Reopen a completed import through the documented\nroute before resuming writes; do not change source IDs to evade a conflict.\n\n## Forwarding or a live bridge\n\nResolve the target conversation and its membership from the verified Ando\nconnection. Preserve author, source channel, original time, and source link\nin the message text. Inspect the current `send_message` schema; do not copy\nlegacy flat arguments into a different catalog.\n\nUse a durable checkpoint keyed by source workspace/channel/message ID and\nsupported target idempotency. Read back uncertain sends before retrying. Verify\npagination and a bounded date window before claiming historical completeness.\nDefine how edits/deletes, bot messages, files, and duplicates are handled.\n\nAn ongoing bridge needs an actual supported event receiver or scheduled\nruntime, an owner, and a stop mechanism. Verify it is installed and delivering\nauthorized events before claiming it is live. Prevent feedback loops when\nmessages can flow both ways. Keep private-source access aligned with target\nmembership, and report unsupported features and partial coverage explicitly.\n"
}