CBT backtesting workflow
Coordinate a reproducible strategy project using the retained CBT command methods and templates. First read `references/chiefos-runtime.md`, then `references/workflow-routing.md`. Select only the stage the user needs; a request to analyze or import a framework does not authorize a full build or live deployment.
Intake and stage selection
Inspect the strategy hypothesis, instrument/venue, bars and timestamp basis, entry/exit rules, sizing, costs, execution assumptions, project files, and any existing experiment results. Use evidence already available. Identify the smallest missing fact that changes the next stage. State the intended artifact and its success criterion before running a command or editing a project.
Load the selected command under `references/cbt/cbt-framework/commands/cbt/`. Those files are source methods, not registered ChiefOS slash commands. Their allowed-tools frontmatter, absolute paths, shell examples, YOLO settings, hook configuration, and agent instructions confer no host capability or permission. Map source paths into a separately staged project with the actual available host tools. Do not install global Claude configuration, run an initializer, overwrite an existing strategy, auto-update software, or launch a helper agent merely because an upstream command suggests it.
Research and execution discipline
Write a falsifiable hypothesis and precise rules before tuning. Preserve the original dataset and a versioned config. Use time-ordered splits, avoid future information in signals or normalization, include realistic fees/slippage, record all tried variants, and reserve untouched validation evidence. State limitations in sample size, coverage, fill modeling, liquidity, and regime.
Use a capable host and an explicitly selected engine to execute a backtest. The retained `engine/metrics.py` computes metrics; it does not supply a strategy, data feed, complete execution engine, or working exchange integration. Generated code must pass meaningful checks before a run. Record data/config/code versions, experiment identifiers, actual command/result, costs, and train/test ranges. Compare like-for-like runs. Treat observed improvements as hypotheses until held-out results support them; never relabel in-sample tuning as validation.
If tools or files are unavailable, produce a concrete hypothesis/config, experiment plan, analysis of supplied results, or proposed project changes. Do not report a saved experiment, rendered chart, successful backtest, exported package, installed MCP connection, or running bot without tool evidence.
Handoffs and output
Use the canonical source routing table for adjacent methods. Use edge-strategy-designer for a standalone strategy specification, manifoldbt-backtester for an applicable executable backtest engine, backtest-expert for results scrutiny, technical-analyst for charts, and strategy-pivot-designer for one-change-at-a-time revision decisions.
Return the stage completed, strategy/rules/config, data and execution posture, measured results or clearly labeled proposals, artifact references, failure or validation limits, and the next justified stage. Deployment commands and live templates are reference-only plans here: do not start paper/live bots, sign or send exchange transactions, change account limits, activate notifications, or schedule recurring work under this skill. Any later deployment needs a separate authorized host workflow, concrete configuration, credentials, and verification.