pre-action-verification

name	pre-action-verification
description	Use before recommending or executing any prod-touching operational action (SQL update, DB reset, helm change, manual job trigger, anything beyond local code edits) - requires reading the triggered code path, searching for recent incidents against the affected component, computing the scale delta vs verification, and stating a rollback. Confidence is not evidence.

Pre-Action Verification

Overview

Recommending or executing a prod-touching action without checking what could go wrong is the same class of dishonesty as claiming completion without verification. The blast radius of an operational action is often much larger than the code change that enabled it — and a "Done" Jira ticket plus a positive status report is not a substitute for actually checking.

Core principle: Before acting on prod, prove the action is safe with evidence, not confidence.

This is the pre-action sibling of verification-before-completion. That skill governs claims after work is done. This one governs recommendations and actions before anything touches prod.

The Iron Law

NO PROD-TOUCHING RECOMMENDATION OR ACTION WITHOUT THE FOUR GATES

If you haven't passed all four gates in this message, you cannot recommend the action.

What Counts as a Prod-Touching Action

• SQL UPDATE / INSERT / DELETE against a prod database
• Resetting status fields, flags, or counters that trigger background jobs
• Helm value changes, ArgoCD sync, image tag bumps targeting prod
• Manually triggering migration jobs, batch jobs, cron jobs
• Restarting prod pods, services, or workers
• Any operation whose effect is visible to external users or other services

Local code edits, branch-level commits, staging-only changes, and read-only queries are not prod-touching for the purposes of this skill (though they may still warrant verification per other skills).

The Four Gates

BEFORE recommending or executing any prod-touching action:

GATE 1 — CODE PATH READ
GATE 2 — LATEST-INCIDENT SEARCH
GATE 3 — SCALE DELTA COMPUTATION
GATE 4 — ROLLBACK STATEMENT

Skip any gate = recommending blind, not verifying

Gate 1: Code Path Read

Identify the entry-point function the action triggers and read it in this session. Not the design doc. Not the PR description. Not a memory entry. The actual source file.

• What does this action cause to execute? Name the function, name the file, name the line range.
• Have I read that function's body in this session? If no — Read it now.
• Are there cache lookups, dedup keys, or state mutations in the path? Apply the invariant questions from code-review-excellence → "Stateful Code & Invariants Checklist".
• Has the code changed since I last looked? git log the file.

Failure mode this catches: "The design doc says X but the implementation does Y." Function signatures lie. Status reports compress. Reading the code is the only reliable check.

Gate 2: Latest-Incident Search

Search the issue tracker for bugs filed against the affected component since the relevant code shipped.

• Component: which service, which subsystem (e.g. consistency-manager, gap-filler)
• Time window: from the ship date of the most recent relevant PR to today
• Issue types: bugs, incidents, hotfixes
• One concrete query: project = X AND created > "YYYY-MM-DD" AND (text ~ "<feature>" OR component = "<component>") AND issuetype = Bug

Failure mode this catches: A bug was filed against the exact code you're about to trigger, by someone else, after the original work shipped. "Done" stamps do not move backward when new bugs are found.

Gate 3: Scale Delta Computation

State explicitly: what was verified, and what is being proposed?

• Verification scope: how many records, symbols, users, requests was the original verification run against?
• Proposed action scope: how many records, symbols, users, requests will this action touch?
• Compute the ratio. State it numerically.

Threshold: If the proposed action is >10× the verified scope, halt and surface failure modes that would differ at scale (cache saturation, rate limits, lock contention, log volume, memory growth, runaway loops). Do not extrapolate happy-case verification across orders of magnitude.

Failure mode this catches: "It worked on staging with 1 symbol over 1 outage; it'll work on prod with 280 symbols over 14 months." The kind of bug that hides at small scale because the failure trigger requires repetition or volume.

Gate 4: Rollback Statement

State, before recommending, exactly how to undo the action if it goes wrong.

• What command reverses the change? (For DB writes: a counter-UPDATE/DELETE with explicit filter.)
• How is the bad state identified? (For batch writes: a marker column, a time range, a source tag.)
• How long until recovery is complete? (Seconds? Minutes? Hours?)
• What downstream systems are affected and need re-sync after rollback?

If the answer is "no clean rollback" → the action requires a higher bar of justification, not a lower one. Surface that explicitly.

Failure mode this catches: "We can't undo this" being discovered after the fact. Bad writes to a deduplicating store (e.g. ReplacingMergeTree with argMax(ingested_at)) are nearly impossible to roll back once a dedup view is in place.

Red Flags — STOP

• "The Jira ticket is Done, so this is safe" — Done means the code shipped, not that the action is safe
• "Staging verified, so prod is fine" — without computing the scale delta
• "It's just a SQL update" — DELETE/UPDATE on a large table with no rollback plan
• "I'll just trigger HF for this pair" — without checking what gap_filler_worker does today
• Recommending an action because the user asked for it, without independently checking the gates
• About to send a message instructing someone else to take the action

Rationalization Prevention

Excuse	Reality
"I read the PR description"	PR descriptions describe intent, not current state. Read the code.
"Memory says it's safe"	Memory captures a snapshot in time. Verify.
"The status report covers it"	Status reports compress. Read the cache lookup, not the summary of it.
"Same pattern as last time"	The code path may have changed. Re-read.
"It's a small action"	The action's scope ≠ its blast radius. Compute the delta.
"I'll just do it and watch"	Production is not the place to learn. Gate before acting.
"Rollback is obvious"	If it's obvious, writing it down costs nothing.

Key Patterns

SQL reset triggering background work:

✅ Read job-trigger code path → Search bugs since job's last deploy → 
   State affected-row count → Write rollback DELETE → THEN recommend
❌ "Yes, reset status to 0 and trigger HF"

Helm value flip on prod:

✅ Read what the flag gates → Check incidents since flag was added →
   State which services react → State how to flip back → THEN recommend
❌ "Yes, set EnableFlatFilling=true on prod"

Manual cron trigger:

✅ Read cron handler → Check job-failure incidents → Estimate runtime/
   write volume → State how to interrupt safely → THEN recommend
❌ "Yes, run the cleanup job manually"

Drafting an instruction for a teammate:

✅ All four gates pass for the action you're asking them to take →
   THEN draft the message
❌ "Артём, можешь сделать X пожалуйста" — without verifying X is safe

When To Apply

ALWAYS before:

• Drafting an operational instruction message (Slack, email, Jira comment)
• Writing a SQL query intended for execution against prod
• Recommending a helm/ArgoCD/k8s action
• Saying "yes" to any "should I do X on prod" question
• Generating a runbook step that will be executed

Rule applies even when:

• The user explicitly asks for the action
• The action seems routine
• A teammate is the one who will execute it (you still own the recommendation)
• It's "just one query"
• You're confident

Why This Matters

Recommendations carry weight. When a user asks "should I do X on prod" and you say "yes," they will act on it. If X is wrong, the consequence accrues to them and to the system. The asymmetry: the cost of running four gates is minutes; the cost of a wrong prod action can be hours to days of cleanup, lost data, or customer impact.

The failure mode this skill exists to prevent is "the design intended X but the implementation does Y, and nobody re-read the code before triggering it at a scale that was never verified." That pattern is recurrent and predictable. The gates make it visible.

The Bottom Line

No prod recommendations without the four gates.

Read the code. Search for incidents. Compute the scale delta. State the rollback.

THEN make the recommendation.

This is non-negotiable.