code-review-for-quant — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited code-review-for-quant (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
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.
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?".
Run this against any function that touches historical financial data.
query_date argument(or equivalent) and filters on filing_date <= query_date (or accepted <= query_date).
period_end, report_date, or as_of_date as theknown-date for filing data.
ticker.info, latest API value)for historical queries.
(not retroactively to all prior dates).
values change as new splits happen.
amendment's own filing date.
KeyError crashes when XBRLhas alternate tags or FPI structure differs).
SPACs, recent IPOs).
ordinary shares with ratio conversion).
insider holdings.
threshold, different dedup rules).
history, not by CUSIP.
None / NaN propagation explicit — no silent coverage gaps.suspicious prints (penny stocks: trades flagged with condition_codes indicating odd lot / late / out-of-sequence).
compounds over millions of trades.
run_date and data_as_of_date..apply() loop.lookups, not list comprehensions over the full universe).
When listing bugs found in a code review, ALWAYS rank by silent-corruption potential, not by severity-of-symptom:
Anti-pattern: leading the review with "you should use a context manager for open()" while the function silently uses period_end as a publication date. The first one is cosmetic; the second corrupts every backtest result.
calculation, simulation).
would leak (e.g., "row with period_end: 2023-12-31 is unknowable on 2024-02-01 if the 10-K was filed 2024-02-15").
lookahead-safety and other relevantskills — don't reinvent the rule.
pd.DataFrame, yfinance, requests,polygon, sec, companyfacts, period_end, filing_date, apply(lambda
This is not a generic linter. It does not catch missing semicolons, unused imports, or PEP8 violations — those are the pre-existing linter's job. It catches the ~20 quant-specific failure modes that generic code review consistently misses. Combine with lookahead-safety, xbrl-fallbacks, insider-dedup and other domain skills for specific-rule fixes.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.