overnight-workflows

The LAST MILE of a de-stale (protocol step 9): a corrected observational finding is not shipped until every RENDERED surface matches the ledger. Use AFTER the honest ledger (step 8) whenever a figure or a marker-vs-lever / causal verdict changes and that number already appears on a live surface — a served/baked HTML page, an embedded chart image, a client+dashboard "twin" pair, a dashboard payload or cache table. The trap: you correct the TEXT/captions and believe you shipped, but the baked chart image still renders the retired number (and its old causal title), a twin doc still asserts the retired claim, or a cached payload still serves the old value — so a corrected caption sits next to a chart that contradicts it. Also covers HOW to draw a retired-causal / marker-not-lever finding honestly. Trigger when you edit a figure that is displayed anywhere, or review a de-stale PR for completeness.

Run an overnight autonomous workflow that takes a cluster of related GitHub issues (typically a P1 review-panel finding set) and ships them to merged PRs by morning. Use when: (1) the user wants 6-15 related issues closed in one autonomous run, (2) the issues split naturally into two PRs (e.g., hardening + features, or refactor + new-functionality), (3) the user is going to sleep and won't be available to merge PR1 between phases, (4) each issue has clear acceptance criteria so each task can be implemented + tested + reviewed independently. Specializes `superpowers:subagent-driven- development` for the "issues -> stacked PRs by morning" problem shape: stacks PR2 on PR1's branch (so PR2 doesn't wait for human PR1-merge mid- night), audits tracker IDs against main before claiming (concurrent sessions steal ids), runs final code-review subagent before proposing merge, and surfaces important findings as PR comments before squashing (so review trail survives). Sister plugin to `overnight-review-client- delivery` (

Guard the step where a VALID early-funnel lift becomes a recommendation. A segment genuinely starts/converts more at stage N — and the write-up is about to say "prioritize this segment" as if that buys the END outcome (enrollment, purchase, activation). Use when: (1) a finding, headline, card, or play recommends tilting effort toward a segment based on a stage-N rate (lead→start, start→submit, signup→trial); (2) the favored segment funnels into a capacity-capped or selective downstream stage (limited seats/inventory/approval slots, an admissions committee, a review queue); (3) you are REWORDING or promoting an existing funnel-stage finding — the reword inherits the original's stage scope, so re-check it; (4) a stakeholder asks "but doesn't that program/product only take a few?". The lift can be real AND the recommendation still over-promise: extra stage-N entrants feed a bottleneck, not the end outcome. Distinct from cohort-milestone-lift-is-funnel-position-not-effect (which attacks the lift's VALIDITY); here

The validity gate for any finding from OBSERVATIONAL data (no randomization). Use this BEFORE trusting or shipping a data finding, and when reviewing/verifying one. Runs a 9-step protocol — leak-free point-in-time cohort · probe outcome−anchor before an event-anchored design · decompose pooled rates by the structural axis (composition / Simpson) · de-confound with a multiple-testing-corrected regression · marker-vs-lever discipline · coverage-limited-join unbiasedness · triple-probe headlines · honest de-stale ledger · ship the correction to every rendered surface — that catches the finding which is genuinely surprising but WRONG (a composition artifact, a leak, an anchor-timing inversion, or an intent marker sold as a lever). Invoke whenever you analyze funnels, cohorts, lift, conversion rates, feature signals, retention, or any "do X → they convert / advance" claim from observational data; whenever a gradient or effect "looks too good"; and whenever you verify a finding before it reaches a stakeholder. The

A request to ELEVATE / amplify / feature an existing number that's already in a deliverable — turn a prose figure into a chart, make it a headline, restore "the breakdown we had" — is itself the trigger to re-verify that number's provenance BEFORE amplifying it. Use when: (1) asked to add a visual/chart for a number that already exists as text, (2) asked to make an existing stat more prominent, (3) a stakeholder says "we had this insight, put it back / show it bigger", (4) a number was seeded earlier as "client feedback" / "stakeholder feedback" / "per the reviewer" and is being built on. Pre-existing and especially stakeholder-contributed numbers carry FALSE AUTHORITY — they look already-vetted, so they skip the provenance scrutiny a brand-new number gets, and may trace to nothing. Verify (grep the source, re-derive with triple-probe) before making them louder. Prevents amplifying a fabrication.

When you orchestrate verification subagents AFTER reading the claims/numbers yourself, do NOT hand the agents the published number to "check" — that anchors them into replicate-and-confirm, not independent verification, and their agreement proves nothing because you already knew the answer. Instead BLIND the re-derivation pass: give each agent the QUESTION, not the number ("what % of X are Y?", never "verify it's 43%"). Put the published number only in front of a SECOND, adversary pass whose job is to break it via a DIFFERENT join/source. Use when: (1) you've read a finding doc / analysis / PR claim in full and are about to dispatch agents to verify it; (2) you're writing a re-derivation/triple-check/fact-check subagent prompt and tempted to include the target number "so they know what to confirm"; (3) a handoff asks you to "independently re-derive" something whose answer is already written in the doc you were handed; (4) you want subagent convergence to mean real agreement, not anchoring on a number you leak

Diagnose silent monotonicity violations (e.g. "Low bucket has higher conversion rate than High bucket" on a rank-quality chart, or any reverse-ordered metric on a model-quality dashboard) caused by broadening a cohort filter in one CTE while leaving sibling event/stage-source CTEs at their original narrower scope. Use when: (1) you just removed or relaxed a `WHERE period IN (...)` / `WHERE scope = X` / similar scope filter on a cohort-defining CTE to broaden coverage (e.g. "include all scored records, not just period-A applicants"), (2) the downstream JOIN pulls in a `funnel_stage` / `latest_status` / `enrollment_state` field from a separate row in the same table, (3) a rank-quality chart suddenly shows reverse-ordered or otherwise impossible numbers (Low > High on Net/cumulative rate, while per-step conditional rates look fine), (4) the per-step transition rates (conditional on prior stage) look reasonable but the "% of full cohort reached final stage" column is broken. Root cause: cohort CTE now spans perio

Diagnose the trap where a cohort defined by a LATE-funnel milestone (aid application filed, application submitted, deposit paid, event attended, document received) shows a strong raw outcome "lift" — and you're about to frame a client/dashboard action ("these convert higher, target/nudge them"). Use when: (1) a cohort's raw conversion/deposit/enrollment rate is much higher than a comparison group (+5–25pp) and the cohort membership is itself reached only AFTER getting partway down the funnel; (2) the comparison ("non-X") group is contaminated by a population that structurally CAN'T have the milestone (e.g. non-domestic applicants can't file a domestic aid form); (3) someone proposes a new feature or a "high-yield" nudge card off that gap. The raw gap is composition + funnel position, not a causal effect of the milestone. Decisive test = matched-grain stratification holding the confounders fixed in BOTH arms; sign-instability across strata is the fingerprint of residual composition; beware the seductive positi

Methodology for breaking a multi-stage conversion FUNNEL down by a SEGMENT to find WHERE in the funnel the segment acts (not just whether it correlates with the final outcome). Use when: (1) asked to break a funnel — signup→activate→subscribe, applied→submitted→accepted→deposited→enrolled, cart→checkout→purchase — down by a segment dimension (geography, scholarship/plan tier, acquisition channel/source, campaign-touch, engagement band, plan type, cohort timing); (2) someone is about to headline a POOLED/MARGINAL "segment X converts more" number; (3) the segment value is correlated with a dominant axis (account level, product line, plan) so the pooled number could be composition; (4) the segmenting attribute might itself be recorded/awarded only AFTER reaching a downstream stage. Three things this prevents: (a) reporting a pooled segment→outcome rate that is really level/program COMPOSITION (read WITHIN the dominant stratum instead); (b) missing that the segment's whole effect concentrates at ONE transition (e

When you can only observe an outcome/attribute on a SUBSET of the population because the join/linkage/bridge is coverage-limited — imperfect identity resolution, a side child-table that only covers some rows, partial instrumentation, survey non-response — validate the restricted estimate is UNBIASED before reporting it. Use when: (1) a join covers only X% of rows and you're about to either treat unmatched rows as null/negative OR report the matched-subset rate as the population rate; (2) the primary record has no foreign key to the entity you need and you found a peripheral table that carries both keys as a bridge; (3) you're weighing "rebuild the full linkage" vs "use the partial one." The technique: find an INDEPENDENT full-coverage reference for the same quantity and compare the bridged-subset rate to it — match ⇒ missingness is ~ignorable (MAR), report with a coverage caveat; diverge ⇒ the gap is informative (MNAR), the restricted estimate is biased and must be recovered or bounded. Prevents silently ship

Verify that external data files in a repository are genuine (not fabricated or hallucinated by an AI agent). Use this skill whenever you encounter data files from external sources (CSV, JSON, Excel) that were committed by an automated process or a previous AI session. Also use when the user asks to "check data", "verify data sources", "audit data files", "check if this data is real", or when you notice data files without clear provenance documentation. Trigger proactively when inheriting a codebase with data/ directories containing external datasets (weather, search trends, economic indices, etc.) — these are the highest-risk files for AI fabrication. Also trigger when the user asks to add a .provenance.md file or document where data came from.

Use when scoping, defining, filtering, or categorizing something whose stated purpose is to "highlight our strength / differentiator", "show what makes us different", "surface what we have that [a competitor / a prior vendor / another team] doesn't", or "lead with our unique value". Triggers during brainstorming / requirements / taxonomy design — the moment you're about to lock the definition of the category the deliverable hangs on. The trap: defining the category by its broad CONCEPT (the signal) instead of by PROVENANCE (the source). A concept-based definition silently includes items that match the concept but come from the same source the competitor already has — so badging them as "our differentiator" invites "we already had that". Use also when reviewing such a definition, or when an advisor / reviewer flags that a scope answer "conflates source with signal".

Independently verify a published data finding, dashboard action card, or a PRIOR retraction/downgrade of one — by re-deriving every headline number from the live database with parallel triple-probing subagents, zero trust in finding docs / ADRs / prior probe files. Use this whenever the user says "verify the rest of the cards", "re-check finding X", "was that retraction correct?", "did we actually verify these cohorts?", "the revalidation deferred half the findings", "sweep the action page", or hands you a verification handoff prompt. Also trigger when a revalidation effort recorded deferred/can't-probe cohorts as "no retract" (false-confidence smell), when a finding sits on a snapshot-vs-history temporal-gate data layer, or when a retraction's stated *rationale* needs an independent check (the number may be real but direction-reversed). Sister to `published-claim-not-in-any-source-finding-retraction` (that EXECUTES a retraction; this DECIDES whether one is warranted) and `whole-dashboard-factcheck-via-parall

Diagnose the trap where you A/B two MODEL VERSIONS by re-bucketing the SAME frozen-cohort outcome matrix (a dashboard/funnel matrix that freezes each unit's bucket at its first score since date X) with a NEWER model's scores, and the newer model looks dramatically better at sorting a downstream/forward outcome. Use when: (1) a prompt/plan calls re-scoring a live cohort with the new model and recomputing a transition/conversion matrix a "clean A/B" between versions, (2) the new model's top bucket hits ~100% (or the bottom ~0%) on a FORWARD transition — a near-perfect monotone gradient (e.g. 1.0/0.94/0.43/0.04), (3) the two versions occupy DISJOINT time windows because the cutover was a one-time switch, so the newer model was only ever scored LATER — contemporaneous with (or after) the outcome it's being "graded" on. The newer score reads PIT/current-state features that REFLECT the realized outcome (deposit/convert status already set) → it is reading the outcome, not predicting it. A 100% forward rate on a real

Methodology for "what can we DO to move users from funnel stage A to stage B" analyses where the deliverable is a list of ACTIONABLE LEVERS (interventions), not just correlates. Use when: (1) a client/PM asks "how do we get more people to advance from <stage A> to <stage B>" (stalled→submitted, signup→activate, trial→paid, cart→checkout) and you must recommend interventions; (2) you have a behavior/event table and are about to rank levers by raw or adjusted lift on the transition; (3) the a-priori "strongest" lever is itself part of the transition act (uploading a doc to submit, completing a checklist that IS submission) so its lift is the act-in-disguise; (4) a behavior shows a NEGATIVE or null RAW association that flips POSITIVE once you control stage/level (Simpson). The fix is a DE-LEAKED FORWARD-GAP TEST: measure the predictor in an EARLY window strictly before the outcome window, measure the outcome in a LATER gap-separated window, AMONG users still un-transitioned at the gap boundary — a surviving effe

When specifying a rolling-window or lookback-window parameter for a monitored metric — especially conversion rates, attribution windows, retention cohorts, or any rate defined as (numerator in window X) / (denominator in window Y shifted by lag Z) — the chosen window length is only defensible if it is calibrated against the actual measured distribution of the underlying event-time lag. A "14-day lookback" for a process whose median completion time is 35 days captures only ~30% of events; a "14-day lookback" for a process whose median is 13 days captures ~50% and is defensible. Use this skill when: (1) writing a metric definition that includes a numeric window parameter (7d, 14d, 28d, 30d, etc.) without explicit justification, (2) reviewing a dashboard or signal catalog where multiple conversion-rate signals share the same window length by default (a sign that no one measured the actual lag distribution), (3) a stakeholder asks "why 14 days?" and the answer is "that's what the spec said", (4) anomaly detection

Decide go/no-go on a candidate ML feature that derives from a SNAPSHOT field with NO point-in-time history table — where joining today's value onto historical training rows back-applies the future and leaks. Two branches with opposite resolutions. Use when: (1) scoring a CRM/account/lead snapshot field (transfer credits, age, status, score) as a model feature and there's no `*_history`/`*_audit`/`*_cdc` for it; (2) a candidate shows a strong incremental gradient you suspect is partly post-outcome leak; (3) someone proposes proving value with a naive with/without ablation; (4) a time-varying attribute (age, tenure, days-since-X) is stored as a recomputed snapshot. Covers: derive-from-immutable-anchor (birthdate→age, created_date→tenure) for PIT-exact with NO history table; and the asymmetric ablation-upper-bound rule when PIT is truly unsatisfiable.

A "conversion / never-convert / progression" rate for a near-absorbing funnel state (created-not- submitted, abandoned-cart, stalled-ticket, dormant-lead, draft-not-finished) swings by orders of magnitude depending on WHEN you observe the pool, NOT on a data error. Observe each record at CREATION-time → high conversion (fast movers included). Observe the pool as it sits at a LATE SNAPSHOT date → near-zero conversion / ~99% "never move" — because the fast movers already drained out, leaving the dead-draft RESIDUE. Use when: (1) reconciling two or more "X% never convert" numbers that disagree wildly (e.g. under 1% vs ~65% vs ~90%), (2) a "99% never move / near-absorbing state" stat is quoted as the conversion baseline for an actionable cohort, (3) a denominator is "everyone currently in status S" read at one date. Fix: before calling the numbers contradictory, align them on ONE outcome and re-derive that outcome observed AT record-creation (the unconditional rate) vs at the late snapshot (the residue rate) on t

Fix the "0% conversion in named stage bucket" false-negative when evaluating a sub-stratification feature on snapshot-based ML training data. Use when: (1) running a multi-query feature-evaluator diagnostic and observing 0% outcome rate in a transitional-stage bucket (e.g., In-Process, Pending, Quote-Sent, Lead-New) with statistically meaningful N, (2) considering rejecting a candidate feature that sub-stratifies that bucket, (3) the training data is built from a current-state snapshot with a temporal gate like `decision_at <= target_date`. The bug: current-snapshot-based SQL typically sends pre-decision progressors to a NULL bucket, not the named transitional bucket. The named bucket self-selects for non-progressors (deterministic 0%). Sub-features within it cannot rescue that. But the feature may still have signal in the NULL bucket where progressors hide. Always stratify NULL by (was-gate-condition-met-at-T, has-submitted, etc.) before concluding a sub-stratification feature is useless.

When you have independently re-derived a subagent's / analysis doc's / PR claim's number "to the digit" and it MATCHED — and you're about to treat the finding as verified. The trap: arithmetic re-derivation confirms the VALUE only; it is STRUCTURALLY BLIND to a wrong label / cohort / conditioning / denominator / definition. A number can reproduce EXACTLY while meaning something else entirely, so "it re-derives" is NOT "the claim is true." Use when: (1) you re-ran a query/computation, got the same value, and feel the finding is now confirmed; (2) verifying analysis findings, fairness stats, dashboard chart values, funnel rates, or any claim that pairs a number with a noun-phrase ("engagement rate", "forward apply→enroll", "deposit when engaged"); (3) folding subagent-reported numbers into a ledger / client deliverable; (4) a re-derivation matches but an adversarial reader (advisor, second agent, the user) reads the same number differently. The fix: verify what each number MEANS against the source — its label,

Use when a user or task asks to COMPARE performance, cost, speed, or quality across model versions (e.g. an older vs newer LLM release), app/prompt/config versions, or any setting that was switched once — using OBSERVATIONAL usage logs, analytics, or a dashboard rather than a controlled experiment. The version is almost always COLLINEAR WITH TIME (you switched on a date), so any cross-version delta is confounded by everything else that changed then (task mix, effort, cohort, season). Trigger this whenever: (1) building or reviewing a "compare versions / configs" chart or a model/effort/version breakdown, (2) about to label a bar "v2 is faster/cheaper/better" from logs, (3) a stakeholder asks "is the new model performing better?" and the only data is historical usage. Prescription: reframe comparison → descriptive breakdown over time, surface the confound ON the view, strip superlative copy, and point to a controlled eval as the only honest performance verdict.

Use whenever a subagent is asked to do a point-in-time (PIT) or historical-reconstruction join that involves bucketing entities by status codes, stage labels, or category mappings — and the project has a canonical source-of-truth for those code lists (e.g., `stage_codes.py`, `cohort_definitions.py`, a shared constants module). Triggers on "PIT probe", "historical reconstruction", "rewind to date X", "as-of-the-anchor reconstruction", "snapshot vs PIT", "stage-conditioned cut at historical date", or any subagent-dispatched data-pipeline work where status-code-to-bucket mapping is in scope. The orchestrator MUST either (a) bake the canonical code constants into the subagent's prompt verbatim, OR (b) independently re-derive the subagent's headline cells using the canonical constants before promoting any result into a doc, follow-on PR, or downstream decision. Subagents under time pressure use plausible-looking but non-canonical code lists, and PIT joins are sign-flip prone when the code list is wrong. Skipping t

TRAP — building a per-stage (or per-state) cohort from a DAILY POINT-IN-TIME entity×date feature panel by anchoring on each entity's FIRST PANEL APPEARANCE at that stage is a PREVALENT-cohort anchor: it is left-truncated and can FLIP THE SIGN of a real effect. Use when: (1) you measure "does attribute A (a completion flag, a status, a score) at stage S associate with outcome Y" by taking each entity's earliest panel row where status==S; (2) the result is surprising — flipped negative, or null — and CONTRADICTS a known benchmark for that stage; (3) a `days_since_<stage_event>` feature on those anchored rows has a huge median (the entity has been in the stage for months — caught mid-stage, not at entry); (4) the stage is "sticky" or residue-prone (deposited-not-enrolled, accepted-not-acted, churn-risk) so the prevalent pool is enriched for the stalled/melt subset. FIX: anchor at INCIDENT stage-ENTRY and validate against a benchmark. See also: exposure-sliced-by-stage-at-event-window-defined-by-outcome, cohort-m

Decide whether to include a NEW sister/variant cohort in an existing aggregate metric (worklist total, "across cohorts" KPI, hero pipeline count) when the new cohort has high logical overlap with one of the existing contributors. Use when: (1) you're adding a cohort C' that is a sharp/broad/strict/loose VARIANT of an existing cohort C (e.g., a "sharp" ≥1-of-top-3-signals cut and a "broad" ≥4-of-8-behaviors cut of the same upstream pool, or a "high-confidence" subset of an existing alert), (2) the surface has an existing aggregate metric that sums sizes across cohorts (often disclaimed as "across cohorts, may overlap" or "not deduped"), (3) C and C' have >50% logical membership overlap by design, (4) you're tempted to extend the sum naively to include C'. Trap: the existing "may overlap" disclaimer is defensible at low overlap (<30%, e.g. cross-funnel-stage cohorts) but BREAKS DOWN at high overlap — including C' double-counts most of C's contribution and visibly inflates a stakeholder-facing metric. Provides t

A RATE (accept rate, win rate, conversion rate, churn rate, approval rate) computed over a current-state SNAPSHOT table is biased when the snapshot differentially retains/prunes one outcome class — losers/denials/cancellations often churn out faster (status overwritten to Withdrawn/Closed/Deleted) than winners. Use when: (1) computing a per-segment accept/admit/ conversion rate FROM a snapshot/upserted table, (2) a rate looks suspiciously high/clean, (3) a denominator is "everyone with a decision" but read from current state, (4) ranking segments by a rate where the ranking itself is the deliverable. Fix: count numerator AND denominator from the immutable event/history log (the full outcome universe), use the snapshot only for attribution. NOT PIT feature leakage (that's a future value back-stamped onto a past row); this is present-tense selection bias in the rate's denominator.

Measure — don't assert — whether a snapshot-sourced TRAINING feature leaks point-in-time (PIT) information, and turn "this field is static, the snapshot is fine" into a per-field GO/FIX/INVESTIGATE verdict backed by a number. Use when: (1) an ML training pipeline reads a current-state SNAPSHOT table (e.g. `crm_account`, `dim_customer`, a CRM/MDM current view) for a feature evaluated at a historical `target_date`/`as_of_date`; (2) someone justified the snapshot as a "static attribute" by engineering judgment, never a check; (3) you must justify EACH remaining snapshot field before a cutover/audit; (4) a `*_history` / CDC / field-history table exists for the entity. The core measure: leak rate = fraction of MATERIALIZED training rows whose field-history shows ≥1 change dated AFTER that row's target_date (equivalently MAX(change_ts per key) > target_date) — that is exactly the share of rows where today's snapshot value differs from the value the model should have seen. Includes: the exact SQL template (single-ho

Use when reviewing/building a regression, forecasting, BSTS, or causal-inference pipeline that assembles a covariate / feature / regressor list and guards against including the outcome — i.e. you see a filter like `[c for c in x_cols if c != y_col]`, `cols.drop(target)`, `features.remove(label)`, "outcome must not be a covariate", or "exclude the target column". The trap: that guard excludes ONLY the exact target column NAME, so a column that is a deterministic TRANSFORM of the target — `log_<target>` (= log1p(y)), `<target>_scaled`, `<target>_lag0`, a standardized or Box-Cox version, a ratio whose numerator is the target — slips through and becomes a regressor. A feature that IS the target (on another scale) gets a fitted weight ≈ 1.0, "explains" the outcome trivially, and CONTAMINATES the whole fit (near-perfect counterfactual → meaningless effect estimate / CI / p-value), not just a display. Trigger also when a per-feature weight/importance panel shows one covariate ≈ 1.0 dominating everything else by ~100

Use when testing whether two binary levers/signals SYNERGIZE — i.e. any "do A and B together beat the sum of their parts" / "super-additive interaction" / "compound effect" / "do these stack" question on a 2×2 of a binary outcome (enroll, convert, retain, click). Two traps that flip the verdict: (1) "super-additive" is SCALE-DEPENDENT — a real +Npp gap on the risk-difference (probability) scale can be exactly ZERO on the odds/logit scale (the levers stack multiplicatively, no interaction), so a blanket "synergy" or "no synergy" claim is wrong without naming the scale; (2) a pooled difference-in-differences that "DISSOLVES under a confounder control" can be a SIMPSON'S-PARADOX artifact when one stratum sits near a rate CEILING (~50%+) and therefore carries a spurious NEGATIVE additive interaction that cancels a real positive one in another stratum. Trigger phrases: "is the combination super-additive", "do the two signals interact", "stack / compound / synergy", "the interaction dissolves under controls", "join

Use when DESIGNING or building a conformance judge / verifier / linter / LLM-as-judge / golden-render check / "does the output honestly reflect the input" gate — anything that validates a DERIVED or RENDERED artifact (HTML, report, serialized payload, dashboard, doc) against the source it was produced from. The trap: the verifier reads its "expected" values from the SAME intermediate artifact the producer already emitted (the serialized framing dict the template consumed, the metadata the renderer wrote, the cached classification) — so the check compares a value to itself and PASSES tautologically on the exact dishonesty it exists to catch (e.g. a "green badge on a negative result" passes because the badge token and the expected token came from the same already-computed dict). Fix + design rule: the verifier must RE-DERIVE its expectations from the RAW inputs by calling the producer logic ITSELF (classify/compute from the source bundle), never trust the intermediate artifact under test. Use when: (1) writing

Decide whether a ranked cohort/segment metric that is confounded by a covariate has a REAL, actionable within-stratum residual — or just re-expresses the covariate. Use when: (1) you have a descriptive ranking of members (programs, majors, lead sources, segments, regions) by an outcome RATE (enroll %, convert %, retain %) and are asked to make it "actionable"; (2) the ranking is confounded by a known covariate (level, funnel stage, product type, cohort vintage); (3) you are about to compute "within-<covariate>" rates to de-confound; (4) the dataset is small so the OUTCOME EVENTS (numerator), not the population, are the binding constraint; (5) you have ≥2 time snapshots/anchors of the same cohort. Prevents the trap of naming a member "actionable" off a pooled, population-floored within-stratum comparison. The make-or-break: floor on outcome events (not population), split the time-anchors (don't pool) and test directional stability, and expect the matched-grain (second-covariate) leg to fall below the event flo

Run an overnight autonomous B-vs-C parallel insight-discovery workflow that surfaces ah-ha findings from data for a client. Use when: (1) a client wants interesting or surprising insights (not just monitoring or action items); (2) you want to hedge LLM creativity against deterministic rigor by running two tracks in parallel and consolidating; (3) the work fits an 8-hour autonomous window with review-panel gates; (4) the underlying data supports both exploratory querying and mechanical candidate scans. Specializes `overnight-review-client-delivery` for INSIGHT DISCOVERY rather than deliverable polishing — the two are sister skills with different problem shapes. ALWAYS use this skill when the user asks for "ah-ha insights", "surprise patterns", "funnel leaks", "hidden findings", "overnight analysis to surface X", or wants a dual-approach (creative + mechanical) for client-facing insight work — even if they don't explicitly name the pattern. NOT for: synchronous analysis (use exploratory- data-analysis), single-

Before starting a large-scale redesign (10+ PRs that rewrite shared files like templates, base layouts, or central views), audit ALL unmerged feature branches for commits that touch the same files. Use when: (1) the user asks for a multi-PR redesign / restructure / migration, (2) the worktree is at the top of main but other long-running branches exist with active work, (3) the redesign will replace files wholesale (template rewrites, route extractions, base.css migrations), (4) the project has a multi-branch flow (one main per client/deployment, e.g. `main` + `client-a-uk` + `feature/whitelabel-X`). Symptom of having skipped this audit: hours after the redesign ships, cherry-picking the parallel branch's work into main produces a head-on conflict on the rewritten file (often progress.html / report.html / a base template), and the parallel branch's a11y / safety / hotfix commits are stranded — they must be hand-merged into the new markup rather than cleanly cherry-picked. Sister to `pre-merge-client-variant-re

Calibrate review intensity per-PR when orchestrating a long chain (10+ PRs) of independent tasks overnight from a single implementation plan. Use when: (1) running `superpowers:subagent-driven-development` against a plan that produces many independent PRs (not stacked PRs from an issue cluster — for that shape use `overnight-multi-issue-implementation`), (2) user has authorized auto-merge on green review, (3) the user is asleep / unavailable to merge between tasks, (4) the chain spans multiple risk tiers (some PRs rewrite views/handlers, others restyle CSS only). The skill prescribes three review tiers — full two-stage / combined single-agent / bash-only verification — and a decision rubric for picking the right tier per PR to maximize overnight throughput WITHOUT silently approving real bugs. Sister to `subagent-driven-development` (specializes its review step for throughput-tuned chains) and `overnight-multi-issue-implementation` (different problem shape — issues vs. plan tasks; stacked vs. independent). Sy

Fire-ASAP orchestrator pattern for multi-track autonomous workflows dispatched via scheduled triggers (RemoteTrigger / CronCreate) rather than in-session agents. Use when: (1) a multi-track overnight workflow's orchestrator trigger has a fixed `t+Nh` timer that wastes wallclock when tracks finish early, (2) an overnight run should run consolidation/merge AS SOON AS all parallel tracks report complete, not on a clock, (3) the parent orchestrator session is too context-heavy to stay alive 12-20h and needs a scheduled successor to pick up track outputs, (4) you're choosing between "fire all tracks + one fixed-timer consolidator" vs "fire tracks + self-rescheduling polling consolidator". The polling pattern replaces a fixed wait with a cheap re-schedule loop that exits to consolidation at the first poll where all tracks report `phase: complete`. Distinct from `successor-handoff` (in-session parent polling a subagent) — this is for scheduled-trigger orchestrators that need to survive session ends.

Overnight specialization of `code-reviewer-subagent-no-bash-blocked-on-pr-diff` (the general tool-gap mechanism). In an UNATTENDED overnight review panel, a reviewer that couldn't see the code reads as a CLEAN one — so a real bug ships by morning. The usual cause: code-review subagents (feature-dev:code-reviewer, voltagent-*, Explore) are frequently provisioned WITHOUT a Bash tool, so when prompted to "review PR #N, fetch the diff with gh pr diff" they return a BLOCKED report (no review performed), or silently review the current checkout (often `main`, which predates the PR). Use when: (1) an overnight review panel (e.g. `overnight-multi-issue-implementation` Phase C, or any `agent-review-panel` run) dispatches reviewers against GitHub PRs or branches not checked out in the working tree; (2) a reviewer returns "I have no shell/gh/git tool" or "the PR sources are not in the working tree"; (3) one reviewer in a parallel panel comes back BLOCKED while siblings succeeded. Fix: pre-generate per-base diffs to files

Run an overnight autonomous work session that produces a client delivery package the next morning, with a multi-agent review panel built in to catch factual errors before they reach the client. Use when: (1) you have client deliverables that need polishing/regenerating before a morning hand-off, (2) you want a thorough quality gate without blocking on synchronous review, (3) the work scope is bounded enough to fit in 1-3 hours of agent time, (4) you want to maximise agent throughput by running content work and review agents in parallel. Implements the Phase A (content work in foreground) / Phase B (8-agent review panel in parallel background) / Phase C (morning synthesis + user hand-off) structure validated on the a causal-impact project, including the locked-file escape hatch discipline for surgical P0 fixes, the "regenerate don't banner" rule for stale content refreshes, and parallel-agent branch hygiene to avoid silent commit drops. NOT for: synchronous code review (use ce:review or claude-code-guide inste