[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-arize-experiments":3,"mdc--bd825o-key":51,"related-org-arize-experiments":278,"related-repo-arize-experiments":436},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":26,"repoUrl":27,"updatedAt":28,"license":29,"forks":30,"topics":31,"repo":46,"sourceUrl":49,"mdContent":50},"experiments","run and compare dataset-backed experiments","Run, read, and compare dataset-backed experiments to find evidence that a prompt or pipeline is improving. Trigger when the user wants to iterate over a dataset with experiments, compare experiment runs, read experiment quality\u002Flatency\u002Fcost, or decide whether a change actually helped. Running a prompt over a dataset is implicitly an experiment — load this skill when dataset-backed work begins, before authoring evaluators for the experiment and before starting the recorded run, not only when reading results. Do NOT trigger on: (1) manual prompt drafting with no dataset-backed evaluation in scope (use `playground`), (2) authoring or refining an evaluator's logic or rubric (use `evaluators`), (3) cross-trace failure diagnosis with no experiment in scope (use `debug-trace`).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"arize","Arize AI","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Farize.jpg","Arize-ai",[13,17,20,23],{"name":14,"slug":15,"type":16},"Datasets","datasets","tag",{"name":18,"slug":19,"type":16},"LLM","llm",{"name":21,"slug":22,"type":16},"Evals","evals",{"name":24,"slug":25,"type":16},"Testing","testing",10513,"https:\u002F\u002Fgithub.com\u002FArize-ai\u002Fphoenix","2026-07-12T08:08:11.691477",null,977,[32,33,34,35,36,15,22,37,38,39,40,41,42,43,44,45],"agents","ai-monitoring","ai-observability","aiengineering","anthropic","langchain","llamaindex","llm-eval","llm-evaluation","llmops","llms","openai","prompt-engineering","smolagents",{"repoUrl":27,"stars":26,"forks":30,"topics":47,"description":48},[32,33,34,35,36,15,22,37,38,39,40,41,42,43,44,45],"AI Observability & Evaluation","https:\u002F\u002Fgithub.com\u002FArize-ai\u002Fphoenix\u002Ftree\u002FHEAD\u002Fsrc\u002Fphoenix\u002Fserver\u002Fagents\u002Fprompts\u002Fskills\u002Fexperiments","---\nname: experiments\ndescription: >\n  Run, read, and compare dataset-backed experiments to find evidence that a prompt or pipeline is improving. Trigger when the user wants to iterate over a dataset with experiments, compare experiment runs, read experiment quality\u002Flatency\u002Fcost, or decide whether a change actually helped. Running a prompt over a dataset is implicitly an experiment — load this skill when dataset-backed work begins, before authoring evaluators for the experiment and before starting the recorded run, not only when reading results. Do NOT trigger on: (1) manual prompt drafting with no dataset-backed evaluation in scope (use `playground`), (2) authoring or refining an evaluator's logic or rubric (use `evaluators`), (3) cross-trace failure diagnosis with no experiment in scope (use `debug-trace`).\nsummary: Iterate over a dataset with experiments — run, read results across quality, latency, and cost, and compare candidates to drive improvement.\n---\n\n# Experiments\n\nAn experiment is one run of a prompt or pipeline over every example in a dataset, captured with its\noutputs and any evaluator annotations so it can be reviewed and compared later. Experiments turn\n\"this prompt feels better\" into evidence: a per-example record you can score, aggregate, and diff\nagainst an earlier run.\n\nReading, comparing, recording, and evaluating are run-path agnostic: they apply equally to\nexperiments created through the SDK or REST API and to experiments culled from traces. Only the run\nstep binds to playground capabilities — the `playground` skill owns prompt authoring and the\nmechanics of starting a recorded run. The `evaluators` skill owns how the scores you read here are\ndesigned. Route dataset evolution and hardening to `datasets`, and human annotation flows to\n`annotate-spans`.\n\n## Before You Start: Read What Already Ran\n\nBefore designing a new experiment on a dataset, read the experiments already run against it. Each\ncarries scaffolding written at creation — a hypothesis, the variable changed, the baseline it built\non — plus observations appended afterward. Reading that record avoids re-running a comparison a\nprevious session settled and tells you which hypotheses are still open. Inventory the dataset's\nexisting evaluators at the same time: what is already scored shapes what the next run can measure.\n\n## Workflow: Iterate Over A Dataset\n\nThe loop's only user touchpoints are defining the goal and accepting a tradeoff; everything between\nis drivable end-to-end, pausing only when one of those two conditions is genuinely underdetermined.\n\n1. Confirm the dataset represents the task: the input fields the run consumes, the expected outputs,\n   and the failure modes worth catching. Context the prompt must consume — a schema, retrieved\n   documents, a policy boundary — belongs in `input`, never in `reference`, which the run under test\n   must not see. When reading a dataset's `reference`, triage its provenance before trusting it as an\n   answer key — it may be golden, a baseline-snapshot, or absent (reference-free); the `evaluators`\n   skill owns that taxonomy.\n2. Make sure the starting prompt is well formed before running it — task, variables, output format,\n   and the constraints needed for consistent scoring. An ill-formed baseline wastes a run.\n3. Run the prompt over the dataset as a recorded experiment, staging the scaffold (hypothesis,\n   changed variable, baseline) at creation so a later session can read the comparison rather than\n   guess at it. A playground experiment is one LLM completion per example; to test multi-turn or\n   read-then-write behavior, prime the example's input with a multi-turn message history so the run\n   scores the completion the model emits next.\n4. Read the results across all three axes together — output quality (evaluator annotations, including\n   each judgment's explanation), latency, and cost — rather than fixating on a single score. Trust\n   aggregates only when the run is complete with zero errors; a half-finished or error-laden run\n   produces misleading summaries.\n5. Score what you observe. Anything example-level and scorable defaults to an evaluator at the moment\n   of observation — scores are reviewable, sortable columns a human can scan; observations are not.\n   Derive the judgment from the experiment's stated purpose, inventory the dataset's existing\n   evaluators, reuse one that matches, and create only on a gap (`evaluators` covers the design).\n6. Form one specific hypothesis for the next candidate — a named failure mode and the single change\n   expected to fix it — and change exactly one axis: prompt, model, invocation params, tool-guidance,\n   or dataset-scope. Changing several axes at once makes the comparison uninterpretable.\n7. Compare the new experiment against its baseline per-example and aligned, not by aggregate means\n   alone or from memory — an averaged metric hides the example a change broke. Splits may carry\n   different success criteria per split; never average a guarded holdout back into the headline\n   number. Use repetitions greater than one when you need a consistency read, not a point estimate.\n8. Report what the comparison showed: a verdict on the hypothesis, a summary across quality, latency,\n   and cost, and the evaluator explanations cited as evidence for the verdict.\n9. Continue hypothesis → run → compare → report until the evidence meets the stated goal, then save\n   the prompt version the evidence supports or the accepted tradeoff selects.\n\n## Recording What You Learned\n\nThere are two moments to write back, and they capture different things. Stage the scaffold before the\nrun, while the framing is fresh — the hypothesis, the changed variable, the baseline — as part of\nstarting the recorded run. After reading results, route by kind: experiment-level narrative —\nhypothesis verdicts, decisions taken, one-off drifts — belongs in the experiment's observations;\nanything example-level and scorable defaults to an evaluator the moment you observe it (step 5), not\nto an observation deferred until it recurs. To append an observation without losing what is already\nthere, read the experiment's current metadata first, then write back the whole object with a new\ntimestamped observation added and every existing key — hypothesis, changed variable, baseline among\nthem — left intact; a write that omits them erases the scaffold the next session depends on.\n\n## Boundaries\n\n- When a needed write — a dataset edit, a run setting, an invocation parameter — has no available\n  path, surface the change you need to the user rather than improvising it through raw reads or\n  writes.\n\n## Things To Avoid\n\n- Don't trust an experiment's aggregates while it is in progress or has nonzero errors.\n- Don't change more than one axis between experiments you intend to compare.\n- Don't average a guarded holdout split back into the headline number.\n- Don't re-run a comparison a previous session already settled; read the scaffolding first.\n- Don't read quality in isolation — a higher score that doubled latency or cost is not a win.\n",{"data":52,"body":54},{"name":4,"description":6,"summary":53},"Iterate over a dataset with experiments — run, read results across quality, latency, and cost, and compare candidates to drive improvement.",{"type":55,"children":56},"root",[57,65,71,108,115,120,126,131,218,224,229,235,244,250],{"type":58,"tag":59,"props":60,"children":61},"element","h1",{"id":4},[62],{"type":63,"value":64},"text","Experiments",{"type":58,"tag":66,"props":67,"children":68},"p",{},[69],{"type":63,"value":70},"An experiment is one run of a prompt or pipeline over every example in a dataset, captured with its\noutputs and any evaluator annotations so it can be reviewed and compared later. Experiments turn\n\"this prompt feels better\" into evidence: a per-example record you can score, aggregate, and diff\nagainst an earlier run.",{"type":58,"tag":66,"props":72,"children":73},{},[74,76,83,85,91,93,98,100,106],{"type":63,"value":75},"Reading, comparing, recording, and evaluating are run-path agnostic: they apply equally to\nexperiments created through the SDK or REST API and to experiments culled from traces. Only the run\nstep binds to playground capabilities — the ",{"type":58,"tag":77,"props":78,"children":80},"code",{"className":79},[],[81],{"type":63,"value":82},"playground",{"type":63,"value":84}," skill owns prompt authoring and the\nmechanics of starting a recorded run. The ",{"type":58,"tag":77,"props":86,"children":88},{"className":87},[],[89],{"type":63,"value":90},"evaluators",{"type":63,"value":92}," skill owns how the scores you read here are\ndesigned. Route dataset evolution and hardening to ",{"type":58,"tag":77,"props":94,"children":96},{"className":95},[],[97],{"type":63,"value":15},{"type":63,"value":99},", and human annotation flows to\n",{"type":58,"tag":77,"props":101,"children":103},{"className":102},[],[104],{"type":63,"value":105},"annotate-spans",{"type":63,"value":107},".",{"type":58,"tag":109,"props":110,"children":112},"h2",{"id":111},"before-you-start-read-what-already-ran",[113],{"type":63,"value":114},"Before You Start: Read What Already Ran",{"type":58,"tag":66,"props":116,"children":117},{},[118],{"type":63,"value":119},"Before designing a new experiment on a dataset, read the experiments already run against it. Each\ncarries scaffolding written at creation — a hypothesis, the variable changed, the baseline it built\non — plus observations appended afterward. Reading that record avoids re-running a comparison a\nprevious session settled and tells you which hypotheses are still open. Inventory the dataset's\nexisting evaluators at the same time: what is already scored shapes what the next run can measure.",{"type":58,"tag":109,"props":121,"children":123},{"id":122},"workflow-iterate-over-a-dataset",[124],{"type":63,"value":125},"Workflow: Iterate Over A Dataset",{"type":58,"tag":66,"props":127,"children":128},{},[129],{"type":63,"value":130},"The loop's only user touchpoints are defining the goal and accepting a tradeoff; everything between\nis drivable end-to-end, pausing only when one of those two conditions is genuinely underdetermined.",{"type":58,"tag":132,"props":133,"children":134},"ol",{},[135,171,176,181,186,198,203,208,213],{"type":58,"tag":136,"props":137,"children":138},"li",{},[139,141,147,149,155,157,162,164,169],{"type":63,"value":140},"Confirm the dataset represents the task: the input fields the run consumes, the expected outputs,\nand the failure modes worth catching. Context the prompt must consume — a schema, retrieved\ndocuments, a policy boundary — belongs in ",{"type":58,"tag":77,"props":142,"children":144},{"className":143},[],[145],{"type":63,"value":146},"input",{"type":63,"value":148},", never in ",{"type":58,"tag":77,"props":150,"children":152},{"className":151},[],[153],{"type":63,"value":154},"reference",{"type":63,"value":156},", which the run under test\nmust not see. When reading a dataset's ",{"type":58,"tag":77,"props":158,"children":160},{"className":159},[],[161],{"type":63,"value":154},{"type":63,"value":163},", triage its provenance before trusting it as an\nanswer key — it may be golden, a baseline-snapshot, or absent (reference-free); the ",{"type":58,"tag":77,"props":165,"children":167},{"className":166},[],[168],{"type":63,"value":90},{"type":63,"value":170},"\nskill owns that taxonomy.",{"type":58,"tag":136,"props":172,"children":173},{},[174],{"type":63,"value":175},"Make sure the starting prompt is well formed before running it — task, variables, output format,\nand the constraints needed for consistent scoring. An ill-formed baseline wastes a run.",{"type":58,"tag":136,"props":177,"children":178},{},[179],{"type":63,"value":180},"Run the prompt over the dataset as a recorded experiment, staging the scaffold (hypothesis,\nchanged variable, baseline) at creation so a later session can read the comparison rather than\nguess at it. A playground experiment is one LLM completion per example; to test multi-turn or\nread-then-write behavior, prime the example's input with a multi-turn message history so the run\nscores the completion the model emits next.",{"type":58,"tag":136,"props":182,"children":183},{},[184],{"type":63,"value":185},"Read the results across all three axes together — output quality (evaluator annotations, including\neach judgment's explanation), latency, and cost — rather than fixating on a single score. Trust\naggregates only when the run is complete with zero errors; a half-finished or error-laden run\nproduces misleading summaries.",{"type":58,"tag":136,"props":187,"children":188},{},[189,191,196],{"type":63,"value":190},"Score what you observe. Anything example-level and scorable defaults to an evaluator at the moment\nof observation — scores are reviewable, sortable columns a human can scan; observations are not.\nDerive the judgment from the experiment's stated purpose, inventory the dataset's existing\nevaluators, reuse one that matches, and create only on a gap (",{"type":58,"tag":77,"props":192,"children":194},{"className":193},[],[195],{"type":63,"value":90},{"type":63,"value":197}," covers the design).",{"type":58,"tag":136,"props":199,"children":200},{},[201],{"type":63,"value":202},"Form one specific hypothesis for the next candidate — a named failure mode and the single change\nexpected to fix it — and change exactly one axis: prompt, model, invocation params, tool-guidance,\nor dataset-scope. Changing several axes at once makes the comparison uninterpretable.",{"type":58,"tag":136,"props":204,"children":205},{},[206],{"type":63,"value":207},"Compare the new experiment against its baseline per-example and aligned, not by aggregate means\nalone or from memory — an averaged metric hides the example a change broke. Splits may carry\ndifferent success criteria per split; never average a guarded holdout back into the headline\nnumber. Use repetitions greater than one when you need a consistency read, not a point estimate.",{"type":58,"tag":136,"props":209,"children":210},{},[211],{"type":63,"value":212},"Report what the comparison showed: a verdict on the hypothesis, a summary across quality, latency,\nand cost, and the evaluator explanations cited as evidence for the verdict.",{"type":58,"tag":136,"props":214,"children":215},{},[216],{"type":63,"value":217},"Continue hypothesis → run → compare → report until the evidence meets the stated goal, then save\nthe prompt version the evidence supports or the accepted tradeoff selects.",{"type":58,"tag":109,"props":219,"children":221},{"id":220},"recording-what-you-learned",[222],{"type":63,"value":223},"Recording What You Learned",{"type":58,"tag":66,"props":225,"children":226},{},[227],{"type":63,"value":228},"There are two moments to write back, and they capture different things. Stage the scaffold before the\nrun, while the framing is fresh — the hypothesis, the changed variable, the baseline — as part of\nstarting the recorded run. After reading results, route by kind: experiment-level narrative —\nhypothesis verdicts, decisions taken, one-off drifts — belongs in the experiment's observations;\nanything example-level and scorable defaults to an evaluator the moment you observe it (step 5), not\nto an observation deferred until it recurs. To append an observation without losing what is already\nthere, read the experiment's current metadata first, then write back the whole object with a new\ntimestamped observation added and every existing key — hypothesis, changed variable, baseline among\nthem — left intact; a write that omits them erases the scaffold the next session depends on.",{"type":58,"tag":109,"props":230,"children":232},{"id":231},"boundaries",[233],{"type":63,"value":234},"Boundaries",{"type":58,"tag":236,"props":237,"children":238},"ul",{},[239],{"type":58,"tag":136,"props":240,"children":241},{},[242],{"type":63,"value":243},"When a needed write — a dataset edit, a run setting, an invocation parameter — has no available\npath, surface the change you need to the user rather than improvising it through raw reads or\nwrites.",{"type":58,"tag":109,"props":245,"children":247},{"id":246},"things-to-avoid",[248],{"type":63,"value":249},"Things To Avoid",{"type":58,"tag":236,"props":251,"children":252},{},[253,258,263,268,273],{"type":58,"tag":136,"props":254,"children":255},{},[256],{"type":63,"value":257},"Don't trust an experiment's aggregates while it is in progress or has nonzero errors.",{"type":58,"tag":136,"props":259,"children":260},{},[261],{"type":63,"value":262},"Don't change more than one axis between experiments you intend to compare.",{"type":58,"tag":136,"props":264,"children":265},{},[266],{"type":63,"value":267},"Don't average a guarded holdout split back into the headline number.",{"type":58,"tag":136,"props":269,"children":270},{},[271],{"type":63,"value":272},"Don't re-run a comparison a previous session already settled; read the scaffolding first.",{"type":58,"tag":136,"props":274,"children":275},{},[276],{"type":63,"value":277},"Don't read quality in isolation — a higher score that doubled latency or cost is not a win.",{"items":279,"total":435},[280,294,305,317,326,333,347,356,367,385,403,413],{"slug":105,"name":105,"fn":281,"description":282,"org":283,"tags":284,"stars":26,"repoUrl":27,"updatedAt":293},"annotate LLM spans and traces","Write effective, consistent annotations on LLM\u002Fagent spans and traces, and coach the user on annotation practice. Load this whenever you are about to record structured feedback with the `batch_span_annotate` tool, or when the user asks how to annotate, label, score, or review spans\u002Ftraces, build a failure taxonomy, or set up human\u002FLLM review. Do NOT load for: pure analysis with no intent to save feedback (use debug-trace), latency or cost statistics, or prompt authoring (use playground).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[285,286,287,290],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":288,"slug":289,"type":16},"Observability","observability",{"name":291,"slug":292,"type":16},"Tracing","tracing","2026-07-12T08:08:14.140984",{"slug":15,"name":15,"fn":295,"description":296,"org":297,"tags":298,"stars":26,"repoUrl":27,"updatedAt":304},"reason about Phoenix dataset structure","Understand what a Phoenix dataset is and reason well about its examples, outputs, splits, and how it feeds evaluators and experiments. Load this whenever a dataset is in view or the user asks what a dataset is, how splits work, what an output \"means\", or how datasets relate to experiments and evals. This skill governs the judgment; any tool descriptions govern the mechanics.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[299,302,303],{"name":300,"slug":301,"type":16},"Data Analysis","data-analysis",{"name":14,"slug":15,"type":16},{"name":21,"slug":22,"type":16},"2026-07-12T08:08:21.695457",{"slug":306,"name":306,"fn":307,"description":308,"org":309,"tags":310,"stars":26,"repoUrl":27,"updatedAt":316},"debug-trace","diagnose failures using trace investigation","Diagnose failure modes by systematically investigating traces. Trigger when the user explicitly asks for cross-trace diagnosis: \"what's going wrong?\", \"were there errors?\", \"debug this\", \"where is my agent struggling?\". Do NOT trigger on: (1) advice questions (\"what should I do?\"), (2) statistical questions (\"what's the average latency?\"), (3) summarize requests, (4) trace filtering (\"show me traces with errors\"), (5) vague questions (\"is there a problem?\"), (6) unrelated requests.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[311,314,315],{"name":312,"slug":313,"type":16},"Debugging","debugging",{"name":288,"slug":289,"type":16},{"name":291,"slug":292,"type":16},"2026-07-12T08:08:10.44243",{"slug":90,"name":90,"fn":318,"description":319,"org":320,"tags":321,"stars":26,"repoUrl":27,"updatedAt":325},"author and refine Phoenix evaluators","Author or refine a Phoenix evaluator — code or LLM-as-a-judge — that scores a run's output. Trigger when the user wants to create a new evaluator, improve an existing one's logic or rubric, choose labels, or decide what to measure on a dataset or experiment. Do NOT trigger on: (1) manual prompt drafting (use `playground`), (2) running or comparing experiments themselves (use `experiments`), (3) cross-trace failure diagnosis with no evaluator in scope (use `debug-trace`).\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[322,323,324],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},"2026-07-31T05:58:09.13624",{"slug":4,"name":4,"fn":5,"description":6,"org":327,"tags":328,"stars":26,"repoUrl":27,"updatedAt":28},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[329,330,331,332],{"name":14,"slug":15,"type":16},{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},{"slug":334,"name":334,"fn":335,"description":336,"org":337,"tags":338,"stars":26,"repoUrl":27,"updatedAt":346},"phoenix-graphql","query Phoenix API with GraphQL","Write efficient GraphQL queries against the Phoenix API. Load this skill in two cases: (1) before composing any non-trivial GraphQL query yourself for data analysis (via the `phoenix-gql` bash command) — it contains schema entrypoints and patterns that eliminate the need for introspection; (2) when the user asks for help writing GraphQL queries for their own scripts, tools, or integrations against Phoenix — it covers the endpoint, authentication, and client examples.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[339,342,343],{"name":340,"slug":341,"type":16},"Analytics","analytics",{"name":300,"slug":301,"type":16},{"name":344,"slug":345,"type":16},"GraphQL","graphql","2026-07-12T08:08:17.163493",{"slug":82,"name":82,"fn":348,"description":349,"org":350,"tags":351,"stars":26,"repoUrl":27,"updatedAt":355},"author and iterate on prompts in Phoenix","Author, edit, or iterate on prompts in the Phoenix prompt playground, including running experiments over a dataset. Load before any playground tool call, including single-shot prompt rewrites.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[352,353,354],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},"2026-07-12T08:08:12.920792",{"slug":357,"name":357,"fn":358,"description":359,"org":360,"tags":361,"stars":26,"repoUrl":27,"updatedAt":366},"span-coding","analyze and code Phoenix spans","Open-code Phoenix spans with PXI-owned notes, recover those notes for axial coding, and promote stable categories into structured annotations. Load this when analyzing spans to discover failure patterns before a taxonomy exists.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[362,363,364,365],{"name":312,"slug":313,"type":16},{"name":18,"slug":19,"type":16},{"name":288,"slug":289,"type":16},{"name":291,"slug":292,"type":16},"2026-07-12T08:08:19.597239",{"slug":368,"name":368,"fn":369,"description":370,"org":371,"tags":372,"stars":382,"repoUrl":383,"updatedAt":384},"arize-admin","manage Arize enterprise user access","Manages Arize users, organizations, spaces, projects, roles, role bindings, resource restrictions, and API keys via the ax CLI. Use for enterprise admin workflows: inviting and offboarding users, onboarding new teams, creating custom roles for SAML\u002FSSO mappings, assigning roles to users, restricting project-level access, and managing service keys for multi-tenant architectures. Covers ax users, ax organizations, ax spaces, ax projects, ax roles, ax role-bindings, and ax api-keys.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[373,376,379],{"name":374,"slug":375,"type":16},"CLI","cli",{"name":377,"slug":378,"type":16},"Operations","operations",{"name":380,"slug":381,"type":16},"Permissions","permissions",38,"https:\u002F\u002Fgithub.com\u002FArize-ai\u002Farize-skills","2026-07-22T05:37:21.991338",{"slug":386,"name":386,"fn":387,"description":388,"org":389,"tags":390,"stars":382,"repoUrl":383,"updatedAt":402},"arize-ai-provider-integration","manage Arize AI provider integrations","Creates, reads, updates, and deletes Arize AI integrations that store LLM provider credentials used by evaluators and other Arize features. Supports any LLM provider (e.g. OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Vertex AI, Gemini, NVIDIA NIM). Use when the user mentions AI integration, LLM provider credentials, create integration, list integrations, update credentials, delete integration, or connecting an LLM provider to Arize.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[391,393,396,399,400],{"name":392,"slug":36,"type":16},"Anthropic",{"name":394,"slug":395,"type":16},"Azure","azure",{"name":397,"slug":398,"type":16},"Integrations","integrations",{"name":18,"slug":19,"type":16},{"name":401,"slug":43,"type":16},"OpenAI","2026-07-22T05:37:23.90468",{"slug":404,"name":404,"fn":405,"description":406,"org":407,"tags":408,"stars":382,"repoUrl":383,"updatedAt":412},"arize-annotation","manage Arize annotation workflows","Creates and manages annotation configs (categorical, continuous, freeform label schemas) and annotation queues (human review workflows) on Arize. Applies human annotations to project spans via the Python SDK. Use when the user mentions annotation config, annotation queue, label schema, human feedback, bulk annotate spans, update_annotations, labeling queue, annotate record, or human review.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[409,410,411],{"name":300,"slug":301,"type":16},{"name":18,"slug":19,"type":16},{"name":288,"slug":289,"type":16},"2026-07-22T05:37:19.010776",{"slug":414,"name":414,"fn":415,"description":416,"org":417,"tags":418,"stars":382,"repoUrl":383,"updatedAt":434},"arize-compliance-audit","audit AI agents for regulatory compliance","INVOKE THIS SKILL when auditing an AI agent or LLM app for regulatory compliance. Covers EU AI Act, GPAI Code of Practice, GDPR, NIST AI RMF, Colorado AI Act, HIPAA, and ISO 42001. Scans the codebase for compliance gaps, cross-references Arize instrumentation for audit trail coverage, and produces an actionable remediation checklist tailored to the selected frameworks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[419,422,425,428,431],{"name":420,"slug":421,"type":16},"Audit","audit",{"name":423,"slug":424,"type":16},"Compliance","compliance",{"name":426,"slug":427,"type":16},"GDPR","gdpr",{"name":429,"slug":430,"type":16},"Legal","legal",{"name":432,"slug":433,"type":16},"Security","security","2026-07-19T05:39:42.632738",23,{"items":437,"total":482},[438,445,451,457,463,470,476],{"slug":105,"name":105,"fn":281,"description":282,"org":439,"tags":440,"stars":26,"repoUrl":27,"updatedAt":293},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[441,442,443,444],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":288,"slug":289,"type":16},{"name":291,"slug":292,"type":16},{"slug":15,"name":15,"fn":295,"description":296,"org":446,"tags":447,"stars":26,"repoUrl":27,"updatedAt":304},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[448,449,450],{"name":300,"slug":301,"type":16},{"name":14,"slug":15,"type":16},{"name":21,"slug":22,"type":16},{"slug":306,"name":306,"fn":307,"description":308,"org":452,"tags":453,"stars":26,"repoUrl":27,"updatedAt":316},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[454,455,456],{"name":312,"slug":313,"type":16},{"name":288,"slug":289,"type":16},{"name":291,"slug":292,"type":16},{"slug":90,"name":90,"fn":318,"description":319,"org":458,"tags":459,"stars":26,"repoUrl":27,"updatedAt":325},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[460,461,462],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},{"slug":4,"name":4,"fn":5,"description":6,"org":464,"tags":465,"stars":26,"repoUrl":27,"updatedAt":28},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[466,467,468,469],{"name":14,"slug":15,"type":16},{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},{"slug":334,"name":334,"fn":335,"description":336,"org":471,"tags":472,"stars":26,"repoUrl":27,"updatedAt":346},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[473,474,475],{"name":340,"slug":341,"type":16},{"name":300,"slug":301,"type":16},{"name":344,"slug":345,"type":16},{"slug":82,"name":82,"fn":348,"description":349,"org":477,"tags":478,"stars":26,"repoUrl":27,"updatedAt":355},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[479,480,481],{"name":21,"slug":22,"type":16},{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},8]