Terraform Skill for Claude
面向Claude的Terraform技能包
Comprehensive Terraform and OpenTofu guidance covering testing, modules, CI/CD, and production patterns. Based on terraform-best-practices.com and enterprise experience.
涵盖测试、模块、CI/CD及生产模式的全面Terraform与OpenTofu指南，基于terraform-best-practices.com及企业实践经验。
When to Use This Skill
何时使用本技能包
Activate this skill when:
- Creating new Terraform or OpenTofu configurations or modules
- Setting up testing infrastructure for IaC code
- Deciding between testing approaches (validate, plan, frameworks)
- Structuring multi-environment deployments
- Implementing CI/CD for infrastructure-as-code
- Reviewing or refactoring existing Terraform/OpenTofu projects
- Choosing between module patterns or state management approaches
Don't use this skill for:
- Basic Terraform/OpenTofu syntax questions (Claude knows this)
- Provider-specific API reference (link to docs instead)
- Cloud platform questions unrelated to Terraform/OpenTofu
激活本技能包的场景：
- 创建新的Terraform或OpenTofu配置与模块
- 为IaC代码搭建测试基础设施
- 选择测试方案（validate、plan、框架选型）
- 规划多环境部署架构
- 实现基础设施即代码的CI/CD流程
- 评审或重构现有Terraform/OpenTofu项目
- 选择模块模式或状态管理方案
请勿使用本技能包的场景：
- 基础Terraform/OpenTofu语法问题（Claude已内置相关知识）
- 提供商专属API参考（建议直接查阅官方文档）
- 与Terraform/OpenTofu无关的云平台问题
1. Code Structure Philosophy
1. 代码结构理念
Module Hierarchy:
| Type | When to Use | Scope |
|---|
| Resource Module | Single logical group of connected resources | VPC + subnets, Security group + rules |
| Infrastructure Module | Collection of resource modules for a purpose | Multiple resource modules in one region/account |
| Composition | Complete infrastructure | Spans multiple regions/accounts |
Hierarchy: Resource → Resource Module → Infrastructure Module → Composition
Directory Structure:
environments/ # Environment-specific configurations
├── prod/
├── staging/
└── dev/
modules/ # Reusable modules
├── networking/
├── compute/
└── data/
examples/ # Module usage examples (also serve as tests)
├── complete/
└── minimal/
Key principle from terraform-best-practices.com:
- Separate environments (prod, staging) from modules (reusable components)
- Use examples/ as both documentation and integration test fixtures
- Keep modules small and focused (single responsibility)
For detailed module architecture, see: Code Patterns: Module Types & Hierarchy
模块层级：
| 类型 | 适用场景 | 范围 |
|---|
| Resource Module | 单一逻辑关联资源组 | VPC + 子网、安全组 + 规则 |
| Infrastructure Module | 为特定目标组合的资源模块集合 | 单区域/账号内的多个资源模块 |
| Composition | 完整基础设施架构 | 跨多区域/账号的基础设施 |
层级关系： 资源 → 资源模块 → 基础设施模块 → 组合架构
目录结构：
environments/ # 环境专属配置
├── prod/
├── staging/
└── dev/
modules/ # 可复用模块
├── networking/
├── compute/
└── data/
examples/ # 模块使用示例（同时作为测试用例）
├── complete/
└── minimal/
来自terraform-best-practices.com的核心原则：
- 将环境（生产、预发布）与模块（可复用组件）分离
- 把**examples/**目录同时作为文档和集成测试夹具
- 保持模块小巧且聚焦单一职责
如需详细模块架构说明，请参考：代码模式：模块类型与层级
2. Naming Conventions
2. 命名规范
Good: Descriptive, contextual
推荐：描述性强、具备上下文
resource "aws_instance" "web_server" { }
resource "aws_s3_bucket" "application_logs" { }
resource "aws_instance" "web_server" { }
resource "aws_s3_bucket" "application_logs" { }
Good: "this" for singleton resources (only one of that type)
推荐：单例资源使用"this"（同类型仅一个实例）
resource "aws_vpc" "this" { }
resource "aws_security_group" "this" { }
resource "aws_vpc" "this" { }
resource "aws_security_group" "this" { }
Avoid: Generic names for non-singletons
避免：非单例资源使用通用名称
resource "aws_instance" "main" { }
resource "aws_s3_bucket" "bucket" { }
**Singleton Resources:**
Use `"this"` when your module creates only one resource of that type:
✅ DO:
```hcl
resource "aws_vpc" "this" {} # Module creates one VPC
resource "aws_security_group" "this" {} # Module creates one SG
❌ DON'T use "this" for multiple resources:
hcl
resource "aws_subnet" "this" {} # If creating multiple subnets
Use descriptive names when creating multiple resources of the same type.
Variables:
resource "aws_instance" "main" { }
resource "aws_s3_bucket" "bucket" { }
**单例资源：**
当模块仅创建同类型的一个资源实例时，使用`"this"`命名：
✅ 推荐：
```hcl
resource "aws_vpc" "this" {} # 模块仅创建一个VPC
resource "aws_security_group" "this" {} # 模块仅创建一个安全组
❌ 不推荐：多实例资源使用"this"
hcl
resource "aws_subnet" "this" {} # 若创建多个子网则不适用
创建同类型多个资源时，请使用具备描述性的名称。
变量命名：
Prefix with context when needed
必要时添加上下文前缀
var.vpc_cidr_block # Not just "cidr"
var.database_instance_class # Not just "instance_class"
**Files:**
- `main.tf` - Primary resources
- `variables.tf` - Input variables
- `outputs.tf` - Output values
- `versions.tf` - Provider versions
- `data.tf` - Data sources (optional)
var.vpc_cidr_block # 而非仅"cidr"
var.database_instance_class # 而非仅"instance_class"
**文件命名：**
- `main.tf` - 核心资源定义
- `variables.tf` - 输入变量
- `outputs.tf` - 输出值
- `versions.tf` - 提供商版本约束
- `data.tf` - 数据源（可选）
Testing Strategy Framework
测试策略框架
Decision Matrix: Which Testing Approach?
测试方案决策矩阵
| Your Situation | Recommended Approach | Tools | Cost |
|---|
| Quick syntax check | Static analysis | , | Free |
| Pre-commit validation | Static + lint | , , , | Free |
| Terraform 1.6+, simple logic | Native test framework | Built-in | Free-Low |
| Pre-1.6, or Go expertise | Integration testing | Terratest | Low-Med |
| Security/compliance focus | Policy as code | OPA, Sentinel | Free |
| Cost-sensitive workflow | Mock providers (1.7+) | Native tests + mocking | Free |
| Multi-cloud, complex | Full integration | Terratest + real infra | Med-High |
| 你的场景 | 推荐方案 | 工具 | 成本 |
|---|
| 快速语法检查 | 静态分析 | , | 免费 |
| 提交前验证 | 静态分析+代码检查 | , , , | 免费 |
| Terraform 1.6+、逻辑简单 | 原生测试框架 | 内置 | 低至免费 |
| 1.6以前版本、或具备Go语言经验 | 集成测试 | Terratest | 中低 |
| 聚焦安全/合规 | 策略即代码 | OPA, Sentinel | 免费 |
| 成本敏感型流程 | 模拟提供商（1.7+） | 原生测试+模拟 | 免费 |
| 多云、复杂场景 | 完整集成测试 | Terratest+真实基础设施 | 中高 |
Testing Pyramid for Infrastructure
基础设施测试金字塔
/\
/ \ End-to-End Tests (Expensive)
/____\ - Full environment deployment
/ \ - Production-like setup
/________\
/ \ Integration Tests (Moderate)
/____________\ - Module testing in isolation
/ \ - Real resources in test account
/________________\ Static Analysis (Cheap)
- validate, fmt, lint
- Security scanning
/\
/ \ 端到端测试（成本高）
/____\ - 完整环境部署
/ \ - 类生产环境配置
/________\
/ \ 集成测试（成本中等）
/____________\ - 模块隔离测试
/ \ - 测试账号内的真实资源
/________________\ 静态分析（成本低）
- validate、fmt、代码检查
- 安全扫描
Native Test Best Practices (1.6+)
原生测试最佳实践（1.6+）
Before generating test code:
-
Validate schemas with Terraform MCP:
Search provider docs → Get resource schema → Identify block types
-
Choose correct command mode:
- - Fast, for input validation
- - Required for computed values and set-type blocks
-
Handle set-type blocks correctly:
- Cannot index with
- Use expressions to iterate
- Or use to materialize
Common patterns:
- S3 encryption rules: set (use for expressions)
- Lifecycle transitions: set (use for expressions)
- IAM policy statements: set (use for expressions)
For detailed testing guides, see:
- Testing Frameworks Guide - Deep dive into static analysis, native tests, and Terratest
- Quick Reference - Decision flowchart and command cheat sheet
生成测试代码前：
-
使用Terraform MCP验证架构：
-
选择正确的命令模式：
- - 速度快，适用于输入验证
- - 计算值和集合类型块必填
-
正确处理集合类型块：
常见模式：
- S3加密规则：集合（使用for表达式）
- 生命周期转换：集合（使用for表达式）
- IAM策略语句：集合（使用for表达式）
如需详细测试指南，请参考：
- 测试框架指南 - 深入讲解静态分析、原生测试及Terratest
- 速查表 - 决策流程图与命令参考
Code Structure Standards
代码结构标准
Resource Block Ordering
资源块排序
Strict ordering for consistency:
- or FIRST (blank line after)
- Other arguments
- as last real argument
- after tags (if needed)
- at the very end (if needed)
为保持一致性，严格遵循以下顺序：
- 或 放在最前（后接空行）
- 其他参数
- 作为最后一个业务参数
- 放在tags之后（如需）
- 放在最后（如需）
✅ GOOD - Correct ordering
✅ 推荐 - 正确排序
resource "aws_nat_gateway" "this" {
count = var.create_nat_gateway ? 1 : 0
allocation_id = aws_eip.this[0].id
subnet_id = aws_subnet.public[0].id
tags = {
Name = "${var.name}-nat"
}
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
}
resource "aws_nat_gateway" "this" {
count = var.create_nat_gateway ? 1 : 0
allocation_id = aws_eip.this[0].id
subnet_id = aws_subnet.public[0].id
tags = {
Name = "${var.name}-nat"
}
depends_on = [aws_internet_gateway.this]
lifecycle {
create_before_destroy = true
}
}
Variable Block Ordering
变量块排序
- (ALWAYS required)
- (when setting to false)
hcl
variable "environment" {
description = "Environment name for resource tagging"
type = string
default = "dev"
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "Environment must be one of: dev, staging, prod."
}
nullable = false
}
For complete structure guidelines, see: Code Patterns: Block Ordering & Structure
- （必填）
- （设为false时）
hcl
variable "environment" {
description = "资源标记用的环境名称"
type = string
default = "dev"
validation {
condition = contains(["dev", "staging", "prod"], var.environment)
error_message = "环境必须是以下值之一：dev、staging、prod。"
}
nullable = false
}
如需完整结构指南，请参考：代码模式：块排序与结构
Count vs For_Each: When to Use Each
Count vs For_Each：场景选型
Quick Decision Guide
快速决策指南
| Scenario | Use | Why |
|---|
| Boolean condition (create or don't) | count = condition ? 1 : 0
| Simple on/off toggle |
| Simple numeric replication | | Fixed number of identical resources |
| Items may be reordered/removed | | Stable resource addresses |
| Reference by key | | Named access to resources |
| Multiple named resources | | Better maintainability |
| 场景 | 使用 | 原因 |
|---|
| 布尔条件（创建或不创建） | count = condition ? 1 : 0
| 简单的开关控制 |
| 简单数值复制 | | 固定数量的相同资源 |
| 项可能被重排/移除 | | 稳定的资源地址 |
| 按键引用 | | 命名式资源访问 |
| 多个命名资源 | | 可维护性更佳 |
✅ GOOD - Boolean condition
✅ 推荐 - 布尔条件
resource "aws_nat_gateway" "this" {
count = var.create_nat_gateway ? 1 : 0
...
}
**Stable addressing with for_each:**
```hcl
resource "aws_nat_gateway" "this" {
count = var.create_nat_gateway ? 1 : 0
...
}
**使用for_each实现稳定寻址：**
```hcl
✅ GOOD - Removing "us-east-1b" only affects that subnet
✅ 推荐 - 移除"us-east-1b"仅影响该子网
resource "aws_subnet" "private" {
for_each = toset(var.availability_zones)
availability_zone = each.key
...
}
resource "aws_subnet" "private" {
for_each = toset(var.availability_zones)
availability_zone = each.key
...
}
❌ BAD - Removing middle AZ recreates all subsequent subnets
❌ 不推荐 - 移除中间可用区会重建所有后续子网
resource "aws_subnet" "private" {
count = length(var.availability_zones)
availability_zone = var.availability_zones[count.index]
...
}
**For migration guides and detailed examples, see:** Code Patterns: Count vs For_Each
resource "aws_subnet" "private" {
count = length(var.availability_zones)
availability_zone = var.availability_zones[count.index]
...
}
**如需迁移指南及详细示例，请参考：代码模式：Count vs For_Each**
Locals for Dependency Management
使用Locals管理依赖
Use locals to ensure correct resource deletion order:
Problem: Subnets might be deleted after CIDR blocks, causing errors
问题：子网可能在CIDR块之后被删除，导致错误
Solution: Use try() in locals to hint deletion order
解决方案：在locals中使用try()提示删除顺序
locals {
References secondary CIDR first, falling back to VPC
Forces Terraform to delete subnets before CIDR association
vpc_id = try(
aws_vpc_ipv4_cidr_block_association.this[0].vpc_id,
aws_vpc.this.id,
""
)
}
resource "aws_vpc" "this" {
cidr_block = "10.0.0.0/16"
}
resource "aws_vpc_ipv4_cidr_block_association" "this" {
count = var.add_secondary_cidr ? 1 : 0
vpc_id = aws_vpc.this.id
cidr_block = "10.1.0.0/16"
}
resource "aws_subnet" "public" {
vpc_id = local.vpc_id # Uses local, not direct reference
cidr_block = "10.1.0.0/24"
}
**Why this matters:**
- Prevents deletion errors when destroying infrastructure
- Ensures correct dependency order without explicit `depends_on`
- Particularly useful for VPC configurations with secondary CIDR blocks
**For detailed examples, see:** Code Patterns: Locals for Dependency Management
locals {
优先引用二级CIDR， fallback到VPC
强制Terraform先删除子网再删除CIDR关联
vpc_id = try(
aws_vpc_ipv4_cidr_block_association.this[0].vpc_id,
aws_vpc.this.id,
""
)
}
resource "aws_vpc" "this" {
cidr_block = "10.0.0.0/16"
}
resource "aws_vpc_ipv4_cidr_block_association" "this" {
count = var.add_secondary_cidr ? 1 : 0
vpc_id = aws_vpc.this.id
cidr_block = "10.1.0.0/16"
}
resource "aws_subnet" "public" {
vpc_id = local.vpc_id # 使用local而非直接引用
cidr_block = "10.1.0.0/24"
}
**重要性：**
- 销毁基础设施时避免删除错误
- 无需显式`depends_on`即可确保正确的依赖顺序
- 在带二级CIDR块的VPC配置中尤为实用
**如需详细示例，请参考：代码模式：Locals依赖管理**
Standard Module Structure
标准模块结构
my-module/
├── README.md # Usage documentation
├── main.tf # Primary resources
├── variables.tf # Input variables with descriptions
├── outputs.tf # Output values
├── versions.tf # Provider version constraints
├── examples/
│ ├── minimal/ # Minimal working example
│ └── complete/ # Full-featured example
└── tests/ # Test files
└── module_test.tftest.hcl # Or .go
my-module/
├── README.md # 使用文档
├── main.tf # 核心资源定义
├── variables.tf # 带描述的输入变量
├── outputs.tf # 输出值
├── versions.tf # 提供商版本约束
├── examples/
│ ├── minimal/ # 最简可用示例
│ └── complete/ # 全功能示例
└── tests/ # 测试文件
└── module_test.tftest.hcl # 或.go文件
Best Practices Summary
最佳实践总结
Variables:
- ✅ Always include
- ✅ Use explicit constraints
- ✅ Provide sensible values where appropriate
- ✅ Add blocks for complex constraints
- ✅ Use for secrets
Outputs:
- ✅ Always include
- ✅ Mark sensitive outputs with
- ✅ Consider returning objects for related values
- ✅ Document what consumers should do with each output
For detailed module patterns, see:
- Module Patterns Guide - Variable best practices, output design, ✅ DO vs ❌ DON'T patterns
- Quick Reference - Resource naming, variable naming, file organization
变量：
- ✅ 始终包含
- ✅ 使用显式约束
- ✅ 合理场景下提供值
- ✅ 为复杂约束添加块
- ✅ 敏感信息使用
输出：
- ✅ 始终包含
- ✅ 敏感输出标记
- ✅ 考虑返回关联值的对象
- ✅ 文档说明消费者如何使用每个输出
如需详细模块模式，请参考：
- 模块模式指南 - 变量最佳实践、输出设计、✅ 推荐 vs ❌ 不推荐模式
- 速查表 - 资源命名、变量命名、文件组织
Recommended Workflow Stages
推荐工作流阶段
- Validate - Format check + syntax validation + linting
- Test - Run automated tests (native or Terratest)
- Plan - Generate and review execution plan
- Apply - Execute changes (with approvals for production)
- 验证 - 格式检查+语法验证+代码检查
- 测试 - 运行自动化测试（原生或Terratest）
- 规划 - 生成并评审执行计划
- 应用 - 执行变更（生产环境需审批）
Cost Optimization Strategy
成本优化策略
- Use mocking for PR validation (free)
- Run integration tests only on main branch (controlled cost)
- Implement auto-cleanup (prevent orphaned resources)
- Tag all test resources (track spending)
For complete CI/CD templates, see:
- CI/CD Workflows Guide - GitHub Actions, GitLab CI, Atlantis integration, cost optimization
- Quick Reference - Common CI/CD issues and solutions
- PR验证使用模拟（免费）
- 仅在主分支运行集成测试（可控成本）
- 实现自动清理（防止资源孤儿）
- 为所有测试资源打标签（追踪支出）
如需完整CI/CD模板，请参考：
- CI/CD工作流指南 - GitHub Actions、GitLab CI、Atlantis集成、成本优化
- 速查表 - 常见CI/CD问题与解决方案
Security & Compliance
安全与合规
Essential Security Checks
核心安全检查
Static security scanning
静态安全扫描
trivy config .
checkov -d .
trivy config .
checkov -d .
Common Issues to Avoid
需避免的常见问题
❌ Don't:
- Store secrets in variables
- Use default VPC
- Skip encryption
- Open security groups to 0.0.0.0/0
✅ Do:
- Use AWS Secrets Manager / Parameter Store
- Create dedicated VPCs
- Enable encryption at rest
- Use least-privilege security groups
For detailed security guidance, see:
- Security & Compliance Guide - Trivy/Checkov integration, secrets management, state file security, compliance testing
❌ 禁止：
- 变量中存储密钥
- 使用默认VPC
- 跳过加密
- 安全组开放至0.0.0.0/0
✅ 推荐：
- 使用AWS Secrets Manager/Parameter Store
- 创建专属VPC
- 启用静态加密
- 使用最小权限安全组
如需详细安全指南，请参考：
- 安全与合规指南 - Trivy/Checkov集成、密钥管理、状态文件安全、合规测试
Version Constraint Syntax
版本约束语法
hcl
version = "5.0.0" # Exact (avoid - inflexible)
version = "~> 5.0" # Recommended: 5.0.x only
version = ">= 5.0" # Minimum (risky - breaking changes)
hcl
version = "5.0.0" # 精确版本（不推荐 - 灵活性差）
version = "~> 5.0" # 推荐：仅5.0.x版本
version = ">= 5.0" # 最低版本（有风险 - 可能包含破坏性变更）
Strategy by Component
组件版本策略
| Component | Strategy | Example |
|---|
| Terraform | Pin minor version | required_version = "~> 1.9"
|
| Providers | Pin major version | |
| Modules (prod) | Pin exact version | |
| Modules (dev) | Allow patch updates | |
| 组件 | 策略 | 示例 |
|---|
| Terraform | 锁定次要版本 | required_version = "~> 1.9"
|
| Providers | 锁定主版本 | |
| 模块（生产） | 锁定精确版本 | |
| 模块（开发） | 允许补丁更新 | |
Lock versions initially
初始锁定版本
terraform init # Creates .terraform.lock.hcl
terraform init # 创建.terraform.lock.hcl
Update to latest within constraints
在约束内更新至最新版本
terraform init -upgrade # Updates providers
terraform init -upgrade # 更新提供商
terraform plan
**For detailed version management, see:** Code Patterns: Version Management
terraform plan
**如需详细版本管理，请参考：代码模式：版本管理**
Modern Terraform Features (1.0+)
现代Terraform特性（1.0+）
Feature Availability by Version
特性版本支持
| Feature | Version | Use Case |
|---|
| function | 0.13+ | Safe fallbacks, replaces |
| 1.1+ | Prevent null values in variables |
| blocks | 1.1+ | Refactor without destroy/recreate |
| with defaults | 1.3+ | Optional object attributes |
| Native testing | 1.6+ | Built-in test framework |
| Mock providers | 1.7+ | Cost-free unit testing |
| Provider functions | 1.8+ | Provider-specific data transformation |
| Cross-variable validation | 1.9+ | Validate relationships between variables |
| Write-only arguments | 1.11+ | Secrets never stored in state |
| 特性 | 版本 | 适用场景 |
|---|
| 函数 | 0.13+ | 安全降级，替代 |
| 1.1+ | 防止变量出现null值 |
| 块 | 1.1+ | 重构时避免销毁/重建资源 |
| 带默认值 | 1.3+ | 可选对象属性 |
| 原生测试 | 1.6+ | 内置测试框架 |
| 模拟提供商 | 1.7+ | 免费单元测试 |
| 提供商函数 | 1.8+ | 提供商专属数据转换 |
| 跨变量验证 | 1.9+ | 验证变量间的关联关系 |
| 只写参数 | 1.11+ | 密钥永不存储在状态文件中 |
try() - Safe fallbacks (0.13+)
try() - 安全降级（0.13+）
output "sg_id" {
value = try(aws_security_group.this[0].id, "")
}
output "sg_id" {
value = try(aws_security_group.this[0].id, "")
}
optional() - Optional attributes with defaults (1.3+)
optional() - 带默认值的可选属性（1.3+）
variable "config" {
type = object({
name = string
timeout = optional(number, 300) # Default: 300
})
}
variable "config" {
type = object({
name = string
timeout = optional(number, 300) # 默认值：300
})
}
Cross-variable validation (1.9+)
跨变量验证（1.9+）
variable "environment" { type = string }
variable "backup_days" {
type = number
validation {
condition = var.environment == "prod" ? var.backup_days >= 7 : true
error_message = "Production requires backup_days >= 7"
}
}
**For complete patterns and examples, see:** Code Patterns: Modern Terraform Features
variable "environment" { type = string }
variable "backup_days" {
type = number
validation {
condition = var.environment == "prod" ? var.backup_days >= 7 : true
error_message = "生产环境要求backup_days >= 7"
}
}
**如需完整模式与示例，请参考：代码模式：现代Terraform特性**
Version-Specific Guidance
版本专属指南
Terraform 1.0-1.5
Terraform 1.0-1.5
- Use Terratest for testing
- No native testing framework available
- Focus on static analysis and plan validation
- 使用Terratest进行测试
- 无原生测试框架
- 聚焦静态分析与计划验证
Terraform 1.6+ / OpenTofu 1.6+
Terraform 1.6+ / OpenTofu 1.6+
- New: Native / command
- Consider migrating from external frameworks for simple tests
- Keep Terratest only for complex integration tests
- 新增： 原生/命令
- 简单测试可考虑从外部框架迁移
- 复杂集成测试仍保留Terratest
Terraform 1.7+ / OpenTofu 1.7+
Terraform 1.7+ / OpenTofu 1.7+
- New: Mock providers for unit testing
- Reduce cost by mocking external dependencies
- Use real integration tests for final validation
- 新增： 单元测试用模拟提供商
- 通过模拟外部依赖降低成本
- 最终验证使用真实集成测试
Terraform vs OpenTofu
Terraform vs OpenTofu
Both are fully supported by this skill. For licensing, governance, and feature comparison, see Quick Reference: Terraform vs OpenTofu.
本技能包完全支持两者。如需许可、治理及功能对比，请参考速查表：Terraform vs OpenTofu。
This skill uses progressive disclosure - essential information is in this main file, detailed guides are available when needed:
📚 Reference Files:
- Testing Frameworks - In-depth guide to static analysis, native tests, and Terratest
- Module Patterns - Module structure, variable/output best practices, ✅ DO vs ❌ DON'T patterns
- CI/CD Workflows - GitHub Actions, GitLab CI templates, cost optimization, automated cleanup
- Security & Compliance - Trivy/Checkov integration, secrets management, compliance testing
- Quick Reference - Command cheat sheets, decision flowcharts, troubleshooting guide
How to use: When you need detailed information on a topic, reference the appropriate guide. Claude will load it on demand to provide comprehensive guidance.
本技能包采用渐进式披露 - 核心信息在主文件中，详细指南按需提供：
📚 参考文件：
- 测试框架 - 深入讲解静态分析、原生测试及Terratest
- 模块模式 - 模块结构、变量/输出最佳实践、✅ 推荐 vs ❌ 不推荐模式
- CI/CD工作流 - GitHub Actions、GitLab CI模板、成本优化、自动清理
- 安全与合规 - Trivy/Checkov集成、密钥管理、合规测试
- 速查表 - 命令 cheat sheet、决策流程图、故障排查指南
使用方式： 当需要某主题的详细信息时，参考对应指南。Claude会按需加载并提供全面指导。
This skill is licensed under the Apache License 2.0. See the LICENSE file for full terms.
Copyright © 2026 Anton Babenko
本技能包基于Apache License 2.0许可。详见LICENSE文件。
版权所有 © 2026 Anton Babenko