# Recurring Report Builder

> Builds a reusable reporting template once, separating what stays fixed from what refreshes each period, so a recurring report takes minutes to update instead of being rebuilt from scratch every cycle. Use whenever the user needs a report that repeats on a schedule, is rebuilding the same management report from a blank page every month, or has a recurring report with no clear separation between the stable structure and the numbers that change each period.

- Skill: `natan-mohart/recurring-report-builder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add natan-mohart/recurring-report-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/natan-mohart/recurring-report-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: Natan-Mohart (https://skillmd.com/u/natan-mohart)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/natan-mohart/recurring-report-builder

---


# Recurring Report Builder

## When to use
Use whenever a report needs to go out on a repeating schedule (weekly, monthly, quarterly) and the current process is rebuilding it from scratch each time, or copying last period's file and manually finding every number that needs updating with no systematic way to know what was missed.

## What it does
Separates a recurring report into its fixed structure (sections, narrative framework, chart types, audience) and its period-varying content (the actual numbers, the specific commentary), producing a template that a future cycle can refresh quickly and consistently, rather than treating every period as a from-scratch writing exercise.

## Method
1. **Name the audience and the decision the report supports**, once, since this rarely changes period to period and should drive every structural choice below it.
2. **Fix the section structure**: what sections exist, in what order, at what level of detail — decided once and held constant, so the reader learns to navigate the report quickly across periods instead of re-orienting every time.
3. **Separate every element into fixed or variable**: chart types and axis definitions are typically fixed; the data plotted is variable. Section headers are fixed; the commentary under them is variable. Mark this explicitly so a future refresh knows exactly what to touch.
4. **Build the narrative framework once**: the kind of commentary each section needs (what changed, why, what it means) as a repeatable prompt for the writer, not a fresh invention each cycle.
5. **Define the refresh checklist**: the specific data sources to pull from, in what order, with what validation (does this number tie to the source system before it goes in the report) — this is what turns "rebuild from scratch" into "follow the checklist."
6. **Version the template deliberately.** When the structure needs to change (a new metric matters now, an old section is no longer useful), change the template itself and note the change, rather than quietly drifting the structure period to period with no record of why.
7. **Time-box the refresh** once the template exists — if refreshing consistently takes longer than a defined target (say, under an hour for a standard monthly report), that's a signal the template still has too much rebuilt-from-scratch work in it.

## Inputs
- The report's audience and the decision it needs to support
- Any existing version of the report, even an inconsistent one, to identify what's actually fixed vs. variable
- Data sources that feed the variable content each period

## Output format
Fixed section structure with the narrative framework per section; explicit fixed-vs-variable marking per element; a refresh checklist naming data sources and validation steps; a defined time-box for how long a refresh should take once the template is in place.

## Example
A monthly management report has been rebuilt from a blank document every month for a year, taking roughly six hours each cycle. Separating it into a fixed structure (five sections, each with a defined chart type and a two-sentence commentary framework) and a refresh checklist (pull revenue from the ERP, pull pipeline from the CRM, tie both to last month's closing numbers before writing commentary) cuts the refresh to under ninety minutes, with the saved time going into better commentary instead of re-deciding the report's shape every month.

## Common pitfalls
- Rebuilding the report's structure from scratch each period instead of treating structure as fixed and content as variable.
- Never defining a refresh checklist, so consistency depends entirely on one person's memory of what to update.
- Letting the structure drift silently period to period instead of deliberately versioning changes with a stated reason.