Weekly FP&A Digest

---
name: weekly-fpa-digest
description: >-
  Sets up a routine that drafts a recurring FP&A update — usually weekly, to
  a Slack channel — automatically, comparing the current period's numbers
  against trailing history and the same period a year ago, so a draft is
  waiting for review before you sit down. This is a routine, not a one-shot
  ask: you configure it once and it runs on its own from then on. Use
  whenever someone wants a standing finance/ops update posted on a schedule,
  or asks to automate a recurring report. Triggers include "set up a weekly
  digest", "post my numbers to Slack every Monday", "automate my weekly
  update", "recurring finance report", "schedule a digest", "daily FP&A
  update", "set this up as a routine", or describing a report they currently
  build and send by hand on a repeating cadence.
metadata:
  author: "Aleph - getaleph.com"
  version: "1.0.0"
---

# Weekly FP&A Digest

## What this skill does

This is the skill that turns into a **routine**: you configure it once, and
from then on it runs on a schedule with nobody watching, drafting the same
standing update every period so it's waiting for you instead of waiting on
you.

It pulls the current period's numbers from your connected systems, compares
them against trailing history and the same period a year ago, and drafts a
Slack message in a fixed, repeatable format. It never posts on its own by
default — it drafts, a human reviews, a human posts. See
`references/setup.md` for why that default matters and when it's safe to
change.

## When to use it

- You (or someone on the team) currently pull the same numbers and write the
  same update by hand, on a repeating cadence — weekly, daily, or monthly.
- Someone wants a standing report in Slack instead of a pull-based dashboard
  nobody checks.
- Setting up any recurring, scheduled finance or ops report.

## Requirements

Unlike a one-shot skill, this one needs to keep working without a person
attaching a fresh file every time, so it requires:

- **A live connection** to the data it's reporting on (via MCP — your ERP,
  billing system, product analytics, or a data warehouse). A pasted export
  works once; a routine needs a connection that's still there next week.
- **A destination** — the Slack channel (or other surface) the update is
  ultimately posted to, plus a reviewer who receives each draft first.
- **A surface that supports scheduling** — Cowork or Code. Chat alone can't
  run something unattended on a clock.

If someone pastes numbers with no connection in place, don't refuse the
draft: produce a one-off digest from the pasted figures, mark the Sources
line as user-provided (see the manual-run footer in
`references/output-template.md`), and note that the routine itself can't
be configured until a live connection exists.

## Setup workflow (one-time)

1. **Define the metrics** — ask the user which numbers matter (revenue,
   usage, pipeline, churn, whatever they currently track by hand) and which
   comparisons they want (trailing 7/30 days, same period last year, or
   both). Do not guess this; get it from the user or from an example of the
   report they currently send.
2. **Confirm the connection** — verify the MCP connection(s) needed to reach
   those metrics are set up. If they aren't, that's a blocker to resolve
   first, not something to paper over with a one-time paste.
3. **Set the schedule and destination** — the cadence (e.g., every Monday at
   7am), the channel the reviewed update gets posted to, and the reviewer
   the draft is delivered to (a DM or a private review channel).
4. **Build the skill** — encode the metric list, the comparison periods, and
   the output structure from `references/output-template.md` into the
   routine, per `references/setup.md`.
5. **Run it in draft mode first** — per `references/setup.md` §4, the
   routine drafts for a trial period before anyone lets it post unattended.

## What it runs, every period

1. Pulls the current period's numbers from the connected system(s).
2. Compares them against trailing history and the same period last year.
3. Drafts the update in the fixed format from `references/output-template.md`.
4. Delivers the draft to the reviewer — a DM or a private review channel,
   never the live channel — unless the user has explicitly enabled
   auto-post after a trial period, per `references/setup.md` §4.
5. Runs again next period. No re-setup needed.

## The setup details

The full configuration pattern — how to structure the schedule, how to wire
the connection, and the draft-only safety default — lives in
`references/setup.md`. Read it before configuring the routine.

## Output format

Always draft the update in the exact structure defined in
`references/output-template.md`, so the digest looks the same, and is
just as scannable, every single week.

## A note on scope

This skill drafts a recurring narrative update from live data. It is not the
system of record for that data, and it should never be the only place those
numbers live — if the connection breaks or a number looks wrong, the
underlying system, not the digest, is the source of truth.

# Setting Up the Routine

This skill is configured once and then runs unattended, which makes the
setup pass more important than for an on-demand skill — mistakes here repeat
every period until someone notices.

## 1. Pick metrics that are actually worth a recurring update

Not every number deserves a standing report. Good candidates share three
traits:

- **Someone currently checks or compiles this by hand, on a repeating
  cadence.** If nobody's doing this manually today, a routine isn't solving
  a real problem yet.
- **The comparison matters more than the raw number.** "Revenue was $412K"
  is trivia. "Revenue was $412K, up 6% vs. trailing 7 days and 22% vs. the
  same week last year" is a signal. Always pair the number with at least one
  comparison period.
- **It's stable enough to trust unattended.** A metric that's still being
  redefined, or that depends on a data source that's mid-migration, isn't
  ready for a routine yet — get it stable on demand first, automate it
  second.

Confirm the exact metric list and comparison periods with the user before
building anything. Do not infer a metric list from a generic template.

## 2. Wire the connection, don't paper over it with a paste

A routine that "worked once" because someone pasted a file is not a routine
— it's a one-time skill run wearing a schedule. Before configuring anything:

- Confirm the MCP connection(s) needed actually reach the data in question.
- If a metric requires a connection that isn't set up yet, say so plainly
  and treat it as a blocker, not a workaround.
- Note where each metric comes from (which connected system) so that when a
  number looks wrong later, there's an obvious place to check first.

## 3. Set the schedule and destination explicitly

- Cadence: most FP&A digests are weekly (a Monday morning read) or daily
  (for usage-based or high-velocity businesses). Confirm which, and the
  exact time — the value is being done *before* the person sits down, so the
  schedule should run well ahead of when they'll actually read it.
- Destination: the specific channel or surface the reviewed update gets
  posted to. Confirm this is a channel people already check, not a new one
  nobody will open. The draft itself is delivered to the reviewer — a DM or
  a private review channel — never the live channel (see §4 below).
- Check the delivery connection, not just the data connections: verify the
  Slack (or other destination) connection is actually set up and the
  reviewer who receives the draft is reachable through it. A routine that
  pulls the numbers fine but can't deliver the draft fails just as quietly
  as a broken data source.

## 4. Default to draft-only, and say why

**The routine should draft the update and stop. It should not post to a
live, shared channel on its own by default.** This isn't caution for its
own sake — it's the same principle that runs through every skill in this
library: the model drafts, a person decides. A wrong number that only a
draft-reviewer sees is a non-event. A wrong number that auto-posts to a
company-wide channel is a trust problem that outlasts the fix.

Recommend a trial period — a few weeks of draft-and-review — before the user
enables auto-post, if they want that at all. Many teams are better served
keeping the review step permanently; that's a legitimate choice, not a
failure to "finish" the automation.

## 5. Handle a broken connection loudly, not silently

If the routine runs and a connection is down or a number looks anomalous
(e.g., zero, null, or wildly outside the trailing range), it should say so
explicitly in the draft rather than posting a confident-looking update built
on bad data. A visible "couldn't reach X this week" is far better than a
wrong number nobody questions because it arrived looking normal.

## 6. Configuring the routine

Once the metrics, connections, schedule, and destination are confirmed,
wire the routine itself:

- **Schedule:** create the scheduled run wherever your surface supports one
  — a routine in Cowork, or a scheduled task in Claude Code — with an
  explicit cadence and time, e.g., every Monday at 7am. State the schedule
  plainly; don't leave the cadence implied.
- **Connection:** point the routine at the MCP connection(s) confirmed in
  §2, by name. The scheduled run needs access to them — a connection that
  only works in an interactive session isn't wired yet.
- **Delivery:** the draft goes to the reviewer — a DM or a private review
  channel, per §4 — never the live channel. Name who receives it.
- **First run in draft mode:** trigger the routine once right after
  configuring it, and have the reviewer check that first draft end to end
  before trusting the schedule. The first unattended run should never be
  the first time anyone sees the output.

# Weekly Digest — Output Format

Always draft the update in exactly this structure, every period. The
consistency is the point — a scannable, identical shape each week is what
makes a standing update actually get read instead of skimmed past.

---

## 📊 {Metric set name} — Week of {date}

**DRAFT — review before posting**

{One line, plain language, on the overall direction: "Steady week — revenue
and usage both up, deliverability flat." Never lead with a number; lead
with the read.}

---

### The numbers

| Metric | This period | {vs. trailing comparison} | {vs. prior-year comparison} |
|---|---|---|---|
| {metric 1} | {value} | {+/- % , direction} | {+/- % , direction} |
| {metric 2} | {value} | {+/- % , direction} | {+/- % , direction} |
| {metric 3} | {value} | {+/- % , direction} | {+/- % , direction} |

Set the comparison headers to match the configured cadence — e.g., "vs.
trailing 7 days" and "vs. same week last year" for a weekly digest, "vs.
trailing 30 days" and "vs. same month last year" for a monthly one.

Every row needs both comparisons if both were configured. A number with no
comparison is rarely useful in this format — don't include one without at
least one, with one exception: a point-in-time metric like cash balance may
run without one, marked explicitly as "no comparison configured" in its
comparison cells rather than left blank.

---

### Worth flagging

{0-2 bullets, only if something crossed a threshold worth a human's
attention — a metric moved unusually, a connection had a gap, a number looks
inconsistent with the rest. If nothing is worth flagging, say "Nothing
unusual this period" rather than omitting the section — an empty section
with a name is a real answer; a missing section reads as a mistake.}

---

*Drafted automatically at {time}. Sources: {which connected systems fed this
draft}. Review and post when ready.*

For a manual run from pasted numbers (no live connection), use this footer
instead:

*Drafted manually at {time}. Sources: user-provided figures — no live
connection. Review and post when ready.*

When the reviewer actually posts the update, they strip the "DRAFT — review
before posting" header and the "Review and post when ready" footer — those
are review scaffolding, not part of the posted message.

WHAT THIS FILE IS
=================
weekly-fpa-digest.skill — Sets up a recurring FP&A update routine that drafts to Slack for human review.

A .skill file is Anthropic's packaging format for Claude Skills. It is a
standard ZIP archive, nothing more. If you are reading this in a text
editor, you are looking at the raw bytes of that archive — this build is
intentionally uncompressed so the contents stay human-readable.

LOOK INSIDE YOURSELF
====================
Rename the file from .skill to .zip and extract it, or run:  unzip weekly-fpa-digest.skill
Every file inside is plain-text markdown — the instructions Claude reads.
There is no executable code in this package.

WHAT'S INSIDE
=============
  SKILL.md
  references/output-template.md
  references/setup.md
  README.txt (this file)

HOW TO USE IT
=============
Upload this file as-is to Claude: Settings -> Skills -> Add.
Or add it in Claude Cowork or Claude Code.

From Aleph (getaleph.com), the FP&A platform.
The full guide: https://www.getaleph.com/claude-skills-library
Questions: marketing@getaleph.com