Review

/operator-cmo:review

Everything else in this plugin reads the decision files. This is the only skill that writes to them, and only after showing the operator a diff.

A stack that produces but never revises its own plan is not a marketing system. It is a content mill with good manners.

Inputs

1. marketing/decisions/quarter.md: the bets, their metrics, their kill dates.
2. marketing/log/results.md: what actually happened. If it is empty or stale, say so first and ask for the numbers. Do not estimate them, and do not read activity counts as outcomes.
3. marketing/drafts/ and marketing/log/shipped.md: what was produced and what went out. The gap between the two is the review bottleneck, measured.

The weekly pass

For each bet: metric, baseline, current, target, days left, and one of three verdicts.

• On track. Nothing to change. Say it in one line and move on.
• Off track, keep. Name the specific thing that will be different next week. "Try harder" is not a thing.
• Kill. The kill condition fired. Say so plainly, name where the budget and hours move, and write the diff to quarter.md. Do not soften a fired kill condition, and do not extend the date because the bet is nearly there. The date was the decision.

Then three numbers that describe the machine rather than the market:

• Produced vs shipped. If produced is much larger than shipped, the gate is the constraint and you should throttle production, not add more skills.
• Review latency. Median hours from draft to decision. Rising latency is the early signal that the human in the loop has become the bottleneck.
• Claims flagged. Assets that needed evidence that positioning.md did not have. A rising count means positioning.md is out of date, not that the writers are careless.

The monthly pass

Everything above, plus the question the weekly pass cannot ask: is the positioning still true. Look for:

• Proof lines older than six months, or marked unverified for more than one quarter. Propose evidencing them or cutting them.
• Disqualifiers that never fired in the outbound runs, which usually means the rule is not really a rule.
• Problem language from real conversations that does not match the phrases in positioning.md. The buyers moved and the file did not.
• Anti-goals that were quietly broken. Name where.

Writing the diff

Never edit a decision file silently. Print the proposed change as a diff, give the reason in one sentence per hunk, and wait for a yes. On approval, apply the edit, bump rev:, and append a line to marketing/log/decisions.md recording what changed and why.

No em dashes.

When the answer is thin

references/operator-playbook.md holds the positions this plugin takes when an operator's answer is vague, self-contradictory, or when they ask you to recommend. Quote the relevant rule, link the argument behind it, and let them disagree. Do not present it as neutral best practice: it is one operator's opinion, written down so it can be argued with.

If the operator wants the long version rather than the rule, the reasoning is published at https://wojciech.io/insights/ and the person behind it is at https://wojciech.io/contact/.

Finish

One table of bets and verdicts, the three machine numbers, and the decision diffs applied or pending. Then the single most important sentence: what is different next week, and who does it.