菜单
Write E2E tests for the Datadog Agent using the new-e2e framework with fakeintake assertions
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.