/alibabacloud-terraform-code-generation

name: alibabacloud-terraform-code-generation
description: |
  Use when the user wants Terraform HCL for Alibaba Cloud (Alicloud) infrastructure —
  new project or extending an existing one. Covers VPC, ECS, ApsaraDB RDS, OSS,
  SLB / ALB, Function Compute v3, ACK, and any other `alicloud_*` resource via the
  provider's own documentation fetched at generation time. For AWS → Alicloud
  migration or importing existing resources into state, use a different skill.
  Triggers: "write terraform for alicloud", "generate alibaba cloud terraform",
  "alicloud HCL", "create alibaba cloud vpc/ecs/rds", "生成阿里云 Terraform",
  "阿里云 HCL", "用 Terraform 部署阿里云", "alicloud provider", "aliyun/alicloud",
  "terraform-provider-alicloud".

Alibaba Cloud Terraform Code Generation

Turn natural-language Alibaba Cloud infrastructure requirements into validated Terraform for the current `aliyun/alicloud` provider. Resource knowledge is pulled from the provider's own docs at generation time — no local gold examples are maintained.

Hard rules (never violate)

1. Credentials — never leak, never require

NEVER read, print, ask for, or write AK/SK values anywhere — HCL, comments, env declarations, shell output, logs. The alicloud provider resolves credentials through seven mechanisms (env AK/SK, shared `config.json`, ECS instance RAM role, Assume Role, OIDC/RRSA, sidecar URI, static HCL) — see `references/auth-and-network.md` for the full chain. All read by the provider itself, never by this skill. Do NOT recommend the deprecated `ALICLOUD_*` / `ALIBABACLOUD_*` (no-underscore) env-var names — the current names are `ALIBABA_CLOUD_ACCESS_KEY_ID` / `_ACCESS_KEY_SECRET` / `_SECURITY_TOKEN`.

2. Honest reporting — never claim a step you didn't run

Never report `fmt: ok` / `validate: ok` / `plan: ok` unless the corresponding command actually executed AND returned that status. When a step is skipped (tool missing, user opt-out), state **"SKIPPED"** (or **"FAILED"**) with a reason. Paraphrasing real output is fine; fabricating it is not.

3. `terraform apply` is off-limits

This skill NEVER runs `terraform apply`. `plan` is opt-in (Step 8); `apply` is strictly the user's action.

Environment (soft recommendations)

• **Terraform ≥ 1.5** recommended. Do not install or download Terraform

automatically; Step 6 checks whether `terraform` is on PATH and reports the actual validation status.

• **Network** is required — Step 4.2 WebFetches each resource's provider doc.

Workflow

Step 1. Parse requirement

Extract:

• `region` — default `cn-hangzhou`.
• `resources[]` — `{ alicloud_type, quantity, attributes }`.
• Non-functional: multi-AZ, encryption, backup, HA, IOPS.

If ambiguous (e.g. "搭个数据库"), ask **at most one** clarifying question.

Step 2. Resolve target directory

Extract `<target-dir>` from the user's request (explicit path like `myshop-infra/` or current working directory if unspecified). All subsequent `fmt` / `init` / `validate` commands run in this directory.

Before writing any `.tf` file, **MUST** create the directory:

mkdir -p <target-dir>

All file writes MUST prefix paths with `<target-dir>/` — never write to the current working directory directly, never write to a generic `outputs/` parent. After generation completes, verify the structure:

ls -R <target-dir>

Step 3. Sketch architecture

Before any HCL, sketch a dependency table — one row per resource:

| resource | depends on | AZ / placement | | --- | --- | --- |

• Expand `resources[]` with implied infra (VPC → VSwitch → SecurityGroup

→ workload); user parse often skips these.

• The expanded list is the input to Step 4's gate.

Step 4. Pre-HCL gate (MANDATORY)

For every distinct `alicloud_*` type from Step 3 (resources **and** data sources), execute 4.1 → 4.2 → 4.3. The calls per type are independent — **issue them in parallel** across types.

4.1 Pre-doc lookup (catalog + patterns, in parallel)

Two local lookups; **run them concurrently** before going to WebFetch:

**(a) Catalog lookup** — confirm the resource exists and check deprecation. The catalog (`references/alicloud-providers.md`) is ~2600 lines; **do NOT `Read` it whole** — use `grep`, which returns just the row(s) you need:

grep "alicloud_<name>" references/alicloud-providers.md

Three outcomes:

• **Row found, status column empty** → note the `[doc](<url>)` from the row;

proceed to 4.2.

• **Row found, status `⚠️ 弃用 → `<new_name>`** → switch the plan to

`<new_name>` and re-lookup. NEVER emit the deprecated name. Common catch: `alicloud_fc_function` → `alicloud_fcv3_function`.

• **Row not found** → stop. Ask the user whether the name was a typo;

don't invent an `alicloud_<guess>`.

**(b) Pattern lookup** (conditional) — if the user's requirement matches a product-specific idiom listed in `references/resource-patterns.md` (e.g. RDS cross-AZ HA, OSS lifecycle noncurrent, VPC peering), read the relevant section. These idioms are NOT in the provider doc's *Required* list but are what the user actually wants (e.g. `zone_id_slave_a` for RDS HA is optional per the doc but required for real cross-AZ placement). Missing them produces "validates but silently wrong" output.

When a matching pattern section is found, **ALL attributes listed in that section's "Required attributes" table MUST appear in the generated HCL** — treat them as mandatory even if the provider doc marks them Optional.

# Quick check whether a relevant pattern exists, then Read only the section:
grep -in "<keyword>" references/resource-patterns.md

4.2 Fetch provider doc (WebFetch)

WebFetch the doc URL from 4.1. If it fails or returns no useful content, construct the raw URL directly from the catalog row's `doc` URL. Preserve the catalog kind: resources use `website/docs/r/`, data sources use `website/docs/d/`.

https://raw.githubusercontent.com/aliyun/terraform-provider-alicloud/master/website/docs/{r|d}/<doc_name