Drive a large refactor / package-extraction under strict author↔architect separation — an architect writes an in-repo design doc and Socratically self-critiques boundaries BEFORE any code, then an author executes incrementally with build + vitest + real-GPU verification per increment. Use when the user asks to "refactor this module", "extract a package", "split boundaries", or do an architecture-guardrail refactor on X-GIS.
Autonomously triage the open GitHub issue backlog and drive the top-N through fix → branch → full gate → PR → CI → merge, with adversarial verification and a final digest. Use when the user asks to "drain the backlog", "batch-fix issues", "resolve the top N issues", or run an autonomous issue-to-merge campaign on X-GIS.
Autonomously build a fail-before/verified test corpus — for each spec story write a test, prove it FAILS for the right reason, implement the wiring, prove it PASSES, logging every red→green transition. Use when the user asks to "wire the spec", "complete the test corpus", "fail-before tests", or turn a spec into a self-validating regression suite on X-GIS.
Localize a render/data divergence in X-GIS when the symptom is a wrong PIXEL or a wrong value many boundaries downstream of its cause — "the polygon outline draws offset from the fill", "the line is too thin", "this value is wrong but I can't see where it got corrupted", "which functions run, in order, in this path". X-GIS's dominant bug archetype is two SIBLING paths that must agree (fill vs outline, CPU vs GPU projection, polygon vs line shader) silently diverging — sub-pixel at native zoom, only visible once an over-zoom / pitch / projection axis amplifies it. This skill is the gdb-parity toolkit for that: dev-only cross-path asserts + watchpoints (CPU), GPU readback-parity, and visual bisect — applied in that order to turn "confirm the symptom" into "localize the cause at the violating line". Pairs with prove-or-refute (an INVARIANT becomes a live devAssert) and visual-artifact-bisect (the real-GPU visual layer).
Adjudicate a CLAIM about code — a bug hypothesis, a suspected regression, "does this fix actually work", a finder's candidate, a reviewer's finding — by PROVING it real or false with a rigorous MATHEMATICAL argument (induction, proof-by- construction with a witness, invariant-violation, or exhaustive-case), NOT a single-shot empirical run or a confident static read. Use whenever the user demands inductive/mathematical/rigorous proof; when you have many candidates from a "generate freely" phase that need adversarial verification before acting; or whenever a plausible-but-unproven claim could waste a fix (or a refutation could hide a real bug). Honed in X-GIS: confident static traces were repeatedly WRONG and "I ran it once" proved nothing about untested inputs — only a construction / invariant / induction settled it. Pairs with visual-artifact-bisect (the real-GPU judge for claims that are inherently visual).
Catch render/coordinate bugs BEFORE rendering — by construction, not observation. Use this the moment a bug smells like PRECISION (deep-zoom drift, f32 loss, fill displaced from outline, "tolerance feels excessive", position wrong only past some zoom) or FRAME-CONSISTENCY (fill≠outline, CPU≠GPU divergence, sphere-vs-ellipsoid geoid, two paths disagree about where a point goes). These are MATH/FRAME bugs wearing a pixel costume; they are exhaustively catchable with a closed-form error budget, a single-authority/branded type, or a metamorphic invariant — no GPU, no screenshot, over the WHOLE input domain, not a sample. This is the FIRST resort. visual-artifact-bisect (render-and-eyeball) is the LAST resort, reserved for the genuinely emergent-raster residue (MSAA seams, blend, overdraw, sub-pixel coverage). If you are about to "render it and see", stop and check whether the bug is actually analytic first. X-GIS coordinate pipeline.