本文へ移動
cccskills
無料GitHub で公開

tracking-beliefs

Separates signal from noise in metrics you cannot observe directly, updating a belief from evidence instead of reacting to the latest reading - Bayesian updates over competing explanations, and a filter that says whether this week's move is real. Use when a metric moves and someone wants to act, when diagnosing why traffic or revenue changed, when a dashboard number contradicts intuition, or when deciding whether a trend is real yet.

インストール方法を見る

含まれるファイル(4)

  • SKILL.md7.2 KB
  • evals/evals.json3.5 KB
  • references/diagnosis.md5.2 KB
  • references/noise-models.md4.7 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Tracking beliefs

You never observe the state of the business. You observe noisy readings of it. Revenue lags settlement, refunds and disputes arrive late, annual plans lump, analytics drops traffic to blockers and bots, and attribution is approximate everywhere.

Two operations, and almost every metric argument needs one of them:

  • Filtering - given a series of noisy readings, what is the underlying level, and is the latest move larger than noise explains?
  • Updating - given evidence, how should belief shift across competing explanations?

Workflow

- [ ] 1. Say what you are actually measuring, and what the reading is a proxy for
- [ ] 2. Decide whether the latest move is real
- [ ] 3. If it is real, list the explanations before looking for evidence
- [ ] 4. Update on the evidence
- [ ] 5. Act only when the belief is concentrated enough to matter

1. Reading versus state

Write both lines:

  • State (unobserved): "how much recurring revenue we are actually earning."
  • Reading (observed): "what Stripe reported as settled this week."

The gap between them is the noise model, and naming it usually resolves the argument before any maths. A weekly revenue reading with settlement lag and refunds has several percent of noise on it before anything real has happened.

2. Is the move real?

node scripts/calc.js track metric.json

Input shape: examples/track.json. The filter separates drift in the true level from measurement noise and reports, per reading, whether it fell outside what drift alone explains.

Read two things: the current level with its interval, and whether the latest reading is surprising. A reading inside the band is not evidence of anything and should not start a project. That single check kills most metric panic.

Supply processVar and observationVar when you know them. Without them the tool guesses from the series itself and says so; the guess is a starting point, not a measurement.

The intuition for the two numbers: observationVar is how much the reading bounces when nothing changed - measurable by reading the same period twice, days apart, and seeing how much it moves. processVar is how much the true level genuinely drifts per period.

3. List explanations before hunting evidence

Enumerate the competing explanations first, with priors, before going to look at anything. Two to four, mutually exclusive.

Doing this in the other order is how confirmation bias operates: you form a hypothesis, find evidence consistent with it, and never ask whether that evidence was also consistent with the alternatives. The likelihood table forces that question.

Priors come from history. If the last five unexplained traffic drops were three tracking bugs and two algorithm updates, that is your prior, and it is a better one than the current mood.

4. Update on the evidence

node scripts/calc.js belief drop.json

Input shape: examples/belief.json. Give it the prior, the transition model (how the world drifts on its own between observations), and the likelihood of the evidence you saw under each explanation.

The likelihood is the honest bit: how probable is this specific evidence if that explanation is true? Evidence that is equally likely under every explanation carries no information, however striking it looks.

The output reports how many bits of uncertainty you removed. Near zero means you learned nothing, and you should go and find a more discriminating observation - which is the valuing-information skill.

5. Act when the belief concentrates

Diffuse belief plus an expensive irreversible action is the bad combination. Options while you are still uncertain:

  • take the action that is best across the surviving explanations (stress-testing-plans)
  • take a reversible version now, the irreversible one later
  • buy a discriminating observation (valuing-information)

Output template

## Reading versus state
State (unobserved): <what we actually care about>
Reading (observed): <what the number literally measures>
Known noise sources: <lag, refunds, bots, attribution, lumpiness>

## Is the move real
<paste calc track>
Level now: <value> +/- <interval>. Latest reading: <inside the band | surprising>

## Competing explanations
<listed before investigating, each with a prior and its source>

| Explanation | prior | source | the observation that would discriminate |
|---|---|---|---|

## Update
<paste calc belief: prior vs posterior, and bits of uncertainty removed>

## What to do
<act | buy a discriminating observation | take the reversible version now>
If the belief is still diffuse, say so and name the next cheapest observation.

Gotchas

  • Start diffuse. A confident wrong prior takes many observations to recover from. When in doubt, spread the prior; over-narrow beliefs are brittle in a way that is hard to see from the inside.
  • Never assign a prior of 0. Zero prior means no evidence can ever revive that explanation. If "our tracking broke" has probability zero, you will never diagnose a tracking break.
  • If every explanation has zero likelihood, your model is wrong, not the world. The tool raises an error rather than silently renormalising. The right response is to widen the observation model or add an explanation you had not considered.
  • Week-over-week deltas conflate drift and noise. That is precisely what the filter separates. A dashboard showing raw WoW percentages is an anxiety generator.
  • The prior is not the current mood. Source it from the last several times this happened.
  • Small samples justify simple explanations. With a handful of data points, prefer the simpler story: elaborate causal chains fitted to three observations generalise worse than "this class of thing usually does that."
  • Do not re-read the same evidence twice. A number quoted in three meetings is one observation. Updating on it three times manufactures false confidence.
  • The filter assumes the noise is roughly stable. After a tracking change or a pipeline migration, the old variance no longer applies. Reset.

Reference

  • references/noise-models.md - typical noise sources by metric, and how to measure your own
  • references/diagnosis.md - the standard explanation sets for revenue, traffic and conversion drops, with likelihood tables

Related skills

  • valuing-information when the belief will not concentrate on its own
  • framing-decisions once the belief is good enough to act on
  • allocating-effort when the rate is stable and you are comparing options rather than diagnosing
  • learning-from-outcomes to check whether past diagnoses were right

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Splits scarce time, budget or traffic across competing products, channels, campaigns or variants by treating them as a multi-armed bandit - Thompson sampling over beta posteriors, with optimism for anything not yet tried enough to judge. Use when deciding what to work on next, how to divide a marketing budget, which product to prioritise, whether to kill something that is underperforming, or when picking a winner among test variants.

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

Turns a vague "what should we do about X" into a scored decision - explicit actions, an explicit unknown, an explicit prior, and one utility scale - then picks by maximum expected utility and checks the result for framing effects. Use when facing a choice between options under uncertainty, when a decision has stalled in circular debate, when someone asks "should we do A or B", or before writing any decision record, strategy memo, or roadmap commitment.

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

Turns past decisions into calibrated judgment - scoring old predictions against what happened, assigning credit for delayed results, and separating a bad decision from a good decision that lost. Use during a retrospective, postmortem, quarterly or monthly review, when reviewing decisions taken 30+ days ago, when attributing a result to a cause, or when someone claims to have called something.

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

Decides how far ahead to plan, what to discount future payoffs by, and which backlog items can be dropped without analysis - using receding-horizon planning, an explicit discount factor, and branch-and-bound pruning against the incumbent. Use when building a roadmap, prioritising a backlog, arguing about short-term versus long-term, setting quarterly or annual plans, or when planning has become an end in itself.

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

Models what a competitor will do next and what happens if you respond - best response, equilibrium, and the difference between a rival who optimises perfectly and one who does not. Use before a price change or price war, when a competitor launches something, when deciding whether to match a rival's move, when analysing a market with few players, or when someone asks "what will they do if we do this".

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

Validates a plan before committing to it - checks whether the ranking survives the assumptions, finds the most likely way it fails, and makes the trade-offs explicit via a Pareto frontier instead of an invented single score. Use before a launch, price change, migration, infrastructure change or major commitment, when running a premortem, when two objectives conflict, or when a decision depends on an assumption nobody has tested.

日本語の概要は準備中です。原文の説明を表示しています。

romainsimon/skills-for-decision-making132026年7月27日 更新

romainsimon のスキルをすべて見る

このスキルの問題を報告する