From data-analyst-aiws
Time-series forecasting workflow for analyst-grade projections, uncertainty quantification, and stakeholder-safe narratives. Use this skill when the user needs a forecast, projection, or trend extrapolation rather than a descriptive summary or a statistical test.
How this skill is triggered — by the user, by Claude, or both
Slash command
/data-analyst-aiws:data-analyst-forecastThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when the user needs a time-series forecast, projection, or forward-looking estimate rather than a retrospective summary or a hypothesis test.
Use this skill when the user needs a time-series forecast, projection, or forward-looking estimate rather than a retrospective summary or a hypothesis test.
This is a forecasting workflow:
This skill assumes:
core-aiws provides the platform SOP and /aiws-improvememory-aiws provides shared cross-project analyst memoryRead from these surfaces when available:
${CLAUDE_PLUGIN_DATA}/shared-memory/${CLAUDE_PLUGIN_DATA}/project-memory/current/Consult these references when the task touches their domain:
references/statistical-interpretation.md — for uncertainty language and interval semanticsreferences/freshness-and-caveats.md — for data-age warnings and regime-change flagsreferences/metric-definitions.md — for canonical metric names and computation rulesreferences/domain-analytics.md — for domain-specific forecasting conventionsThe default deliverable format is a Jupyter notebook (.ipynb). Before presenting the notebook to the user or passing it to a gate:
If the user explicitly requests a different format, honour that, but the notebook remains the default.
Lock down:
A forecast without a clear decision context is just a chart. Push for the "so what" before modelling.
Before touching data, agree on:
Before modelling, characterise the series:
If the effective history is shorter than two full seasonal cycles, flag this as a material limitation.
Before the gate, assemble a plan document that covers:
What we learned from the data
Proposed modelling plan
Risks and caveats
This document is the input to Gate 1. Do not present it to the user yet.
This gate is mandatory. The plan does not reach the user until it survives independent challenge by three reviewer agents.
Spawn three sub-agents in parallel. Each receives the full plan document from Step 4 (data findings, proposed model, validation strategy, risks) and is tasked with finding weaknesses before any compute is spent.
Reviewer A — Feasibility & Data Sufficiency Prompt focus: is the effective history long enough for the proposed granularity and horizon? Does the data quality support the planned imputation and outlier treatment? Are there silent gaps, frequency mismatches, or upstream schema issues that would undermine the model before it even fits? If the plan is over-ambitious given the data, say so.
Reviewer B — Methodology Fit Prompt focus: is the proposed model family the right match for the patterns found in exploration? Would the detected trend, seasonality, or autocorrelation structure be better served by an alternative? Is the holdout window representative or does it risk flattering the model? Are the parameter choices justified or just defaults that happen to be convenient?
Reviewer C — Business Alignment & Scope Prompt focus: does the plan actually answer the business question from Step 1? Is the metric the right one for the stated decision? Is the forecast horizon what the stakeholder needs, or what the data makes easy? Are asymmetric loss functions, known future events, or missing regressors being ignored when they should shape the approach?
Each reviewer returns a structured verdict:
Resolution rules:
After Gate 1 clears, present the reviewed plan to the user. Include:
Wait for explicit user approval before proceeding to modelling. If the user requests changes to scope, granularity, model choice, or data treatment, revise the plan accordingly. If changes are substantial enough to invalidate the Gate 1 review, re-run the affected reviewer(s). Do not treat silence as approval.
Default to Prophet for its transparency, built-in seasonality handling, and interpretable decomposition. It is the right first choice for most analyst-facing forecasts.
Escalate to ARIMA or SARIMAX when:
In either case:
No forecast ships without validation:
Package the deliverable as a Jupyter notebook (the default output format). Run the notebook end-to-end before proceeding — it must execute cleanly with all data queried from source, not hard-coded. Verify that computed results match the narrative.
A complete forecast deliverable includes:
Never let strong prose hide wide intervals. If the 95% band spans a range that would change the decision, say so directly.
This gate is mandatory. The forecast does not ship until it survives independent challenge by three analyst agents.
Spawn three sub-agents in parallel. Each agent receives the full forecast deliverable from Step 9 (data, model choice, validation results, narrative) and is tasked with finding weaknesses. Each challenger has a distinct focus:
Challenger A — Data & Assumptions Prompt focus: interrogate data quality, imputation choices, outlier handling, and whether the effective history length supports the chosen granularity and horizon. Look for silent data gaps, frequency mismatches, and upstream schema changes that could invalidate the series.
Challenger B — Model & Methodology Prompt focus: question model selection, parameter choices, and validation rigour. Would an alternative model family produce a materially different forecast? Are the residuals genuinely clean or is structure being ignored? Is the holdout period representative or does it cherry-pick a calm window?
Challenger C — Stakeholder & Decision risk Prompt focus: stress-test the narrative and the uncertainty communication. Does the deliverable honestly convey what the confidence intervals mean for the decision at hand? Are regime-change risks, missing regressors, or asymmetric loss functions adequately surfaced? Would a non-technical reader walk away with false confidence?
Each challenger returns a structured verdict:
Resolution rules:
Do not suppress or summarise away challenger objections. If a challenger raises a legitimate concern and you disagree, document the disagreement and your reasoning in the deliverable.
After Gate 2 clears, present the final deliverable to the user. Include:
This is a review and discussion step, not a hand-off. The user may request refinements — changes to the narrative tone, different confidence interval widths, additional scenario analysis, or deeper investigation of a challenger concern. Incorporate changes and, if they are substantial enough to invalidate a Gate 2 verdict, re-run the affected challenger(s).
Do not proceed until the user explicitly approves the deliverable. Do not treat silence as approval.
After every non-lightweight forecasting task, run Phase 9 self-improvement through /aiws-improve.
Capture:
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub sashakang/ai-workspace