Imported from konstantinosmpouros/mAgenticX (src/agents/runtime/skill_registry/registry/llm-evaluation/llm-obs-eval-bootstrap/SKILL.md). Install upstream with npx skills add konstantinosmpouros/mAgenticX --skill llm-obs-eval-bootstrap. Copyright stays with the author.

Backend

Detection — At the start of every invocation, before taking any action, determine which backend to use:

1. If the user passed --backend pup anywhere in their invocation → use pup mode immediately, regardless of whether MCP tools are present. Skip steps 2–4.
2. Check whether MCP tools are present in your active tool list. The canonical signal is whether mcp__datadog-llmo-mcp__list_llmobs_evals appears in your available tools.
3. If MCP tools are present → use MCP mode throughout. Call MCP tools exactly as named in this skill's workflow sections.
4. If MCP tools are absent → check whether pup is executable: run pup --version via Bash. A JSON response containing "version" confirms pup is available.
5. If pup responds → use pup mode throughout. Translate every MCP tool call to its pup equivalent using the Tool Reference appendix at the bottom of this file.
6. If neither is available → stop and tell the user:

   "Neither the Datadog MCP server nor the pup CLI is available. Connect the MCP server (claude mcp add --scope user --transport http datadog-llmo-mcp 'https://mcp.datadoghq.com/api/unstable/mcp-server/mcp?toolsets=llmobs') or install pup."

--backend pup is accepted anywhere in the invocation arguments and is stripped before passing remaining args to the skill logic.

pup invocation rules:

• Invoke via Bash: pup llm-obs <subcommand> [flags]
• pup always outputs JSON. Parse directly — no content-block unwrapping (unlike MCP results, which may wrap JSON in [{"type": "text", "text": "<json>"}]).
• If pup returns an auth error, tell the user to run pup auth login and stop.
• Parallelization: issue multiple Bash tool calls in a single message (one pup command per call).
• Time flags: pup accepts bare duration strings (1h, 7d, 30m) and RFC3339 timestamps. Do not use now--prefixed strings — strip the prefix when converting from a skill --timeframe argument: now-7d → 7d, now-24h → 24h, now-30d → 30d.
• --summary on pup llm-obs spans search strips payload fields to essential metadata only. Use it in bulk/search phases where content is not needed.

Invocation ID: At the very start of each invocation, before any MCP tool call, generate an 8-character hex invocation ID (e.g., 3a9f1c2b). Keep it constant for the entire invocation.

Intent tagging: On every MCP tool call, prefix telemetry.intent with skill:llm-obs-eval-bootstrap[<inv_id>] — followed by a description of why the tool is being called. On the first MCP tool call only, use skill:llm-obs-eval-bootstrap:start[<inv_id>] — instead (note the :start suffix). Example first call: skill:llm-obs-eval-bootstrap:start[3a9f1c2b] — Phase 0: map existing eval coverage for task-cruncher

Eval Bootstrap — Generate Evaluators from Production Traces

Given a sample of production LLM traces, analyze input/output patterns and quality dimensions, then propose a ready-to-use evaluator suite. Three output modes — online evaluators are the default; SDK code and the JSON spec are produced on request:

• publish (default) — propose online LLM-judge evaluators, then — only after you confirm the suite — write them to Datadog via create_or_update_llmobs_evaluator as disabled drafts (enabled: false). Nothing is created until you confirm at the Phase 2 checkpoint, and nothing scores any spans until you enable it in the UI — the skill never auto-publishes a live evaluator. Once you enable a draft, it runs automatically on matching production spans, traces, or sessions (no dataset, no task function). The skill auto-classifies each proposed evaluator as span-scoped, trace-scoped, or session-scoped based on what the judgment requires (a per-LLM-call tone check vs. an agent goal completion that needs the whole trace vs. user satisfaction across a whole multi-trace conversation) — you accept or override the classification at that checkpoint. Session-scoped evaluators are only proposed when the app's spans carry a session_id (verified by a probe in Phase 1).
• sdk_code (on request — --sdk-code, or ask after a publish run) — Python .py file using the Datadog Evals SDK (BaseEvaluator / LLMJudge) for offline experiments.
• data_only (on request — --data-only) — self-contained JSON spec, framework-agnostic.

After a publish run, if the user wants the same suite as offline code or a portable spec, they just ask — the skill regenerates the already-confirmed suite in sdk_code / data_only mode without re-exploring (see "On-request code generation" in Phase 3).

Usage

/eval-bootstrap <ml_app> [--timeframe <window>] [--sdk-code | --data-only]

Arguments: $ARGUMENTS

Inputs

If ml_app is missing, ask the user before proceeding. With no mode flag, the skill defaults to publish — it proposes online evaluators and, only after you confirm, creates them as disabled drafts (it never auto-enables them). If both --sdk-code and --data-only are supplied, error out and ask which mode the user wants.

Available Tools

Key get_llmobs_span_content Patterns

Use the path parameter to extract targeted data without fetching full payloads:

How to Use search_llmobs_spans

Additional filters combine with space (AND): @status:error @ml_app:my-app. Dedicated params (span_kind, root_spans_only, ml_app) work alongside query, but query takes precedence over tags.

To find spans with a specific eval: @evaluations.custom.<eval_name>:* — you can only query for eval presence, not specific results.

To detect whether the app uses sessions: session_id:* matches any span carrying a session_id (session_id is a first-class field — no @ prefix). The Phase 1 session probe uses this to gate session-scope evaluators.

Parallelization Rules

1. get_llmobs_span_details: Group span_ids by trace_id. One call per trace_id with ALL its span_ids. Issue ALL calls for a page in a single message.
2. get_llmobs_span_content: Each call is independent — always issue ALL in a single message.
3. get_llmobs_trace / get_llmobs_agent_loop: Parallelize across different traces in a single message.
4. Pipeline parallelism: Start get_llmobs_span_details for page 1 results immediately — don't wait to collect all pages.

Evaluator SDK Reference

Applies to sdk_code mode only. In data_only mode, use this section as domain context when writing rubric prompts — no SDK classes are emitted.

Imports

# Core classes
from ddtrace.llmobs._experiment import BaseEvaluator, EvaluatorContext, EvaluatorResult

# LLM-as-judge
from ddtrace.llmobs._evaluators.llm_judge import (
    LLMJudge,
    BooleanStructuredOutput,
    ScoreStructuredOutput,
    CategoricalStructuredOutput,
)

# Built-in evaluators (use only if needed)
from ddtrace.llmobs._evaluators.format import JSONEvaluator, LengthEvaluator
from ddtrace.llmobs._evaluators.string_matching import StringCheckEvaluator, RegexMatchEvaluator

Only import what the generated file actually uses.

EvaluatorContext (what evaluate() receives)

@dataclass(frozen=True)
class EvaluatorContext:
    input_data: dict[str, Any]          # Task inputs (from dataset record, NOT from span)
    output_data: Any                     # Task output (from task function return, NOT from span)
    expected_output: Optional[JSONType] = None  # Ground truth (if available)
    metadata: dict[str, Any] = {}        # Additional metadata
    span_id: Optional[str] = None        # LLMObs span ID
    trace_id: Optional[str] = None       # LLMObs trace ID

Important — span data vs evaluator data: When exploring production traces, you see span I/O (e.g., input.value, output.messages). But evaluators run in offline experiments where input_data and output_data come from the user's dataset records and task function, not from spans. The dataset schema is user-defined and may not match span structure. Write evaluator prompts with generic {{input_data}} / {{output_data}} placeholders and add comments describing what data the evaluator was designed for, so the user can adapt to their dataset shape.

EvaluatorResult (what evaluate() returns)

EvaluatorResult(
    value=...,                    # Required. JSONType (str, int, float, bool, None, list, dict)
    reasoning="...",              # Optional. Explanation string
    assessment="pass" or "fail",  # Optional. Pass/fail assessment
    metadata={...},              # Optional. Evaluation metadata dict
    tags={...},                  # Optional. Tags dict
)

LLMJudge — LLM-as-Judge Evaluator

judge = LLMJudge(
    user_prompt="...",              # Required. Supports {{template_vars}}
    system_prompt="...",            # Optional. Does NOT support template vars
    structured_output=...,          # Optional. Boolean/Score/Categorical output, or a dict for custom JSON schema
    provider="openai",              # "openai" | "anthropic" | "azure_openai" | "vertexai" | "bedrock"
    model="gpt-4o",                # Model identifier
    model_params={"temperature": 0.0},  # Optional. Passed to LLM API
    name="eval_name",              # Optional. Must match ^[a-zA-Z0-9_-]+$
)

Template variables in user_prompt: {{input_data}}, {{output_data}}, {{expected_output}}, {{metadata.key}} — resolved from EvaluatorContext fields via dot-path into nested dicts.

Structured Output Types

Boolean — true/false with optional pass/fail:

BooleanStructuredOutput(
    description="Whether the response is factually accurate",
    reasoning=True,                    # Include reasoning field in LLM response
    reasoning_description=None,        # Optional custom description for reasoning field
    pass_when=True,                    # True → pass when true, False → pass when false, None → no assessment
)

Score — numeric within a range with optional thresholds:

ScoreStructuredOutput(
    description="Helpfulness score",
    min_score=1,                       # Minimum possible score
    max_score=10,                      # Maximum possible score
    reasoning=True,
    reasoning_description=None,
    min_threshold=7,                   # Scores >= 7 pass (optional)
    max_threshold=None,                # Scores <= N pass (optional)
)

Categorical — select from predefined categories:

CategoricalStructuredOutput(
    categories={
        "correct": "The response correctly answers the question",
        "partially_correct": "The response is partially correct but missing key information",
        "incorrect": "The response is factually wrong or irrelevant",
    },
    reasoning=True,
    reasoning_description=None,
    pass_values=["correct"],           # Which categories count as passing (optional)
)

Custom JSON schema — arbitrary structured responses for multi-dimensional evals:

# Pass a raw dict as structured_output — used as the JSON schema directly
structured_output={
    "type": "object",
    "properties": {
        "relevance": {"type": "boolean", "description": "Whether the response addresses the question"},
        "confidence": {"type": "number", "description": "Confidence score (0.0 to 1.0)"},
        "reasoning": {"type": "string", "description": "Explanation for the evaluation"},
    },
    "required": ["relevance", "confidence", "reasoning"],
    "additionalProperties": False,
}

Always write standard JSON schema — the SDK adapts it per provider automatically (e.g., Anthropic doesn't support minimum/maximum on number fields, so the SDK moves range constraints into the description; Vertex AI converts const/anyOf to enum). The full parsed JSON dict becomes the eval value; a "reasoning" key (if present) is automatically extracted. No automatic pass/fail assessment.

LLMJudge Prompt Guidelines

The structured_output parameter enforces the response format via JSON schema. Do not prescribe the format in the prompt (no "Answer YES/NO", "Rate 1-10", etc.). Instead, describe the evaluation criteria and let the structured output handle the format.

• system_prompt: Set the judge's role and the app's domain context. Does NOT support template vars.
• user_prompt: Present the data via {{input_data}} / {{output_data}}, then describe what good vs. bad looks like for this dimension.

BaseEvaluator — Custom Code-Based Evaluator

For deterministic checks that do not need LLM judgment:

class MyEvaluator(BaseEvaluator):
    def __init__(self, name=None, ...custom_params...):
        super().__init__(name=name)
        self._param = ...  # Store config as private attrs

    def evaluate(self, context: EvaluatorContext) -> EvaluatorResult:
        # Access: context.input_data, context.output_data, context.expected_output, context.metadata
        # Must NOT modify self attributes (thread safety)
        passed = ...  # Your logic here
        return EvaluatorResult(
            value=passed,
            reasoning="...",
            assessment="pass" if passed else "fail",
        )

Built-in Evaluators

# Validate JSON syntax + optional required keys
JSONEvaluator(required_keys=["name", "age"], output_extractor=None, name=None)

# Validate length (characters, words, or lines)
LengthEvaluator(count_by="words", min_length=10, max_length=500, output_extractor=None, name=None)
# count_by: "characters" | "words" | "lines"

# String matching
StringCheckEvaluator(operation="contains", expected="success", case_sensitive=False, name=None)
# operation: "eq" | "ne" | "contains" | "icontains"

# Regex matching
RegexMatchEvaluator(pattern=r"\d{4}-\d{2}-\d{2}", match_mode="search", name=None)
# match_mode: "search" | "match" | "fullmatch"

Evaluator Type Decision Matrix

Source Verification

If you have access to dd-trace-py locally, verify the API surface by reading the corresponding modules:

• ddtrace.llmobs._evaluators.llm_judge — LLMJudge, BooleanStructuredOutput, ScoreStructuredOutput, CategoricalStructuredOutput
• ddtrace.llmobs._experiment — BaseEvaluator, EvaluatorContext, EvaluatorResult
• ddtrace.llmobs._evaluators.format — JSONEvaluator, LengthEvaluator
• ddtrace.llmobs._evaluators.string_matching — StringCheckEvaluator, RegexMatchEvaluator

Workflow

Phase 0: Resolve Inputs & Entry Mode

Entry mode detection:

Parse arguments: Extract ml_app (first non-flag argument), --timeframe (default now-7d), --sdk-code, and --data-only flags. Set output_mode = sdk_code if --sdk-code is set, output_mode = data_only if --data-only is set, otherwise output_mode = publish (the default). Error if both --sdk-code and --data-only are present.

Resolution steps:

1. If ml_app not provided → ask the user.

2. Auto-detect entry mode:

   • If the conversation contains an RCA report (look for "Failure Taxonomy" heading, structured failure modes, or severity ratings) → from_rca. Extract the taxonomy.
   • If the user provides a free-text failure hypothesis (e.g., "the system prompt lacks grounding") → from_rca. Use the hypothesis as the starting eval target.
   • Otherwise → cold_start.

3. If timeframe not provided → default to now-7d.

4. Map existing eval coverage — skip if output_mode = data_only (there is no Datadog eval project to check coverage against): Call list_llmobs_evals (org-wide; filter the result client-side to entries where ml_app == <ml_app>). Then, for each eval with source=custom, call get_llmobs_evaluator(eval_name=...) to inspect its prompt template, target, sampling, and filter, and infer which quality dimension it covers. Issue all evaluator calls in a single message (parallelize). Skip source=ootb evals — their names are self-describing and they may not have a fetchable config.

   By the end of this step you have a complete coverage map: {eval_name → source, enabled, dimension}. Carry this into Phase 2 for deduplication.

   In publish mode, also note any template-variable convention the existing custom evaluators already use (so a new suite reads consistently). Online evaluator templates resolve against the full span JSON, not against EvaluatorContext. See the "Online Template Variables" section under "Publishing Conventions" for the supported syntax ({{span_input}}, {{span_output}}, dot-paths, array selectors, filter accessors).

5. Notebook context detection: Scan the current conversation for a Datadog notebook URL that was produced by /eval-trace-rca (pattern: https://app.datadoghq.com/notebook/{numeric-id}). If found, store it as rca_notebook_url and extract the numeric ID as rca_notebook_id. This is used after Phase 3 to offer appending the evaluator suite to that notebook instead of creating a new one.

Phase 1: Explore Traces & Identify Eval Targets

Goal: Sample production traces, understand what the app does, and identify quality dimensions worth measuring.

Cold Start Path

1. Sample the app: search_llmobs_spans(query="@ml_app:\"<ml_app>\" @status:ok", root_spans_only=true, limit=50, from=<timeframe>). Filter by @status:ok — error spans have no output to evaluate.

   Session probe (gates session-scope proposals; publish mode): in the same message, also call search_llmobs_spans(query="@ml_app:\"<ml_app>\" session_id:*", limit=20, from=<timeframe>).

   • ≥ 1 result → set sessions_present = true. Note the distinct session_id values and, critically, whether the same session_id appears across multiple trace_ids — that cross-trace span is the real signal that a session carries context worth a session-scope evaluator. (A session_id that only ever maps to one trace adds nothing over trace scope.)
   • 0 results → sessions_present = false. Do not propose any session-scope evaluator; record a one-line "session scope skipped — no session_id on sampled spans" note for the proposal.

2. Profile the app and identify evaluation target spans: Call get_llmobs_span_details for span_ids grouped by trace_id. Inspect content_info to classify:

   Signal	App Profile
   content_info has messages	LLM/chat app
   content_info has documents	RAG app
   Spans include agent kind	Agent app
   content_info has metadata	Has custom metadata
   Multiple span kinds in one trace (agent + tool / retrieval + llm from get_llmobs_trace)	Multi-step app — at least one trace-scope evaluator likely belongs in the suite (publish mode)
   Same session_id across multiple trace_ids (from the session probe)	Multi-trace sessions — at least one session-scope evaluator likely belongs in the suite (publish mode, gated on sessions_present)

   For agent/multi-step apps, also call get_llmobs_trace on 2-3 traces to see the full span hierarchy. Compare content_info between the root span and its sub-spans. Then ask two questions for each candidate quality dimension, in this order:

   1. Does the verdict depend on more than one span? (e.g., faithfulness depends on a retrieval span's documents AND an llm span's answer; goal completion depends on the chain of tool calls AND the final response.) If yes → trace scope in publish mode. Don't try to compress this into a single span.
   2. Only if the answer to (1) is no: pick the single span with the richest signal for that dimension (root has the summary; LLM sub-spans have the full system prompt + tool call results + reasoning chain).

   Record the span-kind histogram (agent + tool + llm + retrieval) — multiple kinds under one root is a strong signal you'll have at least one trace-scope evaluator in the suite. See Phase 2's "Span vs. Trace vs. Session Scope Classification" for the mandatory walk-through of canonical trace-scope use cases (and, when sessions_present, the canonical session-scope use cases).

3. Extract content and identify targets: Call get_llmobs_span_content for representative spans. Fetch fields based on app profile:

   App Profile	Fields to Fetch
   LLM/chat	messages (path=$.messages[0] for system prompt), output
   RAG	documents, input, output
   Agent	get_llmobs_agent_loop for the agent span, then messages for detail
   Any with metadata	metadata

   Issue all calls in a single message. As you read, capture two streams of signal:

   Generic quality signals — what does "success" look like? What variance exists across outputs? Each observed quality dimension becomes a candidate evaluator, with the traces you've just read as evidence. Also look for safety signals (scope violations, sensitive data in outputs, out-of-character responses) and add a safety evaluator if you find them.

   Domain signals — these become the domain-specific evaluator category in Phase 2 (the highest-leverage category). For every 5–10 traces, write down:

   • Recurring intents / question categories — what classes of request does this app handle? (applying for benefit X, comparing flight options, summarizing a policy, creating a widget)
   • Entities the app emits in outputs — URLs, agency / company names, code identifiers, monetary amounts, dates, IDs, file paths, phone numbers. Note which ones the user acts on downstream (those are worth a correctness evaluator) versus which are passing references.
   • Tool argument shapes (for agent apps) — name each tool the agent calls and the rough schema of its inputs. Tools with non-trivial schemas (≥ 3 fields, structured types) are candidates for argument-correctness evaluators.
   • Persona / voice rules — does the app always cite a source, always refuse certain topics (medical, legal, financial advice), always speak in a particular tone? Extract the rules implicitly followed across observed outputs.
   • Failure modes specific to the domain — fabricated identifiers, outdated policy references, currency / locale mismatches, off-by-one errors in IDs, wrong units. One observed instance is enough to seed a candidate evaluator.

   Don't try to enumerate domain signals exhaustively before reading traces — let the patterns surface as you read. The goal is breadth in the eventual proposal, not completeness in this exploration step.

From RCA Path

1. Extract the failure taxonomy from the RCA report. Each failure mode with High or Medium severity becomes an eval target. Also run the Phase 1 session probe (query="session_id:*") to set sessions_present — a failure that only manifests across a multi-trace conversation (lost context, repeated mistakes, mounting frustration) is a session-scope target.

2. Check root cause categories for infrastructure failures. Before proposing evaluators, scan the Root Cause column of the taxonomy for any of: Instrumentation Deficiency, Harness Deficiency, Runtime Error, Upstream Data Issue, or any other root cause that points to infrastructure/environment rather than model behavior. If any are present, pause and ask:

   "Some failure modes were diagnosed as infrastructure or instrumentation issues rather than model behavior (e.g., {list the infra root causes}). Evaluators can be designed two ways:

   • Behavior-targeted (recommended for ongoing quality): measure whether the model produces correct, specific output — useful once the infrastructure is fixed and you want to track real quality
   • Artifact-targeted (useful as regression guard): detect the specific broken output observed (e.g., generic placeholder responses) — catches regressions if the infrastructure breaks again

   Which approach do you want, or both?"

   • If behavior-targeted: design evaluators for what correct output looks like, not what the broken output looked like. Use the RCA's expected_output / gold-standard examples as the quality bar.
   • If artifact-targeted: design evaluators that detect the specific failure symptom (e.g., StringCheckEvaluator for a known bad string, LLMJudge that checks for generic placeholders).
   • If both: propose each category separately, clearly labelled.

   If all root causes are behavioral (System Prompt Deficiency, Tool Gap, Tool Misuse, Retrieval Failure, etc.) → skip this step and proceed directly.

3. For each target: if the RCA includes trace IDs, use them directly; otherwise search for matching traces. Fetch 2-3 traces per target with get_llmobs_span_content to understand the concrete pattern.

Phase 2: Propose Evaluator Suite

Goal: Present a concrete evaluator proposal for user confirmation.

In sdk_code / data_only mode — and for eval_scope: span in publish mode — each evaluator judges one data point: input and output for a single record/span, not a full trace or batch. In publish mode, eval_scope: trace judges a whole trace and eval_scope: session a whole multi-trace session — design those against the trace / session payload instead (see "Span vs. Trace vs. Session Scope Classification" below). Design evaluators accordingly for their scope.

Targeting depends on output_mode:

• sdk_code / data_only → offline experiments. Template variables use EvaluatorContext fields ({{input_data}}, {{output_data}}). The actual data shape depends on the user's dataset and task function (see EvaluatorContext note in SDK Reference).
• publish → online evaluation on production spans. Template variables resolve against the full span JSON via dot-paths ({{meta.input.value}}, {{meta.output.messages[*].content}}, …) or the built-in span-kind-aware aliases ({{span_input}}, {{span_output}}). For eval_scope: trace and eval_scope: session, templates resolve against the trace payload ({{spans[...]}}) or the session payload ({{traces[*].spans[...]}}) instead. See "Online Template Variables" under Publishing Conventions for the full syntax. Each evaluator also needs eval_scope, sampling_percentage, and (optionally) filter — surface these in the proposal table so the user can confirm before publishing. Session scope is only used when the Phase 1 probe set sessions_present.

Order proposals from broadest signal to most granular. Propose broadly, let the user curate — see "How many evaluators to propose" below.

1. Domain-specific evaluators — What does "good" mean for this specific app? These are the highest-leverage proposals because they capture quality bars generic evaluators miss. Derive them from the domain signals Phase 1 captured:

   • Recurring intents / question categories the app handles (e.g., "applying for a federal benefit", "comparing flight options", "explaining a policy"). Propose an intent_classification or intent_handling_correctness evaluator scoped to the dominant intents.
   • Specific entities the app produces (URLs, agency names, code identifiers, monetary amounts, dates, IDs). Propose a per-entity correctness evaluator for the ones with real downstream cost when wrong (e.g., cited_url_is_real, agency_name_matches_request, monetary_amount_is_consistent_with_input).
   • Tool argument shapes observed across tool spans. Propose a per-tool argument-correctness evaluator for the tools with non-trivial schemas (e.g., search_flights_args_match_user_request, update_dashboard_widget_targets_correct_widget).
   • Persona / voice expectations — does the app always cite sources, always refuse out-of-scope requests, always speak in a specific tone? Propose evaluators for the voice rules you can extract from observed outputs (cites_a_source, refuses_medical_advice, tone_matches_brand).
   • Domain-specific failure modes seen across traces (fabricated identifiers, outdated policy references, unit mismatches, currency / locale mismatches). One evaluator per recurring failure mode.

   Name each evaluator after the user-facing concern, not the technical check (agency_url_is_real over regex_url_match). Use the trace IDs you read in Phase 1 as evidence — at least one passing case and one failing case per evaluator if you saw both.

2. Outcome evaluators — Did this span / trace produce a good result for the request?

   • Examples: task_completion, answer_correctness, response_groundedness

3. Format evaluators — Does the output meet structural requirements?

   • Examples: valid_json_output, response_length, citation_format

4. Safety evaluators — Does the output stay within appropriate boundaries?

   • Examples: no_pii_leakage, scope_adherence, no_hallucination

How many evaluators to propose

The default 4-6 cap from the older skill version was too tight — it pushed the skill toward generic evaluators only and left domain signals on the table. Updated guidance:

• Aim for 8–15 evaluators in the proposal, distributed across all four categories (with domain-specific usually the largest bucket, outcome second, format and safety smaller). For very simple single-LLM-call apps, fewer is fine; for agent / RAG apps with rich domain signals, lean toward the upper end.
• Quality > generic: every domain-specific proposal should be backed by at least one observed pattern in the sampled traces. Don't invent generic domain evaluators ("response_quality") if you don't have evidence for them.
• Let the user curate: the MANDATORY CHECKPOINT below explicitly asks the user to remove what doesn't apply, not just to approve. Treat the proposal as a candidate set the user trims.

Deduplication Against Existing Coverage

In data_only mode: skip this section entirely (coverage map was not built in Phase 0). Proceed directly to the proposal table.

Before building the proposal, apply the coverage map from Phase 0. Coverage is keyed on (dimension, scope) — not on dimension alone: every OOTB evaluator runs at span scope, and an enabled OOTB eval does NOT preclude proposing a trace-scope or session-scope evaluator for the same dimension. The three scopes answer different questions.

1. Enabled span-scope eval (OOTB or custom) for dimension D:

   • Do NOT propose a new span-scope evaluator for D — that dimension is already covered at span scope.
   • DO propose a trace-scope or session-scope evaluator for D when the trace or session shape calls for it (multi-step app, or multi-trace session — judgment depends on cross-span or cross-trace context). Note the relationship in the rationale: e.g., "OOTB Goal Completeness evaluates each LLM span in isolation; this trace-scope goal_completion checks whether the agent's full sequence of steps achieved the user's request, and a session-scope session_goal_completion checks it across the whole conversation — three different questions."

2. Enabled trace-scope custom eval for dimension D: do NOT propose another trace-scope evaluator for the same dimension; that's a real duplicate. Span-scope on the same dimension is still fair game if the data also fits a single span, and session-scope is fair game if the dimension also needs cross-trace context. Likewise, an enabled session-scope custom eval for D blocks only another session-scope eval for D — span and trace scope remain fair game.

3. Disabled OOTB eval: Do NOT propose a new custom span-scope evaluator for that dimension. Instead, surface it in a short note within the proposal and suggest enabling it in the Datadog UI rather than creating a duplicate. Example:

   hallucination (ootb, disabled) — consider enabling in Datadog UI (Evaluations → Configure) instead of creating a custom span-scope eval. (A trace-scope rag_faithfulness is still in scope and covers a different question.)

4. Gap identification: Open the proposal with a coverage summary line: "Existing coverage: N evaluator(s) already configured ({names}, all span-scope unless noted). Proposing evaluators for uncovered dimensions and uncovered scopes."

5. All dimensions covered: A dimension is "fully covered" only when the relevant scopes are present (span, plus trace and/or session where the app shape calls for them). If the coverage map accounts for every identified quality dimension at the appropriate scope(s), surface this explicitly and ask the user what they want: (a) review/improve existing eval prompts, (b) add coverage for additional dimensions, or (c) proceed anyway.

For each proposed evaluator:

• Name: Must match ^[a-zA-Z0-9_-]+$ (alphanumeric, underscore, hyphen only)
• Type: LLMJudge (Boolean/Score/Categorical/custom JSON schema), built-in (JSONEvaluator, RegexMatchEvaluator, etc.), or BaseEvaluator subclass. In publish mode, only LLM-judge evaluators are supported by the MCP tool — code-based checks must NOT be silently dropped. List them in the same proposal table with Type set to the code-based class, mark them under a "Not publishable in this mode" subsection of the proposal, and tell the user they can get them as offline code on request (--sdk-code, or ask after the publish run) or as a --data-only spec. Treat the code-based proposals as part of the suite for counting and coverage purposes.
• What it measures: 1-2 sentence plain-language description
• Target span: Which span's data the evaluator was designed for (e.g., "root agent span", "LLM sub-span anthropic.request", "all llm spans"). If the root span's I/O is too lossy for the quality dimension (e.g., tool call results aren't visible), note this and specify which sub-span has the signal. In publish mode this maps to a combination of eval_scope (span/trace/session), root_spans_only, and the EVP filter query (e.g. @meta.span.kind:llm or service:web).
• Pass/fail criteria: pass_when=True, min_threshold=7, pass_values=["correct"], or "no automatic assessment" for custom JSON schema
• Template variables: Which of input_data, output_data, expected_output, metadata.* it uses (offline) — or which span paths / aliases it pulls from (publish mode: {{span_input}}, {{span_output}}, {{meta.input.messages[*].content}}, {{meta.metadata.<key>}}, etc.)
• Evidence: At least one trace where it would have caught a failure (or confirmed correct behavior)
• Publish-only fields (only in publish mode): integration_provider (default openai), model_name (default gpt-5.4-mini), sampling_percentage (default 10), eval_scope (default span), and any filter query needed to scope to the right spans. Surface defaults in the proposal so the user can override before publishing.
• integration_account_id (only in publish mode): the integration account the judge LLM is called through. Auto-detected from existing evaluators in the same ml_app (Phase 0 coverage map). Never asked from the user as a raw UUID. If no existing evaluator has one, the field is omitted and the user picks an account in the UI before activating. All evaluators are published with enabled: false regardless — see "Always publish as draft" in Phase 3C for the full activation workflow.

Span vs. Trace vs. Session Scope Classification (publish mode)

Don't ask the user; classify per evaluator and let them override at the checkpoint.

Mandatory: walk the four canonical trace-scope use cases first

If Phase 1 found multi-step traces (≥ 2 span kinds, or any tool / retrieval / workflow span under an agent root), you MUST walk through the four canonical trace-scope use cases below before finalizing the suite. For each, decide explicitly: applies (include with eval_scope: trace) or does not apply (record a one-line reason in a "Skipped trace-scope candidates" subsection of the proposal). Skipping all four without per-item justification is a sign you've over-anchored on span scope — re-check.

Mandatory: walk the canonical session-scope use cases (only when sessions_present)

Gate: perform this walk-through only if the Phase 1 session probe set sessions_present = true. If sessions are absent, skip session scope entirely and note "session scope skipped — no session_id on sampled spans" in the proposal.

When sessions_present, you MUST walk through the four canonical session-scope use cases below. For each, decide explicitly: applies (include with eval_scope: session) or does not apply (one-line reason in a "Skipped session-scope candidates" subsection). Session scope answers questions that span more than one trace under the same session_id — a single trace cannot see prior or later turns.

For other proposed evaluators (e.g. tone, format, safety), apply this scope test in order:

1. Can the judgment be answered correctly from one span's meta.input + meta.output, where "correctly" means the verdict cannot change if you considered other spans in the trace? → eval_scope: span.
2. Otherwise, if it is answerable from the spans of a single trace → eval_scope: trace. Default to trace when the evaluator name contains grounding, faithfulness, hallucination, completeness, correctness across steps, consistency, or workflow — these almost always need cross-span context.
3. Otherwise, if the verdict needs context from more than one trace in the same session_id (overall satisfaction, behavior over time, multi-turn coherence) and sessions_present → eval_scope: session. Default to session when the name contains session, conversation, across turns, over time, satisfaction, frustration, or abandonment. If sessions_present is false, fall back to trace scope and note the limitation.

Trade-offs (don't let these dominate the choice)

Trace scope costs more than span scope: one judgment per completed trace (vs. per matching span), larger prompt payloads, and a 3-minute trigger latency (Datadog waits 3 minutes of inactivity before considering a trace complete; later spans are excluded). Session scope costs the most: one judgment per completed session (a session_id is complete after 30 minutes of inactivity — vs. 3 minutes for a trace — and spans arriving > 30 min after the prior span are excluded), with the largest payloads (every span of every trace in the session, capped at 10,000 spans). These are cost-control levers — handle with sampling_percentage and filter, not by demoting scope. The correctness of the eval is what picks the scope.

Surface the classification

Add a Scope column to the proposal table and a one-sentence rationale per evaluator. If you skipped a canonical trace-scope or session-scope use case, list it under the matching "Skipped …-scope candidates" subsection with the reason — the user will see and can override.

Example rationales:

• tone_check — span. Judging "is this single response polite" needs only one LLM span's meta.output.messages[*].content; no other span in the trace can change that verdict.
• goal_completion — trace. Whether the agent finished the user's request depends on the sequence of tool calls and the final LLM response together — meta.output of any single span only shows that step's output.
• tool_use_correctness — trace. Comparing tool inputs against the request and the final response requires correlating ≥ 3 spans (root, tool, final LLM).
• rag_faithfulness — trace. Grounding pairs the retrieval span's documents with the LLM span's answer.
• session_goal_completion — session. Whether the user's overall goals were met depends on every trace in the session_id, not just the last one — only session scope sees the full conversation.
• user_frustration_signals — session. Frustration surfaces as repeated or rephrased asks across traces; a single trace can't reveal the pattern.

Example "Skipped trace-scope candidates" entry:

• conversation_quality — skipped: traces contain a single LLM call (no multi-turn signal in this app's instrumentation).

Example "Skipped session-scope candidates" entry:

• session_goal_completion — skipped: every session_id maps to a single trace (no cross-trace context — trace scope already covers it).

MANDATORY CHECKPOINT

You MUST output the proposal and wait for user confirmation before proceeding.

## Proposed Evaluator Suite

**App profile**: {LLM | RAG | Agent | Multi-agent}
**Entry mode**: {cold_start | from_rca}

| # | Name | Type | Scope | Measures | Pass Criteria |
|---|------|------|-------|----------|---------------|
| 1 | task_completion | LLMJudge (Boolean) | span | Whether the task was completed on this span | pass_when=True |
| 2 | tool_use_correctness | LLMJudge (Categorical) | trace | Right tool with right arguments across the agent run | pass_values=["correct"] |
| 3 | session_goal_completion | LLMJudge (Categorical) | session | Whether the user's goals were met across the whole multi-trace session | pass_values=["completed"] |
| 4 | ... | ... | ... | ... | ... |

(Drop the **Scope** column when not in `publish` mode.)

For each evaluator:
- **{name}**: {what it measures}
  - Target span: {which span's data it was designed for}
  - Rationale: {which quality dimension it covers and why}
  - {Only in publish mode:} Scope: {span | trace | session} — {one-sentence rationale}
  - Evidence: [Trace {id_short}](https://app.datadoghq.com/llm/traces?query=trace_id:{full_id})

{Only in publish mode, for multi-step apps. Required if any of the four canonical trace-scope use cases was not included above:}

**Skipped trace-scope candidates:**
- `{canonical_use_case}` — {one-line reason it does not apply to this app}

{Only in publish mode, when `sessions_present`. Required if any of the four canonical session-scope use cases was not included above:}

**Skipped session-scope candidates:**
- `{canonical_use_case}` — {one-line reason it does not apply, e.g. "every `session_id` maps to a single trace"}

{Only in publish mode, when the session probe found no sessions:}

**Session scope skipped** — no `session_id` on sampled spans; session-scope evaluators not proposed.

{Only in publish mode, when the suite contains code-based evaluators (JSONEvaluator, RegexMatchEvaluator, LengthEvaluator, StringCheckEvaluator, BaseEvaluator). Required when any code-based proposal exists.}

**Not publishable in this mode** (code-based evaluators — the publish API is LLM-judge only):
- `{name}` ({type}) — {what it would check}. Ask me to emit these as offline SDK code (or run `/eval-bootstrap {ml_app} --sdk-code`), or `/eval-bootstrap {ml_app} --data-only` for a framework-agnostic JSON spec.

Which evaluators should I generate? Treat the proposal as a candidate set — the suite below is intentionally broad so you can pick what matters for your team's quality bar. Reply with which to keep, which to drop, and which to rename; not every domain-specific proposal will fit your priorities. In sdk_code mode you may also add custom evaluators or change provider/model. In publish mode you may override integration_provider, model_name, sampling_percentage, eval_scope, root_spans_only, or filter per evaluator. (In the default publish mode these are created as online drafts in Datadog on confirmation — you review and enable them in the UI. Prefer offline SDK code or a JSON spec instead? Say so and I'll generate the confirmed suite that way.)

Do NOT proceed to code generation until the user confirms.

Phase 3: Generate Output

Branch on output_mode:

• publish (default) → skip to Phase 3C
• sdk_code → Phase 3A below
• data_only → skip to Phase 3B

On-request code generation (after a publish run)

The default path publishes online evaluators. If the user then asks for the suite as offline code or a portable spec (e.g. "now generate the SDK code for these", "give me a JSON spec"), do not re-run Phase 1–2. Reuse the already-confirmed evaluator suite and jump straight to Phase 3A (sdk_code) or Phase 3B (data_only), translating each published online evaluator into the offline form:

• The online prompt template (span/trace/session placeholders) becomes an offline LLMJudge with generic {{input_data}} / {{output_data}} placeholders (offline data comes from the user's dataset/task function, not spans — see the EvaluatorContext note), preserving the rubric and pass criteria.
• Code-based checks that couldn't be published online (the "Not publishable in this mode" set) are emitted as real BaseEvaluator / built-in evaluators here.

This works the other way too: a user who started with --sdk-code can ask to publish the confirmed suite online (Phase 3C).

Phase 3A: Generate & Write Evaluator Code

Goal: Generate the final .py file and write it to disk.

For each confirmed evaluator, generate production-quality Python code following the SDK Reference patterns above.

Code Generation Rules

1. Ground prompts in traces: LLMJudge system prompts and user prompts must reference patterns actually observed in production traces. Never write generic prompts like "evaluate whether the response is good" — ground them in the app's domain, observed failure patterns, and success criteria.

2. Keep template variables generic, add comments for context: Use {{input_data}} and {{output_data}} as top-level placeholders in prompts — do NOT reference nested span paths like {{input_data.messages[-1].content}}. The evaluator's data comes from the user's dataset and task function, not directly from spans. Instead, add a comment above each evaluator describing what data it was designed for and what the user should adapt:

   # Designed for: input_data = user query, output_data = assistant response text
   # Observed from: root agent span (input.value → output.value)
   # If your dataset uses a different structure, adapt the prompt references below.

3. Use the narrowest evaluator type: If a check can be done with JSONEvaluator, RegexMatchEvaluator, StringCheckEvaluator, or LengthEvaluator, do NOT use an LLMJudge. Code-based evaluators are faster, cheaper, and deterministic.

4. BaseEvaluator subclasses:

   • Call super().__init__(name=name) in __init__
   • Return EvaluatorResult from evaluate()
   • Do NOT modify instance attributes in evaluate() (thread safety)

5. Names: Must match ^[a-zA-Z0-9_-]+$. Use snake_case descriptive names.

6. Imports: Consolidate at the top of the file. Only import classes that are actually used.

7. Evaluator list: Collect all evaluators into an evaluators list at the bottom of the file.

8. Anonymize PII: Strip emails, names, and sensitive data from any trace content included in LLMJudge prompts or the header comment.

Output Format

The generated .py file should follow this structure:

"""
Auto-generated evaluators for {ml_app}
Generated: {YYYY-MM-DD} by eval-bootstrap

App profile: {LLM | RAG | Agent | Multi-agent}

Quality dimensions covered:
  - {target_name}: {description}
    Evidence: https://app.datadoghq.com/llm/traces?query=trace_id:{full_id}
  ...

Usage:
    from ddtrace.llmobs import LLMObs

    experiment = LLMObs.experiment(
        name="my-experiment",
        task=my_task_fn,
        dataset=dataset,
        evaluators=evaluators,
    )
    experiment.run()
"""

{imports — only what is used}


# --- Outcome Evaluators ---

{evaluator code}


# --- Format Evaluators ---

{evaluator code}


# --- Safety Evaluators ---

{evaluator code}


# --- Evaluator Suite ---

evaluators = [
    {eval_1_variable_name},
    {eval_2_variable_name},
    ...
]

Only include section comments (Outcome/Format/Safety) for categories that have evaluators.

Write the file

Write the generated code to the output path (suggest ./evals/{ml_app}_evaluators.py if not specified), then display a summary:

## Generated Evaluators

Wrote {N} evaluators to `{output_path}`:

| # | Name | Type | Covers |
|---|------|------|--------|
| 1 | ... | ... | ... |

### Next Steps

1. **Review**: Check the generated prompts and criteria match your expectations
2. **Test offline**: Use `LLMObs.experiment(evaluators=evaluators)` to batch-evaluate against a labeled dataset and verify scores

Notebook export (after summary)

After displaying the summary, offer notebook export.

• If rca_notebook_url was detected in Phase 0:

  An RCA notebook was created earlier in this session: {rca_notebook_url} Would you like to (a) append the evaluator suite summary to that notebook, or (b) create a new standalone notebook?

  If append: use the notebook creation fallback pattern (see below) with mcp__datadog-mcp__edit_datadog_notebook (id={rca_notebook_id}, append_only=true, evaluator suite summary cell).

  If new: use the notebook creation fallback pattern (see below) with mcp__datadog-mcp__create_datadog_notebook.

• If no rca_notebook_url:

  Would you like to export this evaluator suite summary to a Datadog notebook?

  If yes: use the notebook creation fallback pattern (see below) with mcp__datadog-mcp__create_datadog_notebook:

  • name: Eval Bootstrap: {ml_app} — YYYY-MM-DD
  • type: report
  • cells: single markdown cell with the evaluator suite summary
  • time: { "live_span": "1h" }

Notebook creation fallback pattern (apply to every create_datadog_notebook / edit_datadog_notebook call):

1. Try the MCP tool first.
2. If the MCP call fails, inspect the error:
   • Auth / permission error (401, 403) → stop and tell the user.
   • Field validation error (error names a specific field) → fix that field and retry the MCP call once.
   • Any other error (binding, serialization, unexpected response) → fall back to pup:
     • Write the payload to /tmp/nb_bootstrap_{ml_app}.json as a full API envelope: {"data": {"attributes": {"name": "...", "time": {...}, "cells": [...]}, "type": "notebooks"}}
     • Run pup notebooks create --file /tmp/nb_bootstrap_{ml_app}.json
     • If pup is not available either, render the notebook content as markdown in chat.
3. After successful creation by either method, output the URL: Evaluator suite exported to notebook: <url>

Notebook cell content — the markdown cell should contain:

## Eval Bootstrap: {ml_app}

**Generated**: YYYY-MM-DD | **App profile**: {LLM | RAG | Agent | Multi-agent} | **Entry mode**: {cold_start | from_rca}
**Generated code**: `{output_path}`

{One sentence: what does this app do?}

**Coverage**: {N} new evaluators ({comma-separated dimension names}) | {N} existing (unchanged: {names}) | {gaps if any: dimensions identified but not covered, and why}

### Evaluator Suite

| # | Name | Type | Measures | Pass Criteria |
|---|------|------|----------|---------------|
| 1 | ... | ... | ... | ... |

### Evidence

{For each evaluator: name — 1-line description — [Trace link]}

### Next Steps

1. Review generated prompts in `{output_path}`
2. Run against a labeled dataset to validate scores
3. Deploy to Datadog LLM Experiments

Phase 3B: Generate & Write Eval Spec JSON

Goal: Serialize the confirmed evaluator suite and representative trace samples to a single self-contained JSON file — zero SDK dependencies.

Output path: ./evals/{ml_app}_eval_spec.json

JSON Schema

{
  "schema_version": "1",
  "generated_at": "<ISO 8601 UTC>",
  "generated_by": "eval-bootstrap",
  "app": {
    "ml_app": "<string>",
    "app_type": "LLM | RAG | Agent | Multi-agent",
    "trace_window": "<timeframe param, e.g. now-7d>",
    "trace_count": "<integer>"
  },
  "evaluators": [
    {
      "name": "snake_case_name",
      "category": "outcome | format | safety",
      "type": "llm_judge | code_check",
      "description": "<1-2 sentence plain-language description>",
      "target_span": "<which span: root, llm sub-span, etc.>",
      "scoring": {
        "scale": "boolean | score_1_10 | categorical",
        "categories": ["<only present when scale=categorical>"],
        "pass_criteria": "<human-readable: true, >= 7, in [correct], etc.>"
      },
      "rubric": "<full prompt text for llm_judge; null for code_check>",
      "implementation_hints": {
        "type_if_code_check": "json_valid | regex | contains | length_words | null",
        "pattern_if_code_check": "<pattern string or null>",
        "notes": "<optional framework-agnostic implementation guidance>"
      },
      "evidence": [
        {
          "trace_id": "<32-char hex>",
          "span_id": "<16-char hex>",
          "url": "https://app.datadoghq.com/llm/traces?query=trace_id:<trace_id>",
          "observation": "<why this trace illustrates the evaluator>"
        }
      ]
    }
  ],
  "sample_records": [
    {
      "trace_id": "<string>",
      "span_id": "<string>",
      "input": {},
      "output": "<string>",
      "suggested_labels": {
        "<evaluator_name>": "pass | fail | <score>"
      }
    }
  ]
}

Field Notes

• evaluators[].type: "llm_judge" for semantic evaluators; "code_check" for deterministic checks (regex, length, JSON validity, etc.).
• evaluators[].rubric: For llm_judge — full prompt text grounded in observed trace patterns. Use {{input}} and {{output}} as generic placeholders (not {{input_data}} — that's ddeval-specific). For code_check — null.
• evaluators[].implementation_hints.notes: Optional framework-agnostic guidance, e.g. "For OpenAI Evals, use rubric as a model-graded criterion. For Braintrust, use as an LLM scorer. For Promptfoo, use as an llm-rubric assertion."
• sample_records: 10–20 representative traces from Phase 1. suggested_labels are Claude's best-read from trace inspection — n

Truncated - read the full file at https://github.com/konstantinosmpouros/mAgenticX/blob/38af7e6803715e47f1fbba71f11f21943e144079/src/agents/runtime/skill_registry/registry/llm-evaluation/llm-obs-eval-bootstrap/SKILL.md.