$npx -y skills add ancoleman/ai-design-components --skill platform-engineeringDesign and implement Internal Developer Platforms (IDPs) with self-service capabilities, golden paths, and developer experience optimization. Covers platform strategy, IDP architecture (Backstage, Port), infrastructure orchestration (Crossplane), GitOps (Argo CD), and adoption pa
| 1 | # Platform Engineering |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Build Internal Developer Platforms (IDPs) that provide self-service infrastructure, reduce cognitive load, and accelerate developer productivity through golden paths and platform-as-product thinking. |
| 6 | |
| 7 | Platform engineering represents the evolution beyond traditional DevOps, focusing on creating product-quality internal platforms that treat developers as customers. The discipline addresses the developer productivity crisis where engineers spend 30-40% of time on infrastructure and tooling instead of features. |
| 8 | |
| 9 | ## When to Use This Skill |
| 10 | |
| 11 | Trigger this skill when: |
| 12 | - Building or improving an internal developer platform |
| 13 | - Designing a developer portal (Backstage, Port, or commercial IDP) |
| 14 | - Implementing golden paths and software templates |
| 15 | - Establishing or restructuring a platform engineering team |
| 16 | - Measuring and improving developer experience (DevEx) |
| 17 | - Integrating IDP with infrastructure, CI/CD, observability, or security tools |
| 18 | - Driving platform adoption across an engineering organization |
| 19 | - Assessing platform maturity and identifying capability gaps |
| 20 | |
| 21 | ## Core Concepts |
| 22 | |
| 23 | ### Platform as Product |
| 24 | |
| 25 | Treat internal platforms with the same rigor as customer-facing products: |
| 26 | |
| 27 | **Product Management Approach:** |
| 28 | - Define platform vision, strategy, and roadmap |
| 29 | - Identify developer "customers" and their pain points |
| 30 | - Measure success via adoption metrics, satisfaction surveys, and business impact |
| 31 | - Iterate based on feedback loops and usage analytics |
| 32 | - Balance new capabilities with platform reliability and support |
| 33 | |
| 34 | **Key Differences from Traditional DevOps:** |
| 35 | - DevOps focuses on delivery pipelines; platform engineering builds comprehensive developer experiences |
| 36 | - Platform teams operate as product teams (product managers, UX designers, engineers) |
| 37 | - Success measured by developer productivity and satisfaction, not just infrastructure metrics |
| 38 | - Self-service is the primary interface, not ticket queues |
| 39 | |
| 40 | ### Internal Developer Platform (IDP) Architecture |
| 41 | |
| 42 | **Three-Layer Architecture:** |
| 43 | |
| 44 | **1. Developer Portal (Frontend)** |
| 45 | - Service catalog: Inventory of services with ownership, dependencies, health status |
| 46 | - Software templates: Project scaffolding with best practices baked in |
| 47 | - Documentation hub: Centralized, searchable, version-controlled docs |
| 48 | - Self-service workflows: Environment provisioning, deployments, access requests |
| 49 | |
| 50 | **2. Platform Orchestration (Backend)** |
| 51 | - Infrastructure provisioning: Multi-cloud resource management |
| 52 | - Environment management: Dev, staging, production lifecycle |
| 53 | - Deployment automation: GitOps-based continuous delivery |
| 54 | - Configuration management: Separation of app and infrastructure concerns |
| 55 | |
| 56 | **3. Integration Layer (Glue)** |
| 57 | - CI/CD integration: Pipeline visibility and triggering |
| 58 | - Observability: Metrics, logs, traces surfaced in portal |
| 59 | - Security: Vulnerability scanning, policy enforcement, secrets management |
| 60 | - FinOps: Cost visibility, budgets, optimization recommendations |
| 61 | |
| 62 | For detailed architecture patterns and component breakdowns, see `references/idp-architecture.md`. |
| 63 | |
| 64 | ### Golden Paths and Scaffolding |
| 65 | |
| 66 | **Golden Path Principle:** |
| 67 | Provide opinionated templates that handle 80% of use cases while allowing escape hatches for the remaining 20%. |
| 68 | |
| 69 | **Template Components:** |
| 70 | - Repository structure and boilerplate code |
| 71 | - Infrastructure as code (Kubernetes manifests, Terraform) |
| 72 | - CI/CD pipeline configurations |
| 73 | - Observability instrumentation (metrics, logging, tracing) |
| 74 | - Security configurations (RBAC, network policies, secrets) |
| 75 | - Documentation templates (README, runbooks, architecture diagrams) |
| 76 | |
| 77 | **Constraint Mechanisms:** |
| 78 | - Policy-as-code enforcement (OPA, Kyverno) for security and compliance |
| 79 | - Resource limits and quotas to prevent over-provisioning |
| 80 | - Required health checks and observability instrumentation |
| 81 | - Approved base images and dependency scanning |
| 82 | |
| 83 | For template design patterns and examples, see `references/golden-paths.md`. |
| 84 | |
| 85 | ### Developer Experience (DevEx) Optimization |
| 86 | |
| 87 | **Cognitive Load Reduction:** |
| 88 | - Abstract infrastructure complexity without hiding necessary details |
| 89 | - Provide sensible defaults with clear override mechanisms |
| 90 | - Use progressive disclosure (simple for common cases, advanced options available) |
| 91 | - Consolidate tooling (single developer portal vs. 15+ separate tools) |
| 92 | |
| 93 | **Key Metrics:** |
| 94 | |
| 95 | **DORA Metrics:** |
| 96 | - Deployment frequency (how often code reaches production) |
| 97 | - Lead time for changes (commit to production duration) |
| 98 | - Mean time to recovery (MTTR for incidents) |
| 99 | - Change failure rate (percentage of deployments causing incidents) |
| 100 | |
| 101 | **SPACE Framework:** |
| 102 | - Satisfact |