Update to Deriv

{
  "description": "Map trade names to New Deriv API Options contract families, proposal shapes, and live availability. Use whenever a task selects, adds, or configures a Deriv Options trade type — Accumulator options, Rise/Fall, Higher/Lower, Matches/Differs, Even/Odd, Over/Under, Multipliers, Touch/No Touch, Stays Between / Goes Outside, Vanilla options, Turbo options, Asian options, Reset Call / Reset Put, or High/Low Ticks — even if the user just says \"up/down\", \"digits\", \"binary call/put\", or \"add accumulators to my bot\" without naming contract codes. Not for Legacy API compatibility or CFD execution.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 438
    },
    {
      "relative_path": "references/accumulators.md",
      "size_in_bytes": 4184
    },
    {
      "relative_path": "references/advanced.md",
      "size_in_bytes": 2166
    },
    {
      "relative_path": "references/barrier-options.md",
      "size_in_bytes": 2331
    },
    {
      "relative_path": "references/catalog.md",
      "size_in_bytes": 3013
    },
    {
      "relative_path": "references/digits.md",
      "size_in_bytes": 2069
    },
    {
      "relative_path": "references/multipliers.md",
      "size_in_bytes": 2241
    },
    {
      "relative_path": "references/up-down.md",
      "size_in_bytes": 4322
    },
    {
      "relative_path": "references/vanilla-turbos.md",
      "size_in_bytes": 2264
    }
  ],
  "name": "deriv-trade-types",
  "skill_md_contents": "---\nname: deriv-trade-types\ndescription: Map trade names to New Deriv API Options contract families, proposal shapes, and live availability. Use whenever a task selects, adds, or configures a Deriv Options trade type — Accumulator options, Rise/Fall, Higher/Lower, Matches/Differs, Even/Odd, Over/Under, Multipliers, Touch/No Touch, Stays Between / Goes Outside, Vanilla options, Turbo options, Asian options, Reset Call / Reset Put, or High/Low Ticks — even if the user just says \"up/down\", \"digits\", \"binary call/put\", or \"add accumulators to my bot\" without naming contract codes. Not for Legacy API compatibility or CFD execution.\n---\n\n## Hosted MCP first, then bundled references\n\nIf hosted MCP tools are available, call them by bare name (`get_schema`, `get_field`, `validate_payload`, `get_example`, `search_endpoints`, `guide_api_conventions`, `guide_authenticate`, and the other hosted guide tools). Do not use bundled field lists while those tools work. Never invent fields.\n\nIf those tools are missing or fail, read this skill and its `references/`. Do not invent fields that are not in those files.\n\nNever name a host-namespaced tool; use the bare tool name only.\n\n# Configure trading contract types\n\nTurn each requested trade family into a small adapter from UI state to a live-schema-validated proposal request. Keep authentication, transport, market data, and position management outside the adapter so several families can share one app.\n\n## Route user language\n\nRead [the trade-family catalog](references/catalog.md) first. Then read only the references for the requested families:\n\n- [Accumulators](references/accumulators.md)\n- [Rise/Fall and Higher/Lower](references/up-down.md)\n- [Digits](references/digits.md)\n- [Multipliers](references/multipliers.md)\n- [Touch, range, and other barrier options](references/barrier-options.md)\n- [Vanilla and Turbos](references/vanilla-turbos.md)\n- [Asian, reset, and tick-lookback families](references/advanced.md)\n\nDo not load every family reference for a focused request.\n\nParse app surface, trade family, and underlying market separately. “Derivatives” does not identify a contract type; “Derived Indices” identifies a market family. Clarify the intended meaning when it changes the implementation. Do not invent a `DERIVATIVES` value or route CFDs through the Options proposal flow.\n\n## Resolve every family against the hosted Deriv API MCP\n\nRead and enforce the [New API-only guard](../deriv-trading-app/references/new-api-only.md) for each family. Shared contract codes do not make a surrounding Legacy proposal envelope valid.\n\nFor each selected family:\n\n1. Call `guide_place_contract` for the proposal-to-buy method and live contract-type narrative.\n2. Use `search_endpoints` to resolve proposal, active-symbol, and contracts-for endpoint IDs.\n3. Read the proposal request as JSON with `get_schema`. Use `get_field` for the contract-type enum and every conditional field the adapter needs.\n4. Use `get_example` as a starting point, never as proof that the same fields fit another family.\n5. Validate a representative proposal from that adapter with `validate_payload` before finalising it.\n6. At runtime, use active-symbol and contracts-for responses plus proposal validation metadata to decide whether the selected symbol/account supports the family and which control values are allowed.\n\nIf these tools are unavailable, use the current [contract-type guide](https://developers.deriv.com/llms/contract-types.md), [proposal guide](https://developers.deriv.com/llms/proposal.md), and [proposal comparison](https://developers.deriv.com/comparison/proposal/) only as New API cross-checks. A published flat proposal schema may permit unrelated family fields and therefore proves structural validity only. Do not finalise a family-specific executable payload until a New-API-aware validator or a read-only proposal request on the New public endpoint confirms the combination. If sources conflict or that confirmation is unavailable, stop; never fall back to a Legacy example or repository type.\n\n## Adapter contract\n\nEach adapter should define:\n\n- A stable internal family ID and user-facing label.\n- The currently verified API contract type or direction choices.\n- Typed control state and validation derived from live contract metadata.\n- A pure proposal builder that either returns a valid request or a structured validation error.\n- A reset policy for controls that do not apply after a family or symbol change.\n- Formatting for proposal, confirmation, open-position, and result summaries.\n- Focused tests for valid, boundary, unavailable, and stale-selection cases.\n\nNever reuse the generic proposal builder when the selected family needs fields it cannot express. Extend its typed input or create a family-specific adapter, as Accumulators require.\n\n## Multi-family safety\n\n- Key proposal state by account, connection generation, family, direction, symbol, and control values.\n- Cancel the previous proposal subscription and clear its ID before changing any of those keys.\n- Disable buy until a fresh proposal matches the entire current selection.\n- Display only controls supported by the selected family and current contracts-for metadata.\n- Do not silently translate one family into a superficially similar one. Ordinary Rise/Fall and barrier-based Higher/Lower are distinct products.\n- Prefer an explicit unavailable state to falling back to a different contract.\n\n## Verify\n\nTest every selected family independently and test switching between each pair of materially different shapes. Include a regression proving that a proposal received just before a family switch cannot be bought afterwards. Validate fixtures against the hosted Deriv API MCP, but never send `buy` while testing a proposal adapter.\n"
}