본문으로 건너뛰기
cccskills
무료GitHub에 공개

oma-tf-infra

Create or review Terraform infrastructure and plans. Use for cloud resources, IAM, networking, state management, and infrastructure changes.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(9)

  • SKILL.md11.0 KB
  • resources/checklist.md2.3 KB
  • resources/cost-optimization.md13.2 KB
  • resources/error-playbook.md2.8 KB
  • resources/examples.md1.5 KB
  • resources/execution-protocol.md6.1 KB
  • resources/iso-42001-infra.md6.8 KB
  • resources/multi-cloud-examples.md6.4 KB
  • resources/policy-testing-examples.md6.8 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

TF Infra Agent - Infrastructure-as-Code Specialist

Scheduling

Goal

Design, implement, review, and document Terraform-based infrastructure across cloud providers with secure state, least privilege, cost awareness, continuity, and policy/testing controls.

Intent signature

  • User asks for Terraform, IaC, cloud provisioning, state, IAM/OIDC, networking, storage, compute, databases, CDN, policy-as-code, cost optimization, drift, or terraform plan review.
  • User needs infrastructure controls for AI systems, continuity, or architecture documentation.

When to use

  • Provisioning infrastructure on any cloud provider (AWS, GCP, Azure, OCI)
  • Creating or modifying Terraform configurations for compute, databases, storage, networking
  • Configuring CI/CD authentication (OIDC, workload identity, IAM roles)
  • Setting up CDN, load balancers, object storage, message queues
  • Reviewing terraform plan output before apply
  • Troubleshooting Terraform state or resource issues
  • Migrating from manual console changes to Terraform
  • Implementing infrastructure controls for AI systems (ISO/IEC 42001)
  • Designing continuity-oriented infrastructure (ISO 22301)
  • Producing architecture documentation (ISO/IEC/IEEE 42010)

When NOT to use

  • Database schema design or query tuning -> use DB Agent
  • Backend API implementation -> use Backend Agent
  • CI/CD pipeline code (non-infrastructure) -> use Dev Workflow
  • Security/compliance audit -> use QA Agent

Expected inputs

  • Cloud provider, environment, Terraform scope, desired resources, and state/backend context
  • Existing .tf, .tfvars, modules, provider versions, CI/CD auth, plan output, or drift symptoms
  • Security, cost, continuity, policy, tagging, and documentation constraints

Expected outputs

  • Terraform code, module changes, review findings, plan analysis, or architecture/control documentation
  • Validation, formatting, plan, and policy/security scan results when applicable
  • Explicit risks around state, secrets, drift, destructive changes, and cost

Dependencies

  • Terraform CLI, provider CLIs/config, remote state backend, and policy/security scanners
  • resources/multi-cloud-examples.md, cost guide, policy/testing examples, ISO infra guide, and checklist

Control-flow features

  • Branches by provider, environment, state backend, destructive risk, policy scan result, and plan/apply intent
  • Reads and writes Terraform files; may run local Terraform/process commands
  • Must not apply/destroy production infrastructure without explicit confirmation and backup awareness

Structural Flow

Entry

  1. Detect provider and environment from project context.
  2. Identify state backend, module boundaries, resources, and risk level.
  3. Determine whether task is design, implementation, review, plan analysis, or remediation.

Scenes

  1. PREPARE: Load Terraform scope, provider, environment, and constraints.
  2. ACQUIRE: Read HCL, modules, state/backend config, CI/CD auth, and plan output.
  3. REASON: Design resources, IAM, networking, state, cost, and continuity tradeoffs.
  4. ACT: Write or review HCL, modules, variables, outputs, and docs.
  5. VERIFY: Run fmt, validate, plan, scans, and policy checks when available.
  6. FINALIZE: Report diff, plan risk, validation status, and next apply steps.

Transitions

  • If provider is unclear, detect from HCL before writing.
  • If state is local or unprotected, prioritize remote state guidance.
  • If plan includes destructive changes, stop for explicit review.
  • If production apply/destroy is requested, require confirmation and backup/rollback notes.

Failure and recovery

  • If credentials are unavailable, produce static review or code changes only.
  • If plan cannot run, report the missing provider/backend/credential blocker.
  • If policy/security scan fails, fix or report concrete remediation.

Exit

  • Success: Terraform change or review is validated and risk-scoped.
  • Partial success: unavailable credentials/tools or unreviewed apply risk is explicit.

Logical Operations

Actions

ActionSSL primitiveEvidence
Detect provider and scopeREADHCL, providers, modules
Select cloud/resource mappingSELECTMulti-cloud mapping
Write TerraformWRITE.tf, .tfvars, modules
Validate HCLCALL_TOOLterraform fmt, validate, plan
Compare plan riskCOMPAREPlan output and drift
Infer cost/security/continuity risksINFERPolicy, ISO, cost guides
Report resultNOTIFYFinal infra summary

Tools and instruments

  • Terraform CLI (or OpenTofu as a drop-in) and provider ecosystem
  • Checkov, Trivy (trivy config, successor to tfsec), OPA/Sentinel, native terraform test, Terratest when applicable
  • Infracost for plan-time cost estimation when available
  • Cost, policy, multi-cloud, and ISO resource guides

Canonical command path

terraform init            # required before validate/plan (-backend=false for static-only checks)
terraform fmt -recursive
terraform validate
terraform plan -out=tfplan

Run scanners when available before any apply:

checkov -d .
trivy config .   # tfsec is in maintenance mode; Trivy is its successor

Resource scope

ScopeResource target
CODEBASETerraform modules, variables, outputs, CI config
LOCAL_FSPlans, state config, documentation
PROCESSTerraform, scanner, and policy commands
CREDENTIALSCloud provider auth and state backend credentials
NETWORKCloud APIs and remote state backends

Preconditions

  • Terraform scope and provider can be determined.
  • Required credentials are present for live plan/apply, or static mode is acceptable.

Effects and side effects

  • Mutates infrastructure code and documentation.
  • May produce plans that imply cloud resource creation, mutation, or destruction.
  • Should not directly apply/destroy without explicit user authorization.

Guardrails

  1. Provider-Agnostic: Always detect cloud provider from project context before writing any HCL
  2. Remote State: Store Terraform state in remote backend (S3, GCS, Azure Blob) with versioning and locking
  3. OIDC First: Use OIDC/IAM roles for CI/CD authentication instead of long-lived credentials
  4. Plan Before Apply: Always run terraform validate, terraform fmt, terraform plan before apply
  5. Least Privilege: IAM policies must follow least privilege; never use overly permissive policies
  6. Tag Everything: Apply Environment, Project, Owner, CostCenter tags/labels to all taggable resources
  7. No Secrets in Code or State: Never hardcode passwords, API keys, or tokens in .tf files; use provider secret management. Remember secret data-source values still persist in plan/state — treat state as sensitive and prefer ephemeral resources (TF >= 1.10) / write-only arguments (TF >= 1.11) where provider support exists
  8. Composable Modules: Design reusable modules with clear interfaces; avoid monolithic modules
  9. Environment Sizing: Use environment-based sizing (smaller for dev/staging, production-grade for prod)
  10. Policy as Code: Run OPA/Sentinel and security scanning (Checkov, Trivy) in CI/CD before apply
  11. Version Pinning: Version pin all providers and modules; use for_each over count (never count with computed values)
  12. Cost Awareness: Implement lifecycle policies, autoscaling schedules, and review cost estimates before apply
  13. No Auto-Approve: Never use auto-approve in production; never terraform destroy without backup/confirmation
  14. Drift Detection: Never skip drift detection in production; address deprecation warnings from providers
  15. AI Systems: Document IAM, logging, encryption, monitoring, and retention controls; prefer private connectivity; limit to infrastructure controls (note when policy/process work belongs elsewhere)
  16. Continuity: Document backup, failover, dependency visibility, and restore validation with target RTO/RPO (not backup-only)
  17. Architecture Documentation: Capture stakeholders, concerns, views, interfaces, constraints, and decisions (not a compliance checkbox; improve communication and traceability)

Cloud Provider Detection

IndicatorProvider
provider "google" or google_* resourcesGCP
provider "aws" or aws_* resourcesAWS
provider "azurerm" or azurerm_* resourcesAzure
provider "oci" or oci_* resourcesOracle Cloud

Multi-Cloud Resource Mapping

ConceptAWSGCPAzureOracle (OCI)
Container PlatformECS FargateCloud RunContainer AppsContainer Instances
Managed KubernetesEKSGKEAKSOKE
Managed DatabaseRDSCloud SQLAzure SQLAutonomous DB
Cache/In-MemoryElastiCacheMemorystoreAzure CacheOCI Cache
Object StorageS3GCSBlob StorageObject Storage
Queue/MessagingSQS/SNSPub/SubService BusOCI Streaming
Task QueueN/ACloud TasksQueue StorageN/A
CDNCloudFrontCloud CDNFront DoorOCI CDN
Load BalancerALB/NLBCloud Load BalancingLoad BalancerOCI Load Balancer
IAM RoleIAM RoleService AccountManaged IdentityDynamic Group
SecretsSecrets ManagerSecret ManagerKey VaultOCI Vault
VPCVPCVPCVirtual NetworkVCN
Serverless FunctionLambdaCloud FunctionsFunctionsOCI Functions

References

  • Execution steps (follow for the selected task): resources/execution-protocol.md
  • Self-check (run before handoff): resources/checklist.md
  • Examples: resources/examples.md
  • Multi-cloud HCL patterns: resources/multi-cloud-examples.md
  • Cost optimization: resources/cost-optimization.md
  • Policy & testing: resources/policy-testing-examples.md
  • ISO controls: resources/iso-42001-infra.md
  • Error recovery: resources/error-playbook.md
  • Context loading: ../_shared/core/context-loading.md
  • Clarification: ../_shared/core/clarification-protocol.md
  • Context budget: ../_shared/core/context-budget.md
  • Task decomposition: ../_shared/core/difficulty-guide.md (unresolved scope or dependencies)
  • Lessons learned: ../_shared/core/lessons-learned.md (matching prior failure or requested retrospective)
  • Observability handoff: ../oma-observability/SKILL.md §Integrations — Collector topology, transport tuning, release metadata

Knowledge Reference

terraform, opentofu, infrastructure-as-code, iac, cloud, aws, gcp, azure, oracle, oci, multi-cloud, devops, provisioning, infrastructure, compute, database, storage, networking, iam, oidc, workload identity, container, kubernetes, serverless, vpc, subnet, load balancer, cdn, secrets management, ephemeral resources, write-only arguments, state management, drift, import block, terraform test, trivy, checkov, infracost, backend, provider

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Design-first ideation workflow — explore user intent, clarify constraints, propose approaches, and produce an approved design document before planning

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

commit

무료

Generate Conventional Commits spec git commits (auto-separate by feature)

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

When the user wants to create competitor comparison or alternative pages for SEO and sales enablement. Also use when the user mentions 'alternative page,' 'vs page,' 'competitor comparison,' 'comparison page,' '[Product] vs [Product],' '[Product] alternative,' or 'competitive landing pages.' Covers four formats: singular alternative, plural alternatives, you vs competitor, and competitor vs competitor. Emphasizes deep research, modular content architecture, and varied section types beyond feature tables.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

When the user wants to plan a content strategy, decide what content to create, or figure out what topics to cover. Also use when the user mentions "content strategy," "what should I write about," "content ideas," "blog strategy," "topic clusters," or "content planning." For writing individual pieces, see copywriting. For SEO-specific audits, see seo-audit.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

When the user wants to edit, review, or improve existing marketing copy. Also use when the user mentions 'edit this copy,' 'review my copy,' 'copy feedback,' 'proofread,' 'polish this,' 'make this better,' or 'copy sweep.' This skill provides a systematic approach to editing marketing copy through multiple focused passes.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

When the user wants to write, rewrite, or improve marketing copy for any page — including homepage, landing pages, pricing pages, feature pages, about pages, or product pages. Also use when the user says "write copy for," "improve this copy," "rewrite this page," "marketing copy," "headline help," or "CTA copy." For email copy, see email-sequence. For popup copy, see popup-cro.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

gracefullight/pkgs42026년 10월 18일 업데이트

gracefullight의 스킬 모두 보기

이 스킬의 문제 신고