qonto-crew-onboard

Qonto 新员工入职

每位新员工入职时，都会触发同一套手动流程：在 Qonto 上邀请他们、按需设置卡片限额、准备入职第一天的安排。这项技能只需一句话就能完成这些事。以读取为主，少量写入操作：每项写入操作都需要单独确认，所有敏感操作都由用户在 Qonto 应用中通过自己的 SCA 完成。

前提条件

1. 首先调用 get_organization → 获取组织、账户和国家/地区信息。然后调用 get_authenticated_membership → 获取请求者的角色。邀请成员和申请卡片需要 Admin/Owner 角色：如果已验证的成员角色权限不足，请如实说明，并将操作降级为只读预览，展示计划执行的内容。
2. 不受国家/地区影响：成员、团队和卡片在所有 Qonto 国家/地区（FR、DE、ES、IT、AT、NL、BE、PT）的操作方式都相同。这里不涉及税务逻辑——无需降级处理。
3. 由用户决定每个角色的策略——卡片类型、每月限额、是否仅限线上使用、所属团队等，例如“开发者 → 虚拟卡，€200/月，仅限线上使用，团队 Tech”。在对话中定义一次（或粘贴用户的笔记）。如果某个角色没有对应策略，应当提问，绝不能猜测。

工作流

1. 快照与权限

依次调用 get_organization → get_authenticated_membership（检查角色；如果不是 Admin/Owner，则如实警告）→ list_memberships（分页，per_page ≤ 50；统计成员人数，并确认该邮箱尚未受邀）→ list_teams → list_cards。

2. 加载策略——绝不自行编造

询问（或回忆）每个角色对应的策略：卡片类型（虚拟/实体）、每月支出限额、单笔交易限额（如有）、是否仅限线上使用、目标团队。将策略整理成表格展示。套餐限制：询问用户使用的套餐，并与 list_memberships 返回的成员人数进行比较；如果邀请可能超出套餐限制或产生按席位计费，应在邀请前发出警告。不要陈述未经核实的价格（get_qonto_public_pricing 可用于查询公开套餐信息）。

3. 解析句子，然后回顾所有内容

“Alex 周一入职，担任开发者” → 名字、角色、入职日期。询问缺少的信息（至少需要电子邮箱地址——邀请必填，绝不能猜测）。将角色映射到对应策略。任何写入操作之前，先展示一张完整的回顾表：邀请（邮箱、在 Qonto 上授予的角色）、团队（现有团队或要创建的团队）、卡片申请（类型、限额、是否仅限线上使用）、欢迎礼包项目。用户批准整个计划后，仍需逐项确认每个写入操作。

4. 执行——逐项确认每个写入操作

• create_membership → 向新员工发送 Qonto 邀请邮件。先确认；报告状态时应说“邀请已发送，等待接受”，绝不能说“成员已激活”。
• 仅当策略指定的团队不存在于 list_teams 中时，才调用 create_team。先确认。
• create_card_request → 按策略提交卡片申请（持卡人、卡片类型、限额、是否仅限线上使用）。这是有意设置为申请，而不是直接创建卡片：申请会进入 Qonto 应用的“申请”部分，由 Admin/Owner 使用自己的 SCA 批准。绝不能将卡片描述为已激活——它仍在等待批准（可通过 list_requests 跟踪）。
• MCP 无法完成的事项（升级套餐、永久更改权限）→ 说明无法完成，并引导用户前往应用操作。

5. 欢迎清单

包含入职第一天的信息、卡片策略、待处理事项，以及安排第一天活动和准备欢迎消息的提醒。这项技能不会探查或调用其他 MCP 服务。

6. 离职——反向流程

“Sam 周五离职” → 在 list_memberships 中查找 Sam，在 list_cards 中查找其卡片，然后在明确确认后调用 change_card_status，将每张卡片冻结。生成一份回收清单：归还实体卡、设备、应用/工具访问权限、待处理的费用报销申请、邮件转发。这项技能绝不会删除或永久撤销任何内容——成员停用和永久撤销操作必须在 Qonto 应用中完成，清单会明确说明操作位置。冻结的卡片可以恢复；这正是这么做的原因。

7. 报告 — 输出格式

始终在对话中使用 Markdown 表格回复：

1. 入职回顾（操作 · 工具 · 状态：✅ 已完成 / 🕐 等待 SCA 审批 / ⏭ 已跳过 + 原因）。
2. 卡片申请状态 — 明确写明“正在等待 Qonto 应用中的审批”。
3. 欢迎清单（事项 · 负责人 · 状态）。
4. 离职：以复选框列表形式列出恢复清单。

防护规则

• 未在当前对话中获得明确确认，绝不执行写入操作 — 先提供完整回顾，然后逐项确认每次写入（create_membership、create_team、create_card_request、change_card_status）。绝不把待处理的申请说成已完成。
• 各角色的策略由用户决定，绝不自行编造。如果没有针对该角色的策略，就询问。
• 计划成员数限制：询问所用计划，统计成员人数，并在邀请前提醒。
• 离职流程中绝不删除任何内容：只冻结并提供清单；最终撤销操作须在 Qonto 应用中完成。
• 写入操作需要 Admin/Owner 权限 — 先检查 get_authenticated_membership，并如实说明否则哪些操作会失败。
• 电子邮件和个人数据：严格使用用户提供的信息，绝不猜测地址。所有内容均须分页（per_page ≤ 50）。