Menu
Write E2E tests for the Datadog Agent using the new-e2e framework with fakeintake assertions
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
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.
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.
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.
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.
Autonomously work on Jira backlog tickets, creating PRs and shepherding them to merge
| name | write-e2e |
| description | Write E2E tests for the Datadog Agent using the new-e2e framework with fakeintake assertions |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash, Agent |
| argument-hint | <feature-or-check-name> [--platform linux|windows|both] [--env host|docker|k8s] |
| model | sonnet |
Write end-to-end tests for the Datadog Agent using the test/e2e-framework/ framework.
Parse $ARGUMENTS to determine what to test.
| What | Where |
|---|---|
| Framework API (environments, provisioners, agentparams) | test/e2e-framework/AGENTS.md |
| Fakeintake API (payload types, client methods, extending) | test/fakeintake/AGENTS.md |
| Setup, prerequisites, running tests | docs/public/how-to/test/e2e.md |
| Real tests to use as patterns | test/new-e2e/tests/ (see lookup table in e2e-framework AGENTS.md) |
| Check system overview | root AGENTS.md § "Check System" |
| Test placement / team ownership | CODEOWNERS |
| CI job definitions | .gitlab/test/e2e/e2e.yml, .gitlab/windows/test/e2e/windows.yml |
| CI trigger rules | .gitlab-ci.yml (search for .on_*_or_e2e_changes) |
| Examples | test/new-e2e/examples/ |
Read the first two files before writing any test. Browse examples and a few real tests that match your use case.
test/new-e2e/tests/<area> directory (check CODEOWNERS);
one file per platform target (e.g., disk_nix_test.go, disk_win_test.go)cd test/new-e2e && go vet ./tests/<area>/...dda inv new-e2e-tests.run --targets=./tests/<area>/...
See test/e2e-framework/AGENTS.md § "Validating E2E tests" if it failsgrep -n 'TARGETS:.*<area>' .gitlab/test/e2e/e2e.ymlShow the user: files created, how to compile-check, how to run locally
(dda inv new-e2e-tests.run --targets=./tests/<area>/...), and whether
CI changes are needed.