94 skills published by DataDog across 17 repositories. Together they weigh 1 778 309 tokens — that is what loading all of them at once would cost you in context.
94 skills 1 778 309 tokens total
Generate the Agent Supply Chain newsletter by researching team activity on GitHub and Confluence, then creating a Confluence draft and Gmail draft
Give your AI agents something more useful than a prompt. Velocity through clarity.
Autonomously work on Jira backlog tickets, creating PRs and shepherding them to merge
Create a new Fx component using the modern def/fx/impl pattern (NOT legacy)
Add a new configuration field to the Datadog Agent (datadog.yaml)
Create a new Go core check that collects metrics and sends them to Datadog
Create a new Go module in the agent repository
Create a new Python invoke task for the dda CLI
Create a pull request for the current branch with proper labels and description
Create a reno release note for a PR or change
Create a new RuntimeSetting that can be changed at runtime via `agent config set/get` and the config API
Add a new section to the agent status output (agent status command)
Add a new CLI subcommand to an agent binary (agent, cluster-agent, etc.)
Audit CWS (runtime-security) io_uring functional-test coverage and add a functional test for any io_uring opcode whose operation CWS observes but that is not exercised through io_uring. Test-driven — coverage is judged by tests, never by reading eBPF/hook internals. Use when auditing io_uring test coverage or after new IORING_OP_ opcodes appear.
Extract an Allium specification from an existing codebase. Use when the user has existing code and wants to distil behaviour into a spec, reverse engineer a specification from implementation, generate a spec from code, turn implementation into a behavioural specification, or document what a codebase does in Allium terms.
Judge whether Agent behavior belongs in a new-e2e, integration, or unit test
Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or gather requirements, capture domain behaviour, specify a feature or system, define what a system should do, or is describing functionality and needs help shaping it into a specification.
Explains a lading.yaml config file from the regression test suite, using the lading Rust source as ground truth for field meanings and defaults.
>- Build, deploy, and test Datadog Agent components (agent, cluster-agent, operator, CSI driver) on a local Kubernetes cluster using the injector-dev CLI. Use when the user wants to iterate on local Agent or Operator change, spin up a local k8s test environment.
Find where an Agent config setting or section is defined in the YAML schemas, and print its schema node, using `dda inv schema.locate`
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.
Analyze static quality gate on-disk size changes, correlate with Confluence exception records and GitHub PRs by milestone
Review and triage PR review comments on the current branch — groups threads by file, separates bots from humans, walks through unresolved comments interactively
Run E2E tests locally using the new-e2e framework with Pulumi-based infrastructure
Fetch a Jira issue and propose an implementation plan based on codebase analysis
Run Windows E2E tests (MSI install tests or Fleet Automation/installer tests) locally against AWS-provisioned VMs
Update a C/C++ third-party library under deps/ — bump version, reconcile sources/copts/config.h/patches, and verify the build.
Use when a user asks to update, bump, or troubleshoot OpenTelemetry Collector dependencies in datadog-agent, including OCB build failures, ddflareextension golden files, static quality gates, or OTel transitive dependency conflicts.
Write E2E tests for the Datadog Agent using the new-e2e framework with fakeintake assertions
> Create or review Stratus Red Team attack techniques. Use when asked to add, create, or implement a new attack technique for AWS, Azure, GCP, Entra ID, EKS, or Kubernetes in the stratus-red-team project. Also use when reviewing PRs or code that implements attack techniques — the guidelines serve as a review checklist.
> Analyze a threat-intel blog post or report against Stratus Red Team coverage. Extract cloud TTPs, classify each as Covered / Partial / Open issue / Not covered, produce a markdown coverage report, and suggest GitHub issue drafts for the gaps. Use when the user pastes a threat-intel URL (Microsoft, Mandiant, CrowdStrike, Unit 42, etc.) and asks for a coverage report, gap analysis, TTP extraction, or "what does Stratus cover from this report". Also use when given a local report file (.md, .txt, .pdf) or pasted text.
Tests and validates Stratus Red Team attack techniques by executing warmup, detonation, and cleanup phases with comprehensive validation. Validates cloud credentials, parses command output, checks expected outcomes, and generates HTML reports. Use when testing attack techniques, validating TTPs, verifying technique behavior, or when user mentions stratus, warmup, detonate, or technique IDs like aws.*, azure.*, gcp.*, k8s.*, or entra-id.*. Supports AWS, Azure, GCP, Kubernetes, and Entra ID.
Author, edit, and review GuardDog YARA source-code detection rules (.yar) that follow the capability/threat/risk model. Use when adding a new detection rule, changing an existing rule's patterns or metadata, splitting capabilities from threats, debugging false positives, or writing rule test cases under guarddog/analyzer/sourcecode/.
APM - traces, services, dependencies, performance analysis.
Use pup CLI for immediate Datadog operations or generate code for integration into applications
Live Debugger - inspect runtime argument/variable values in production by placing log probes on methods. Use when asked what values a function receives, what parameters look like at runtime, or to capture live data from running services without redeploying.
File GitHub issues to the right repository (pup CLI or plugin)
Log management - search, pipelines, archives, and cost control.
Monitor management - create, update, mute, and alerting best practices.
Datadog CLI (pup). OAuth2 auth with token refresh.
Symbol Database - search service symbols, find probe-able methods.
Load when investigating a specific flaky test. Gets history, failure pattern, and category, then recommends fix, quarantine, or escalate.
Load when investigating a failing PR CI pipeline or checking PR health. Attributes each CI failure as flaky, infra, or regression, proposes a targeted action, and reports code coverage.
Datadog API CLI with 49 command groups, 300+ subcommands. Skills and domain agents for monitoring, logs, APM, security, and infrastructure.
| Use when adding, debugging, or modifying LLMObs plugins for an LLM library completions / streaming / embeddings / agent runs / orchestration / tool calls / retrieval", "LLMObsPlugin", "getLLMObsSpanRegisterOptions", "setLLMObsTags", "SPAN_KINDS", "span kind", any provider tag ("openai" / "anthropic" / "genai" / "google" / "langchain" / "langgraph" / "ai" llmobs), "VCR cassettes".
| Use when writing, modifying, or debugging tests for an LLMObs plugin in "assertLlmObsSpanEvent", "useLlmObs", "getEvents", any MOCK_* matcher ("MOCK_STRING" / "MOCK_NOT_NULLISH" / "MOCK_NUMBER" / "MOCK_OBJECT"),
| Use when adding, modifying, debugging, or reviewing dd-trace-js serverless platform integrations that create serverless integration, function invocation root span, Lambda runtime, Azure Functions, GCP Functions, type = 'serverless', DD_LAMBDA_HANDLER, datadog-lambda-js, deployed serverless verification, manual serverless test.
Write a new library instrumentation end-to-end. Use when the user ask to add a new APM integration or a library instrumentation.
> Converts Spock/Groovy test files in a Gradle module to equivalent JUnit 5 Java tests. Use when asked to "migrate groovy", "convert groovy to java", "g2j", or when a module has .groovy test files that need to be replaced with .java equivalents.
Convert JUnit 5 @MethodSource/@CsvSource/@ValueSource parameterized tests to @TableTest (JDK8)
>- Performance-overhead review of a code diff / branch / PR for the dd-trace-java tracer. Flags hot-path allocation, unbounded memory, repeated work, escaping objects, native-boundary crossings, and JVM-specific pitfalls (escape analysis, JNI / virtual-thread pinning, backtracking-regex ReDoS, varargs/boxing hashing, String.format, ByteBuddy-Advice anti-patterns) using the tracer performance rubric. Use whenever the user wants a performance / overhead / hot-path review, asks to check a diff or PR for allocation / GC / memory / latency / startup cost, or mentions the "perf rubric" or the "do no harm / assume hot" tracer posture — verify-first findings; it never edits code.
> Post-migration quality review. Checks Java test files produced by migrate-groovy-to-java against the shared quality rules. Use after migration, or on any branch with recently migrated .java test files. Produces structured FINDING blocks grouped by severity, then offers to auto-fix BLOCKERs and WARNINGs.
>- Review a code diff / branch / PR for technical debt — code duplication, unnecessary complexity / over-engineering, and redundant or dead code. Use whenever the user wants a tech-debt, cleanup, or refactor review, asks to check a branch or PR for duplication / complexity / dead code before opening a PR, or behavior-preserving fixes; it never changes behavior.
> 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. "trace_handlers", "PATCH_MODULES", "context_with_data", "context_with_event", "TracingEvent", "VCR", "cassette", "generative-ai", "LLM integration", "riot", "riotfile", "suitespec", "new integration", "wrap", "unwrap".
> Run circular import detection against ddtrace and propose architectural fixes for any cycles found. Use this when adding or refactoring modules, or when the detect_circular_imports CI job reports new cycles on a PR.
> Compare CPython source code between two Python versions to identify changes in headers and structs. Use this when adding support for a new Python version to understand what changed between versions.
> Diagnose and fix slow base venv build times caused by unnecessary recompilation of native extensions (CMake, Cython, Rust) across riot generate runs. Use when CI base venv builds are slow, when ext_cache isn't saving time, or when investigating warm build regressions.
> Find all CPython internal headers and structs used in the codebase, particularly for profiling functionality. Use this when adding support for a new Python version to identify what CPython internals we depend on.
> 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.
| 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. "_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".
> 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).
> Review CI results for the current branch, commit, or PR using the Datadog MCP. Use this when CI is failing, to understand what's blocking a PR, or to get actionable fix instructions for failed jobs and tests.
> Run performance benchmarks to measure the impact of code changes. Discovers relevant benchmark scenarios based on changed files, executes them comparing a baseline version against local changes, and summarizes performance results. Use this when touching performance-sensitive code paths or when asked about performance impact.
> 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.
Analyze Azure DevOps CI build failures in dd-trace-dotnet pipeline. This skill should be used when the user mentions a failing CI build, PR checks failing, Azure DevOps pipeline failures, test failures in CI, or when they share a build ID or PR number and want to understand what went wrong. Analyzes build failures, categorizes them (infrastructure/flaky/real), and provides actionable recommendations.
Stack Trace Crash Analysis for dd-trace-dotnet
Error Stack Trace Analysis for dd-trace-dotnet
>
>- Update/bump the libdatadog native library version in dd-trace-dotnet. Use when the user asks to bump, update, or upgrade libdatadog, or mentions a new libdatadog release version.
Perform a review on a GitHub PR, leaving comments on the PR
>- results with ci-watch, investigate failures, and report. Use when the user asks to check, watch, or monitor CI, or to see whether a pipeline passed.
>- Analyze a dd-trace-php crash report (event.json) to identify the crashing binary, correlate stacktraces to source code, and determine root cause. Use when investigating wild crash reports from crash tracking.
>- Generate release notes for the current version.
Run Datadog Terraform provider acceptance tests with proper RECORD modes and capture output for analysis. This agent is invoked via Task tool and writes results to files.
> End-to-end workflow to diagnose, reproduce, fix, and validate a failing Datadog Terraform provider integration test. Takes any input pointing at other description of what's failing. Runs autonomously through 8 phases — identify → validate in CI → reproduce locally → plan fix → execute → open draft PR → monitor → report.
> Generate a Datadog Terraform provider data source end to end and open a review-ready (operationIds), artifact name, cardinality, description, and overwrite target; (2) Generation — build an annotated OpenAPI slice with slice_and_annotate.py, run tfgen on it, run make docs/build, and commit onto a new branch; (3) PR — a quick runtime-risk scan (trusting the generator for correctness), draft the standard PR body with disclaimers + testing guide, and open the PR with `gh`. Use this skill whenever the user wants to generate a Datadog data source, mentions tfgen / generator-v2, slice_and_annotate, an OpenAPI operation they want a data source for, opening a PR for a generated data source, evaluating generated code against goldens, or writing cassette / acceptance-test instructions — even if they don't say "skill".
Run a manual test of the current change end-to-end and output reproducible test instructions for the PR "Test instructions" section.
Cut a new datadog-go release and update CHANGELOG.md following the repo's house style. Use when asked to "prepare a release", "cut version X.Y.Z", "update the changelog for the release", "bump the version", or "tag a release" for the DataDog/datadog-go repo. Walks the three-step release process (changelog → telemetry version → git tag) and enforces the 13 changelog guidelines.
Use when creating a new branch in dd-sdk-ios for a JIRA ticket or feature. Use when choosing a branch name or base branch for development work.
Use when committing changes in dd-sdk-ios. Use when writing commit messages, signing commits, or staging files before a commit.
Use when creating a pull request in dd-sdk-ios. Use when writing PR titles, PR body, or choosing the target branch.
Use when asked to run tests in the dd-sdk-ios project — whether a full module suite, a specific test class, or a single test method. Use when choosing between make, xcodebuild, or Xcode MCP for running iOS/tvOS/visionOS tests.
Use when writing, reviewing, or renaming Swift APIs, including declarations, call sites, argument labels, Boolean names, protocols, overloads, documentation comments, and small abstractions.
Use when public API changes have been made to review and update all *_FEATURE.md documentation files, or to audit whether they are still accurate.
Use when adding, removing, moving, or renaming Swift source files in the dd-sdk-ios Xcode project. Use when the task involves file creation, deletion, or relocation in any module (DatadogRUM, DatadogLogs, DatadogCore, etc.). Use when you would otherwise reach for Write, Bash mv/mkdir/rm, or manual pbxproj editing for file management.
Use when verifying SDK event payloads in the Android SDK sandbox, debugging what events are emitted, or validating request bodies via logcat with the sample Kotlin app.
Scaffold a new datadog-ci plugin end-to-end using repository conventions.
Write tests for datadog-ci commands and helpers using established repository patterns.
Walks through releasing a new datadog-lambda-js Lambda layer version — the automated Commercial release (version bump, tag, GitLab sign/publish jobs, npm publish, GitHub release) and the manual GovCloud layer publish. Pauses for explicit confirmation before every irreversible or externally-visible step (tag push, GitLab manual jobs, npm publish, GitHub release, GovCloud deploy). Triggers on "release a new layer version", "cut a new datadog-lambda-js release", "publish the lambda layer", or similar. Source of truth: https://datadoghq.atlassian.net/wiki/spaces/SLS/pages/2724037230/Lambda+Layer+Node.js#Commercial
Add integration tests to TestGCMetrics.java for new GC collector support added to new-gc-default-jmx-metrics.yaml. Use when a PR adds a new garbage collector to the metrics YAML without a corresponding test.
Prepares a jmxfetch release by bumping the version in pom.xml, README.md, and test.yml, and populating the CHANGELOG.md entry. Pass the new version as the argument (e.g. /prepare-release 0.52.0).
Starts a new jmxfetch development cycle by bumping to the next SNAPSHOT version in pom.xml, README.md, and test.yml, and adding a new CHANGELOG.md placeholder. Pass the next snapshot version as the argument (e.g. /start-dev-cycle 0.52.1-SNAPSHOT).
Datadog docs lookup using docs.datadoghq.com/llms.txt and linked Markdown pages.