OpenTelemetry prompts help turn a vague request for tracing into a verifiable instrumentation change. The useful outcome is an understandable path through a service, including where context crosses a process boundary and where errors are recorded. A large number of spans does not establish that the important operation is visible. These prompts focus on a single request path, broken trace context and the attributes that make telemetry useful.
State the runtime and the export path
Provide the language, framework, package versions and runtime, including whether work runs in a browser, server process or background worker. Describe the exporter and collection path without credential values. Include a sanitized trace or a precise description of what is missing. Ask the agent to inspect existing initialization before adding another SDK instance.
The OpenTelemetry signals overview describes collecting, processing and exporting telemetry. It is a starting reference for signal categories. For actual code, require documentation matching the installed language SDK and instrumentations; availability and setup differ across runtimes.
Instrument a meaningful operation
Choose an operation with a clear start, completion and failure result. Explain the question the trace should answer. Ask the agent to separate existing automatic instrumentation from application-specific gaps. This avoids duplicated spans and makes the proposed change easier to review. Include expected behavior when the telemetry destination is unavailable.
Plan OpenTelemetry instrumentation for {{operation}} in {{code_paths}}.
Runtime and versions: {{runtime_versions}}. Existing setup: {{setup}}.
Identify automatic coverage and missing application boundaries.
Propose the minimum useful spans, events and attributes, with their
purpose and sensitivity. Match installed APIs. Implement only after the
plan is clear, then verify one successful and one failed operation.
Find the boundary where context is lost
A disconnected trace often needs a timeline rather than a configuration rewrite. Provide the sender, transport and receiver code, including queue or scheduled work boundaries. Ask the agent to identify where context is created, injected, extracted and made active. Keep retries visible so repeated work is not mistaken for a second unrelated request.
Investigate missing parent-child trace relationships for {{request_path}}.
Use {{sender_code}}, {{transport_code}}, {{receiver_code}} and {{trace_sample}}.
Map context creation and propagation across each boundary. Identify the
first unsupported assumption. Propose a focused repair and a test that
checks the resulting relationship, including {{async_or_retry_case}}.
Do not add a second global instrumentation setup to mask the issue.
Review attributes for cost and diagnostic value
An attribute should answer a question that someone investigating the service will ask. Raw URLs, request bodies and unique identifiers can create privacy or volume problems without helping that investigation. Ask for bounded alternatives and the specific queries they support. Keep identifiers only where their diagnostic role and treatment are deliberate.
Audit telemetry attributes in {{instrumented_paths}}.
For each field, state its diagnostic use, sensitivity and likely number
of distinct values. Propose bounded alternatives for unconstrained labels.
Check error events and exporter logs for credentials or full payloads.
Show how an investigator would follow {{failure_scenario}} after the change.
Verify the entire path, including export
A local span existing in memory is not proof that it reaches the intended backend. Check initialization, sampling, batching and shutdown in the environment where the code runs. Trigger a controlled failure and verify its representation. Report exactly which part was observed if access to the backend is unavailable.
Save the approved instrumentation prompt in Kipt with blanks for runtime, operation and trace evidence. For deciding which signals the team needs before choosing an SDK, start with the observability prompts.