plan-payroll

规划工资发放

按顺序完成三项技能：确认工资发放是否有资金覆盖，若存在缺口则先补足，然后执行发放。

业主在这里不会分开问两个问题。“我能发工资吗”和“执行工资发放”是同一个顾虑，如果把两者拆到两次会话中，就会出现有人在晚上 11 点录入发放数据，却没有先核对银行余额的情况。

解析参数：

• --horizon（默认 30）——预测窗口天数：30、60 或 90
• --payroll-date（可选）——工资发放日期；默认为下一个计划发薪日

第 1 步——工资发放是否有资金覆盖？（cash-flow-snapshot）

调用 cash-flow-snapshot。它负责预测计算、置信区间和 CSV 备用方案，此处不要重新实现这些内容。

• **输入：**预测窗口和工资发放日期。
• **输出：**30/60/90 天预测、具名风险标记、聊天摘要和一个 XLSX 文件。

在其他内容之前，先用一行话给出结论：覆盖充足、资金紧张，或在某个具名日期上短缺某个具名金额。

**关卡——链条接下来走向何处。**如果工资发放资金充足，询问是否跳过催收步骤，直接进入发放。如果存在缺口，则呈现缺口并等待明确的“看看我们能收回多少”，然后才进入第 2 步。

第 2 步——弥补缺口（invoice-chase）

调用 invoice-chase。它负责排序、语气匹配，以及按发票类型区分的发送路径。

• **输入：**第 1 步得出的缺口金额及其到账日期。
• **输出：**按优先级排列的逾期发票，每张附带一份已起草的催款提醒；通过 PayPal 开具的发票排入 PayPal 发送队列，其余发票生成邮件草稿。

将排序结果与第 1 步关联：显示在窗口期内能收回多少款项，以及这是否真正弥补了工资缺口。如果一份催款提醒要 45 天后才能到账，那对周五的发薪毫无帮助，需要明确说明。

**关卡——未经批准，任何内容都不会发送。**在业主说“发送”之前，只保留草稿，可以逐条确认，也可以由业主指定批量发送。

第 3 步——筹备发放（payroll-prep）

调用 payroll-prep。它负责周期设置、工时汇总、异常检查以及账簿同步。

• **输入：**工资周期、员工名册，以及第 1 步的现金结论。
• **输出：**逐人列出的发放表，每个异常都标注到对应的人员，附合计数，以及发薪日所需的现金金额。

沿用第 1 步的结果，而不是重新计算。当 payroll-prep 报告本次发放能否通过时，它使用本链条已生成的预测，再加上第 2 步预计能收回的款项。

关卡——逐条确认标记。payroll-prep 会逐条检查每个异常。不要将其合并为一句“看起来没问题吗？”，因为每一条都关系到某个人的薪酬。

**关卡——发放本身。**连接了 Gusto 时，发放在 Gusto 中进行暂存（payroll-prep 通过 update_payroll 写入已批准的输入，且从不调用 run_payroll）。连接了 QuickBooks Payroll 时，连接器只负责读取，不具备发放暂存写入功能，因此结果是经过验证的发放表，由业主手动录入。这是连接器当前所能提供的结果，而非降级路径。只有当数据源确实返回了员工名册和发薪计划时，才会进行暂存：如果已连接的数据源报告存在员工但未提供任何数据，payroll-prep 会停止暂存路径，链条随后明确地以发放表结束。**由业主提交。**两者都不可用时，交付物是供手动录入的已验证发放表，这是完整的结果，而不是降级结果。即使 Gusto 报告了阻塞项，情况同样如此，此时发放表会继承 payroll-prep 给出的阻塞项列表。

第 4 步——闭环收尾

按以下顺序给出一份总结：现金结论、已发送的内容及收件人、如果催款提醒全部兑现后的预计资金状况，以及已暂存的发放——人数、总工时、税前工资总额、从账户流出的现金、发薪日期，以及仍未关闭的标记。

Ray Okonkwo 只需看四行即可掌握情况：15 日现金短缺 4,200 美元；已发送三份催款提醒，覆盖 6,800 美元，其中两份很可能在窗口期内到账；已为 9 人暂存发放，金额 18,340 美元，Marcus 的一条缺失打卡记录仍未处理。

输出

请按照车主保存的输出偏好交付 Step 4 摘要,切勿默认生成 Markdown 文件。 请检查 ## Business context 区块中的 Output preference(共享样式指南规则,../../shared/artifact-style.md):

• 可视化产物(默认): 以House style渲染 HTML 页面,将现金结论作为首要统计卡片,已发送提醒及其预计回款金额使用等宽数字(tabular-nums)显示,暂存运行的总计数据中,任何未解决的标记以药丸样式(pill)呈现。预计现金须标注为“预计”。
• 偏好 docx / md / notion / canva: 以该形式交付相同内容:DOCX 或 Markdown 文件;通过连接器创建的 Notion 页面(使用指定的目标名称,绝不覆盖);或通过 Canva 连接器创建的 Canva 文档(每次运行新建设计,并以日期命名;表格转为列表)。若 Notion 或 Canva 未连接,则回退为可视化产物,并说明原因。
• Best for skill: 使用可视化产物。该输出为一屏内容,用于回答“我能否发放工资”。

连接器故障

如果无法访问任何账本(MYOB、NetSuite、QuickBooks、Xero 或 Zoho Books,以车主使用的为准),请按类别停止并说明原因——现金预测是整个链路的基础。如果支付连接器或邮件连接器(Gmail 或 M365)失败,请说明具体是哪一个并继续处理其余部分。如果薪资系统失败,则转为运行表路径,而不是中止流程;车主仍可获得可以执行的薪资方案。当运行无法暂存或同步到账簿中(存在阻碍项、缺少写入权限)时,请在 Step 4 摘要中说明,并交付运行表以及供簿记员录入的日记账分录摘要;适用哪条路径由 payroll-prep 的阻碍项检查决定。

不应做的事

• 不要提交薪资。 本链路只负责暂存,由车主提交。即使车主要求直接执行,此规则同样适用。
• 未经批准不要发送提醒。 在获得明确指示前,仅保存为草稿。
• 不要因为车主说“直接运行薪资”就跳过 Step 1。 现金检查只需约三十秒,而它正是本链路存在的原因。
• 不要在 Step 3 中重新计算预测。 现金数据只能有一套,且只能来自同一个来源。
• 不要批量处理异常审核。 每个人、每个问题都需单独决策。
• 不要把缺少薪资连接器视为阻碍。 运行表是设计好的路径。在断定没有薪资数据来源之前,请先检查 QuickBooks Payroll;使用 QuickBooks 的企业往往已具备该功能,而未必使用 Gusto。
• 不要将尚未到账的现金承诺为已收。 预计就是预计,必须标注。
• 不要在链路的任何输出中复述任何人的社会安全号码(SSN)、出生日期、家庭住址或银行账号(../../shared/personal-data.md)。

链路之后

薪资已覆盖,提醒已发出,运行也已暂存,等待车主提交。下一步自然是“支付账单”——/pay-the-bills 会在同一现金画面下处理供应商款项。相关的还有:“现金预测”(cash-flow-snapshot),用于在提醒逐步转化为回款时持续观察资金状况;以及“结月”(/close-month),用于在期间结束时使用。最多提供三项建议,并跳过车主在本次会话中已拒绝的建议。

使用未列出的工具

本 skill 中提到的连接器是经过测试的路径,而非唯一选择。如果车主希望此流程使用尚未连接或未列出的工具,可提供 build-connector——它会先检查连接器目录,否则通过 Zapier 进行连接,绝不会直接对原始 API 进行手工开发。连接建立后,该工具将与其他可选连接器一样加入本 skill,并遵循同样的审批关卡。