Simple Forecast / Trend Model
Build a simple, defensible forecast of a time series (revenue, demand, signups, usage) with the assumptions and method stated up front and the projection plus a confidence band as the output. Scopes the series, horizon, method, and assumptions FIRST (so the forecast isn't an unexplained black box), then builds the projection with a baseline and an interval, then reviews it for sanity against history and overfitting. Use this for forecasting a metric, projecting a trend, estimating future demand, a simple time-series projection, or a 'what will this be next quarter' estimate.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the forecastdata-analystentry
lock the series, horizon, method, and assumptions
Show working prompt
Frame the forecast before computing it. Step 1: identify the metric, its time grain (daily/weekly/monthly), and how much history you have. Step 2: inspect the history for trend, seasonality, and level shifts, and note them. Step 3: pick a method appropriate to the data and JUSTIFY it (linear/exponential trend, simple moving average, naive-seasonal, simple exponential smoothing) — prefer the simplest method the data supports; avoid overfitting short series. Step 4: state the forecast horizon and the key assumptions (no regime change, seasonality repeats). Step 5: write an acceptance-criteria checklist ('method is justified by the observed pattern', 'forecast covers the stated horizon', 'output includes a confidence/uncertainty band', 'assumptions are stated', 'projection is continuous with recent history'). Call write_task_note and write the method choice + assumptions + checklist to notes/scope.md. - Build the forecastdeveloper
compute the projection with a baseline and an uncertainty band
Show working prompt
Compute the forecast with the scoped method. Step 1: fit the chosen method to the history (e.g. fit a trend line, compute smoothing, or seasonal-naive). Step 2: project the metric over the full horizon and produce point forecasts per period. Step 3: compute an uncertainty band (e.g. +/- from the residual standard error, or a simple high/low scenario) so the output is a range, not just a line. Step 4: emit data/forecast.json with history, point forecast per period, and the band; if helpful, also render a small inline line chart of history + forecast in index.html. Step 5: ensure the forecast joins smoothly to the last actual value (no implausible jump). On a loop-back, fix only the named gaps. Call write_task_note with the projected values and the band.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Open data/forecast.json and review it for plausibility and rigor against notes/scope.md. Step 1: confirm the chosen method is justified by the observed pattern, the forecast covers the full stated horizon, and the assumptions are stated. Step 2: confirm the projection is continuous with recent actuals (no implausible jump) and the trend direction matches the history. Step 3: confirm the output includes an uncertainty band (not just a point line) that widens with the horizon or is at least present and reasonable. Step 4: re-compute one forecast period by hand from the method and confirm the model agrees. Step 5: watch for overfit or absurd extrapolation — a short, noisy series projected into a steep unbounded curve. Write PASS/FAIL per criterion; any FAIL loops back to build. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- forecast this metric
- project a trend
- estimate future demand
- time series forecast
- what will next quarter be
Source
View this craftbook on GitHub · MIT license