Phoenix Iterate

A structured workflow for AI-assisted quantitative strategy iteration. Instead of randomly tweaking code, this skill enforces a disciplined loop: read history, form hypothesis, write code, validate against past mistakes, backtest progressively, diagnose results, and record lessons.

Dependencies

This skill is an orchestrator — it coordinates two companion skills that must be installed separately:

Skill	Purpose	Commands provided
INLINECODE0	Backtest submission, monitoring, early-stop, results	INLINECODE1
INLINECODE2

Deep feature-level forensic analysis | deep_forensics.py |

Install them first:
CODEBLOCK0

All cli.py references below assume backtest-poller is installed as a sibling directory (../backtest-poller/cli.py). Adjust the path if your install location differs.

When to use

• - "Let's iterate on the strategy"
• "Start a new strategy version"
• "Run the phoenix iteration loop"
• "What should I try next?"

The Iteration Loop

CODEBLOCK1

Step 1: Get Decision Context

CODEBLOCK2

Returns:

• - Constitutional memory (all past lessons sorted by severity)
• Available strategy blueprints with historical performance
• Mutation dimensions (what can be changed)
• Recent iteration history (what was tried, what happened)
• Resource constraints and validation windows

Step 2: Form a Trading Hypothesis

Before writing code, answer these questions:

1. 1. What am I changing? — Pick exactly one mutation dimension
2. Why do I think this will be better? — Based on data, not intuition
3. What if I'm wrong? — Worst case scenario, does it violate any iron laws?
4. Will this affect trade frequency? — If trades decrease, there must be a compensating mechanism

Mutation Dimensions:

Dimension	Description	Examples
INLINECODE7	How the strategy survives downturns	QQQ buy-and-hold, cash defense, SMA filter
INLINECODE8

How much capital per trade | Kelly %, max trade value, total exposure cap |
| selection | What stocks to trade | Premarket volume, RS breakout, HV lottery |
| profit_management | What to do with winners | Hold to expiry, take-profit at 200%, trailing stop |

Step 3: Write & Scan Code

1. 1. Create a new strategy directory: INLINECODE11
2. Base it on the latest passing version
3. Run constitutional scan:

CODEBLOCK3

If violations are found, fix them before submitting.

Step 4: Progressive Validation

Submit through increasingly demanding test windows. Only promote to the next stage after passing.

CODEBLOCK4

CODEBLOCK5

Shortcut: If you only changed profit management (not entry logic), you can skip Smoke/Stress and start from Medium.

Step 5: Diagnose

CODEBLOCK6

For deeper analysis, run the feature forensics (requires qc-deep-feature-forensics skill):
CODEBLOCK7

Step 6: Record & Decide

CODEBLOCK8

Decision Matrix:

Outcome	Action
Current stage passed	Change dates to next stage, resubmit
DD exceeded but promising

Analyze monthly cashflow, find bleeding point, targeted fix |
| Too few trades | Red flag — loosen entry conditions or shorten cooldown |
| Sharpe < 1.0 but DD ok | Acceptable for now, optimize Sharpe later |
| Full period passed | Strategy qualified! |

Quick Reference

CODEBLOCK9

Rules

• - Only 1 backtest can run at a time (serial execution). Never submit a second backtest while one is running.
• Full-period backtests take 2-3 hours — always use progressive validation to fail fast. Do not jump directly to full-period.
• Always run scan_strategy() before submitting. Constitutional violations must be resolved before backtest submission. Do not bypass the scanner.
• Each iteration must change exactly one mutation dimension. Changing multiple variables at once makes it impossible to attribute success or failure to a specific change.
• Record every iteration result, including failures. Unrecorded iterations will be lost and the same mistake may be repeated.
• The poller daemon handles monitoring automatically after submission. Do not poll the QC API manually — let the daemon manage state.