arize-instrumentation

Name: arize-instrumentation
Author: github

37kstars4.6kforks

How to install arize-instrumentation?

github/awesome-copilot/arize-instrumentation

$npx -y skills add github/awesome-copilot --skill arize-instrumentation

Installs into the current project.

Summary

Adds Arize AX tracing to an LLM application for the first time. Follows a two-phase agent-assisted flow to analyze the codebase then implement instrumentation after user confirmation. Use when the user wants to instrument their app, add tracing from scratch, set up LLM observabil

Files · 1

View on GitHub

SKILL.md

1	# Arize Instrumentation Skill
2
3	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](https://arize.com/docs/ax/alyx/tracing-assistant) and the [Arize AX Tracing — Agent Setup Prompt](https://arize.com/docs/PROMPT.md).
4
5	## Quick start (for the user)
6
7	If the user asks you to "set up tracing" or "instrument my app with Arize", you can start with:
8
9	> Follow the instructions from https://arize.com/docs/PROMPT.md and ask me questions as needed.
10
11	Then execute the two phases below.
12
13	## Core principles
14
15	- Prefer inspection over mutation — understand the codebase before changing it.
16	- Do not change business logic — tracing is purely additive.
17	- Use auto-instrumentation where available — add manual spans only for custom logic not covered by integrations.
18	- Follow existing code style and project conventions.
19	- Keep output concise and production-focused — do not generate extra documentation or summary files.
20	- 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.
21
22	## Phase 0: Environment preflight
23
24	Before changing code:
25
26	1. Confirm the repo/service scope is clear. For monorepos, do not assume the whole repo should be instrumented.
27	2. Identify the local runtime surface you will need for verification:
28	- package manager and app start command
29	- whether the app is long-running, server-based, or a short-lived CLI/script
30	- whether `ax` will be needed for post-change verification
31	3. 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.
32	4. 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.
33
34	## Phase 1: Analysis (read-only)
35
36	Do not write any code or create any files during this phase.
37
38	### Steps
39
40	1. Check dependency manifests to detect stack:
41	- Python: `pyproject.toml`, `requirements.txt`, `setup.py`, `Pipfile`
42	- TypeScript/JavaScript: `package.json`
43	- Java: `pom.xml`, `build.gradle`, `build.gradle.kts`
44	- Go: `go.mod`
45
46	2. Scan import statements in source files to confirm what is actually used.
47
48	3. Check for existing tracing/OTel — look for `TracerProvider`, `register()`, `opentelemetry` imports, `ARIZE_`, `OTEL_`, `OTLP_*` env vars, or other observability config (Datadog, Honeycomb, etc.).
49
50	4. Identify scope — for monorepos or multi-service projects, ask which service(s) to instrument.
51
52	### What to identify
53
54	\| Item \| Examples \|
55	\|------\|----------\|
56	\| Language \| Python, TypeScript/JavaScript, Java, Go \|
57	\| Package manager \| pip/poetry/uv, npm/pnpm/yarn, maven/gradle, go modules \|
58	\| LLM providers \| OpenAI, Anthropic, LiteLLM, Bedrock, etc. \|
59	\| Frameworks \| LangChain, LangGraph, LlamaIndex, Vercel AI SDK, Mastra, etc. \|
60	\| Existing tracing \| Any OTel or vendor setup \|
61	\| Tool/function use \| LLM tool use, function calling, or custom tools the app executes (e.g. in an agent loop) \|
62
63	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).
64
65	### Phase 1 output
66
67	Return a concise summary:
68
69	- Detected language, package manager, providers, frameworks
70	- Proposed integration list (from the routing table in the docs)
71	- Any existing OTel/tracing that needs consideration
72	- If monorepo: which service(s) you propose to instrument
73	- If the app uses LLM tool use / function calling: note that you will

People who liked this also viewed

6 picks

Type

arize-instrumentation

37kstars4.6kforks

View on GitHub

How to install arize-instrumentation?

github/awesome-copilot/arize-instrumentation

$npx -y skills add github/awesome-copilot --skill arize-instrumentation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Arize Instrumentation Skill
2
3	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](https://arize.com/docs/ax/alyx/tracing-assistant) and the [Arize AX Tracing — Agent Setup Prompt](https://arize.com/docs/PROMPT.md).
4
5	## Quick start (for the user)
6
7	If the user asks you to "set up tracing" or "instrument my app with Arize", you can start with:
8
9	> Follow the instructions from https://arize.com/docs/PROMPT.md and ask me questions as needed.
10
11	Then execute the two phases below.
12
13	## Core principles
14
15	- Prefer inspection over mutation — understand the codebase before changing it.
16	- Do not change business logic — tracing is purely additive.
17	- Use auto-instrumentation where available — add manual spans only for custom logic not covered by integrations.
18	- Follow existing code style and project conventions.
19	- Keep output concise and production-focused — do not generate extra documentation or summary files.
20	- 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.
21
22	## Phase 0: Environment preflight
23
24	Before changing code:
25
26	1. Confirm the repo/service scope is clear. For monorepos, do not assume the whole repo should be instrumented.
27	2. Identify the local runtime surface you will need for verification:
28	- package manager and app start command
29	- whether the app is long-running, server-based, or a short-lived CLI/script
30	- whether `ax` will be needed for post-change verification
31	3. 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.
32	4. 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.
33
34	## Phase 1: Analysis (read-only)
35
36	Do not write any code or create any files during this phase.
37
38	### Steps
39
40	1. Check dependency manifests to detect stack:
41	- Python: `pyproject.toml`, `requirements.txt`, `setup.py`, `Pipfile`
42	- TypeScript/JavaScript: `package.json`
43	- Java: `pom.xml`, `build.gradle`, `build.gradle.kts`
44	- Go: `go.mod`
45
46	2. Scan import statements in source files to confirm what is actually used.
47
48	3. Check for existing tracing/OTel — look for `TracerProvider`, `register()`, `opentelemetry` imports, `ARIZE_`, `OTEL_`, `OTLP_*` env vars, or other observability config (Datadog, Honeycomb, etc.).
49
50	4. Identify scope — for monorepos or multi-service projects, ask which service(s) to instrument.
51
52	### What to identify
53
54	\| Item \| Examples \|
55	\|------\|----------\|
56	\| Language \| Python, TypeScript/JavaScript, Java, Go \|
57	\| Package manager \| pip/poetry/uv, npm/pnpm/yarn, maven/gradle, go modules \|
58	\| LLM providers \| OpenAI, Anthropic, LiteLLM, Bedrock, etc. \|
59	\| Frameworks \| LangChain, LangGraph, LlamaIndex, Vercel AI SDK, Mastra, etc. \|
60	\| Existing tracing \| Any OTel or vendor setup \|
61	\| Tool/function use \| LLM tool use, function calling, or custom tools the app executes (e.g. in an agent loop) \|
62
63	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).
64
65	### Phase 1 output
66
67	Return a concise summary:
68
69	- Detected language, package manager, providers, frameworks
70	- Proposed integration list (from the routing table in the docs)
71	- Any existing OTel/tracing that needs consideration
72	- If monorepo: which service(s) you propose to instrument
73	- If the app uses LLM tool use / function calling: note that you will

People who liked this also viewed

6 picks

Type