reflect: check for sibling reflect-ci/fix-ci dispatches before finalizing

skills/reflect/SKILL.md

@@ -26,6 +26,7 @@ Every invocation of this skill — single-transcript or multi-conversation mode
 - A session, or a corpus-scan bucket, shows heavy user involvement — many corrections, clarifying answers typed out by hand, repeated manual confirmations — over a short span. That's a signal a durable preference exists and hasn't been captured yet, not just a signal something went wrong; hand it to `automate-me` (step 4) rather than writing a one-off skill edit for it.
 - It's been a while since the corpus-wide pass (`top_sessions.py` + this skill's lenses across the worst offenders) last ran. No fixed cadence and no cron — just periodically worth doing by hand, since a single pass has reliably turned up real, evidence-backed findings each time so far.
 - The user asks *why does X keep happening* across a span of time or across machines — e.g. "why do these PRs keep thrashing," "look at all our conversations from the last day," "check every DO worker." That's a request for **multi-conversation mode** (below), not a single-transcript reflect: a repeated-failure pattern's signature often only shows up in the *shape* of many transcripts (a burst of sessions across several machines within minutes of each other), which no single transcript can reveal on its own.
+- This invocation is itself an automated `reflect-ci-*` task in a headless CI-repair pipeline, with no human to ask "why does X keep happening." Run the sibling-branch check in step 1 unconditionally rather than waiting for that question to be asked — the dispatch-burst pattern above applies just as much to concurrent automated reflect dispatches as to concurrent human-directed sessions.
 
 Skip when the conversation is trivial, off-topic, or already covered by a skill the parent followed correctly. One-offs are not learnings.
 
@@ -45,6 +46,8 @@ To also cover the DigitalOcean/SSH remote targets in `~/.invoker/config.json`, a
 
 Feed `corpus_scan.py`'s output JSON to the same lens fan-out in step 3 below in place of a single transcript path — give each reviewer the aggregate JSON (not 100+ raw transcripts) plus the specific file paths for anything they want to read in full.
 
+**Check for sibling reflect passes before finalizing.** An automated CI-repair pipeline can dispatch the *same* failing job to several independent workflows at once, each of which files its own `fix-ci-*` → `verify-ci-*` → `reflect-ci-*` chain with no shared coordination beyond git history — confirmed directly in one pass: a single job (`fleet / a71f331 (12 jobs)`) had three separate workflow dispatches each authoring a near-identical, unmerged fix within a two-hour window, and four separate `reflect-ci-a71f331-*` branches each running this skill's full lens fan-out against essentially the same commit family. Before spawning reviewers, run `git branch --all | grep -E "reflect-ci-<job-id>|fix-ci-<job-id>"` (substituting the actual job id) and note in the synthesis step if siblings exist — a reflect pass that doesn't know it's one of several concurrent ones will likely draft an overlapping-but-not-identical skill edit, adding a second wave of redundant review cost on top of the first wave of redundant fixes. This detector is distinct from the "When to invoke" dispatch-burst trigger below, which assumes a human is present to ask "why does X keep happening" — an Invoker-dispatched `reflect-ci-*` task runs with no human in the loop, so check for siblings unconditionally in that context rather than waiting to be asked.
+
 ### 2. Run the cost audit, then spawn parallel reviewers
 
 Token usage is exact data sitting in every transcript (Claude Code and Codex embed a `usage{}` block per turn; Cursor's local transcripts don't — see below). Don't have an LLM reviewer eyeball the raw JSONL to guess at spend or thrash — that both burns context (the file itself can be multi-MB) and produces unreliable numbers. Run the mechanical counter first, then hand its *output* (small, structured) to the Cost lens: