platform-engineering
Skill4 starsChanged 12 months agoMITView on GitHub
Platform engineering and architecture guide covering Infrastructure as Code, container orchestration (Kubernetes/Docker), service mesh, developer platforms, internal developer portals, platform automation, multi-tenancy, resource management, and infrastructure standards. Use when designing platform architecture, implementing IaC, managing Kubernetes clusters, building developer platforms, or establishing infrastructure standards. (project)
- Commits and pushes
We split this skill into the rules it gives an agent
31 rules. 0 are common, 31 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
31
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 47
When starting a platform engineering task:
- Distinctive: line 69
Version control: All infrastructure in Git
- Distinctive: line 145
Git as single source of truth: All desired state in Git
- Distinctive: line 231
Use remote state for cross-stack references
- Distinctive: line 234
Use workspaces sparingly (prefer separate state files)
- Distinctive: line 416
Always use remote state with locking
- Distinctive: line 417
Never commit state files to version control
- Distinctive: line 418
Use separate state files per environment
- Distinctive: line 422
Keep modules focused and reusable
- Distinctive: line 424
Document inputs, outputs, and examples
- Distinctive: line 428
Never commit secrets to version control
- Distinctive: line 429
Use secret management tools (Vault, AWS Secrets Manager)
- Distinctive: line 436
Always set resource requests and limits
- Distinctive: line 437
Use namespaces for logical separation
- Distinctive: line 442
Use Pod Security Standards
- Distinctive: line 444
Run containers as non-root users
- Distinctive: line 446
Use secrets for sensitive data (never ConfigMaps)
- Distinctive: line 450
Use multiple replicas for critical services
- Distinctive: line 459
Document platform usage with examples
- Distinctive: line 466
Create meaningful dashboards and alerts
- Distinctive: line 472
Use spot/preemptible instances where appropriate
- Distinctive: line 492
Write Terraform module for cluster provisioning
- Distinctive: line 498
Document cluster architecture and runbooks
- Distinctive: line 502
Create namespace with resource quotas
- Distinctive: line 506
Create CI/CD pipeline
- Distinctive: line 510
Document service dependencies and runbooks
- Distinctive: line 514
Create feature branch in IaC repository
- Distinctive: line 516
Run terraform plan and review changes
- Distinctive: line 518
Test and validate functionality
- Distinctive: line 519
Create pull request with plan output
- Distinctive: line 549
Follow promotion process through environments
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🎯 SKILL ACTIVATED: platform-engineering ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Platform Engineering & Architecture
Comprehensive guide for building and managing modern platform engineering infrastructure. This skill provides production-tested patterns for Infrastructure as Code, container orchestration, developer platforms, and platform automation.
When to Use This Skill
Automatically activates when working on:
- Infrastructure as Code implementation (Terraform, Pulumi, CloudFormation)
- Kubernetes cluster management and container orchestration
- Platform architecture design and developer platforms
- GitOps automation (ArgoCD, Flux)
- Service mesh configuration (Istio, Linkerd)
- Multi-tenancy and resource management
- Platform cost optimization and governance
- Internal developer portal development (Backstage, Port)
Overview
Purpose: Enable teams to build robust, scalable platform infrastructure that empowers developers with self-service capabilities while maintaining security, reliability, and cost efficiency.
Scope:
- Infrastructure as Code (Terraform, Pulumi, CloudFormation, Ansible)
- Container orchestration (Kubernetes, Docker, ECS, AKS, GKE, EKS)
- Service mesh and networking (Istio, Linkerd, Envoy)
- Developer platforms and internal portals (Backstage, Port, Humanitec)
- Platform automation and GitOps (ArgoCD, Flux, Jenkins, GitHub Actions)
- Multi-tenancy and resource isolation
- Cost optimization and FinOps
- Infrastructure standards and governance
This skill is for:
- Platform engineers building internal developer platforms
- Infrastructure architects designing scalable systems
- Teams migrating to cloud-native architectures
- Organizations implementing platform engineering practices
Quick Start Checklist
When starting a platform engineering task:
- Identify the infrastructure layer (compute, networking, storage, orchestration)
- Choose appropriate IaC tool (Terraform for multi-cloud, native tools for single cloud)
- Define resource hierarchy and naming conventions
- Implement state management and backend configuration
- Design for multi-environment support (dev, staging, prod)
- Plan security controls and access management
- Define monitoring and observability strategy
- Document platform architecture and runbooks
- Implement cost tracking and tagging strategy
- Set up automated testing for infrastructure changes
Core Concepts
1. Infrastructure as Code (IaC)
Definition: Managing infrastructure through version-controlled code rather than manual processes.
Key Principles:
- Declarative over imperative: Define desired state, not steps
- Idempotency: Same input produces same output
- Version control: All infrastructure in Git
- Immutable infrastructure: Replace rather than modify
- State management: Track current infrastructure state
- Modularity: Reusable components and modules
Tool Selection:
Terraform: Multi-cloud, largest ecosystem, HCL language
Pulumi: Programming languages (Python/TypeScript/Go), cloud-native
CloudFormation: AWS-native, tight AWS integration
ARM/Bicep: Azure-native, JSON/domain-specific language
Ansible: Configuration management + provisioning
CDK: Cloud-native using programming languages2. Container Orchestration
Kubernetes Architecture:
┌─────────────────────────────────────────────────┐
│ Control Plane │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ API │ │ etcd │ │ Scheduler │ │
│ │ Server │ │ │ │ │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
│ ┌─────────────────────────────────────────┐ │
│ │ Controller Manager │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘
│
┌─────────────┼─────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ Node 1 │ │ Node 2 │ │ Node 3 │
│ │ │ │ │ │
│ Kubelet │ │ Kubelet │ │ Kubelet │
│ Pods │ │ Pods │ │ Pods │
└─────────┘ └─────────┘ └─────────┘Core Resources:
- Pods: Smallest deployable units (containers)
- Deployments: Manage replica sets and rolling updates
- Services: Stable networking and load balancing
- ConfigMaps/Secrets: Configuration and sensitive data
- Namespaces: Resource isolation and multi-tenancy
- Ingress: External access and routing rules
- PersistentVolumes: Storage abstraction
3. Platform Layers
┌────────────────────────────────────────────────┐
│ Developer Experience Layer │
│ (Portals, CLIs, APIs, Documentation) │
└────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────┐
│ Platform Services Layer │
│ (CI/CD, Observability, Secrets, Service Mesh)│
└────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────┐
│ Orchestration Layer │
│ (Kubernetes, ECS, Nomad) │
└────────────────────────────────────────────────┘
│
┌────────────────────────────────────────────────┐
│ Infrastructure Layer │
│ (Compute, Network, Storage, Security) │
└────────────────────────────────────────────────┘4. GitOps Principles
Core Tenets:
- Git as single source of truth: All desired state in Git
- Declarative desired state: What, not how
- Automated synchronization: Continuous reconciliation
- Pull-based deployment: Cluster pulls changes from Git
GitOps Workflow:
Developer → Git Push → CI Pipeline → Update Manifest Repo
↓
GitOps Controller monitors repo
↓
Detects drift, applies changes
↓
Cluster state matches Git5. Multi-Tenancy Patterns
Namespace-based Tenancy:
apiVersion: v1
kind: Namespace
metadata:
name: tenant-acme
labels:
tenant: acme
environment: production
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-acme-quota
namespace: tenant-acme
spec:
hard:
requests.cpu: "100"
requests.memory: 100Gi
persistentvolumeclaims: "10"Cluster-based Tenancy:
- Dedicated clusters per tenant/environment
- Stronger isolation, higher cost
- Simplified RBAC and networking
Virtual Clusters:
- vCluster, Loft, Capsule
- Lightweight isolation within shared cluster
- Balance between namespace and cluster tenancy
Common Patterns
Pattern 1: Terraform Module Structure
terraform/
├── modules/
│ ├── vpc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ └── versions.tf
│ ├── eks-cluster/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ └── security.tf
│ └── rds-postgres/
│ └── ...
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── backend.tf
│ │ ├── terraform.tfvars
│ │ └── versions.tf
│ ├── staging/
│ │ └── ...
│ └── prod/
│ └── ...
└── shared/
└── networking/
└── ...Key Practices:
- Separate modules from environments
- Use remote state for cross-stack references
- Implement state locking (S3 + DynamoDB for AWS)
- Version modules with Git tags
- Use workspaces sparingly (prefer separate state files)
Pattern 2: Kubernetes Application Deployment
# Standard three-resource pattern
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-service
namespace: production
spec:
replicas: 3
selector:
matchLabels:
app: api-service
template:
metadata:
labels:
app: api-service
version: v1.2.3
spec:
containers:
- name: api
image: registry.example.com/api-service:v1.2.3
ports:
- containerPort: 8080
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: api-secrets
key: database-url
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: api-service
namespace: production
spec:
selector:
app: api-service
ports:
- port: 80
targetPort: 8080
type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: api-service
namespace: production
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/rate-limit: "100"
spec:
ingressClassName: nginx
tls:
- hosts:
- api.example.com
secretName: api-service-tls
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80Pattern 3: Platform Service Catalog
Developer Portal (Backstage) Structure:
# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: api-service
description: Customer API microservice
annotations:
github.com/project-slug: company/api-service
backstage.io/techdocs-ref: dir:.
tags:
- api
- microservice
- production
spec:
type: service
lifecycle: production
owner: platform-team
system: customer-platform
providesApis:
- customer-api
consumesApis:
- auth-api
- notification-api
dependsOn:
- resource:postgres-db
- resource:redis-cachePattern 4: Infrastructure State Management
Terraform Backend Configuration:
# backend.tf
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "prod/vpc/terraform.tfstate"
region = "us-east-1"
encrypt = true
dynamodb_table = "terraform-state-lock"
# Enable versioning on the bucket for rollback
# Enable MFA delete for production
}
}
# Workspace-based alternative (use sparingly)
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "env:/${terraform.workspace}/terraform.tfstate"
region = "us-east-1"
}
}Resource Files
For detailed guidance on specific topics, see:
Core Infrastructure
- architecture-overview.md - Platform architecture patterns, layering strategies, reference architectures, and decision frameworks
- infrastructure-as-code.md - Terraform, Pulumi, CloudFormation patterns, module design, state management, testing strategies
- container-orchestration.md - Kubernetes architecture, workload patterns, networking, storage, security best practices
Platform Services
- developer-platforms.md - Internal developer portals (Backstage, Port), self-service platforms, service catalogs, developer experience
- gitops-automation.md - ArgoCD, Flux CD, continuous deployment, progressive delivery, automated rollbacks
- service-mesh.md - Istio, Linkerd implementation, traffic management, security policies, observability
Operations & Management
- multi-tenancy.md - Namespace isolation, resource quotas, RBAC patterns, network policies, cost allocation
- resource-management.md - Resource requests/limits, autoscaling (HPA, VPA, KEDA), cluster autoscaling, capacity planning
- cost-optimization.md - FinOps practices, cost allocation, right-sizing, spot instances, reserved capacity
Standards & Governance
- infrastructure-standards.md - Naming conventions, tagging strategies, security baselines, compliance frameworks
- platform-security.md - Pod security standards, network policies, secrets management, vulnerability scanning, runtime security
Best Practices
Infrastructure as Code
- State Management:
- Always use remote state with locking
- Never commit state files to version control
- Use separate state files per environment
- Enable state file versioning for rollback
- Module Design:
- Keep modules focused and reusable
- Version modules with semantic versioning
- Document inputs, outputs, and examples
- Test modules independently
- Security:
- Never commit secrets to version control
- Use secret management tools (Vault, AWS Secrets Manager)
- Implement least-privilege IAM policies
- Enable encryption at rest and in transit
Kubernetes
- Resource Management:
- Always set resource requests and limits
- Use namespaces for logical separation
- Implement resource quotas per namespace
- Enable horizontal pod autoscaling
- Security:
- Use Pod Security Standards
- Implement network policies for pod isolation
- Run containers as non-root users
- Scan images for vulnerabilities
- Use secrets for sensitive data (never ConfigMaps)
- Reliability:
- Implement health checks (liveness, readiness, startup)
- Use multiple replicas for critical services
- Configure pod disruption budgets
- Implement proper graceful shutdown
Platform Engineering
- Developer Experience:
- Provide self-service capabilities
- Automate common tasks
- Document platform usage with examples
- Measure and improve developer productivity
- Observability:
- Implement structured logging
- Set up metrics collection (Prometheus)
- Configure distributed tracing
- Create meaningful dashboards and alerts
- Cost Management:
- Tag all resources for cost allocation
- Implement resource quotas
- Monitor and optimize resource usage
- Use spot/preemptible instances where appropriate
Anti-Patterns to Avoid
❌ Manual infrastructure changes - Always use IaC ❌ Shared state files - Separate state per environment/component ❌ No resource limits - Can cause resource exhaustion ❌ Running as root - Security vulnerability ❌ Ignoring health checks - Leads to cascading failures ❌ No pod disruption budgets - Maintenance causes outages ❌ Untagged resources - Impossible to track costs ❌ No backup strategy - Data loss risk ❌ Overprovisioning by default - Wastes money ❌ No monitoring/alerting - Flying blind
Common Tasks
Task: Create New Kubernetes Cluster
- Define cluster specification (node count, size, region, version)
- Write Terraform module for cluster provisioning
- Configure RBAC and service accounts
- Set up networking (VPC, subnets, security groups)
- Install core platform services (ingress, cert-manager, monitoring)
- Configure GitOps controller (ArgoCD/Flux)
- Implement backup and disaster recovery
- Document cluster architecture and runbooks
Task: Onboard New Service to Platform
- Create namespace with resource quotas
- Set up RBAC for team access
- Configure network policies
- Provision required resources (databases, caches, queues)
- Create CI/CD pipeline
- Configure monitoring and alerting
- Set up logging and tracing
- Register in service catalog
- Document service dependencies and runbooks
Task: Implement Infrastructure Change
- Create feature branch in IaC repository
- Make changes in development environment first
- Run terraform plan and review changes
- Apply changes to dev environment
- Test and validate functionality
- Create pull request with plan output
- Peer review and approval
- Apply to staging, then production
- Monitor for issues and rollback if needed
Integration Points
This skill integrates with:
- devsecops: Security scanning, policy enforcement, compliance
- sre: Incident response, reliability engineering, SLO/SLI management
- release-engineering: Deployment automation, progressive delivery, rollback strategies
- cloud-engineering: Cloud-specific implementations (AWS/Azure/GCP)
- systems-engineering: OS-level configuration, networking, performance tuning
Triggers and Activation
This skill activates when you:
- Work with Infrastructure as Code files (*.tf, *.yaml in k8s/, helm/, infra/)
- Mention platform engineering topics (Kubernetes, Terraform, IaC)
- Design platform architecture or developer platforms
- Implement GitOps or container orchestration
- Configure multi-tenancy or resource management
Next Steps
For your specific task:
- Identify which resource file addresses your needs
- Review the relevant patterns and examples
- Adapt to your infrastructure and requirements
- Implement with testing in dev environment first
- Follow promotion process through environments
Total Resources: 11 detailed guides covering all aspects of platform engineering Pattern Library: 50+ production-tested infrastructure patterns Maintained by: Platform Engineering team based on real-world production experience
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- magnus919/agent-skills★ 162same name
- foreturn/product-studio★ 3same name
- ffsshhttiikk/opencode-agents-skills★ 2same name
- joaocarloscruz/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- api-engineeringSkill
- backend-dev-guidelinesSkill
- budget-and-cost-managementSkill
- build-engineeringSkill
- cloud-engineeringSkill
- cybersecuritySkill
- database-engineeringSkill
- devsecopsSkill
- documentation-as-codeSkill
- engineering-managementSkill
- engineering-operations-managementSkill
- error-trackingSkill
- frontend-dev-guidelinesSkill
- general-it-engineeringSkill
- infrastructure-architectureSkill
- infrastructure-strategySkill
- network-engineeringSkill
- observability-engineeringSkill
- release-engineeringSkill
- route-testerSkill
- skill-developerSkill
- sreSkill
- systems-engineeringSkill
- technical-leadershipSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

