| name | implementation-query-model |
| description | Implement the shared conversation turn engine, API-bound message projection, model streaming, retry and fallback, stop processing, derived progress/prompt assistance, speculative execution, and continuation decisions. Use when implementing or reviewing prompt submission, recursive model/tool turns, streamed content assembly, usage accounting, model recovery, structured output, token/turn limits, prompt suggestions, speculation, or API-safe conversation normalization. |
Implementation Query and Model Runtime
Implement semantic query engine shared by interactive, headless, SDK, agent, and remote adapters. Keep presentation, transcript persistence, tool execution, and compaction behind explicit collaborators; this skill owns the ordering and decisions that connect them.
Implementation workflow
- Read the complete query and model contract before changing turn execution, API payload construction, model streaming, retry logic, or message repair.
- Read the complete model and provider catalog before changing model aliases, provider mappings, defaults, allowlists, options, capability predicates, context/output limits, validation, deprecation, delegated-model inheritance, or overload fallback.
- Use the architecture diagram to trace the normal loop and recovery edges, the model resolution and availability diagram for selection and provider/capability boundaries, and the derived assistance and speculation diagram for stop-phase scheduling, stale suggestion generations, copy-on-write boundaries, and non-atomic acceptance. Treat the written
QM-* and MOD-* requirements as authoritative when a diagram omits detail.
- Model durable history, API-bound history, partial stream state, and presentation events as separate data products. Never mutate durable history merely to satisfy one provider's wire rules.
- Implement one iteration as an explicit state transition. Preserve the ordering of projection, context-pressure handling, streaming, recovery, tool continuation, hooks, queued input, and limit checks.
- Preserve provider-neutral text/image/document order. Admission and recovery
may verify store-owned identities/digests internally, but only a qualified
provider adapter may materialize immutable media bytes into a provider
body. Preflight every count/byte/profile limit before transport.
- Make every accepted tool-use identifier terminal before leaving or retrying an attempt. Repair malformed historical pairing only in the API projection unless strict validation is enabled.
- Snapshot turn-level gates and limits at the documented boundaries. Do not let an asynchronous configuration refresh change policy midway through one query invocation.
- Keep derived summaries, prompt suggestions, and speculative work outside authoritative history until their explicit projection/acceptance point.
- Exercise every applicable acceptance scenario in the references, including model-policy/provider faults, native-media rejection, cancellation, partial-stream, derived-assistance, and speculative-commit cases.
Ownership boundaries
- Own user-turn admission through terminal query outcome, typed-media projection
and quarantine, model-request construction, stream interpretation, model
retry/fallback, usage accumulation, and API-safe message normalization.
- Receive tool execution as an ordered stream of normalized results: concurrency-safe groups may arrive in completion order, while accepted identity, pairing, source parentage, and unsafe barriers remain authoritative. Do not implement permission or sandbox policy here.
- Receive compaction and context-collapse decisions through bounded interfaces. Do not make summaries authoritative transcript replacements.
- Publish semantic events; leave terminal layout, SDK serialization, and remote transport framing to presentation adapters.
- Request transcript append and flush operations through persistence interfaces. Do not make transport retries rewrite durable conversation history.
- Own the scheduling and projection points for derived assistance; leave its UI rendering to adapters and never treat an auxiliary model call as the user's authoritative answer.
Completion check
Confirm that normal completion, local-only input, tool continuation, stop-hook blocking, tool/agent progress summaries, prompt-suggestion suppression, speculative boundary/acceptance, structured-output failure, budget exhaustion, model fallback, prompt overflow, maximum output, cancellation, incomplete stream, and non-retryable API failure each end with an explicit outcome and a coherent message chain.
