Arize Instrumentation

Arize Instrumentation Skill

Use this skill when the user wants to add Arize AX tracing to their application. Follow the two-phase, agent-assisted flow from the Agent-Assisted Tracing Setup and the Arize AX Tracing — Agent Setup Prompt.

Quick start (for the user)

If the user asks you to "set up tracing" or "instrument my app with Arize", you can start with:

Follow the instructions from https://arize.com/docs/PROMPT.md and ask me questions as needed.

Then execute the two phases below.

Core principles

• Prefer inspection over mutation — understand the codebase before changing it.
• Do not change business logic — tracing is purely additive.
• Use auto-instrumentation where available — add manual spans only for custom logic not covered by integrations.
• Follow existing code style and project conventions.
• Keep output concise and production-focused — do not generate extra documentation or summary files.
• NEVER embed literal credential values in generated code — always reference environment variables (e.g., os.environ["ARIZE_API_KEY"], process.env.ARIZE_API_KEY). This includes API keys, space IDs, and any other secrets. The user sets these in their own environment; the agent must never output raw secret values.

Phase 0: Environment preflight

Before changing code:

1. Confirm the repo/service scope is clear. For monorepos, do not assume the whole repo should be instrumented.
2. Identify the local runtime surface you will need for verification:

• package manager and app start command
• whether the app is long-running, server-based, or a short-lived CLI/script
• whether ax will be needed for post-change verification

1. Do NOT proactively check ax installation or version. If ax is needed for verification later, just run it when the time comes. If it fails, see references/ax-profiles.md.
2. Never silently replace a user-provided space ID, project name, or project ID. If the CLI, collector, and user input disagree, surface that mismatch as a concrete blocker.

Phase 1: Analysis (read-only)

Do not write any code or create any files during this phase.

Steps

1. Check dependency manifests to detect stack:

• Python: pyproject.toml, requirements.txt, setup.py, Pipfile
• TypeScript/JavaScript: package.json
• Java: pom.xml, build.gradle, build.gradle.kts
• Go: go.mod

1. Scan import statements in source files to confirm what is actually used.

1. Check for existing tracing/OTel — look for TracerProvider, register(), opentelemetry imports, ARIZE_*, OTEL_*, OTLP_* env vars, or other observability config (Datadog, Honeycomb, etc.).

1. Identify scope — for monorepos or multi-service projects, ask which service(s) to instrument.

What to identify

Key rule: When a framework is detected alongside an LLM provider, inspect the framework-specific tracing docs first and prefer the framework-native integration path when it already captures the model and tool spans you need. Add separate provider instrumentation only when the framework docs require it or when the framework-native integration leaves obvious gaps. If the app runs tools and the framework integration does not emit tool spans, add manual TOOL spans so each invocation appears with input/output (see Enriching traces below).

Phase 1 output

Return a concise summary:

• Detected language, package manager, providers, frameworks
• Proposed integration list (from the routing table in the docs)
• Any existing OTel/tracing that needs consideration
• If monorepo: which service(s) you propose to instrument
• If the app uses LLM tool use / function calling: note that you will add manual CHAIN + TOOL spans so each tool call appears in the trace with input/output (avoids sparse traces).

If the user explicitly asked you to instrument the app now, and the target service is already clear, present the Phase 1 summary briefly and continue directly to Phase 2. If scope is ambiguous, or the user asked for analysis first, stop and wait for confirmation.

Integration routing and docs

The canonical list of supported integrations and doc URLs is in the Agent Setup Prompt. Use it to map detected signals to implementation docs.

• LLM providers: OpenAI, Anthropic, LiteLLM, Google Gen AI, Bedrock, Ollama, Groq, MistralAI, OpenRouter, VertexAI.
• Python frameworks: LangChain, LangGraph, LlamaIndex, CrewAI, DSPy, AutoGen, Semantic Kernel, Pydantic AI, Haystack, Guardrails AI, Hugging Face Smolagents, Instructor, Agno, Google ADK, MCP, Portkey, Together AI, BeeAI, AWS Bedrock Agents.
• TypeScript/JavaScript: LangChain JS, Mastra, Vercel AI SDK, BeeAI JS.
• Java: LangChain4j, Spring AI, Arconia.