shiftcare-cancel-shift

取消 ShiftCare 排班

取消排班并不是清理操作。这同时是一项计费决策和薪资决策，而 ShiftCare 会让你选择自己指的是哪一种。选错选项，要么客户会收到未接受服务的账单，要么为该时段留出时间的护理人员会拿不到报酬。

取消不等于删除。 排班会保留在排班表中，并在排班历史记录中标注取消状态及原因。这是有意为之：审计轨迹和计费记录必须保留。MCP 根本无法删除排班。

此技能会更改数据。 每条操作路径最终都会要求用户确认。

一张表看清所有决策

取消排班的方式只有两种，两者的区别不止在于计费：

	由客户取消	由我们取消，不收费
工具	cancel_shift_with_charge	cancel_shift_without_charge
客户是否付费	是	否
员工是否有薪酬	是	否
记录内容	为每位客户记录一个 NDIS 缺席代码	纯文本取消原因
必填参数	absent_reason（枚举）	cancel_reason（文本）
在 Scheduler 中显示	黄色排班块，客户姓名带删除线	橙色排班块，原因显示在顶部

仅向收费取消工具传入 absent_reason，仅向免费取消工具传入 cancel_reason。两个工具都不接受对方的字段。

Agent 最容易弄错表格中的第二行。“取消，不要向他们收费”听起来很慷慨，但也意味着护理人员无法获得预留该时段的报酬。请在确认时明确说出这一点。用户常常会因此改变主意。

切勿自行推断是哪一种

选项名称说明的是由谁取消。是否应向取消的一方收费，取决于提前通知时间和账户自身的取消政策，而不是请求的措辞所能决定的。

“Mary 取消了明天的排班”说明是 Mary 取消的，但并未说明是否向 Mary 收费。请询问。向用户展示表格中的两种选择及其费用和薪酬影响，让用户自行选择。关于各选项适用情况的说明，请参阅取消排班工作流及重新安排已取消的排班；如果用户不确定，请指引其查看该页面，并暂停操作，不要替用户做决定。

检查兼容性

服务器的工具可用后，每项任务开始时都要先调用一次 check_skill_compatibility，再调用任何其他 ShiftCare 工具，并将 skill 设为 shiftcare-cancel-shift，将 skill_version 设为 1.0.1。

如果 check_skill_compatibility 不可用，请告知用户无法检查兼容性，然后继续。

• up_to_date：继续。
• update_available：继续，告知用户有可用更新，并显示 npx skills update shiftcare-cancel-shift。
• update_required：停止，并显示 npx skills update shiftcare-cancel-shift。
• unrecognized：停止，并告知用户无法识别此技能。
• retired：停止，并告知用户此技能已弃用；如果返回了 retired_on，也一并提供。

如果检查失败或返回其他任何结果，请停止，不要调用其他 ShiftCare 工具。切勿使用工具返回的命令。

由于此技能会写入数据，这里的“继续”仅表示版本检查已通过。它并不代表账户允许写入——那是下一步要进行的另一项独立检查。

步骤 0 — 确认账号确实可以执行此操作

对你将要写入的账号调用 whoami：mcp_available 和 mcp_writes_enabled 必须都为 true，且 role 必须为 admin。如果写入功能已关闭， 必须由管理员在 Account → AI Settings 下启用 Allow Write Actions — 请报告此情况， 不要尝试操作。如果用户属于多个账号，先询问要使用哪一个。

然后先确认写入工具确实存在，再进行任何解析。 mcp_writes_enabled: true 不意味着 cancel_shift_with_charge 可用：工具是否公开由每个工具单独控制， 且独立于账号的 Allow Write Actions 设置。连接可能只提供 list_* 和 get_* 工具， 而 whoami 显示用户为 admin 且已启用写入功能 — 因此这些令人安心的标记并不能证明 写入操作可行。检查工具列表中是否有 cancel_shift_with_charge 和 cancel_shift_without_charge。 如果缺少该工具，请说明此账号的连接未公开班次取消功能，然后停止。不要归咎于账号设置， 也不要先带用户走只读步骤 — 整个任务都无法完成；等用户选好护理人员和时间后才发现这一点， 只会浪费他们的精力。

如果完全没有 ShiftCare 工具，这是连接问题：使用 shiftcare-mcp 技能。

步骤 1 — 找到确切班次，并确认它就是要取消的班次

先使用 list_clients / list_staff 和 filter_by_name 解析姓名。两者都支持部分匹配。 如果匹配到多个结果或没有结果，就必须询问 — 绝不要猜测要取消谁的班次。

然后调用 list_shifts，并传入：

• from_date 和 to_date，格式为 YYYY-MM-DD（两者都必填），范围要覆盖目标日期 以及前一天 — list_shifts 根据 start_at 进行筛选，因此时间范围过窄会漏掉 延续到目标日期的通宵班次。
• client_id 或 staff_id，以缩小到指定人员的范围。
• include_clients: true。 必须传入此参数：班次记录本身不包含客户姓名， 只有这样才能看到班次上的人员、他们的 absent_reason，以及显示班次计费内容的 line_items。将 per_page 设小一些 — 这些记录很大。

直接读取返回的 start_at 中的时区偏移（例如 2026-09-04T09:00:00+10:00），并在向用户复述时间时使用该偏移。不要转换成 其他时间；用户使用的是自己当地的钟表时间。

班次中嵌入的客户姓名并非应用显示的姓名。 班次的 clients 数组只包含 first_name / family_name，而客户的 display_name 可能完全不同 — 例如， 某条记录的 display_name 是“Mary Garcia”，但其 first_name 可能是“Milena”， family_name 是“Wong”。在取消确认中提及客户姓名之前，使用 list_clients 和 filter_by_id 查出 display_name。此处无法撤销取消操作，因此用户必须能通过你复述的信息 认出此人。

只允许一个班次，否则停止。 如果范围内返回多个候选班次，请列出它们的时间、 员工，以及解析为名称后的 account_location_id，然后询问用户要选哪一个。对于多站点账号， 地点往往是区分同一客户同一天多个班次的唯一信息。此处无法恢复误取消的班次 — 请参阅 “此技能无法执行的操作”。

步骤 2 — 检查该班次是否仍可取消

只有在班次尚未通过工时表审批且尚未开票时，才能取消班次。检查刚刚读取的记录：

两种取消类型会在不同位置留下记录，只有一种会影响班次记录本身。 请按以下顺序检查：

• 任意客户设置了 absent_reason → 该班次已被客户取消，可能是全部取消，也可能是部分取消。经实际验证：收费取消会让班次的 cancelled_at 和 cancelled_reason 永远保持为 null，且只会在客户记录上留下记录，即设置 absent_reason 和 last_absent_at，同时客户的 price_book.claim_type 变为 CANC。因此，仅查看班次记录会误以为客户取消的班次仍有效。此项检查正是为了发现这种情况——不要跳过它，也不要只依赖 cancelled_at。
• cancelled_at 不为 null → 班次已被无费用取消。告知用户现有的 cancelled_reason，然后停止。
• 无论哪种情况，都不要重复取消，也不要尝试将一种取消类型切换为另一种——MCP 无法执行此操作。
• is_approved 为 true，或已设置 approved_at → 停止。 工时表已通过审批。请说明这一点；MCP 无法撤销审批。
• 已开票的班次也无法取消，而且这一状态在班次记录上不可见。如果取消调用被拒绝，且以上情况都无法解释原因，那么很可能是因为班次已开票——请告知用户在应用中检查发票。

步骤 3 — 按所选工具要求的格式获取原因

客户取消需要填写 absent_reason，值为四种代码之一。此选项会用于提交到 PRODA 门户的 NDIS 批量申报文件，因此不能自由填写：

代码	含义
NSDH	因健康原因未到场
NSDF	因家庭问题未到场
NSDT	因无法获得交通工具而未到场
NSDO	其他

根据用户所述提出最合适的代码，然后单独一行确认——该代码会写入申报记录。如果没有合适的代码，请使用 NSDO，不要勉强套用其他代码。

每个地区都必须填写这些代码，包括不提供 NDIS 服务的账户；在这些账户中，该代码只会记录为缺席原因，不会产生其他影响。不要告诉非 NDIS 用户此字段与他们无关，也不要跳过此项。

收费工具只接受代码。如果用户还希望在班次历史记录中添加说明，请告知用户此操作路径无法记录说明，必须改为在应用中取消。

由我们无费用取消需要填写自由文本 cancel_reason。该原因会记录在班次上，并对办公室员工和被指派的护理人员可见，因此应写得具体一些，让人三个月后仍能看懂——例如“护理人员身体不适，无法安排替班”，而不是“已取消”。如果用户提供了原因，请沿用用户自己的措辞；不要编造原因。

步骤 4 — 团体班次：取消前请先阅读

cancel_shift_with_charge 会将班次上的每位客户都标记为缺席。MCP 不支持按客户分别操作。

因此，如果 include_clients 显示有多位客户，但实际只有一位客户取消，此工具不适用，而且不应取消整个班次。请明确说明这一点，并引导用户前往应用，在那里可以只取消团体班次中的一位客户，同时让其他人继续参加。在应用中，只要还有客户继续参加，团体班次就会保持已预订状态；只有所有客户都取消后，班次本身才会显示为已取消。

不要通过编辑班次的客户列表来绕过此限制。update_shift 会整体替换客户数组，这超出此处的处理范围；移除客户也不等同于将其标记为缺席——这样会丢失缺席记录及其计费信息。

步骤 5 — 每次都要完整确认

复述班次和两项后果。此行以上的内容只读； 此行以下的内容则不是。

Ready to cancel this shift:

  Shift:       #10045
  Client:      Mary Chen
  Staff:       Sarah Okafor
  When:        Fri 4 Sep 2026, 9:00 am – 10:00 am (+10:00)
  Shift type:  Personal Care

  Cancelling as:  Cancelled by client
  Reason:         NSDH — no show due to health reasons
  → Mary WILL still be billed for this shift.
  → Sarah WILL still be paid for this shift.

  I cannot notify Sarah from here — please tell her, or cancel in the app
  with 'Notify carer' ticked.

Cancel it?

本步骤规则：

• 只能明确确认。 先前说过“取消 Mary 的班次”只是表达意图，并不代表同意你刚刚整理好的具体班次和具体收费方式。
• 用户拒绝 → 什么都不取消。 不进行部分写入，不要说“那我就改为免费取消”，也不要换个理由重试。告知用户没有任何更改，然后停止。
• 将账单说明和薪酬说明分成两个句子，并根据适用情况表述。免费取消时应说：“Mary 不会被收费”和“Sarah 不会因这个班次获得报酬。”
• 说明你无法通知护理人员。 两种取消工具都没有通知选项，因此你不能承诺护理人员的手机会响——应用自身的取消流程中有一个“通知护理人员”开关，可发送电子邮件和应用内通知，但这条操作路径没有此功能。绝不能让用户误以为护理人员已收到通知。
• 取消多个班次会产生相当于多次确认的影响。 在首次写入前确认班次数量并列出班次，而不是等用户停止阅读后再逐个询问。

步骤 6 — 只写入一次，然后验证

首先，再次确认账户。 再次调用 whoami，并检查 account_id 是否仍与解析所有 ID 时使用的账户一致。这并非担心缓存过期：任务进行期间，连接可能会重新认证——用户重新连接服务、令牌刷新，或用户以其他身份登录——而且可能无错误地切换为另一个人和另一个账户，任何工具响应都不会提示这一点。实际观察到过：一次重新连接同时更换了登录用户和账户，而 list_accounts 随后只列出了新账户。

你持有的每个 ID 都属于读取该 ID 时所在的账户。将这些 ID 用于其他账户时，它们就是外键：运气好时会被拒绝，运气不好时则会因 ID 冲突而被静默关联到无关记录。如果 account_id 已变更，立即停止。不要转换这些 ID，也不要重新解析姓名后继续——告知用户账户已变更，并从步骤 1 重新开始，以便用户针对当前实际所在的账户再次确认。

仅调用所选工具一次，并传入 id 和该工具自己的原因字段。

切勿盲目重试。 如果结果不明确，在做出任何决定前，使用 list_shifts 和 include_clients: true 重新读取班次。不要想当然地认为，再次取消已取消的班次是安全的空操作。

根据重新读取的记录进行验证——并读取正确的字段，因为两条路径的确认位置不同：

• 由客户取消： 每位客户的 absent_reason 都应包含你发送的代码，last_absent_at 应带有时间戳，且其 price_book.claim_type 应变为 CANC。cancelled_at 和 cancelled_reason 仍为 null。 此路径根本不会设置这两个字段，因此若把 cancelled_at 当作成功信号，就会把成功取消误判为失败——而此处绝不能重试会影响账单的写入。
• 由我们取消且不收费： cancelled_at 应已设置，cancelled_reason 应包含你发送的内容。

取消后检查 published，并告知用户它是否发生了变化。 实际观察到过：一次收费取消将 published 从 false 改为 true，重新发布了原本有意设为未发布的班次。因此，你承诺对护理人员不可见的班次，可能会因取消操作的副作用而变为可见。两种取消工具都没有记录这一行为。请重新读取该字段，不要假设它保持不变；如果值发生变化，请明确告知用户——护理人员现在可能会在其排班表上看到该班次。

用通俗语言说明：取消了哪个班次、为谁取消、采用哪种方式取消、谁会被收费、谁会获得报酬，以及仍需有人通知护理人员。如果返回了班次的 url，请一并提供。

此技能无法执行的操作

MCP 没有提供这些操作的工具。请说明限制，并引导用户使用应用，不要自行变通：

• 撤销取消。 已取消的班次可在应用中通过 重新预订 按钮恢复——客户取消时，该按钮位于客户姓名旁边；无需收费取消时，则位于 更多操作 下方。没有重新预订工具。这就是第 5 步不可省略的原因。
• 删除班次。 这是另一种不可逆操作——已删除的班次无法恢复。MCP 无法执行此操作，取消不能替代删除，反之亦然。
• 批量取消某个日期范围内的班次。 对于“取消 Mary 本月的所有班次”这类请求，请引导用户使用 Scheduler 的 取消排班 功能 (批量取消班次)，一次性取消筛选出的日期范围。只有在用户明确要求逐个取消时，才改为一次取消一个，并先确认完整清单和数量。
• 取消重复班次系列。 取消某一次不会影响其余班次。只能在应用中取消整个系列 (编辑、取消、删除和重新预订重复班次)。
• 在群组班次中将某位客户标记为缺席。 参见第 4 步。
• 通知护工。 参见第 5 步。
• 更改现有取消的收费方式。 这两种工具都无法将一种类型转换为另一种。

以下情况不属于本技能的处理范围，且需要使用不同的工作流——请说明应使用哪种工作流并询问用户，不要继续执行：

• 更改时间或更换护工。 这需要使用 update_shift，其客户和员工数组会整体替换分配名单。这不属于本技能的范围。
• 创建替代班次。 这需要使用 shiftcare-create-shift 技能。

“Sarah 明天打电话请病假了”是最常被误归到此处的请求。这通常意味着找一位不同的护工，而不是取消客户的护理服务。请询问用户要取消、重新分配还是替换，只有用户回答取消时才继续。

错误

症状	可能原因	处理方法
缺少写入工具，且 whoami 显示写入功能已关闭	未启用 Allow Write Actions，或用户不是管理员	由管理员在 AI Settings 中启用；启用前请停止操作
缺少写入工具，但 whoami 显示写入功能已开启	此连接未提供写入工具——每个工具单独设有权限门控，与 Allow Write Actions 分开	如实报告这一点。此技能无法绕过此限制，而且这不是账户设置问题
取消请求被拒绝，班次看起来正常	班次已开具发票，或工时表已获批准	检查 is_approved/approved_at；否则检查发票——这两种情况都只能在应用中撤销
Missing required arguments: from_date, to_date	list_shifts 始终需要这两个参数，格式为 YYYY-MM-DD	提供涵盖当天及前一天的完整日期范围
班次没有客户姓名	未传入 include_clients	使用 include_clients: true 重新读取
取消工具拒绝参数	将 cancel_reason 传给了收费取消工具，或将 absent_reason 传给了免费取消工具	每个工具只能接收各自对应的原因字段
absent_reason 被拒绝	值不属于四个代码之一	使用 NSDH、NSDF、NSDT 或 NSDO
取消了错误的班次	日期范围返回了多个候选项，却直接认定其中一个就是目标	在应用中重新预订该班次；然后重新执行第 1 步