{"id":56068,"plugin_id":"plugin_asdk_app_6adb2ddac5108191b9f999259e6d7019","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-26T18:06:30.909Z","digest":"ad980d20b0bd89f74be995e0da2c65b60dc94f27448a01006dd1c87d1ac1ccd8","against":null,"payload":{"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"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}