forecast-contract

name	forecast-contract
description	Before accepting any time-series forecast, event judgment, or structured temporal output, force-check horizon length, output schema, numeric plausibility, label set, and uncertainty strategy.

Debug Prefix Protocol

• When called, print this first: [Skills: forecast-contract] Follow: <rules / context constraints that really apply now>; Current step: <one-line note>.
• If this skill clearly depends on one rule, add one more line like [Rules: <rule>] ..., then continue with the real work.
• The debug prefix should stay stable, short, and easy to grep.

When To Use

• You need to output future forecast sequences, interval forecasts, structured judgments, MCQ choices, post-event trend judgments, or multi-variable future trajectories.
• Before any time-series task enters the final answer or saves experiment results to disk.

Main Problems This Skill Prevents

This skill mainly prevents four common failures:

• wrong forecast horizon length
• wrong output format / schema
• values look like numbers, but their scale, direction, volatility, or regime is completely wrong
• the right answer should be Uncertain or should carry explicit uncertainty, but it is written as a hard answer

Forced Checks

1. Horizon Length

• Output length must match the task requirement exactly.
• If the task needs multi-variable output, both variable dimension and time dimension must match.
• Do not use vague handling like almost right length, missing a few points, or add a few more and cut them later.

2. Output Schema

• Write the output schema clearly first, then generate the answer.
• For classification / MCQ / structured fields, use only the allowed label set.
• For tasks that need JSON, tables, fixed fields, or fixed order, do schema self-check first.

3. Numerical Plausibility

Check at least:

• whether units and scale match history
• whether there is unexplained explosion, drift, sudden jump, or negative value
• whether volatility level is reasonable
• whether forecast values break known physical constraints, business constraints, or boundary conditions
• whether known relations between variables are broken

4. Uncertainty Strategy

• When evidence is weak, event effects are unclear, history is unstable, or the task itself allows uncertain answers, prefer Uncertain, intervals, confidence info, or explicit uncertainty instead of hard guessing.
• Uncertainty must be tied to weak evidence, regime switch, data quality, or event ambiguity. Do not write one vague line like may have errors.

Suggested Validation Style

• Fix schema and horizon before generation.
• Before generation, check again whether the flow already compared direct use / zero-shot / few-shot / frozen-backbone / light adaptation instead of training first and validating the output later.
• After generation, do a three-step self-check: length check, label check, value check.
• If validation fails, roll back earlier first and check whether the real problem comes from input length, event understanding, data contract, or time format.
• If experiments or results are being saved, still follow ztxexp.

Relation With Other Skills

• For time-series tasks, pair this skill with time-series first to understand the task, events, and length strategy.
• When input sources are complex, pair it with data-interface first to stabilize the data contract.
• In formal reports, write the validation result from this skill into the evidence section of report-writing.
• When ts-critic or critic-loop finds structured output out of control, they should call this skill explicitly.

Output Format

• Target output type
• Target horizon / schema
• Validation result
• Numerical plausibility judgment
• Uncertainty decision
• Whether the flow may enter the next step