company-cfo

/company-cfo — 公司 CFO 月度工作流

管理层用于制定分配／削减／招聘／现金 runway 决策的常规分析。主要节奏为每月（每月 1 日运行，分析上一个已结束的月份）。每周和情景模式用于覆盖两次月度分析之间的时间。

与 personal-cfo（家庭）对应的匿名化团队范围版本。对公司账目采用相同的严谨方法（按月末交易总额、分类陷阱、情景建模）。

步骤 0 — 加载公司配置和上次运行记录

开始工作前，按以下顺序阅读：

1. ${COMPANY_CFO_ROOT:-$HOME/code/company-cfo}/ 中的配置文档（CLAUDE.md 或 AGENTS.md，以存在的文件为准）——贵公司的具体方法、数据源映射、分类规则、分配机制。**这是贵公司如何计算各项数据的权威依据。**不要自行编造方法。
2. ${COMPANY_CFO_ROOT}/reports/monthly/ 中最新的报告——上个月的快照。说明管理层做出了哪些决定，以及有哪些事项尚未解决。
3. 该文件夹中最新的 *-followup.md（如果存在）——补充决策、情景分析。
4. Agent 记忆中的任何相关笔记，或在记忆为空时查看 ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/——持续更新的背景信息：已知异常、管理层约束、当前流失情况。
5. 在 ${COMPANY_CFO_ROOT} 中运行 git log --oneline -10——上次运行后有哪些内容已发布。

如果 COMPANY_CFO_ROOT 目录尚不存在：首次运行引导会要求用户创建该目录，基于 references/company-config-template.md 创建 AGENTS.md（为 Claude Code 创建指向它的 CLAUDE.md 符号链接），并设置环境变量。

步骤 1 — 解析模式

调用方式	模式	频率
/company-cfo monthly（默认）	monthly	每月 1 日运行一次，分析上一个已结束的月份
/company-cfo weekly	weekly	简要现金动态——当前现金及未来 2 周的预期流入和流出
/company-cfo scenario <question>	scenario	在预测工具中进行临时建模
/company-cfo pickup	pickup	从上次运行中断处继续（检查 git 日志、上次报告和未解决事项）

以下章节将详细介绍月度工作流。每周和情景模式将在末尾概述。

---

月度工作流

询问用户：我们要报告哪个月份？（默认：上一个日历月。）

然后依次执行以下阶段。进入下一阶段前暂停并确认。

阶段 1 — 拉取原始数据

针对目标月份，从每个数据源拉取原始数据。标准数据源类别（各公司的实际工具见其配置文档）：

数据源类别	提供的数据	常用工具
银行／现金账户	现金实况、内部与外部转账、分配接收方	Mercury CLI、Plaid、银行直接导出的数据
支付处理平台	收入、订阅、流失、打款时间	Stripe API、Paddle、LemonSqueezy
薪资／承包商	W-2 薪资、承包商报酬	Plane、Deel、Gusto、Rippling
费用管理	报销、公司卡	Ramp、Brex、Divvy
其他收入来源	非主要账单来源	直接开票工具、其他支付平台

将所有拉取的数据保存到 ${COMPANY_CFO_ROOT}/data/YYYY-MM/<source>-*.json[l]（已加入 git 忽略——不会提交原始数据）。

还要从银行数据源拉取当前现金余额，作为“今天”的期初现金数据。

**如果某个数据源尚未接入：**先使用 /toolify <source> 接入，然后再运行 CFO 工作流。首次集成只需付出一次性成本。

阶段 2 — 分类并核对

将所有现金账户的流出归入公司使用的类别。类别初始集合及维护分类的规范，请参阅 references/categorization.md。

需要检查的常见陷阱（完整列表请参阅 references/traps.md）：

• 现金与信用卡重复计数 — 如果银行记录显示一笔“信用卡自动还款”流出，而信用卡账户又显示了单笔消费，就不要重复计算。仅筛选现金账户，或将信用卡视为负债账户。
• 内部转账 — 支票账户 ↔ 储蓄账户之间的转账净额为零。应排除（通常通过 kind=internalTransfer 筛选条件或账户配对匹配来实现）。
• 币种不一致 — 承包商付款工具通常会以收款人的提现币种返回 destination_amount。进行美元／基础币种成本分析时，始终使用 source_amount（或同等字段）。
• 分配计数 — 如果领导层有 N 位应按月获得分配款的合伙人，请核实是否有 N 笔分配款。如果只有 N-1 笔，请标记缺少的合伙人——通常是有人暂缓提取款项以平衡现金。

撰写报告前的交叉核对：

• 银行中的工资扣款总额 ≈ 工资工具 API 总额 + 费用（允许因暂扣扣款而存在少量差额）
• 本月收到的支付处理商打款 ≈ 银行中来自该处理商的流入（允许存在时间差）
• 银行中的费用管理工具流出 ≈ 费用管理工具中已批准的支出（允许存在现金收付时间差）

阶段 3 — 计算月末现金（交易汇总法）

使用交易汇总，不要使用从当前余额倒推的方法。 倒推法屡次导致 CFO 工作流出错——银行 API 在拉取时的余额快照可能相差数万美元，而且误差会传递到每个历史月末值中。

正确方法（完整步骤请参阅 references/eom-cash-methodology.md）：

# 1. Pull ALL transactions for each cash account (Checking + Savings + any other cash-holding):
#    <bank-tool> transactions list --account-id <id> --format jsonl --max-items 100000
# 2. Sum the amount field across all transactions in each account.
# 3. The sum should equal that account's CURRENT available_balance exactly.
#    (Sanity check — if not, missing data or a pre-history baseline deposit exists.)
# 4. For any past date T: balance_at_T = sum of all transactions posted on or before T
#    (plus any pre-history baseline, which should be ~$0 if the sanity check passes).

月末现金交叉核对：上月月末现金 + 本月现金净变动，应与本月月末现金精确到美元一致。

如果交易汇总无法与当前余额核对一致，不要改用倒推法作为备用方案。应先调查差额——可能是拉取数据缺失（超时、分页）、账户未知，或存在合理的历史期初余额。

阶段 4 — 更新情景预测工具

大多数 CFO 工作流都适合使用情景预测工具——一种交互式预测工具，可根据可调整的假设（收入增长、费用情景、招聘计划、分配变动）预测未来 N 个月的月末现金。

常见结构（参考实现请参阅 references/scenario-projector.md）：

• HISTORICAL（最近 3 个已结账月份）— 在 TODAY 之前提供背景信息
• TODAY — 当前实际现金余额（按日历位置标示在当前月份内）
• Mo 1 — 当前日历月份的月末（部分月份 — 本月剩余时间内的活动）
• Mo 2-7 — 接下来 6 个完整日历月份的月末（从这里开始应用情景设置）

每月：starting + revenue − expenses = profit → ending

月内现金周期低点（与每周现金脉搏相关）：大多数 CFO 系统关注的是月内的低点（现金可能触及下限的时刻），而不仅仅是高点（月底）。公式取决于付款频率——请参阅 references/scenario-projector.md。

每次月度运行时更新预测工具：

1. 将刚结账的月份及其所有类别字段追加到 HISTORICAL；删除最早的月份。
2. 将 startingCash 更新为今天的实际银行余额。
3. 对任何发生重大变化的类别，更新其费用基线。
4. 更新 baselineMrr（扣除处理费用后）。
5. 核实预设是否仍然合理（如果薪酬结构或招聘计划发生变化，可能需要更新情景）。

阶段 5 — 编写快照报告

按照 references/report-template.md 中的模板，创建 ${COMPANY_CFO_ROOT}/reports/monthly/YYYY-MM.md。章节（可根据需要调整）：

1. 执行摘要 — 标题 + 状态表（净现金、期末余额、当前 MRR、过去 N 个月、建议）
2. 现金流入 — 按来源分类（支付处理商、其他收入、一次性收入）
3. 现金流出 — 按类别分类（与预测工具的类别结构一致）
4. 工资明细 — 已核实的承包商 + W-2 分类
5. 分配款 — 谁收到了款项，谁没有（标记异常）
6. 收入指标 — 活跃订阅数、MRR 变化、近期取消情况（含金额和客户）
7. 前瞻性预测 — 预测工具给出的 1-3 个情景（链接到预测工具状态）
8. 建议采取的行动 — 供领导层决策的具体事项
9. 待处理事项 — 下个月要解决的问题

用通俗易懂的英文撰写原因说明段落：发生了什么，以及为什么。如有延续情况，请参考上个月（“供应商 X 上月流失的影响已全部体现在 6 月的付款中”）。

阶段 6 — 更新记忆

如果符合以下任一情况，请在记忆存储中更新 company_cfo_<company-slug>.md（Agent 的记忆，或 ${MAKERSKILLS_MEMORY:-${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/memory}/）：

• 分配款／薪酬结构发生变化
• 活跃订阅数或 MRR 有明显变化
• 新增收入来源（新的计费平台）
• 合作伙伴／承包商决策有变化
• 新的现金底线或分配限制

不要让记录过度膨胀。替换过时信息；不要无止境地追加。

阶段 7 — 审查并发布

遵循公司的 git 工作流：

首次运行前，检查仓库根目录中的 .gitignore，确认其中排除了原始导出文件——阶段 1 会将敏感的银行／工资／支付处理商数据写入 data/，这些内容绝不能提交。如果缺少相关规则，请添加：

cd ${COMPANY_CFO_ROOT}
# Verify .gitignore excludes raw data + secrets
if ! grep -q '^data/' .gitignore 2>/dev/null; then
  cat >> .gitignore <<'GITIGNORE'
# Raw financial data — never commit
data/
*.jsonl
*.env
*.env.local
.mcp.json
GITIGNORE
  git add .gitignore
  git commit -m "Seed .gitignore for raw financial data"
fi

然后只发布报告和预测工具变更（在此仓库中绝不要运行 git add -A——只能指定要添加的文件，以免意外提交 data/ 中的文件）：

cd ${COMPANY_CFO_ROOT}
git checkout -b feature/YYYY-MM-snapshot
git add reports/monthly/YYYY-MM.md scenarios/index.html $(ls AGENTS.md CLAUDE.md 2>/dev/null)   # targeted
git status --short                                                    # verify no data/ or .env files staged
git commit -m "YYYY-MM monthly snapshot"
git push -u origin feature/YYYY-MM-snapshot
gh pr create --base main --title "YYYY-MM monthly snapshot"

绝不要在 ${COMPANY_CFO_ROOT} 中运行 git add -A。 意外泄露 data/ 文件会将银行交易记录和合作伙伴分配款 ACH 信息推送到 git 远程仓库。只能指定要添加的文件。

合并前：进行代码审查（如适用），或手动审查差异。然后合并并删除分支。

---

每周现金状况模式

精简设计，适合在 15 分钟的每周同步会议中使用。

1. 获取当前现金余额（银行 API accounts list）
2. 获取过去 7 天的交易记录，以及未来 7 天的预定支出（工资、已知账单）
3. 计算：当前现金、下次发薪日期 + 金额、下次 Stripe 付款日期 + 金额
4. 如果现金低于未来 2 周的支出（低于现金底线），则发出提示
5. 一行状态：Cash $X | Next payroll $Y on <date> | Next inflow $Z on <date> | Floor status: OK|WATCH|BREACH

保存到 ${COMPANY_CFO_ROOT}/reports/weekly/YYYY-WW.md。

搭配 /loopify 安排每周运行（通常是周一上午 9 点）。

情景模式

按需使用——适用于“如果我们 9 月雇用一名年薪 $150K 的工程师会怎样？”或“如果流失率上升 2% 会怎样？”等问题。

打开情景预测工具，调整相关参数，然后截取结果现金预测的屏幕截图或导出结果。将分析保存到 ${COMPANY_CFO_ROOT}/reports/scenarios/YYYY-MM-DD-<question-slug>.md。

如果情景决策影响重大（新员工、分配变更、大额支出），还要运行 /decide 使决策正式化。

接续模式

从上次运行继续。列出：

1. 最近的月度报告（ls -t ${COMPANY_CFO_ROOT}/reports/monthly/*.md | head -1）
2. 最近的每周现金状况报告
3. ${COMPANY_CFO_ROOT} 的最新 git log（自上次快照以来发布了哪些内容）
4. 当前叙述对应的记忆记录
5. 上份报告 §9 中的待处理事项

不要假定训练数据中的信息仍然适用。 务必先检查报告、记忆和 git log。

协同使用

• personal-cfo — 同级技能。Personal-cfo 负责家庭财务（房屋计算、月度现金流、大额采购）。两者遵循相同的方法（交易求和法、情景建模），但适用范围不同。
• company-brain — CFO 报告会存储在其中并建立 Wiki 索引。company brain 中的 outputs/ 会累积月度报告；Wiki 页面会汇总各月的趋势。
• toolify — 接入公司专属数据源（Mercury API、Stripe、Plane、Ramp 或同类服务）。用于首次运行时的集成设置。
• loopify — 安排每月运行（每月 1 日）和每周现金状况检查（周一上午 9 点）。
• decide — 用于处理报告中发现的重大决策（分配变更、招聘、现金下限突破后的应对）。使用 37signals 框架将其正式化。
• deep-research — 用于影响情景输入的基准问题（“典型 SaaS 营销预算占 ARR 的比例是多少？”）。

质量须知

• 绝不臆造方法。 每家公司计算现金的方式都不同——请遵循 ${COMPANY_CFO_ROOT} 中公司的配置文档。若未记录，请先询问，不要猜测。
• 交易求和法不可妥协。 从余额快照回推的方法屡次导致 CFO 工作流出错。请使用原始交易求和，并与当前余额核对。
• 分类规范比准确性更重要。 每月使用相同分类，才能读取趋势；年中更改分类，会让趋势变成噪声。
• 支出基准应采用实际数据，而非“安全”估值。 如果软件支出实际为 $12K，却按 $8K 建模，就会产生过于乐观的预测，破坏模型。
• 收入应扣除处理费用，而非按总额计算。 Stripe 等支付处理商约 3% 的费用会显著影响月度现金流入。
• 月中周期低点比月底更重要。 按月结算时，现金会在月中大幅下降。现金下限适用于低点，而非月底高点。
• 每周结算会大幅平滑周期——如果支付处理商支持，将结算频率从每月改为每周，是可采取的最有效现金管理措施之一。请参阅 references/eom-cash-methodology.md。
• 数字无法对账时，请停止。 不要提交存在未解释差额的报告。请先调查——曾有一次 $42K 的对账差额悄无声息地持续了数周，后来才被发现。

不适用此技能的情况

• 临时查询单个数字（“我们目前有多少现金？”）——直接查询银行数据源即可，不要运行完整工作流。
• 税务／会计问题——不在适用范围内；请咨询 CPA。
• 个人财务——请改用 personal-cfo。
• 投资者路演财务数据——属于不同领域（多年预测、深入分析单位经济效益）。此技能涵盖日常运营中的 CFO 工作节奏，不涉及融资叙事。