Menu
Decide whether a release note is needed, and if so create or update a Reno fragment, following dd-trace-py's conventions (docs/releasenotes.rst).
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Register a new environment variable / configuration option in dd-trace-py. Use whenever you add (or rename) a DD_*/_DD_*/OTEL_*/DATADOG_* environment variable so it is documented, validated, and tracked for cross-language feature parity. Covers supported-configurations.json, the generated _supported_configurations.py module, docs/configuration.rst, and the feature-parity registry hand-off.
dd-trace-py integration development guide. Use when creating, modifying, or debugging contrib integrations in the Python tracer. Covers the patch module system, context_with_data, context_with_event (new), registration, testing with riot, and common anti-patterns. LLM/AI integrations should use this skill for APM-side workflow only; use llmobs-integrations for LLMObs-specific lifecycle, extraction, streaming, and VCR guidance. Pin is DEPRECATED. Triggers: "dd-trace-py", "ddtrace", "contrib", "integration", "patch.py", "trace_handlers", "PATCH_MODULES", "context_with_data", "context_with_event", "TracingEvent", "VCR", "cassette", "generative-ai", "LLM integration", "riot", "riotfile", "suitespec", "new integration", "wrap", "unwrap".
dd-trace-py LLMObs integration development guide. Use when creating, modifying, or debugging LLMObs integrations for LLM/AI libraries in the Python tracer. Covers BaseLLMIntegration, stream handling, message extraction, token counting, tool call parsing, and VCR-based testing patterns. Triggers: "llmobs", "LLMObs", "BaseLLMIntegration", "llmobs_set_tags", "_llmobs_set_tags", "BaseStreamHandler", "submit_to_llmobs", "integration.trace", "LLM span", "VCR", "cassette", "anthropic", "openai", "google_genai", "claude_agent_sdk", "generative-ai", "LLM integration", "llmobs_enabled".
Native crash log analysis for dd-trace-py
Run targeted linting, formatting, and code quality checks on modified files. Use this to validate code style, type safety, security, and other quality metrics before committing. Supports running all checks or targeting specific checks on specific files for efficient validation.
Validate code changes by intelligently selecting and running the appropriate test suites. Use this when editing code to verify changes work correctly, run tests, validate functionality, or check for regressions. Automatically discovers affected test suites, selects the minimal set of venvs needed for validation, and handles test execution with Docker services as needed.
| name | releasenote |
| description | Decide whether a release note is needed, and if so create or update a Reno fragment, following dd-trace-py's conventions (docs/releasenotes.rst). |
| allowed-tools | ["Bash","Read","Grep","Glob"] |
Required: breaking API change, new feature, bug fix, deprecation, dependency upgrade — if it's customer-impacting. Not required: CI chores, internal-only/not-yet-released API changes, test-only changes.
If customer impact is unclear, ask the user what the customer impact is. Never guess —
unless the PR/issue/ticket you were given already states it. If no note is needed, say so and
suggest the changelog/no-changelog PR label instead.
The note is for a customer upgrading dd-trace-py — never for a dd-trace-py contributor. It is not a PR summary. Internal rationale, implementation detail, and CI/test notes go in the PR description, not here.
features/fixes/upgrade/deprecations/issues/api/security/other)
isn't given, ask.git diff --name-only <base>...HEAD -- releasenotes/notes/, where
<base> is the branch you're merging into (usually origin/main; use the actual base if
this branch forked off a release branch instead). Only reuse a fragment from that diff — one
already on the base branch may already be released; create a new fragment instead of
editing a shipped one.Generate the skeleton: riot run reno new <slug> (slug: lowercase, hyphenated, e.g.
fix-aioredis-catch-canceled-error). Edit the generated YAML, keeping only the section(s)
that apply — one Reno fragment per change.
Format: <scope>: <sentence(s)>. Scope is the component name (see
:ref:release_notes_scope in docs/releasenotes.rst — tracing, profiling, ASM,
dynamic instrumentation, CI visibility, or the integration name). Use internal when the
change genuinely isn't tied to one product (e.g. core threading/fork-safety affecting several
products) — that's a legitimate scope, not a placeholder for when you didn't pick one.
Fix — state the customer-visible symptom, not the root cause, in present tense:
Fixes an issue where <symptom> occurs when <condition>.
Feature/behavior change — if it's configurable or changes a default, state the exact env var / config option / argument and what it does. Don't skip this when a toggle exists.
Never include: internal function/class names, internal tag prefixes (_dd.*),
RFC/JIRA/ticket numbers, CI job names, draft leftovers (TODO, XXX, unfinished sentences),
or "why we built it this way" rationale.
Length: 1-2 sentences. Longer only to show a code example for a new public API.
Verify facts against the code, not the PR title — defaults and numbers drift.
Good (fix):
fixes:
- |
profiling: Fixes inconsistent handling of ``DD_PROFILING_MAX_FRAMES`` by clamping it
before stack collection so samples stay within the backend's 600-location limit.
Good (feature, toggle):
features:
- |
AI Guard: Adds per-integration kill switches ``DD_AI_GUARD_ANTHROPIC_ENABLED`` and
``DD_AI_GUARD_LANGCHAIN_ENABLED`` (default ``true``). Set to ``false`` to disable AI
Guard for that provider/framework.
Bad → good rewrite (internal scope is fine here — not product-specific; the fix is the wording):
# Bad: internal mechanism, no customer symptom
fixes:
- |
internal: Fixed a GC reference-cycle leak in PeriodicThread.
# Good
fixes:
- |
internal: Fixes a memory leak that causes memory usage to grow over time in
long-running processes using background periodic tasks.