cloud-create-project

What this skill does

# Create Serverless Project

Create Elastic Cloud Serverless projects using the Serverless REST API. Use the `cloud-manage-project` skill for day-2
operations like listing, updating, or deleting projects.

## Prerequisites and permissions

- Ensure `EC_API_KEY` is configured. If not, run `cloud-setup` skill first.
- Creating projects requires a Cloud API key with **Admin** or **Organization owner** role.
- This skill does not perform a separate role pre-check. Attempt the requested operation and let the API enforce
  authorization. If the API returns an authorization error (for example, `403 Forbidden`), stop and ask the user to
  verify the provided API key permissions.

### Manual setup fallback (when `cloud-setup` is unavailable)

If this skill is installed standalone and `cloud-setup` is not available, instruct the user to configure Cloud
environment variables manually before running commands. Never ask the user to paste API keys in chat.

| Variable      | Required | Description                                                    |
| ------------- | -------- | -------------------------------------------------------------- |
| `EC_API_KEY`  | Yes      | Elastic Cloud API key used for project creation operations.    |
| `EC_BASE_URL` | No       | Cloud API base URL (default: `https://api.elastic-cloud.com`). |

> **Note:** If `EC_API_KEY` is missing, or the user does not have a Cloud API key yet, first check whether the user has
> an Elastic Cloud account. If not, propose starting a free trial at
> [Elastic Cloud free trial](https://cloud.elastic.co/registration) — 14 days of full access with no credit card
> required. Once registered, direct the user to generate a key at
> [Elastic Cloud API keys](https://cloud.elastic.co/account/keys), then configure it locally using the steps below.

Preferred method (agent-friendly): create a `.env` file in the project root:

```bash
EC_API_KEY=your-api-key
EC_BASE_URL=https://api.elastic-cloud.com
```

All `cloud/*` scripts auto-load `.env` from the working directory.

Alternative: export directly in the terminal:

```bash
export EC_API_KEY="<your-cloud-api-key>"
export EC_BASE_URL="https://api.elastic-cloud.com"
```

Terminal exports may not be visible to sandboxed agents running in separate shell sessions, so prefer `.env` when using
an agent.

## Critical principles

- **Never display secrets in chat.** Do not echo, log, or repeat API keys, passwords, or credentials in conversation
  messages or agent thinking. Direct the user to the `.elastic-credentials` file instead. The admin password must
  **never** appear in chat history, thinking traces, or agent output.
- **Confirm before creating.** Always present the project configuration to the user and ask for confirmation before
  running the creation script.
- **Admin credentials are for API key creation only.** The script saves the `admin` password to `.elastic-credentials`
  for bootstrapping a scoped API key. The `admin` user has full privileges and cannot be modified in serverless. Never
  use admin credentials for direct Elasticsearch operations (querying, indexing, etc.) — always create a scoped API key
  first (see Step 8). The `load-credentials` command excludes admin credentials by default — use `--include-admin`
  **only** during Step 7/8, then reload without it once the API key is created. Never read or display the contents of
  `.elastic-credentials` in chat.
- **Recover lost credentials.** If the script fails to write `.elastic-credentials` (disk full, permissions, etc.), the
  save may be incomplete. Check `.elastic-credentials` for the password first. If missing, use the
  `cloud-manage-project` skill's `reset-credentials` command to generate a new password.
- **Region is permanent.** A project's region cannot be changed after creation.
- **Prefer automatic readiness checks.** Pass `--wait` to the creation script so it polls until the phase changes from
  `initializing` to `initialized`. Only fall back to manually polling the status endpoint if `--wait` is unavailable.

## Project types

| Type            | Description                               | Key endpoints                    |
| --------------- | ----------------------------------------- | -------------------------------- |
| `elasticsearch` | Search, analytics, and vector workloads   | Elasticsearch, Kibana            |
| `observability` | Logs, metrics, traces, and APM            | Elasticsearch, Kibana, APM, OTLP |
| `security`      | SIEM, endpoint protection, cloud security | Elasticsearch, Kibana, OTLP      |

### Project type inference

Map the user's request to the correct `--type` value:

| User says                                                   | `--type`        |
| ----------------------------------------------------------- | --------------- |
| "search project", "elasticsearch project", vector search    | `elasticsearch` |
| "observability project", "o11y", logs, metrics, traces, APM | `observability` |
| "security project", "SIEM", detections, endpoint protection | `security`      |

Do **not** silently default to any type. If the user does not specify a type, infer it from the conversation context
(for example, discussing log ingestion suggests `observability`, discussing detections or SIEM suggests `security`,
discussing search or vector workloads suggests `elasticsearch`). Always present the inferred type to the user and ask
for confirmation before proceeding. If context is insufficient to infer a type, ask the user to choose.

### Product tiers

Observability and security projects support a `--product-tier` flag. Default to `complete` unless the user explicitly
requests a different tier.

| Project type    | Tier              | Description                                           |
| --------------- | ----------------- | ----------------------------------------------------- |
| `observability` | `complete`        | Full observability suite (logs, metrics, traces, APM) |
| `observability` | `logs_essentials` | Log management only                                   |
| `security`      | `complete`        | Full security suite (SIEM, cloud, endpoint)           |
| `security`      | `essentials`      | Core SIEM only                                        |

Elasticsearch projects do not have a product tier — use `--optimized-for` instead.

## Sensible defaults

Present these defaults to the user before creation. Ask if they want to use or change them:

| Setting | Default           |
| ------- | ----------------- |
| Region  | `gcp-us-central1` |

Project type must be confirmed with the user — do not assume a default. See "Project type inference" above.

Always use `--optimized-for general_purpose` unless the user explicitly requests `vector`. Do not proactively offer the
`vector` option.

If the user does not specify a name, ask for one — it is required.

## Workflow: Create a project

```text
Project Creation:
- [ ] Step 1: Verify API key is set
- [ ] Step 2: Present defaults and confirm with user
- [ ] Step 3: List available regions (optional)
- [ ] Step 4: Create the project
- [ ] Step 5: Save credentials and endpoints
- [ ] Step 6: Wait for project to initialize
- [ ] Step 7: Set environment variables
- [ ] Step 8: Recommend creating a scoped API key
```

### Step 1: Verify API key is set

```bash
echo "${EC_API_KEY:?Not set}"
```

If `EC_API_KEY` is not set, run the `cloud-setup` skill first to configure authentication and defaults.

### Step 2: Present summary and confirm with user

Before presenting the summary, ensure the project type has been explicitly confirmed by the user. If no type was
specified, infer one from the conversation context and propose it. If the context is ambiguous, ask the user to choose
from `elasticsearch`, `observability`, or `security`.

Always show a confirmation summary before creating. Include different fields depending on project type:

**Elasticsearch project:**

```text
Project Summary:
  Type:          elasticsearch
  Name: