New Entity Requirements

Gather initial requirements for an entirely new Terraform resource or data source, then materialize them as an OpenSpec proposal: a change under openspec/changes/<name>/ with proposal.md, design.md, tasks.md, and delta capability specs. Sources: repo API client code, Elastic API documentation (via the Elastic docs MCP server when available, otherwise web fetch/search), and user input for decisions the code and docs cannot answer.

For the CLI sequence (create change, resolve artifact order, run openspec instructions, write files), follow openspec-propose. This skill adds what to research and what to put in each artifact for a new Terraform entity.

Input

• Entity concept: User specifies the target (e.g. “Elasticsearch API key”, “Kibana SLO”, “Fleet integration”). Optionally: resource vs data source, proposed type name.
• API scope: Which backend (Elasticsearch vs Kibana/Fleet) and, if known, API name or doc URL.
• Change name (optional): Kebab-case id for openspec new change (e.g. add-elasticsearch-security-api-key-resource). If missing, derive one from the entity and confirm with the user if ambiguous.

Workflow

1. Resolve API surface

• Elasticsearch: Wrappers live in internal/clients/elasticsearch/ (e.g. security.go, cluster.go). They call apiClient.GetESClient() and use the go-elasticsearch client (e.g. esClient.Security.PutUser). Shared models: internal/models/. If no wrapper exists yet, search the go-elasticsearch API (dependency github.com/elastic/go-elasticsearch/v8) for the relevant namespace (e.g. Security, Watcher, Transform).
• Kibana and Fleet: OpenAPI-generated client: generated/kbapi/kibana.gen.go. Higher-level wrappers: internal/clients/kibanaoapi/ and internal/clients/fleet/ (e.g. alerting_rule.go, connector.go). Use kbapi types and ClientWithResponses methods for the target API.