--- name: skill-feasibility-study type: skill license: CC BY-NC-SA 4.0 description: >- Assess whether a proposed bot.Trader strategy is worth validating before any build begins — establish the structural advantage it claims, confirm regulatory and venue feasibility, model the costs it must clear, and return a written verdict of proceed, park, or reject. Use this at the first gate of Path A's validation gauntlet, whenever a strategy sits at Hypothesis and needs a feasibility read before backtesting starts. Research and recommendation only: it never trades, never writes execution code, and never clears the gate itself — promote and retire verdicts are the Owner's. The optimiser behaviour as a skill rather than an agent (APP-541); proposed until the first study has been run once. status: proposed --- # feasibility-study The first gate of Path A's validation gauntlet, written as a behaviour rather than a role. bot.Trader's kick-off (APP-541) settled two classification calls by nature, not by convenience: **Trader is not an agent** — execution is deterministic platform code under the "no LLM in execution path" guardrail — and **Optimiser is not an agent either**, because what it does is a repeatable, propose-only research behaviour with no standing mission of its own. That is a skill (`core-operating-model`, classify-by-nature). This is that skill: it reads a hypothesis, does the research, and hands back a verdict someone else acts on. > **Proposed — not yet adopted.** APP-541 allows this artefact to be deferred until the behaviour has actually been exercised once, and it has not been. Run the first study against this shape, then adopt it (drop `status: proposed`) or fold it into the operator loop if the behaviour proves too thin to stand alone. ## Trigger A bot.Trader strategy sits at **Hypothesis** in the *Trader Registry* and needs a feasibility read before it may enter the gauntlet — Path A's rule is that every strategy declares a structural advantage and confirmed regulatory/venue feasibility **before validation begins**. Commissioned by `operator-bottrader` under **Mandate A**, typically from the weekly loop. Runs on demand for any candidate strategy; one strategy per run. **Mandate A only.** Path B is exempt from A's lifecycle and gauntlet by design (*Charter: bot.Trader-B*), and B's agent is told nothing about how to trade. Never run this skill for Path B, and never feed its output to B's agent — doing so would brief the subject of the experiment and destroy it. ## Behaviour One pass, ending in a written verdict: 1. **Read the hypothesis.** Load the candidate from the *Trader Registry* and its Strategy doc, plus *Platform Strategy* for the guardrails and bars it must meet. State in one line what the strategy claims to earn and from whom. 2. **Establish the structural advantage.** Name the specific structural reason this edge exists and persists — who is on the other side of the trade and why they keep taking it. Path A's premise is compounding "not by finding patterns humans miss, but by enforcing discipline humans lack", so a claim resting on a pattern with no structural story fails here, however good the numbers look. "The backtest works" is not a structural advantage. 3. **Confirm regulatory and venue feasibility.** Can this actually be traded, by us, at OANDA, on the intended universe — instrument availability, financing and rollover mechanics, position and leverage limits, data availability at the required frequency, and any regulatory constraint. Confirm against the venue's own documentation, not from memory. 4. **Model the costs it must clear.** Apply the FX cost model: spread, financing, fees, and expected slippage. **Stamp the verdict with the cost-model version it was priced against** — the version identifier the model carries since APP-966 — so that when reconciliation against realised fills moves an assumption (`operator-bottrader`, *Cost-model reconciliation*), the standing of every filed verdict is legible rather than unknown. State the per-trade cost hurdle the edge must beat, and the rough frequency and edge size the strategy would need to clear it. Path A's first guardrail is *no trade without positive EV after costs* — a strategy that cannot clear its own costs is rejected here, before any build. 5. **Mark what is known, assumed, and unknown.** Every load-bearing figure is labelled. An assumption carried into the gauntlet as a fact is the failure this gate exists to catch. 6. **Return the verdict — proceed, park, or reject.** With the reasoning, the residual risks, and, on *proceed*, the specific work the next gauntlet stage needs **and a forward projection**: the expected edge, frequency and cost hurdle the pass rests on, and which bar carried it. The projection is the calibration baseline — when the strategy reaches paper, its realised result is compared against it and a miss is attributed to the gate or the cost model (`operator-bottrader`, *Gauntlet calibration*). It is recorded now, before any result is known, because a projection written afterwards is written around the result (APP-912). Write it to the strategy's ticket or doc in plain language, so it can be read without opening the model. The verdict is a recommendation. It does not move the strategy's lifecycle stage. ## The verdicts * **Proceed** — structural advantage named, venue feasibility confirmed, cost hurdle clearable on stated assumptions. Recommend entry to backtest, with the open questions listed. * **Park** — the idea may hold, but a blocking unknown must be resolved first (missing data, an unconfirmed venue mechanic). Name the one thing that would unpark it. * **Reject** — no structural advantage, infeasible at the venue, or the costs eat the edge. Say which, in one line. A cheap rejection here is the gate working, not a wasted run. ## Guardrails * **Propose-only.** Research and a written verdict. This skill never trades, never places an order, never touches a live or demo account, and never writes execution or strategy code — Forge builds, through Relay, after a decision. * **Never clears its own gate.** Lifecycle gate verdicts on Path A (promote/retire) are the **Owner's** (APP-541). This skill prepares the evidence and recommends; `operator-bottrader` carries it to the Owner. It does not advance a strategy's stage. * **No stage skipped, no bar bent** (*Platform Strategy*). A feasibility verdict is not a licence to shortcut backtest or walk-forward, and this gate is never waived to keep a favoured idea alive. * **Structural advantage or nothing.** No strategy proceeds on pattern-fitting alone. If the honest answer is "we don't know why this works", that is a *park* or a *reject*, not a *proceed*. * **Real numbers only.** Venue mechanics confirmed against source; costs from the platform's cost model. No fabricated figures, no remembered spreads (`convention-ticket`). * **Mandate A only.** Never run for Path B; never brief B's agent with its output. * **One strategy per run.** Comparing candidates against each other is prioritisation — the operator's call, not this gate's. ## Setup Commissioned on demand by `operator-bottrader` under Mandate A, typically surfaced by `task-bottrader-operator-loop`. Not scheduled: it fires when a candidate reaches the gate, so it needs no `task-*` loader of its own (`convention-artefact-format`, the skill-vs-task-only rule — the behaviour has genuine ad-hoc reuse and no standing cadence). Output lands on the strategy's ticket or Strategy doc; the *Trader Registry* stage changes only on the Owner's verdict.