opencode-knowledge-work 0.0.0-stage → 0.1.0

package/content/small-business/skills/small-business-cash-flow-snapshot/SKILL.md

@@ -0,0 +1,251 @@
+---
+name: cash-flow-snapshot
+description: >
+  Reads AR/AP, historical cash timing, and known fixed costs from the ledger
+  (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) or from PayPal, Square, or Stripe — or
+  a CSV upload — and produces a 30/60/90-day cash flow forecast with
+  percentage-variance confidence bands and named risk flags. Delivers a chat
+  summary and a downloadable XLSX. Use when the user asks "forecast my cash
+  flow," "will I make payroll," mentions "runway," or says "cash crunch."
+  Falls back to CSV upload when no connector is live.
+compatibility: "Requires one or more of: a ledger MCP (MYOB, NetSuite, QuickBooks, Xero, Zoho Books), PayPal MCP, Shopify MCP, Square MCP, Stripe MCP, file upload (CSV fallback). Output uses xlsx skill."
+allowed-tools: Read, WebFetch
+---
+
+# Cash Flow Snapshot
+
+Produces a 30/60/90-day cash flow forecast with percentage-variance confidence
+bands and named risk flags. Delivers a two-part output: a concise chat summary
+and a downloadable XLSX workbook.
+
+**Quick start**
+
+> "Will I make payroll next month?"
+
+Claude pulls the current bank balance, AR/AP, and fixed costs from connected
+sources, calculates expected inflows and outflows across 30, 60, and 90-day
+windows, applies confidence bands from each customer's payment variance, and
+flags specific risks by name.
+
+---
+
+## Workflow
+
+### Step 1 — Identify available data sources
+
+Check which connectors are live. Pull from every one that is, in one batch:
+
+1. The ledger — MYOB, NetSuite, QuickBooks, Xero, or Zoho Books, whichever is connected — for AR aging, AP, fixed costs, and the cash balance. Ledgers are peers (`../../shared/connector-neutrality.md`); if two are connected, ask which is the source of record and take totals from that one only
+2. PayPal — transaction history and settlement timing
+3. Square — sales and payout history
+4. Stripe — charge and payout history
+5. Shopify — orders (`list-orders`) as the inflow, plus payout timing. Shopify on its own is enough to run: for a commerce business it is often the largest inflow. The payout read may fail because the connector's scopes exclude Shopify Payments — then ask the owner for their payout schedule and model from that; never infer a lag (`reference/v2_sources.md`)
+6. CSV upload — when no connector is connected
+
+If no connector is live and no file is attached, ask the user to either connect
+a source or upload a CSV (income/expense tabular data, any reasonable format).
+Note which sources were used in the output — this affects confidence band width.
+
+**Always establish the starting cash balance** — "will I make payroll" is a
+question about the balance, not the net. Pull it in Step 2, or ask: "What's in
+the business account right now, and as of what date?" **Never assume one.** If
+nobody knows, head the output "no opening balance — net change only" and drop
+cash-on-hand from the risk flags.
+
+### Step 2 — Pull the data
+
+**From the ledger:**
+- Balance sheet: bank and cash balances with the as-of date — the opening balance
+  (MYOB holds none; see `reference/v2_sources.md`)
+- AR aging report: customer name, invoice amount, invoice date, due date, days outstanding
+- AP: vendor name, amount due, due date
+- Recurring fixed costs: rent, payroll, subscriptions (look for recurring transactions)
+
+**From Gusto, when connected:**
+- The next payroll run's date and expected amount, and the regular pay-schedule
+  cadence — the real numbers for the biggest fixed cost, instead of inferring
+  payroll from recurring transactions. When Gusto and the ledger disagree on
+  payroll, trust Gusto for timing and amount and say so in the output
+
+**From PayPal / Stripe / Square:**
+- Settlement history: transaction date, amount, settlement date
+- Use settlement lag (transaction date → payout date) to compute each source's
+  average and variance payment delay
+
+**From CSV upload:**
+- Parse as income/expense tabular data
+- Required columns (flexible naming): date, amount, type (income or expense), description
+- If columns are ambiguous, show the header row and ask the user to confirm mapping
+
+### Step 3 — Compute historical payment timing
+
+For each AR customer (or income source from CSV), calculate:
+- **Mean payment lag** — average days from invoice/transaction date to receipt
+- **Payment variance** — standard deviation of payment lag across last 6–12 payments
+- Use variance to set confidence band width (see Step 4)
+
+If fewer than 3 payments exist for a customer, use the population mean as the
+point estimate and apply a ±30% variance band as the default. When running on
+CSV data with sufficient history (≥3 payments per source), compute the band
+from the actual payment variance — do not assume ±30%.
+
+### Step 4 — Build the 30/60/90-day forecast
+
+Produce three time windows: 0–30 days, 31–60 days, 61–90 days.
+
+For each window, compute:
+
+| Line | Method |
+|---|---|
+| Expected inflows | AR due in window, adjusted for mean payment lag |
+| Expected outflows | AP due in window + fixed costs falling in window |
+| Net cash position | Inflows − Outflows |
+| Confidence band | ± weighted average payment variance as a % of expected inflows |
+
+Confidence band formula:
+```
+band_pct = weighted_avg_stddev_days / avg_payment_lag_days
+low  = net_cash × (1 − band_pct)
+high = net_cash × (1 + band_pct)
+```
+
+Round band_pct to one decimal place. Cap at ±50% — higher variance means the
+data is too thin to model; flag it instead (see Step 5).
+
+### Step 5 — Flag named risks
+
+Scan for conditions that push the low-band estimate negative or create a
+liquidity crunch. For each risk found, produce a one-line flag:
+
+- **Late-payer risk:** "Customer X historically pays 18 days late; that shifts
+  their USD 8,400 invoice out of the 30-day window into day 48."
+- **Payroll crunch:** "Payroll (USD 22,000) hits April 15. Opening balance USD 31,000
+  on April 1, plus inflows, minus outflows, puts low-band cash on hand April 14
+  at USD 19,200. Shortfall risk: USD 2,800." Needs a sourced balance.
+- **Thin data warning:** "Only 2 payments on record for Customer Y — confidence
+  band set to default ±30%."
+- **No-connector warning:** "Running on CSV data only — no real-time AP or
+  recurring cost data. Confidence bands are wider than normal."
+
+Limit to the top 5 risks by severity (largest dollar impact first).
+
+### Step 6 — Deliver outputs
+
+**Chat summary** (always). Use a markdown table for the forecast, not a fenced
+code block — the chat surface renders markdown tables; a fenced block shows up
+as raw monospace text. Shape:
+
+- Title line: Cash Flow Snapshot — <date range>
+- Source(s): <connectors used>
+- Opening balance: AUD X,XXX as of <date> (or: none on file — net change only)
+
+Then the forecast as a markdown table, amounts carrying the business's currency
+code (`../../shared/currency-and-locale.md`), never a bare symbol:
+
+| Window | Expected | Low | High |
+|---|---|---|---|
+| 30-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |
+| 60-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |
+| 90-day net | AUD X,XXX | AUD X,XXX | AUD X,XXX |
+
+Then risks as a short bulleted list under "⚠ Risks flagged: <count>".
+
+**XLSX workbook** (always): read `xlsx/SKILL.md` first, then produce three sheets:
+
+1. **Summary** — the 30/60/90 forecast table with confidence bands. Beneath
+   each window row, expand inline sub-rows showing the individual transactions
+   that make up its inflows (green) and outflows (red). This makes the estimates
+   auditable without leaving the Summary sheet.
+
+2. **Detail** — all transactions grouped by window, sorted by date within each
+   group. Include a running net column (cumulative inflows minus outflows within
+   the window) and a subtotal row at the bottom of each window showing total
+   inflows, total outflows, and net. Grey out past transactions in a separate
+   section at the bottom for reference. Ensure all three windows have rows even
+   if one is empty — show a "No transactions in this window" placeholder row.
+
+3. **Risks** — the flagged risks with dollar impact and affected window.
+
+Save as `cash-flow-snapshot-[YYYY-MM-DD].xlsx`.
+
+**The forecast page** (always, alongside the chat summary — never instead of
+it), delivered per the owner's stored output preference — never default to a
+markdown file. Check the `## Business context` block's `Output preference`
+(shared style guide rule, `../../shared/artifact-style.md`):
+
+- **Visual artifact (the default):** render the full forecast as an HTML page
+  in the house style. The 30/60/90-day nets are stat tiles with the confidence
+  range as each tile's context line; the transaction detail is a table with
+  right-aligned tabular-nums amounts; each risk flag carries a status pill —
+  critical for a projected shortfall, warn for late-payer and thin-data flags;
+  sources and opening balance sit in a small header panel.
+- **docx / md / notion / canva preference:** deliver the same content in that
+  form — a DOCX or markdown file, a Notion page created via the connector
+  (named destination, never overwriting), or a Canva Doc created via the Canva
+  connector (a new design each run, named with the date; tables become
+  lists); fall back to the visual artifact if Notion or Canva is not
+  connected — and say that is why. The XLSX still ships alongside.
+- **Best for skill:** use the visual artifact — a forecast is read at a glance
+  and re-run often.
+
+---
+
+## After the run
+
+One line on what just happened: the forecast is built and the risks are named.
+Then offer the single most relevant next step, plus at most two others nearby:
+
+- If a payroll crunch was flagged: "can I make payroll" runs `/plan-payroll`.
+- "Who owes me money?" runs `invoice-chase` to pull collections forward.
+- "Close the month" runs `/close-month` so next forecast runs on clean books.
+
+Max three offers, and never repeat an offer the owner declined this session.
+
+## Approval gates
+
+This skill is read-only — no approval gate before generating the forecast.
+
+Remind the user after delivery:
+> "This forecast is based on [sources listed]. It is not a substitute for
+> accounting advice — verify with your bookkeeper before making financing decisions."
+
+---
+
+## More sources, and a schedule
+
+Read `reference/v2_sources.md` for the full mapping:
+
+- **Shopify** — payments inflow timing, which is often the largest single inflow for a commerce business and settles on a delay worth modeling
+- **NetSuite** — a ledger of record, common at the larger end of the segment: AR, AP, fixed costs, and the cash balance via reports and SuiteQL
+- **Xero** — a ledger of record: aged receivables, bills, bank balances, and the organisation's currency and financial year
+- **Ramp** — card spend that hasn't hit the books yet, which is the most common reason a forecast is quietly optimistic
+- **Ramp balances** — real business and treasury account balances with history. When the owner banks with Ramp this is a sourced opening balance rather than a number they had to remember
+- **MYOB** — AR and AP legs for MYOB shops. Read-only, and it holds **no bank or cash balances at all** — never source an opening balance from it
+
+Nothing about the forecast logic changes. These are additional legs into the same model.
+
+### Running on a schedule
+
+This skill is schedulable. The monthly preset is a cash heads-up before the month turns.
+
+Offer it once, after a forecast the owner found useful:
+
+```
+Want this monthly, a few days before month end? That's when it's most useful,
+and it's the same forecast you just got.
+```
+
+Scheduling is a property of this skill. There is no separate command for it.
+
+**QuickBooks summary fields lie.** Read `../../shared/quickbooks-report-traps.md` before quoting any total from a QuickBooks summary object: the AP aging summary nets vendor credits into its buckets and can show a negative overdue figure, and the P&L summary can report expenses as zero against real rows. Total the rows, or use the detail call.
+
+## Reference files
+
+| File | Load when |
+|---|---|
+| `reference/gotchas.md` | When a connector returns unexpected data or variance is extreme |
+| `reference/examples/worked-example.md` | When modeling the output format for a new data shape |
+
+## Using a tool that isn't listed
+
+The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.

package/content/small-business/skills/small-business-cash-flow-snapshot/reference/examples/worked-example.md

@@ -0,0 +1,92 @@
+# Worked example — cash-flow-snapshot
+
+**Scenario:** Small services business. QuickBooks + PayPal connected. Three
+active customers, monthly payroll, office rent.
+
+---
+
+## Input data (pulled from connectors)
+
+**AR aging (QuickBooks):**
+
+| Customer       | Invoice | Amount   | Due Date   | Days Outstanding |
+|----------------|---------|----------|------------|------------------|
+| Acme Corp      | INV-112 | USD 8,400   | Apr 10     | 12               |
+| BlueSky LLC    | INV-108 | USD 14,200  | Apr 22     | 0                |
+| Crestwood Inc  | INV-115 | USD 6,000   | May 5      | —                |
+
+**Historical payment lag (from PayPal settlements):**
+
+| Customer       | Mean Lag | Std Dev | Payments on Record |
+|----------------|----------|---------|--------------------|
+| Acme Corp      | 18 days  | 4 days  | 11                 |
+| BlueSky LLC    | 7 days   | 2 days  | 8                  |
+| Crestwood Inc  | 12 days  | 5 days  | 6                  |
+
+**Fixed costs (QuickBooks recurring AP):**
+- Payroll: USD 22,000 — hits April 15
+- Rent: USD 3,200 — hits May 1
+- Software subscriptions: USD 480 — hits May 1
+
+---
+
+## Step 3 output — adjusted inflow dates
+
+| Customer       | Invoice Amount | Adj. Receipt Date | Notes                             |
+|----------------|---------------|-------------------|-----------------------------------|
+| Acme Corp      | USD 8,400        | Apr 28            | Due Apr 10 + 18-day mean lag      |
+| BlueSky LLC    | USD 14,200       | Apr 29            | Due Apr 22 + 7-day mean lag       |
+| Crestwood Inc  | USD 6,000        | May 17            | Due May 5 + 12-day mean lag       |
+
+---
+
+## Step 4 output — 30/60/90 forecast
+
+Confidence band calculation:
+- Weighted avg stddev: 3.6 days
+- Weighted avg mean lag: 12.7 days
+- band_pct = 3.6 / 12.7 = **28.3%**
+
+| Window  | Expected Inflows | Expected Outflows | Net      | Low (−28%) | High (+28%) |
+|---------|-----------------|-------------------|----------|------------|-------------|
+| 0–30d   | USD 22,600         | USD 22,000           | +USD 600    | −USD 5,928    | +USD 7,128     |
+| 31–60d  | USD 6,000          | USD 3,680            | +USD 2,320  | +USD 1,670    | +USD 2,970     |
+| 61–90d  | USD 0              | USD 0                | USD 0       | —          | —           |
+
+---
+
+## Step 5 output — risks flagged
+
+1. **Payroll crunch:** Payroll (USD 22,000) hits April 15. Low-band inflows through
+   April 14: USD 0 (both AR receipts fall April 28–29). Shortfall risk: up to USD 22,000.
+   *Recommend: confirm receivables timing with Acme and BlueSky before April 14.*
+
+2. **Late-payer risk:** Acme Corp historically pays 18 days late. Their USD 8,400
+   invoice (due Apr 10) shifts to April 28 — after payroll.
+
+---
+
+## Step 6 output — chat summary
+
+```
+Cash Flow Snapshot — Apr 23 → Jul 21, 2026
+Sources: QuickBooks, PayPal
+
+              Expected    Low        High
+30-day net:   +USD 600      −USD 5,928    +USD 7,128
+60-day net:   +USD 2,320    +USD 1,670    +USD 2,970
+90-day net:   USD 0         —          —
+
+⚠ 2 risks flagged:
+  • Payroll crunch: USD 22K payroll hits Apr 15; AR receipts don't clear until
+    Apr 28–29. Low-band shortfall risk: up to USD 22,000.
+  • Late-payer: Acme Corp (mean 18-day lag) shifts USD 8,400 past payroll date.
+
+Confidence band: ±28% (based on historical payment variance across 3 customers).
+
+This forecast is based on QuickBooks AR/AP and PayPal settlement history.
+It is not a substitute for accounting advice — verify with your bookkeeper
+before making financing decisions.
+```
+
+**XLSX:** `cash-flow-snapshot-2026-04-23.xlsx` — Summary / Detail / Risks sheets.

package/content/small-business/skills/small-business-cash-flow-snapshot/reference/gotchas.md

@@ -0,0 +1,62 @@
+# Gotchas — cash-flow-snapshot
+
+Known edge cases and connector failure modes.
+
+---
+
+## 1. QuickBooks AR aging includes invoices already collected
+
+**Bad:** Including fully-paid invoices from the AR aging report inflates inflow
+projections. QuickBooks sometimes shows USD 0-balance invoices in aging exports.
+
+**Good:** Filter AR rows to `balance_due > 0` before computing inflows. If the
+connector doesn't expose balance_due, subtract known PayPal/Stripe settlements
+from the invoice total before including it.
+
+---
+
+## 2. PayPal settlement lag varies by transaction type
+
+**Bad:** Assuming all PayPal receipts settle in 1–2 business days. PayPal holds
+funds differently for disputes, new sellers, and high-value transactions — using
+a flat settlement assumption produces overconfident inflow timing.
+
+**Good:** Compute settlement lag from actual `transaction_date` → `completed_date`
+pairs in the PayPal transaction history. Use the computed mean and stddev per
+customer or transaction type.
+
+---
+
+## 3. CSV column names are inconsistent across accounting exports
+
+**Bad:** Requiring exact column names like "Date", "Amount", "Type". QuickBooks
+CSV exports use "Transaction Date", "Amount", "Transaction Type". Wave uses
+"Date", "Amount", "Account Type". Rigid parsing fails silently.
+
+**Good:** Fuzzy-match column headers (date → transaction date → txn date;
+amount → debit/credit; type → category → account type). Show the header row
+to the user and confirm mapping before computing — one question beats a silent
+wrong forecast.
+
+---
+
+## 4. Fixed costs hidden in one-off AP entries
+
+**Bad:** Only pulling recurring line items labeled as "recurring" in QuickBooks.
+Many SMBs don't tag fixed costs consistently — rent may appear as a one-off
+vendor bill each month.
+
+**Good:** Look for AP entries that appear in 3+ consecutive months with the same
+vendor and similar amount (±10%). Treat these as recurring fixed costs in the
+forecast. Surface the list to the user: "I'm treating these as fixed monthly
+costs — does that look right?"
+
+---
+
+## 5. Confidence band formula breaks when mean payment lag is zero
+
+**Bad:** Dividing stddev by a mean lag of 0 (e.g. immediate payment customers
+like Square POS) produces a divide-by-zero error or an infinite band.
+
+**Good:** If mean lag ≤ 1 day, set band_pct to 5% (low variance, near-immediate
+settlement). Don't attempt the division.

package/content/small-business/skills/small-business-cash-flow-snapshot/reference/v2_sources.md

@@ -0,0 +1,84 @@
+# More sources
+
+Additional data legs into the same forecast model. The logic is unchanged — these widen what it can see.
+
+Pull everything in one parallel batch. A forecast that touches five systems serially is a forecast the owner stops waiting for.
+
+---
+
+## Ledger sources — whichever is connected
+
+Ledgers are peers (`../../../shared/connector-neutrality.md`). Whichever is connected supplies the ledger legs.
+
+| Source | What it supplies |
+|---|---|
+| MYOB | **AR and AP legs only** — read-only, no bank or cash balances, and reporting reaches back three financial years |
+| NetSuite | AR, AP, fixed costs, and the cash balance, via reports and SuiteQL |
+| QuickBooks | AR aging, AP in two calls: the balance sheet's A/P line for the total, and `qbo_accounting_get_ap_aging_detail` with `due_before` set to the forecast horizon for the timing of what leaves (rows bucketed by due date, credits kept apart); the AP aging summary nets vendor credits and goes negative, so it is never the source, and an unconstrained detail call overflows (Trap 1). Plus recurring costs and the balance sheet |
+| Xero | Aged receivables, bills, bank account balances, and the organisation record (currency, financial year) |
+| Zoho Books | Cash from `list_bank_accounts` (`current_balance`, summed across active accounts); AR from `list_invoices` `status=unpaid` with `due_date` per invoice (`response_option=1` for the summed balance); AP from open `list_purchase_orders` plus `list_expenses` `status=unbilled`; the organisation record via `get_organization`. **No bill object and no cash-flow report:** recurring fixed costs come from the owner or from recurring expenses, and the forecast is built from invoice due dates and purchase-order expected dates, not from a ledger projection — say so in the sources line |
+
+**Two ledgers connected: read both, total from one.** Ask which is the source of record, say which in the output, and take every total (opening balance, AR, AP) from that one. Read the other only for detail it uniquely holds. Never sum the same figure across two ledgers.
+
+**MYOB is the one ledger that cannot give you the opening balance.** Pull AR aging, payables, sales totals, and standard payment terms from it, then ask the owner for the bank balance or take it from a processor. Heading the forecast "no opening balance — net change only" is the honest outcome when nobody can supply one.
+
+From the ledger: AR aging with due dates, AP with due dates, recurring fixed costs, and the cash balance.
+
+---
+
+## Shopify — inflow timing
+
+For a commerce business this is often the largest single inflow, and it does not arrive when the order does.
+
+Pull orders, payouts, and the payout schedule. The gap between order date and payout date is the thing that matters — a business with USD 40,000 in orders this week and a two-day payout delay has a very different 30-day picture than one on a weekly settlement cycle.
+
+Model the payout dates, not the order dates. Using order dates makes a forecast that is optimistic by exactly the settlement lag, every time.
+
+**Payouts may not be readable.** The Shopify connector's scopes exclude Shopify Payments, so payout reads fail while orders succeed. When that happens, ask the owner for their payout schedule (daily, weekly, the lag in days) and model from that, and say in the Sources line that the timing came from the owner. Never infer a settlement lag from order dates or from another store's norm.
+
+---
+
+## Ramp — the spend that hasn't landed
+
+The most common reason a cash forecast is quietly wrong: card spend that has been made but not yet coded into the books.
+
+Pull outstanding card transactions and unsubmitted expenses. Add them as a known outflow even where they have no ledger entry yet.
+
+**Ramp also answers the opening-balance question.** It exposes business and treasury account balances with history. For an owner banking on Ramp that turns "what's in the account right now" from a question into a sourced figure — which is the difference between a payroll answer and a payroll guess.
+
+Reimbursements pulled from Ramp may also live in the owner's expense tool (Expensify). Count them once.
+
+Say what was added and where it came from:
+
+```
+Outflows include USD 4,180 in card spend from Ramp that hasn't hit QuickBooks
+yet. Without it this forecast would be about USD 4k optimistic.
+```
+
+That sentence is often the single most useful line in the output.
+
+---
+
+## What doesn't change
+
+- Confidence bands still come from each customer's historical payment variance
+- Risk flags still name the specific customer, amount, and days overdue
+- The CSV path is still fully supported and still produces the same forecast
+- Never invent a number. A source that returned nothing is reported by name as unavailable
+
+---
+
+## Reporting sources
+
+Always say what the forecast was built from. Owners take these to lenders, and "based on QuickBooks and Shopify payouts through Jul 27" is what makes it defensible.
+
+List anything unavailable too:
+
+```
+Built from: QuickBooks (AR, AP, fixed costs), Shopify (payout timing), Ramp
+(uncoded card spend).
+Not available this run: Stripe — auth expired. Any Stripe revenue is missing
+from these inflows.
+```
+
+The second half matters more than the first. An owner who knows what's missing can judge the number. One who doesn't will trust it completely.

package/content/small-business/skills/small-business-close-month/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: close-month
+description: Closes the books and turns them into a decision as a three-link chain — month-end-prep reconciles the ledger against every connected payment processor and writes the P&L narrative, cash-flow-snapshot then refreshes the 30/60/90-day forecast off the newly closed numbers rather than raw ones, and report-builder publishes and distributes the close packet. Requires a ledger (MYOB, NetSuite, QuickBooks, Xero, or Zoho Books) and uses Gusto, PayPal, Ramp, Shopify, Square, and Stripe when connected, falling back to statement or CSV uploads. Trigger on "close the month," "month-end," "close the books," "reconcile," "send the close packet to my accountant," or when the owner asks why revenue or margin moved last month. An owner who wants only the reconciliation and its flags, with no forecast refresh and no packet distribution, routes to month-end-prep directly.
+allowed-tools: Read, WebFetch
+---
+
+Run the month-end chain. Close, then forecast off the closed books, then publish. The ordering is the product.
+
+Parse arguments:
+- `--month` (default: previous calendar month) — `YYYY-MM`
+- `--save-to` (default `files`) — `files` (Drive / OneDrive), `desktop`, or `both`
+
+**A ledger is required** — MYOB, NetSuite, QuickBooks, Xero, or Zoho Books, whichever is connected; they are peers (`../../shared/connector-neutrality.md`). If none is reachable, stop and say so. Reconciliation without a ledger is not a close. Offer the CSV path from `month-end-prep` rather than producing a partial packet. If two ledgers are connected, ask which holds the books being closed and name it in the packet.
+
+## Step 1 — Close and reconcile (month-end-prep)
+
+Run `month-end-prep` for the target month, start to finish.
+
+- **In:** the target month.
+- **Out:** the reconciliation table, the flagged items (uncategorized, suspicious duplicates, missing receipts), the P&L narrative, and the close packet XLSX plus one-page PDF.
+- **Gate:** `month-end-prep`'s own Step 6 sign-off holds. The owner triages every flagged item — or explicitly skips it — before anything downstream runs.
+
+**This step owns the numbers.** Nothing later in the chain recategorizes a transaction or restates revenue.
+
+### The hard gate before Step 2
+
+Do not start the forecast until the owner has signed off on the close. Say plainly what is waiting:
+
+> "Books are closed for April — USD 3,200 in variances resolved, two receipts still missing. Ready to refresh your cash forecast off these closed numbers?"
+
+If flagged items are still open, name them and ask whether to forecast anyway. A forecast built on eleven uncategorized transactions is a forecast built on a guess, and the owner deserves to know which they are getting.
+
+## Step 2 — Forecast off the closed books (cash-flow-snapshot)
+
+Run `cash-flow-snapshot` using the reconciled month as its historical base.
+
+- **In:** the closed-month figures from Step 1 — actual AR collection timing, actual fixed costs as coded, actual settlement lag.
+- **Out:** the 30/60/90-day forecast with confidence bands and named risks.
+- **Gate:** none. The forecast is read-only.
+
+**Say why this ordering matters, in the output.** A forecast run on raw books inherits every miscoded expense and every unmatched settlement. Running it after the close means the payment-timing history is real and the fixed-cost floor is right. One line is enough:
+
+> "This forecast is built on April's closed books, so the collection timing and cost floor reflect reconciled numbers — not the raw register."
+
+If the close surfaced something that moves the forecast — a duplicate vendor charge removed, a settlement finally matched — call out the delta against last month's forecast.
+
+## Step 3 — Publish and distribute (report-builder)
+
+Run `report-builder` to package and deliver the close.
+
+- **In:** the P&L narrative and packet from Step 1, the forecast from Step 2.
+- **Out:** the merged close packet — chat summary first, then the workbook. Save the definition so next month's close publishes the same pack without being described again.
+- **Gate:** saving to the owner's own drive is automatic. **Sending to an accountant or anyone else is not** — draft the message, show it, and wait.
+
+Merge, do not staple. The packet reads: what the month was, what the books say, what the next 90 days look like off those books, and what is still open.
+
+Example, Okonkwo Mechanical: "April closed at USD 84,200, up 6% on March. Margin held at 38%. Two receipts outstanding. The 30-day forecast is USD 11,400 net at the midpoint — Rosewood's USD 12,400 is the swing."
+
+## What not to do
+
+- **Do not forecast before the close is signed off.** The ordering is the entire reason this is a chain.
+- **Do not auto-fix a flagged item.** Show the gap, recommend the action, wait.
+- **Do not delete a suspected duplicate without explicit confirmation.** Show both records side by side.
+- **Do not restate a number downstream.** Step 1 owns the books; later steps cite them.
+- **Do not send the packet to an accountant without approval.**
+- **Do not proceed without a ledger.** Say what is missing, by category, and offer the CSV path.
+
+## Output
+
+End with a one-paragraph recap: revenue and margin, gaps still open, the 30-day forecast midpoint and its top risk, and the file paths. If anything was skipped rather than resolved, list it so the owner can come back to it.
+
+Also render the merged close as one HTML artifact using the house artifact style (`../../shared/artifact-style.md`) — additive to the chat recap and the packet files, never instead of them. Revenue, margin percent, and the 30-day forecast midpoint are stat tiles with their comparison as context lines; the reconciliation and flagged items are a table with tabular-nums amounts and a status pill per row (good reconciled, warn skipped, critical unresolved); the 30/60/90 forecast gets its own panel; the open-items checklist closes the page.
+
+## After the run
+
+One line: the month is closed, forecast refreshed, packet published. Then the single most relevant next step, with at most two others nearby:
+
+- If the forecast flagged a payroll risk: "can I make payroll" runs `/plan-payroll`.
+- "Who owes me money?" runs `invoice-chase` on the AR the close just confirmed.
+- "The weekly pack, on schedule" runs `/report-pack` so these numbers recur.
+
+Max three offers. Never repeat an offer the owner declined this session.
+
+## Using a tool that isn't listed
+
+The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.