How to turn a trading idea into a quant strategy specification

1. Define the contract between the idea and the code

Start with one research question: which observable behavior might explain the signal, and what result would challenge that idea? Then describe rules without words such as strong, cheap, timely or appropriate unless a formula or threshold defines them.

Specify the eligible instruments and their historical membership. A universe described as current index members is different from a universe reconstructed at each historical date. If the required historical membership or disclosure timing is unavailable, record that limitation before interpreting results.

1. 01Inputs: instruments, fields, units, frequency, lookback and missing-data handling.
2. 02Decisions: signal formula, ranking, ties, selection count and rebalance calendar.
3. 03Execution: signal availability, order time, price convention and unfilled-order handling.
4. 04Portfolio: capital, weights, cash, position limits, exits, fees and slippage.

2. Use a specification template before asking for Python

The following prompt is a workflow template, not a strategy recommendation. Replace placeholders with research choices. Ask for unresolved questions first so the AI does not quietly choose a universe, a price or an execution rule for you.

Research question: [the behavior to test and the reason for testing it]
Universe: [instruments; historical membership rule; inclusion/exclusion rules]
Data: [fields, frequency, adjustment convention, available-at timing]
Signal: [formula, lookback, thresholds, ranking and tie handling]
Decision schedule: [when the signal is calculated and positions reviewed]
Execution: [earliest order time, price convention, unfilled-order policy]
Portfolio: [capital, sizing, holding count, cash and position limits]
Exit rules: [rebalance, stop, time limit or other explicit conditions]
Constraints: [suspensions, price limits, trading lots and data gaps]
Costs: [fees, slippage and their calculation conventions]
Evaluation: [dates, benchmark, metrics and independent validation period]
Before coding: list ambiguous or unavailable conditions for confirmation.
After coding: map each rule to its implementation and proposed checks.

3. Replace ambiguous phrases with testable decisions

A more detailed prompt is useful only when its details settle actual choices. Check the gaps most likely to change a trade before reviewing the sophistication of the generated code.

4. Review the FiClaw implementation against the confirmed spec

FiClaw connects the strategy idea, spec, generated Python, historical backtest and diagnosis. Use that chain to compare the implementation with the confirmed rules. A run that completes successfully still needs a logic review: valid Python can implement the wrong signal timing or rebalance rule.

Inspect a small number of dates and trades by hand, including a missing-data case and a rebalance with constrained execution if those cases occur. Save the prompt, confirmed spec, code version, settings and review notes together. If a rule changes after the first run, create a new version and state the reason rather than rewriting the original experiment silently.

These checks are a suggested review process, not a claim that every item is automatically captured or audited by FiClaw. Capture any missing evidence separately and have a qualified reviewer confirm the implementation. The external initialization and warm-up references explain general concepts, not FiClaw's engine or default settings.

1. 01Can a reviewer explain why each sampled instrument was eligible or excluded?
2. 02Does every sampled signal use only information available at that time?
3. 03Do target positions, orders, fills and costs follow the agreed rules?
4. 04Are unavailable inputs and unresolved assumptions visible in the research record?

Frequently asked questions