Trending Society: A curated library for people building with AI.

1. Overview

This skill turns user infrastructure goals into Terraform configurations for Huawei Cloud. The primary workflow is to:

understand the user's actual deployment intent
determine which resources should be created
determine whether existing resources should be reused
confirm key specifications and dependencies
verify every resource specification against the target region's available resources — query first, write later
ensure Terraform is installed
generate Terraform configuration files
run validation steps and fix generation issues until terraform plan succeeds
ask user for confirmation and execute terraform apply if approved

This skill provides an interactive workflow where the agent guides the user through credential configuration, validates the plan, and executes apply upon explicit user confirmation.

2. Prerequisites

Before using this skill, ensure the following are available:

Terraform — installed in PATH or auto-installable (see validation-workflow.md)
Provider download source — the Huawei Cloud mirror should be reachable (see validation-workflow.md)
Target region — the deployment region (e.g. cn-north-4, cn-south-1) must be identified
Windows long-path support (Windows only) — this skill ships a deep reference/** + assets/** tree, and git clone on Windows can abort with Filename too long and leave an incomplete work tree. Before cloning on Windows:
- prefer a short clone root (e.g. D:\hw-skills) instead of a deeply nested project directory;
- or enable long paths for that single command: git clone -c core.longpaths=true https://gitcode.com/developer-skill/huaweicloud-skills.git;
- if an existing clone already has an incomplete work tree, repair it in place: git config core.longpaths true && git checkout -f. Linux/macOS need no special handling for these paths.

3. Parameter Confirmation

Before generating Terraform, propose a concrete resource plan for the user to confirm. The plan should include:

recommended resource specifications
available candidate options when applicable
whether to create new resources or reuse existing ones
pricing information only when obtained from a reliable source

See reference/guardrails.md for rules about not fabricating specifications and prices.

Do not ask the user to provide every parameter manually. Instead:

infer the likely architecture from the user's goal
propose a concrete plan with recommended defaults
confirm only the small number of decisions that materially affect correctness, cost, or architecture

Users should mainly confirm a proposed solution, not build the full parameter set themselves.

4. Workflow

This skill works in nine phases:

4.0 Credential handling (MUST READ)

AK/SK credentials are read from environment variables HW_ACCESS_KEY and HW_SECRET_KEY (plus HW_SECURITY_TOKEN or HUAWEICLOUD_SECURITY_TOKEN for temporary/STS). They authenticate the Terraform provider only — they are NOT written into the FunctionGraph function user_data, which holds only a pre-created DevBridge API Key (see reference/ecs-devbridge-option.md).

Because the provider does not reliably resolve security_token from env vars, the agent must write it to terraform.tfvars as security_token when using temporary/STS credentials. AK/SK themselves may be passed via TF_VAR_access_key / TF_VAR_secret_key.

DevBridge API Key handling: the key MUST be pre-created in the sandbox before apply — reuse the sandbox key if valid, otherwise create one via DevStage API using the sandbox's user-level AK/SK (which DevStage accepts). Pass it as devbridge_api_key. The FunctionGraph function only forwards this key and never creates keys, so it carries no AK/SK.

Before any step that depends on credentials (resource queries, terraform plan, etc.), read the complete rules in reference/guardrails.md. If an API or Terraform call fails with an authentication error: tell the user the specific error, ask them to confirm when the issue is resolved, then retry. Do not guide the user on how to configure credentials.

4.1 Understand the user's real goal

The user may describe a resource directly, such as creating an ECS instance, or describe a business goal, such as deploying a website or launching an application.
You must first infer the intended Huawei Cloud architecture from the user's objective, not just from explicit resource names.

4.2 Determine the resource set

Based on the user's goal, identify:

which resources need to be created
which existing resources may be reused
what dependencies exist between the resources

For example:

a simple public website may require VPC, subnet, security group, ECS, and EIP
a managed database deployment may require VPC, subnet, security group, and RDS
a scalable public service may require VPC, subnet, security group, ECS or AS, ELB, and public access

4.3 Propose a resource plan for confirmation

Pre-confirmation checklist (CRITICAL — MUST complete ALL items before proposing the plan when ECS is in the resource set):

When the resource set includes ECS instances, the following checklist MUST be completed before proposing the resource plan to the user. Each item must be explicitly resolved — "skipped" is not a valid state.

DevBridge decision (4.3.1): Read reference/ecs-devbridge-option.md and ask the user whether to install DevBridge SSH tunnel. Record the answer (yes/no). This decision determines the security group configuration (see 4.3.2).
Security group ports (4.3.2): If DevBridge = yes → zero inbound rules, egress limited to TCP 443/80 + UDP 53. If DevBridge = no → ask user which ports to open.
Region confirmed: User has confirmed or accepted the recommended region.
OS image confirmed: User has confirmed or accepted the recommended OS image.

Forbidden:

❌ Proposing a resource plan without completing the pre-confirmation checklist when ECS is in the resource set
❌ Skipping the DevBridge question or assuming the answer
❌ Proceeding to 4.4 (resource availability verification) with unresolved checklist items

Before generating Terraform, propose a concrete resource plan for the user to confirm following the rules in the Parameter Confirmation section.

See reference/guardrails.md for rules about handling sensitive information.

4.3.1 ECS DevBridge SSH tunnel decision (CRITICAL — MUST ask before security group configuration)

This step MUST be executed before 4.3.2 (security group rules). The DevBridge decision determines the security group configuration:

DevBridge = yes → zero inbound rules (SSH comes through tunnel, not public port), egress limited to TCP 443 + TCP 80 + UDP 53
DevBridge = no → ask user which ports to open (4.3.2)

When creating ECS, check reference/ecs-devbridge-option.md for DevBridge SSH tunnel option. If the file exists, read it and follow its instructions (ask user, check conditions, generate with DevBridge, post-apply guidance, destroy cleanup).

Forbidden:

❌ Skipping this step and proceeding directly to security group configuration
❌ Assuming the user's DevBridge preference without asking
❌ Reading reference/ecs-devbridge-option.md but not asking the user

4.3.2 Confirm security group rules with user (CRITICAL)

Prerequisite: 4.3.1 (DevBridge decision) must be completed first. The security group configuration depends on the DevBridge decision:

If DevBridge = yes: zero inbound rules, egress limited to TCP 443 + TCP 80 + UDP 53 (DevBridge tunnel connects out on TCP 443). Do NOT ask about inbound ports.
If DevBridge = no: proceed with the normal port confirmation workflow below.

Required workflow (when DevBridge = no):

Infer likely ports from user's goal (Web server → 80, 443; SSH → 22; Database → 3306, 5432)
Ask user to confirm ports: "需要开放哪些端口？推荐：80、443、22"
Generate rules based on confirmed ports, NOT default rules

Terraform generation:

# User confirmed: 80, 443, 22

resource "huaweicloud_networking_secgroup_rule" "http" {
  security_group_id = huaweicloud_networking_secgroup.main.id
  direction         = "ingress"
  ethertype         = "IPv4"
  port_range_min    = 80
  port_range_max    = 80
  protocol          = "tcp"
  remote_ip_prefix  = "0.0.0.0/0"
}

# ... similar for 443, 22 (always include ethertype = "IPv4")

# Always include egress
resource "huaweicloud_networking_secgroup_rule" "egress" {
  security_group_id = huaweicloud_networking_secgroup.main.id
  direction         = "egress"
  ethertype         = "IPv4"
  remote_ip_prefix  = "0.0.0.0/0"
}

Forbidden:

❌ Using only egress rule without ingress rules
❌ Using hardcoded default ports without asking user
❌ Generating rules that don't match user confirmation
❌ Configuring security group before completing the DevBridge decision (4.3.1)

4.4 Verify resource availability BEFORE generating any code

This step is mandatory and must never be skipped. A failed query is not a license to proceed — it is a blocker that must be resolved.

Before writing a single line of Terraform, you MUST verify every resource specification in the confirmed plan against the target region. The target region is already known from the confirmed plan in step 4.3 — lacking the region means step 4.3 was incomplete and must be revisited. There is no excuse for not knowing which region you are deploying to.

Step 1 — Read the target skill's SKILL.md first (DO NOT skip): You MUST read the file ../huawei-cloud-computing-query/SKILL.md before invoking the skill. This tells you the exact invocation format, required parameters, parameter format, and how to pass the target region. You cannot correctly invoke a skill you haven't read.
Step 2 — Invoke the skill with confirmed parameters: Only after reading the skill definition, invoke the huawei-cloud-computing-query skill with the exact parameters it requires, passing the target region from the confirmed plan in step 4.3. Confirm that each resource specification in the confirmed plan actually exists and is available in the target region. Any specification that cannot be confirmed MUST NOT appear in any .tf file.
Cross-region assumptions are forbidden — a resource available in region A does NOT imply availability in region B. Always re-query for the target region.

Forbidden:

❌ Invoking the huawei-cloud-computing-query skill without first reading its SKILL.md
❌ Guessing or fabricating parameters for skill invocation
❌ Proceeding to generate Terraform when a resource specification cannot be confirmed available
❌ Assuming resource availability carries over across regions

If the query fails (environment error, network issue, SDK crash):

You MUST NOT proceed to generate Terraform. Stop immediately.
Diagnose and fix the issue: invoke the huawei-cloud-computing-query skill's environment check, verify credentials, check network.
Retry the query. If it fails again, fix and retry again.
There is no "graceful degradation" — an unverified specification is a broken deployment waiting to happen.
The only acceptable outcomes from this step are: (a) all specs confirmed available, or (b) a spec is confirmed unavailable and the user is asked to choose a different one.

Why this matters: Writing an unavailable flavor into main.tf produces a configuration that passes terraform validate but fails at terraform apply — the worst kind of error because it surfaces only after minutes of waiting.

When modifying existing Terraform (user asks to change a flavor, switch regions, use a different instance type, etc.): re-run the availability query for the new specification in the new region BEFORE editing any .tf file. Do not assume the previously-queried results still apply.

4.5 Generate Terraform after confirmation

Pre-generation validation (CRITICAL — MUST pass before writing any .tf file):

If the resource plan includes ECS instances, verify:

DevBridge decision was explicitly made (yes or no) in 4.3.1 — not skipped
If DevBridge = yes: reference/ecs-devbridge-option.md was read and all conditions checked
Security group rules match the DevBridge decision (DevBridge = yes → zero inbound; DevBridge = no → user-confirmed ports)

If any check fails, go back to 4.3 and complete the pre-confirmation checklist. Do NOT generate Terraform with unresolved decisions.

CRITICAL: Before generating, MUST read relevant reference documents from Section 8.1 mapping table.

Once the user confirms the resource plan, generate the Terraform files following the required structure and style rules.

See reference/terraform-generation-guide.md for detailed file structure and content rules.

Critical: Generate all required files (providers.tf, variables.tf, main.tf, terraform.tfvars, README.md) and verify they exist before proceeding.

4.6 Verify credentials configuration

Before proceeding to validation, verify that Huawei Cloud credentials are configured via environment variables.

See reference/guardrails.md for rules about AK/SK handling.

4.6.1 Configure Huawei Cloud mirror for provider download

Before running terraform init, configure the Huawei Cloud mirror to avoid slow downloads from the official Terraform registry. Do NOT attempt to download from official registry first. Always use Huawei Cloud mirror.

Steps:

Check if local provider cache exists (see validation-workflow.md for locations)
If cache exists and version >= 1.90.0, skip download

If download needed, create .tfrc file in the project directory:

provider_installation {
  network_mirror {
    url = "https://mirrors.huaweicloud.com/terraform/"
    include = ["registry.terraform.io/huaweicloud/*"]
  }
  direct {
    include = ["registry.terraform.io/hashicorp/*"]
  }
}

Set TF_CLI_CONFIG_FILE environment variable to the .tfrc file path
Every terraform init command MUST include TF_CLI_CONFIG_FILE in the same command line. Bare terraform init without the env var is FORBIDDEN. Example:
```
export TF_CLI_CONFIG_FILE="/path/to/project/.tfrc" && terraform init -upgrade
```

4.7 Validate and fix the generated configuration

Run validation in order: terraform fmt -recursive → terraform init → terraform validate → terraform plan

If any step fails, inspect the error, fix the configuration, and retry until terraform plan succeeds.

See reference/validation-workflow.md for detailed validation steps.

4.8 Display cost estimation (CRITICAL — MUST NOT SKIP)

This step is MANDATORY and MUST be executed immediately after terraform plan succeeds, BEFORE any confirmation dialog or terraform apply. Skipping this step is a CRITICAL violation.

Cost display format (fill with actual resources from the plan):

💰 费用预估

即将创建的资源：
- [资源类型] ([规格]): [预估费用]
- [资源类型] ([规格]): [预估费用]
- ...

预估合计: [总费用]

📌 华为云价格计算器: https://www.huaweicloud.com/pricing.html#/calculator

Required elements (ALL must be present):

Resource list with specifications (from confirmed plan)
Estimated monthly cost per resource (range is acceptable)
Total estimated cost
Link to Huawei Cloud pricing calculator (fixed URL)

If you cannot estimate a cost: still list the resource with "费用请参考价格计算器" — do NOT omit the resource from the list.

Verification: Before proceeding to step 4.9, confirm that you have output ALL required elements above. If any element is missing, stop and add it.

4.9 Execute terraform apply with user confirmation

After cost estimation is displayed, popup a confirmation dialog for user confirmation before executing apply.

See reference/guardrails.md for rules about user confirmation workflow.

4.10 Apply error repair loop

If terraform apply fails, inspect the error, fix the configuration, re-run terraform plan, and re-execute terraform apply. Repeat until successful.

4.11 Post-apply resource verification

After terraform apply succeeds, verify that deployed resources match the confirmed plan. If discrepancies found, report and fix them.

5. Guardrails

See reference/guardrails.md for detailed guardrail rules.

Key principles:

Do not fabricate specifications, prices, or resource facts
Execute terraform apply with explicit user confirmation
Do not request sensitive information
Do not invoke any referenced skill without first reading that skill's SKILL.md file

6. Terraform Generation Rules

After the user confirms the resource plan, generate Terraform that is minimal, valid, and aligned with the confirmed solution.

See reference/terraform-generation-guide.md for detailed guidance on file structure, content rules, data source usage, and variable design.

Core principles:

Start from the confirmed resource plan
Follow the Minimum Viable Configuration principle
Prefer Terraform validity over unnecessary flexibility
Use existing package references when relevant

7. Environment Preparation and Validation

See reference/validation-workflow.md for detailed guidance on ensuring Terraform availability, provider download (from Huawei Cloud mirror), validation order, authentication, and repair loop.

8. Reference Usage and Template Guidance

Use the reference materials, templates, examples, and helper utilities in the skill package when relevant.

8.1 Use existing references when relevant

MUST consult these references before generating:

Resource	Reference Document	Key Pattern
通用规则	`reference/guardrails.md` + `reference/terraform-generation-guide.md`	密码自动生成、不向用户要敏感信息
Security Group	`reference/VPC-best-practices/VPC-best-practices.md` → "Deploy Security Group"	`ethertype` is required
ECS with EIP	`reference/ECS-best-practices/Deploy-Instance-with-EIP-best-practices.md`	Use `huaweicloud_compute_eip_associate`, `public_ip = .address`
ECS with DevBridge	`reference/ECS-best-practices/Deploy-Instance-with-DevBridge-best-practices.md`	user_data + zero ingress SG + EIP for outbound + DevBridge auto-setup
VPC/Subnet	`reference/VPC-best-practices/VPC-best-practices.md` → "Deploy Basic Network"	VPC/subnet structure
RDS	`reference/RDS-best-practices/RDS-best-practices.md`	Database + network config

8.2 Use existing examples and templates as a starting point

If the package contains an example close to the target scenario, use it as a starting point. Preserve useful structure, adapt to the confirmed plan, and remove unneeded resources.

8.3 Match user goals to relevant references

Map business goals to service references (e.g., "deploy a website" → VPC + ECS + EIP, "managed database" → RDS + network).

8.4 Use references to improve, not to overbuild

Keep the final Terraform aligned with the user-confirmed plan and follow Minimum Viable Configuration principle.

8.5 Do not rely on templates blindly

Always verify that the template matches the confirmed plan and validate through the normal validation workflow.

8.6 Packaging and publishing size limits

assets/** is a library of ready-to-use templates and accounts for most of the files in this skill package; SKILL.md + reference/** are the rules and must always ship. If the channel used to publish the skill enforces a file-count or archive-size ceiling, publish SKILL.md + reference/** only, exclude assets/**, and tell the user which templates were left out instead of silently dropping them.

The duplicated assets/rds/reference/** copy (88 documents that already exist under reference/**) has been removed — shipping the same reference documents twice inflated both the file count and the archive size, and its deepest paths were the ones that broke Windows git clone. Do not re-introduce copies of reference/** inside assets/**.

9. Quality Checklist

Before finalizing, ensure:

The generated Terraform matches the confirmed resource plan
All 5 required files were generated and verified (providers.tf, variables.tf, main.tf, terraform.tfvars, README.md)
No sensitive information was requested from user
Validation reached terraform plan, or the blocker was clearly explained
Cost estimation was displayed BEFORE user confirmation (step 4.8 — MUST NOT skip)
Cost estimation includes ALL required elements: resource list, specifications, estimated cost per resource, total cost, pricing calculator link
User was asked for confirmation via confirmation dialog before terraform apply
terraform apply was executed only after explicit user confirmation (or user declined)
If ECS is in the plan: DevBridge decision was explicitly asked and recorded (yes/no) in 4.3.1