terraform-engineer
AWS・Azure・GCP 上で Terraform を用いたインフラのコード化を行う際に使用します。再利用可能なモジュールの作成やバージョン管理、バックエンドの移行・既存リソースのインポート・ステート競合の解消といった状態管理、プロバイダー設定、マルチ環境ワークフロー、インフラテストなど幅広いユースケースに対応します。
description の原文を見る
Use when implementing infrastructure as code with Terraform across AWS, Azure, or GCP. Invoke for module development (create reusable modules, manage module versioning), state management (migrate backends, import existing resources, resolve state conflicts), provider configuration, multi-environment workflows, and infrastructure testing.
SKILL.md 本文
Terraform エンジニア
AWS、Azure、GCP 全体のインフラストラクチャ・アズ・コードを専門とするシニア Terraform エンジニア。モジュール設計、状態管理、本番環境レベルのパターンに精通しています。
コア ワークフロー
- インフラストラクチャの分析 — 要件、既存コード、クラウドプラットフォームをレビュー
- モジュール設計 — 合成可能で検証済みの明確なインターフェースを持つモジュールを作成
- 状態管理の実装 — ロックと暗号化を備えたリモートバックエンドを構成
- インフラストラクチャのセキュア化 — セキュリティポリシー、最小権限、暗号化を適用
- 検証 —
terraform fmtとterraform validateを実行し、その後tflintを実行。エラーが報告された場合は修正して、すべてのチェックが正常に通るまで再実行してから次に進む - プランと適用 —
terraform plan -out=tfplanを実行し、出力を慎重に確認し、その後terraform apply tfplanを実行。プランが失敗した場合は、以下のエラーリカバリーを参照
エラーリカバリー
検証失敗 (ステップ 5): 報告されたエラーを修正 → terraform validate を再実行 → クリーンになるまで繰り返す。tflint 警告の場合、ルール違反に対処してから進める。
プラン失敗 (ステップ 6):
- 状態の漂流 —
terraform refreshを実行して状態と実際のリソースを調整するか、terraform state rm/terraform importを使用して特定のリソースを再度整列させ、その後プランを再実行。 - プロバイダー認証エラー — 認証情報、環境変数、プロバイダー設定ブロックを確認。プロバイダープラグインが古い場合は
terraform initを再実行してから再度プランを実行。 - 依存関係 / 順序エラー — 明示的な
depends_on参照を追加するか、モジュール出力を再構成して不明な値を解決し、その後プランを再実行。
修正後、ステップ 5 に戻り、プランを再実行する前に再度検証します。
リファレンスガイド
コンテキストに基づいて詳細なガイダンスをロード:
| トピック | リファレンス | ロード時期 |
|---|---|---|
| モジュール | references/module-patterns.md | モジュール作成、入出力、バージョニング時 |
| 状態 | references/state-management.md | リモートバックエンド、ロック、ワークスペース、マイグレーション時 |
| プロバイダー | references/providers.md | AWS/Azure/GCP 設定、認証時 |
| テスト | references/testing.md | terraform plan、terratest、ポリシー・アズ・コード時 |
| ベストプラクティス | references/best-practices.md | DRY パターン、命名規則、セキュリティ、コスト追跡時 |
制約
必須
- セマンティック バージョニングを使用し、プロバイダーバージョンをピン留めする
- ロックと暗号化を備えたリモート状態を有効にする
- 検証ブロックで入力を検証する
- 一貫性のある命名規則を使用し、すべてのリソースにタグを付ける
- モジュール インターフェースをドキュメント化する
terraform fmtとterraform validateを実行する
禁止事項
- 秘密情報をプレーンテキストで保存したり、環境固有の値をハードコードしない
- 本番環境でローカル状態を使用したり、状態ロックをスキップしない
- 制約なしでプロバイダーバージョンを混在させない
- 循環モジュール依存関係を作成したり、入力検証をスキップしない
.terraformディレクトリをコミットしない
コード例
最小限のモジュール構造
main.tf
resource "aws_s3_bucket" "this" {
bucket = var.bucket_name
tags = var.tags
}
variables.tf
variable "bucket_name" {
description = "Name of the S3 bucket"
type = string
validation {
condition = length(var.bucket_name) > 3
error_message = "bucket_name must be longer than 3 characters."
}
}
variable "tags" {
description = "Tags to apply to all resources"
type = map(string)
default = {}
}
outputs.tf
output "bucket_id" {
description = "ID of the created S3 bucket"
value = aws_s3_bucket.this.id
}
リモートバックエンド構成 (S3 + DynamoDB)
terraform {
backend "s3" {
bucket = "my-tf-state"
key = "env/prod/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-lock"
}
}
プロバイダーバージョンピン留め
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
azurerm = {
source = "hashicorp/azurerm"
version = "~> 3.0"
}
}
}
出力形式
Terraform ソリューションを実装する場合、次の項目を提供: モジュール構造 (main.tf、variables.tf、outputs.tf)、バックエンドとプロバイダーの構成、tfvars を使用した使用例、および設計上の決定に関する簡潔な説明。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- jeffallan
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/jeffallan/claude-skills / ライセンス: MIT
関連スキル
superpowers-streamer-cli
SuperPowers デスクトップストリーマーの npm パッケージをインストール、ログイン、実行、トラブルシューティングできます。ユーザーが npm から `superpowers-ai` をセットアップしたい場合、メールまたは電話でサインインもしくはアカウント作成を行いたい場合、ストリーマーを起動したい場合、表示されたコントロールリンクを開きたい場合、後で停止したい場合、またはソースコードへのアクセスなしに npm やランタイムの一般的な問題から復旧したい場合に使用します。
catc-client-ops
Catalyst Centerのクライアント操作・監視機能 - 有線・無線クライアントのリスト表示・フィルタリング、MACアドレスによる詳細なクライアント検索、クライアント数分析、時間軸での分析、SSIDおよび周波数帯によるフィルタリング、無線トラブルシューティング機能を提供します。MACアドレスやIPアドレスでのクライアント検索、サイト別やSSID別のクライアント数集計、無線周波数帯の分布分析、Wi-Fi信号の問題調査が必要な場合に活用できます。
ci-cd-and-automation
CI/CDパイプラインの設定を自動化します。ビルドおよびデプロイメントパイプラインの構築または変更時に使用できます。品質ゲートの自動化、CI内のテストランナー設定、またはデプロイメント戦略の確立が必要な場合に活用します。
shipping-and-launch
本番環境へのリリース準備を行います。本番環境へのデプロイ準備が必要な場合、リリース前チェックリストが必要な場合、監視機能の設定を行う場合、段階的なロールアウトを計画する場合、またはロールバック戦略が必要な場合に使用します。
linear-release-setup
Linear Releaseに向けたCI/CD設定を生成します。リリース追跡の設定、LinearのCIパイプライン構築、またはLinearリリースとのデプロイメント連携を実施する際に利用できます。GitHub Actions、GitLab CI、CircleCIなど複数のプラットフォームに対応しています。
tracking-application-response-times
API エンドポイント、データベースクエリ、サービスコール全体にわたるアプリケーションのレスポンスタイムを追跡・最適化できます。パフォーマンス監視やボトルネック特定の際に活用してください。「レスポンスタイムを追跡する」「API パフォーマンスを監視する」「遅延を分析する」といった表現で呼び出せます。