Skip to content
cccskills
FreePublished on GitHub

forecast-accuracy

Use when constructing the forecast call — commit / best-case / pipeline categorisation, deal-level evidence test, accuracy retro-loop. Triggers on 'build the forecast', 'why does our commit miss'.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md8.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

forecast-accuracy

When to use

  • The quarterly forecast call is being constructed and the team needs a categorisation rule that survives retro — not a feel-good number that flatters this week.
  • Commit has missed two or more quarters and nobody can name which signals broke — the retro-loop is missing or the categorisation rule is unwritten.
  • A new RevOps lead inherits a pipeline and needs to rebuild the forecast call without inheriting last regime's optimism bias.

Do NOT use to design pipeline stages (route to pipeline-strategy), qualify a single deal (route to deal-qualification-meddic), or build the finance-side top-down / bottom-up model (composes against — but does not duplicate — the finance-partner forecasting capability, via the forecast-construction-shape interface).

Cognition cluster

  • Mental model 16 — Leading vs. lagging indicators. Closed-won is lagging; per-stage conversion and MEDDIC-slot completeness are leading. A forecast built on lagging signals can only confirm the result after it lands. See docs/contracts/mental-models.md § 16.
  • Mental model 29 — Premortem. Before locking the call, write the post-quarter retro as if commit missed by 20 %. The premortem surfaces which categorisations are riding on weak evidence; demote those before the call locks. See mental-models.md § 29.
  • Mental model 9 — Hypothesis-driven thinking. Each commit deal carries a falsifiable claim: "this closes by <date> because <evidence>." If the claim cannot be falsified inside the quarter, the deal is best-case, not commit. See mental-models.md § 9.
  • Context-spine — product + customer-segment. Read the product slot for what is actually GA-shippable this quarter (deals depending on non-shipped scope are not commit), and the customer-segment slot for segment-historical close rates — pricing-power and cycle-length differ by segment and the forecast must too. See context-spine.

Procedure

Step 0: Inspect — inherit pipeline + qualification artefacts

Pull stage-definitions.md, coverage-by-cell.md from pipeline-strategy, and the latest meddic-card.md per deal from deal-qualification-meddic. Inspect whether each commit-candidate deal carries falsifiable evidence per MEDDIC slot — a forecast built without that inspection is rep opinion, not categorisation.

Step 1: Lock the three categories with falsifiable rules

  1. Commit — deal closes in-window with ≥ 90 % subjective probability and MEDDIC slots all filled with evidence and decision-process has buyer-written dates inside the window.
  2. Best-case — deal could close in-window with ≥ 50 % probability and ≤ 2 MEDDIC slots unfilled and at least one decision-process date inside the window.
  3. Pipeline — everything else. Pipeline is not a forecast category; it is the population from which commit and best-case are drawn.

Reject "commit" placements that do not meet all three commit criteria, regardless of $ value or rep confidence.

Step 2: Apply the segment-historical close rate

For each deal, compute expected $ = $ × segment-historical in-window close-rate (trailing four quarters). Aggregate by category. If commit-$ exceeds (segment historical commit close-rate × pipeline-$ in commit), the call is structurally optimistic — find the optimism source before defending the number.

Step 3: Premortem the commit list

Write "if commit misses by 20 %, the reason is ___." The most common patterns: (a) one anchor deal slipped, (b) segment cycle lengthened, (c) procurement/legal queues bunched at quarter-end. Tag each commit deal with which of these would kill it; deals tagged with two or more move to best-case.

Step 4: Construct the call with confidence bands

Report commit $ = sum of commit-tagged after Step 3 demotions. Best-case $ = commit + best-case-tagged. Attach the band: "commit ± <historical-deviation>; best-case ± <historical upside>". A call without a band has no honesty about its prior miss-rate.

Step 5: Run the accuracy retro-loop at quarter-end

Compare predicted commit / best-case / pipeline to actual closed-won by category. Compute per-rep, per-segment, and per-stage miss-rate. Patterns that repeat for two quarters become categorisation rule changes in Step 1; one-off misses become deal-level evidence upgrades in Step 0.

Related Skills

WHEN to use this

  • Constructing the quarterly forecast call from a qualified pipeline.
  • Running the accuracy retro-loop and feeding it back into Step 1.

WHEN NOT to use this

  • Designing pipeline stages or per-stage conversion targets — route to pipeline-strategy.
  • Single-deal qualification or disqualification — route to deal-qualification-meddic.
  • Finance-side top-down model or board-deck forecast — composes against (does not replace) the finance-partner forecasting capability via the forecast-construction-shape interface.

When the agent should load this

  • "Build the Q3 forecast call."
  • "Why does our commit keep missing?"
  • "Run the forecast retro for last quarter."
  • "Welche Deals gehören wirklich in Commit?"

Output

  1. forecast-call.md — commit $ and best-case $ with confidence bands; per-segment breakdown.
  2. commit-list.md — one row per commit deal: $, segment, MEDDIC-completeness, decision-process date, premortem tag (none / single-risk / two-risk demoted).
  3. retro-deltas.md (at quarter-end) — predicted vs actual per category, per-segment, per-rep miss-rate, and the categorisation-rule change (if any) for next quarter.

Gotcha

  • "Strong commit" without buyer-written dates inside the window is a wish, not a forecast. Subjective probability without artefact evidence is what the retro will punish.
  • Segment-historical close rates change after a pricing change, a packaging change, or a competitive shift. Recompute the rates when the segment shape changes, otherwise the call inherits the old regime's optimism.
  • Reporting commit as a point estimate without the band hides the prior miss-rate. A team that has missed by 18 % twice and reports commit ± 0 % is performing forecasting, not doing it.

Do NOT

  • Do NOT place a deal in commit because the size is large; size is independent of evidence.
  • Do NOT skip the premortem on commit deals — most misses come from a small number of anchor deals slipping, and the premortem is where you catch them.
  • Do NOT change categorisation rules on a single-quarter miss; rules change on a two-quarter pattern.

Runnable example

End of Q2, last two commits missed by 14 % and 21 %.

  • Step 1 enforcement — three deals placed in commit had ≥ 2 MEDDIC slots open; demoted to best-case (–$ 540 k commit, +$ 540 k best-case).
  • Segment close-rate — Mid-Market historical commit close-rate is 78 %; commit-$ implies 91 % aggregate close-rate; structural optimism of ~$ 320 k.
  • Premortem — two anchor deals (each > 10 % of commit) tagged single-risk (procurement queue); one tagged two-risk (no buyer-written date) → demoted.
  • Final call — "commit $ 4.1 m ± 12 % (historical deviation); best-case $ 6.7 m + 8 % / – 14 %." Commit-list flags the two procurement-risk anchors for VP-level intervention.
  • Retro at quarter-end — predicted commit $ 4.1 m, actual $ 4.0 m; rule unchanged; one rep over-commits two quarters running → categorisation-coaching action.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

Use when defining or auditing the activation event — aha-moment selection, retention correlation, falsifiable definition. Triggers on 'what is our aha moment', 'redefine activation'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

Use when capturing an architectural decision — file naming, next ADR number, Status / Context / Decision / Consequences, index regen; fires even without saying 'ADR'.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

Adversarial critique — devil's advocate, stress-test, honest teardown ('poke holes', 'be brutal', 'was hältst du davon'); explicit request only. Routine code or design review → code-review.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

Use when reading, creating, or updating agent documentation, module docs, roadmaps, or AGENTS.md. Understands the full .augment/, agents/, and copilot-instructions structure.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

Use for an adversarial red-team / blue-team / auditor review of an AI agent's CONFIG + behaviour (rules, skills, MCP, hooks, permissions) — attack-chain → defensive-gap list, not a code audit.

The English summary is being prepared. Showing the original description.

event4u-app/agent-config12Updated Oct 18, 2026

See all skills by event4u-app

Report a problem with this skill