一键导入
locate-config-setting
Find where an Agent config setting or section is defined in the YAML schemas, and print its schema node, using `dda inv schema.locate`
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Find where an Agent config setting or section is defined in the YAML schemas, and print its schema node, using `dda inv schema.locate`
用 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 | locate-config-setting |
| description | Find where an Agent config setting or section is defined in the YAML schemas, and print its schema node, using `dda inv schema.locate` |
| allowed-tools | Bash, Read |
| argument-hint | [setting.path] |
| model | sonnet |
Locate a Datadog Agent configuration setting or section in the schema source and print its definition plus the exact file and line where it lives.
Use this whenever you need to answer "where/how is config key X defined?" — its
type, default, env vars, description, or which schema file to edit. It is much
faster and more reliable than grepping the ~20k lines of schema YAML by hand,
because the schema is split across files (core_schema.yaml plus per-section
sub-files referenced via $ref), so a naive grep often points at the wrong file.
dda inv -- schema.locate <setting.path>
<setting.path> is the dotted logical path exactly as a user writes it in
datadog.yaml / system-probe.yaml — e.g. api_key, proxy.https,
apm_config.enabled. (Use -- so invoke treats the path as a positional arg.)
It can also be a pattern: any argument containing a character outside
[A-Za-z0-9_.] (e.g. *, $, [) is matched against every full dotted path
in the schema instead of looked up exactly. The pattern is treated as a regular
expression (re.search); if it isn't valid regex it falls back to shell-style
glob (fnmatch). So '*enabled' lists every setting whose path ends with
enabled. Pattern matches are printed as a compact, sorted
[<schema>] <path> -> <file>:<line> list (one line per match) rather than full
node blocks; pass --json for the full {schema, path, file, line, node} array.
| Flag | Effect |
|---|---|
--target core / --target system-probe | Restrict to one schema (default: search both). |
--json | Emit a JSON array of {schema, path, file, line, node} instead of human text. Use this when you want to parse the result programmatically. |
node_type, type, default,
env_vars, visibility, description, tags.properties collapsed to the
sorted list of immediate child key names (so a big section like apm_config
doesn't dump thousands of lines). Drill into a child to see its full node.[<schema>] <file>:<line>.log_level), it prints one block per
schema, labeled [core] and [system-probe].apm_config, logs_config) is reported at
its $ref: line in pkg/config/schema/yaml/core_schema.yaml — that's where it's
wired in.apm_config.enabled) is reported in
the sub-file (pkg/config/schema/yaml/apm_config.yaml:<line>) — that's where
its real definition is, and the file you'd edit.api_key,
proxy.https) is reported directly in core_schema.yaml.pkg/config/schema/yaml/ — no build step or
agent binary needed; works straight from a checkout. Line numbers are real.properties). Array items and
patternProperties internals are out of scope.# Top-level setting → core_schema.yaml + full node
dda inv -- schema.locate api_key
# Setting inside a split section → resolves into the sub-file
dda inv -- schema.locate apm_config.enabled
# Bare split section → $ref site in core_schema.yaml, child names only
dda inv -- schema.locate apm_config
# Restrict to one schema and get machine-readable output
dda inv -- schema.locate process_config.enabled --target core --json
# Pattern (glob): every setting whose full path ends with 'enabled'
dda inv -- schema.locate '*enabled'
# Pattern (regex): every path containing 'proxy' (a bare word like 'proxy' is an
# exact lookup, so add metacharacters to force a pattern/contains-match)
dda inv -- schema.locate '.*proxy'
tasks/schema/locate.py (registered in tasks/schema/__init__.py).pkg/config/schema/yaml/. To regenerate it, see dda inv schema.generate.create-config-field skill.