Imported from barrsn/opencode-quant-rnd (AGENTS.md). Install upstream with npx skills add barrsn/opencode-quant-rnd. Copyright stays with the author.

OpenCode project instructions

You are operating a quantitative R&D repository. Treat reproducibility, causality and leakage control as hard requirements.

Non-negotiable rules

1. Do not access or modify files outside this git worktree.
2. Never read, print, copy or commit secrets, .env, broker credentials, SSH keys, browser profiles or OS credential stores.
3. Never place live orders or enable live broker execution.
4. Never optimize against a sealed holdout or report it repeatedly during search.
5. Never claim a strategy is robust from a single split, a single asset, a single timeframe or an uncosted backtest.
6. Every material numerical claim must be reproducible from code, configuration and saved outputs.
7. Prefer the project's rnd-run tool for routine execution. Generic shell commands should be exceptional.
8. Use Polars LazyFrame/scan operations for data engineering. Convert to pandas only at a documented compatibility boundary.
9. Shift signals by the declared execution lag before backtesting. Features at timestamp t may only use information available by t.
10. Any external implementation copied or adapted must have its source and license checked first. Prefer installing dependencies or referencing upstream code over vendoring.

Required R&D loop

For a research request, use this loop:

• SCOUT: inspect repository state, relevant upstream docs/source and existing experiments.
• SPECIFY: write or update a hypothesis with data, label, entry/exit, cost model, validation and acceptance criteria.
• BASELINE: run the simplest valid baseline first.
• IMPLEMENT: make the smallest justified change.
• TEST: run unit/data/leakage tests.
• BENCHMARK: measure runtime/memory when performance-sensitive code changes.
• VALIDATE: run time-aware validation and stress tests.
• CRITIQUE: ask an independent reviewer subagent to look for leakage, overfit and implementation errors.
• DECIDE: accept, reject or re-plan based on predeclared criteria.

Stop and re-plan after repeated non-improvement rather than widening the search until a lucky backtest appears.

Model use

• Use strong cloud/free-tier models for orchestration, finance reasoning and independent review when configured.
• Use local Ollama models for cheap bounded tasks, summarization, file classification and offline fallback.
• Different subagents should be independently reviewable. Do not ask one agent to both invent and certify the same result when another configured reviewer is available.

Coding standards

• Python 3.11 target.
• Typed public functions where practical.
• Ruff format/lint and pytest.
• Avoid hidden global mutable state.
• Random seeds are explicit and persisted.
• Prefer NumPy/Numba vectorization over Python loops in hot paths.
• Use Polars expressions instead of Python UDFs where possible.
• Add a regression test for every bug that affected results.