Prepare a weekly SaaS metrics anomaly digest

Implementation guide · untested

Source-supported actions are attributed evidence. Proposed steps, prompts, synthetic examples and checks are original editorial guidance; the workflow has not been run.

Why this agent / simpler alternative

Agent contribution

The useful agent contribution is reconciling named metric definitions across supplied datasets, explaining evidence behind a flagged movement and preparing a short investigation queue. Arithmetic should remain reproducible outside the language model.

Simpler alternative

Use a spreadsheet with locked formulas or a native analytics dashboard when the same small set of metrics comes from one source. Add narrative assistance only if interpretation and cross-source reconciliation are real recurring work.

Unsuitable when

Metric definitions or identity joins are unsettled, source data is incomplete, the audience expects audited financial reporting, or the intended use is autonomous pricing, customer action or financial forecasts.

Source-supported scope

A community recipe specifies multi-source descriptive metrics, baseline flags and a scheduled narrative. Its configuration is not verified connector code or evidence of operational delivery.

Setup — required, optional and unknown

Required

1. A metric owner who can approve the reporting calendar, customer-count unit, subscription normalization and activation definition.

2. An isolated draft workspace and redacted exports for the first trial; choose connector work only after a compatibility check.

3. A fixed aggregation specification and independent calculation method for checking the digest.

Optional

1. An approved change log of releases, campaigns and outages to compare against anomaly dates.

2. A later read-only integration plan and a separately approved reporting audience.

Unknown

1. Exact Hermes/runtime/model behavior, supported connectors, query implementation, pagination and permissions remain untested.

2. Current API limits, provider terms, pricing and data-residency suitability have not been verified.

3. The recipe's cost estimate and comparative benchmark statements are not independently substantiated.

Inputs and access

1. Name

   Subscription snapshots

   Format

   CSV/JSON: pseudonymous subscription/customer IDs, status, currency, recurring amount, interval, effective timestamps

   Source or owner

   Billing data owner

   Access scope

   Approved reporting period plus comparison windows; exclude payment credentials

   Permission needed

   Authorize these fields for the chosen processing destination; new live access needs separate approval.

2. Name

   Product cohort extract

   Format

   CSV/JSON: pseudonymous account ID, signup timestamp, activation timestamp or approved event marker

   Source or owner

   Product analytics owner

   Access scope

   Minimum fields needed for the defined cohort

   Permission needed

   Confirm linkage and permitted use; exclude raw personal-event payloads.

3. Name

   Acquisition aggregates

   Format

   CSV: report date, channel, signups and attribution convention

   Source or owner

   Marketing analytics owner

   Access scope

   Aggregated approved date range

   Permission needed

   Owner authorizes use; no ad-account writes.

4. Name

   Metric contract and context

   Format

   Text/JSON: formulas, timezone, cutoffs, currency policy, expected latency, event version and release log

   Source or owner

   Finance/product owners

   Access scope

   This reporting workflow

   Permission needed

   Owners sign off definitions; reporting audience approval is separate.

Documented source actions

1. 1

   Retrieve billing, events and acquisition data.

   Input: Stripe, product analytics and GA4

   Output: Source inputs

   Checkpoint: Connector and completeness checks unspecified.

   Source: What this skill does, item 1; Configuration ↗

2. 2

   Calculate metrics; compare with a 30-day baseline using a two-standard-deviation rule.

   Input: Inputs

   Output: Metric flags

   Checkpoint: Implementation and statistical validation unspecified.

   Source: What this skill does, items 2–3 ↗

3. 3

   Write narrative and proposed investigations; schedule Slack delivery.

   Input: Flags and context

   Output: Digest

   Checkpoint: Review approval unspecified.

   Source: What this skill does, items 4–6; How to invoke ↗

Proposed implementation steps — unexecuted

1. 1

   Write metric_contract.json before collecting data. Define MRR inclusion rules, month-normalization of billing intervals, refund treatment, active-customer unit, conversion cohort maturity, activation event version and local reporting cutoff. Record unresolved business decisions as blocking questions.

   Input: Metric contract and reporting needs

   Output: Versioned metric contract and decision log

   Checkpoint: The metric owner can reproduce each definition in plain language. Do not let a model select financial policy from column names.

2. 2

   Build input_manifest.csv with each filename, extraction timestamp, coverage start/end, timezone, currency set, row count and owner. Check missing partitions, duplicate IDs and the proportion of product records that cannot be linked to billing. Keep raw copies immutable in the approved workspace.

   Input: Three approved extracts and metric contract

   Output: Data-coverage report and join-exception queue

   Checkpoint: Stop metrics dependent on absent or stale sources. A missing value remains missing, never zero.

3. 3

   Create deterministic metric tables with numerator, denominator, formula version and source-row references. Separate currencies unless an approved conversion policy and dated rates are supplied. Reconcile opening MRR plus categorized movements to closing MRR, listing unexplained residuals.

   Input: Coverage-approved inputs

   Output: metrics.csv and reconciliation.csv

   Checkpoint: Independent arithmetic matches the chosen definitions. A residual above the owner's agreed tolerance blocks the affected financial summary.

4. 4

   Construct anomaly_candidates.csv with baseline dates, sample count, mean, spread, observed value and rule used. Exclude the current comparison period from its own baseline. Mark insufficient observations and zero spread as unevaluable. Treat any flag as a triage signal rather than proof of an incident.

   Input: Metric history, metric version and sufficient observations

   Output: Auditable anomaly table with validity status

   Checkpoint: The calculation can be recomputed without the model; definition changes or incomplete windows suppress misleading comparisons.

5. 5

   Draft a digest whose rows link to metric calculations. Separate observation, possible explanation and proposed investigation. Compare dates to releases or campaigns only as hypotheses unless direct evidence supports a cause. Include data gaps and one owner-action question per material flag.

   Input: Valid anomaly candidates and approved context log

   Output: Private digest draft and evidence map

   Checkpoint: Every number traces to a metric row; no invented market percentile, attributed cause or rollback recommendation based only on correlation.

6. 6

   Have the metric owner approve or correct the draft, then save the review result. Prepare a future-delivery specification with exact destination, permitted content, schedule, data-freshness gate and duplicate-send key. Keep delivery and recurring integration disabled until separately authorized and tested.

   Input: Digest draft, evidence map and reviewer decisions

   Output: Reviewed local digest plus proposed delivery specification

   Checkpoint: A draft is not proof of Slack delivery. Approval covers the named audience and information, not arbitrary customer-level disclosure.

Original starter prompt — proposed

Origin

editorial_proposal

Text

Prepare a private draft SaaS metrics digest for {period} using only {approved_exports}, {metric_contract} and {context_log}. First identify missing coverage and definition conflicts. Return reproducible metric rows with numerators, denominators and source references; then flag unusual changes using {anomaly_rule}. Label causal explanations as hypotheses unless direct evidence supports them. Keep currencies separate under {currency_policy}. Do not connect accounts, create credentials, schedule jobs, post messages or change billing/product settings. Stop affected calculations when data is incomplete and return the exact question for {metric_owner}.

Placeholders

1. period

2. approved_exports

3. metric_contract

4. context_log

5. anomaly_rule

6. currency_policy

7. metric_owner

Limitations

Original draft-first proposal. It neither supplies verified connectors nor grants access, scheduling or sending permission.

Synthetic worked example — not an agent run

Status

synthetic

Label

Invented arithmetic example, not company results or an executed anomaly run

Content

Period

Example week

Currency

CAD

Opening mrr

1000

Movements

New

100

Expansion

40

Contraction

-20

Churn

-50

Closing mrr

1070

Reconciliation residual

0

Activation

Activated

10

Eligible signups

40

Rate

0.25

Fixture baseline mean

0.4

Fixture baseline standard deviation

0.05

Fixture z score

-3

Draft text

MRR rises by CAD 70 in this fictional fixture. Activation is 10 of 40 eligible signups, 25%. The illustrative baseline flags it for review. Cause is unestablished; first confirm event coverage and cohort definitions.

Delivery status

not sent

Artifact url

Not specified.

Costs and effort — unmeasured

Verified prices

Setup work

1. Agree definitions across billing, product and acquisition owners.

2. Map fields, evaluate identity joins and implement a reproducible calculation layer.

3. For any later live deployment, verify exact connector read scopes and run a sandbox access check.

Recurring work

1. Check extraction freshness and reconciliations; resolve unmatched records; review explanations and proposed investigations.

Unknowns

1. Actual model/API/hosting costs and human review effort are unmeasured.

2. Provider charges and integration availability depend on the chosen accounts and plans.

3. No evidence establishes financial accuracy, time savings or return on investment.

Failure modes

1. Signal

   Closing MRR differs from opening plus categorized movements.

   Consequence

   A fluent summary conceals a billing-definition or coverage error.

2. Signal

   Event name/version changes or cohort maturity differs between periods.

   Consequence

   An apparent activation change may be measurement drift.

3. Signal

   A currency, late-arriving extract or duplicate account is silently combined.

   Consequence

   Totals and rates become incomparable.

4. Signal

   The digest asserts a release caused a decline without supporting investigation.

   Consequence

   The team may take an expensive corrective action for the wrong reason.

Recovery steps

1. Trigger

   Reconciliation or join check fails.

   Action

   Quarantine affected metric rows; trace the residual to source IDs and obtain an owner-approved rule correction. Recompute before rewriting the narrative.

   Stop condition

   Unexplained financial residual or unresolved identity mapping remains.

2. Trigger

   A baseline is invalid or the current period is incomplete.

   Action

   Label the metric unavailable, retain available observations and specify the earliest coverage needed for a comparable run.

   Stop condition

   Do not manufacture baseline values or silently carry forward old data.

3. Trigger

   A proposed explanation lacks evidence.

   Action

   Rewrite it as a question and cite the missing evidence needed; leave operational changes outside the digest workflow.

   Stop condition

   No causal assertion or action commitment is published without support and authorization.

Source-observed and proposed approval boundaries

Source observed

The recipe schedules a configured Slack destination; approval behavior is unspecified.

Editorial recommendations

1. Authorize each processing destination and the minimum business data it receives.

2. Account grants, credentials and persistent access require separate approval; never put secrets in the prompt or artifact.

3. Approve the exact reporting audience and recurring content scope before any delivery.

4. The digest does not authorize refunds, subscription changes, deployments, employee decisions or financial transactions.

Unexecuted validation plan

Fixture

Unexecuted proposal: synthetic billing rows matching the example reconciliation, 40 eligible signups with 10 activations, a known baseline of mean 0.40 and standard deviation 0.05, plus variants containing a duplicate ID, missing extract, mixed currency and changed event version.

Acceptance checks

1. Reconcile fictional closing MRR to CAD 1,070 with zero residual.

2. Return activation 25% and illustrative z-score -3.0 under the supplied calculation convention.

3. Detect the duplicate, missing-source, currency and definition-drift variants.

4. Every narrative number resolves to a calculation row; causal claims remain hypotheses.

5. No live data access, credentials, recurring jobs or external messages are needed for this fixture.

Stop conditions

1. Owner has not settled the metric definitions.

2. Any negative fixture produces a confident complete digest without a visible warning.

3. Unapproved live access or sending would be required.

4. Independent calculations and reported numbers disagree.

Executed

No

Limits

1. No APIs, connectors, schedules or message delivery were tested.

2. The public file is an instruction recipe; no end-to-end operational evidence was established here.

3. The synthetic example is illustrative bookkeeping and anomaly arithmetic, not accounting guidance or a statistical reliability claim.

4. Source publication date is unknown; file modification metadata does not establish initial publication.

5. Canadian reporting inputs require an explicit timezone/currency policy; jurisdictional or integration suitability is not established.

Guide source links

https://github.com/mergisi/awesome-hermes-agent/blob/main/skills/weekly-mrr-digest/SKILL.md ↗
documented_steps; approval_boundaries.source_observed