TSH Platform Engineering
tsh-platform-engineering is the discipline plugin for infrastructure, CI/CD and deployment: Terraform modules, pipelines with OIDC and plan gates, production-shaped Kubernetes workloads, observability with SLOs, secrets management, and evidence-based cloud cost audits.
It is the cloud-agnostic half of TSH's infrastructure guidance. Everything specific to one cloud lives in that cloud's own plugin (see Pairs with a cloud plugin).
Who installs it
A discipline plugin travels with you, so install it at user scope. Install the repository's cloud plugin at project scope. The install commands and the scope table are on the Installation page.
What it ships
| Skill | Invoke | What it does |
|---|---|---|
| deploying-to-kubernetes | /tsh-platform-engineering:deploying-to-kubernetes | Configures Kubernetes workloads to a production standard: choosing between Deployment, StatefulSet, DaemonSet and Job, resource requests and limits and the QoS class they produce, readiness/liveness/startup probes, PodDisruptionBudgets and anti-affinity, HPA/KEDA/VPA scaling, Helm chart and Kustomize overlay structure, ingress, and non-root security contexts. Use when deploying an application to a cluster, writing or reviewing manifests or charts, or adding scaling and resilience to an existing workload. |
| designing-multi-cloud-architecture | /tsh-platform-engineering:designing-multi-cloud-architecture | Selects cloud services and a multi-cloud topology using an explicit decision framework: which of the six multi-cloud patterns fits the actual driver, how AWS, Azure and GCP services map onto each other, where a cloud-agnostic abstraction pays for itself and where it costs more than lock-in, and how to phase a migration. Use when choosing cloud services for a workload, planning a cross-cloud or DR topology, or evaluating a move between providers. |
| implementing-ci-cd-pipelines | /tsh-platform-engineering:implementing-ci-cd-pipelines | Designs and implements CI/CD pipelines on GitHub Actions, GitLab CI, Bitbucket Pipelines, Azure Pipelines or Jenkins: stage structure and caching, deployment strategy (rolling, blue-green, canary), OIDC federation for cloud credentials instead of stored keys, monorepo affected-only builds, and the plan-artifact and approval gates an infrastructure-as-code pipeline requires. Use when creating or changing a pipeline, wiring deployment or cloud authentication, or reviewing pipeline changes. |
| implementing-observability | /tsh-platform-engineering:implementing-observability | Implements metrics, logs, traces and alerting to a standard that supports an on-call rotation: choosing a stack (Prometheus/Grafana, Loki, Tempo or Jaeger, CloudWatch, Datadog, OpenTelemetry), RED and USE metrics, SLOs with error budgets, alerts that fire on user-visible symptoms and link to runbooks, and structured logging with trace correlation. Use when adding monitoring to a service, defining SLOs, writing alert rules, or fixing an alerting setup that pages too often. |
| implementing-terraform-modules | /tsh-platform-engineering:implementing-terraform-modules | Writes and reviews reusable Terraform modules for AWS, Azure and GCP — the module interface that outlives the resources inside it: the standard file layout, input-variable validation, outputs, provider pinning, remote state with locking, the Terraform-versus-Terragrunt decision, and Terratest coverage. Use when authoring a module that more than one caller or service will instantiate with its own inputs, standardizing provisioning across environments, or reviewing a Terraform pull request — this is the module-structure layer, loaded alongside the cloud provider's own resource patterns, not instead of them. |
| managing-secrets | /tsh-platform-engineering:managing-secrets | Chooses and implements a secrets management approach for cloud and Kubernetes workloads: cloud-native secret stores versus Vault versus Sealed Secrets or External Secrets, OIDC federation for CI/CD instead of long-lived keys, rotation policy, and audit logging. Use when storing credentials, wiring pipeline authentication to a cloud provider, or auditing how a project handles secrets. |
| optimizing-cloud-cost | /tsh-platform-engineering:optimizing-cloud-cost | The cloud-agnostic cost framework TSH provisions against: matching a workload to a pricing model (reserved, committed-use, spot, serverless), storage tiering with lifecycle policies, the mandatory cost-allocation tag set and how to enforce it, right-sizing method, and the cost-impact estimate every infrastructure proposal carries. Use when sizing new infrastructure, estimating the cost of a change, or setting up tagging and budget governance — not for auditing a specific account, which is the cloud-specific skill's job. |
| Agent | Mention | Model | What it does |
|---|---|---|---|
| devops-engineer | @tsh-platform-engineering:devops-engineer | opus | Implements infrastructure, CI/CD and deployment work — Terraform modules, pipelines, Kubernetes workloads, observability, secrets — validating every change with plan, dry-run or template rather than applying it, and reporting cost impact. Use for delegated platform tasks from an implementation plan, or any infrastructure change that should be built and validated without touching live infrastructure. |
| infrastructure-auditor | @tsh-platform-engineering:infrastructure-auditor | opus | Audits infrastructure for security exposure, cost waste and operational-practice gaps — reads IaC and CI configuration, validates against live cloud state where credentials allow, detects drift and shadow resources, and returns a severity-ranked findings report. Use for an infrastructure, security-posture or FinOps audit of a repository, account or project, before a release or as a periodic review. |
Skills are invoked as /tsh-platform-engineering:<skill> and agents as @tsh-platform-engineering:<agent>.
Conventions the plugin holds to
- Nothing here applies infrastructure. Where a skill or agent validates a change it uses
plan,validate,--dry-run=serverortemplate, and apply instructions go to a human. The devops-engineer agent carries an explicit mutation lock. - Every proposal carries a cost estimate, and flags a projected increase above 10%.
- The project's existing conventions win over any default in the plugin. Each skill starts from the shared context file described below, which is also where the greenfield questions live.
Shared context
shared/discovering-infrastructure-context.md is read by every skill in the plugin and by both agents, via ${CLAUDE_PLUGIN_ROOT}. It keeps the detection logic in one place instead of repeating it across seven skills.
| Section | What it detects |
|---|---|
| Precedence | Order of authority: project instructions (CLAUDE.md, .claude/rules/, decision records, infrastructure/README.md, .devops/instructions.md), then existing infrastructure code, then provider documentation resolved against the pinned versions. An Accepted decision record settles the question it covers. |
| 1. CI/CD platform | GitHub Actions, Bitbucket Pipelines, GitLab CI, Azure Pipelines or Jenkins, from the pipeline file present. |
| 2. IaC dialect | Terraform, Terragrunt, raw Kubernetes manifests, Helm, Kustomize, CloudFormation, AWS CDK, Azure Bicep or Pulumi. |
| 3. Cloud provider and pinned versions | versions.tf, required_providers, Chart.yaml, provider blocks and .terraform.lock.hcl. |
| 4. Policy, secrets and state | Policy-as-code and linting, SOPS, Sealed Secrets, External Secrets Operator, HashiCorp Vault, and the remote state backend. |
| 5. Observability and GitOps | Prometheus, OpenTelemetry, log shippers, ArgoCD and Flux. |
| 6. Greenfield | When nothing exists, three questions asked with AskUserQuestion: target cloud, primary workload, expected scale. If the user declines, the default is managed containers, stated as a default and not a decision. |
Before implementing, the file requires a statement of the platform, dialect, cloud, pinned versions and any project convention that overrides a plugin default.
Pairs with a cloud plugin
| Here | In the cloud plugin |
|---|---|
| Terraform module structure, variables, state, Terragrunt, Terratest | That cloud's resource patterns and service defaults |
| The cost framework: pricing models, tiering, tagging governance | That cloud's service inventory, waste checks and cost report |
| Pipelines, Kubernetes, observability, secrets | - |
| Cross-cloud comparison and multi-cloud topology | - |
Each of the three major clouds has a plugin:
Neither side links to the other by file path, because a path across plugins is not stable across install modes. Each plugin stands alone and the model routes on descriptions.
MCP servers and hooks
The plugin bundles no MCP servers and no hooks. Provider, Kubernetes, Helm and CI platform documentation comes from context7, which tsh-core bundles and which is read-only (see the context7 integration).
Cloud documentation and live-state servers ship with the cloud's own plugin: aws-documentation in tsh-stack-aws, the three Google Cloud servers in tsh-stack-gcp, and none in tsh-stack-azure. A GCP repository therefore never starts an AWS server, and no cloud server appears in a repository with no cloud plugin installed.
Assumes tsh-core
The plugin references /tsh-core:managing-decision-records and /tsh-core:writing-technical-documents by name. Both degrade to a missing command, not an error, if tsh-core is absent. Install tsh-core anyway; it depends on nothing.
Referenced from other plugins
debugging-codeintsh-product-engineeringexcludes infrastructure and deployment faults, such as a misconfigured pipeline, cluster or cloud resource, and assigns them to this plugin.orchestrating-feature-implementationlists this plugin (CI, deployment) among those that may not be installed, and says to name the gap to the user.tsh-stack-serverlessleaves the deploy pipeline itself (CI system, OIDC, the deploy role) to this plugin.