Quant Alpha Research

Quant Alpha Research

Overview

Use this skill to turn quant ideas into falsifiable repo-native research work. Prefer rejection-first evidence, current artifacts, small executable slices, and explicit pass/fail reporting over broad brainstorming.

Operating Stance

• Treat every alpha as false until it survives current data-quality, out-of-sample, holdout, shuffle, cost, and capacity checks.
• Use current repo docs and artifacts as the source of truth. Memory and older reports can orient the search, but must not be treated as current proof.
• If the user asks to execute a roadmap or start Stage 0, do the empirical slice instead of extending architecture discussion.
• If the user asks for analysis-only, keep it analysis-only and avoid file edits.
• If the user asks for read-only validation, do not write to the source repo. Load references/patterns.md for the detailed read-only workflow.
• Keep provider coverage, provider concordance, alpha validation, falsification, and promotion status separate.
• Do not bypass live-trading, governance, or promotion boundaries to make a candidate look deployable.
• Protect unrelated user changes. Read git status before editing a repo and avoid touching unrelated dirty files.

Tool Boundary

• Start with read-only commands: git status, targeted file reads, rg, and artifact inspection.
• Edit only after the user asks for implementation or roadmap execution.
• Never change manifests, promotion state, live-trading config, provider credentials, or canonical-parent labels unless the task explicitly requires it and current gates support it.
• Do not copy secrets, raw private artifacts, or API responses into the skill or public reports.

Workflow

1. Orient from the current repo.

   • Read the most recent planning docs, candidate reports, promotion cards, and relevant artifacts.
   • Identify the current canonical parent, horizon, data surface, and active blockers.
   • Prefer targeted reads over broad artifact scans.

2. Convert the request into a research contract.

   • State the mechanism, data source, horizon, landing shape, comparison parent, and fail-closed blockers.
   • Choose a narrow first slice that can produce evidence quickly.
   • For external articles or threads, separate source claims from repo-verified conclusions.

3. Choose the landing shape before coding.

   • Consider gate, veto, replacement, delayed entry, capacity haircut, sleeve activation, or score perturbation.
   • Prefer selection-layer rules when prior smooth overlays have transmitted weakly or stayed at-par.
   • Require a reason before changing a manifest, canonical parent, or promotion state.

4. Build the smallest Stage 0 that can reject the idea.

   • Reuse repo-native loaders, feature builders, reports, and tests.
   • Write a report or artifact only where the repo already stores quant research evidence.
   • Record coverage, event counts, changed rows, forward returns, costs, and comparison parent metrics.

5. Falsify before optimizing.

   • Run delay, time shuffle, label shuffle, symbol holdout, liquidity-bucket, cost/funding, capacity, and provider-sensitivity checks when relevant.
   • Stop fail-closed if data trust cannot be proved.
   • Do not promote based only on pairwise uplift, attractive Sharpe, or factor-level IC.

6. Report in decision form.

   • Lead with go, no-go, watch, blocked, or research-only.
   • List exact artifacts, commands run, tests, and remaining blockers.
   • If no credible alpha exists, say so clearly and rank the next falsification or data-unlock step.

7. Verify the research output.

   • Re-run the repo-native tests, reports, or read-only evidence probes needed for the decision.
   • For output-quality checks, compare the answer against current artifacts rather than memory or thesis appeal.

Decision Tree

• New alpha request: read the current roadmap and canonical parent, then produce one net-new candidate lane plus Stage 0 validation.
• Existing candidate review: start from promotion and falsification artifacts, not from thesis appeal.
• Roadmap execution: treat the document as an execution contract and produce concrete artifacts or runs.
• Provider/data request: separate fill/coverage from concordance/trust, then decide whether alpha reruns are allowed.
• External article/thread: write source-bounded mechanisms, hypotheses, and Stage 0 tests; do not summarize as market commentary only.
• Long-running job status: verify live process state and append-only output growth, not just terminal text.

References

Load only the reference needed for the current request:

• references/patterns.md: repo patterns and anti-patterns from crypto quant-research lanes.
• references/stage0_and_falsification.md: required Stage 0 fields, falsification matrix, and promotion blockers.
• references/output_templates.md: compact decision-report templates.

Output Contract

For alpha decisions, include:

• candidate or lane name
• parent/comparator and horizon
• data sources and trust status
• Stage 0 result or blocker
• falsification status
• promotion status
• next executable action

Never collapse validated, passed falsification, and promotable into one label.