code-review-for-quantlisted

# Code review for quant Generic code review catches off-by-one errors and missing `with` blocks. Quant code has its own failure modes — and they're the ones that silently corrupt research output without raising. This skill enforces a domain-specific checklist before approving any quant-touching code. ## Core principle **Quant bugs hide as plausible numbers.** A backtest that runs cleanly and produces a nice equity curve can still be using future data. The test "did it crash?" is meaningless. The test is "did each datapoint trace to a publication date that precedes the query?". ## The checklist Run this against any function that touches historical financial data. ### A. Time semantics - [ ] Every read of historical state takes a `query_date` argument (or equivalent) and filters on `filing_date <= query_date` (or `accepted <= query_date`). - [ ] No use of `period_end`, `report_date`, or `as_of_date` as the known-date for filing data. - [ ] No use of "current" snapshots (`ticker.info`, latest API value) for historical queries. - [ ] Splits / reverse splits applied with split-date as the cutoff (not retroactively to all prior dates). - [ ] Adjusted prices not used for absolute price thresholds — adjusted values change as new splits happen. - [ ] Earnings revisions / amendments treated as known only from the amendment's own filing date. ### B. Data shape - [ ] Fall-through on missing fields (no `KeyError` crashes when XBRL h