Standardise AI Coding Tools Across Platform Engineering: Cursor Rules, Skills, and Commands That Scale

Your platform engineering team has adopted AI coding assistants. Cursor, GitHub Copilot, Windsurf, Cline — probably a mix. Each engineer has their own setup: custom rules (or none), personal prompts bookmarked in a notes app, different models for different tasks, and wildly different productivity outcomes.

One engineer generates Kyverno policies in seconds. Another fights with the AI for 20 minutes and writes it manually. Same tool, same team, 10x productivity gap. The difference isn't the tool — it's the configuration, context, and shared knowledge baked into how each person uses it.

This is the same problem platform engineering solves for infrastructure: individual variation → standardised golden paths → everyone gets the best experience by default. It's time to apply platform thinking to AI tool usage itself.

The Problem: Artisanal AI Usage

Right now, AI coding tool usage in most platform teams looks like this:

• No shared rulesets: Each engineer has (or doesn't have) their own .cursorrules or .github/copilot-instructions.md. Best practices live in one person's config, not the team's
• No shared prompts: The perfect prompt for "generate a Helm chart with security best practices" exists in someone's head. Everyone else starts from scratch every time
• Inconsistent model selection: One engineer uses Claude for architecture, GPT-4 for code generation, and a local model for sensitive code. Another uses the default model for everything. Neither has benchmarked which works best for their stack
• No context engineering: The AI doesn't know your infrastructure conventions, naming standards, policy requirements, or architectural decisions. Every prompt starts from zero
• No measurement: Nobody knows if AI tools are actually saving time. No data on which tasks benefit most, which prompts work best, or where the tools fail consistently

Rulesets: Your Team's AI Operating Manual

Rulesets are the foundation. They're the persistent context that shapes every AI interaction — the equivalent of coding standards, but for AI-assisted development.

Project-Level Rules (Checked Into Git)

These live in the repository and apply to every engineer working on that codebase:

# .cursorrules (or .github/copilot-instructions.md)

## Project Context
This is a Kubernetes platform engineering project for regulated
European enterprises. All infrastructure must comply with:
- EU AI Act (risk classification, human oversight)
- DORA (ICT risk management, incident reporting)
- NIS2 (essential service security)
- CRA (software supply chain security)

## Infrastructure Standards
- Kubernetes: OpenShift 4.15+ or vanilla Kubernetes 1.29+
- GitOps: ArgoCD (never kubectl apply from local machine)
- Policy: Kyverno (not OPA/Gatekeeper for new policies)
- Secrets: External Secrets Operator + HashiCorp Vault
- Monitoring: OpenTelemetry Collector → Prometheus + Grafana
- TLS: cert-manager with Let's Encrypt (staging) / private CA (prod)
- Container base images: Red Hat UBI 9 minimal

## Code Standards
- Helm charts: always include values.schema.json
- YAML: 2-space indent, explicit string quoting for ports/versions
- Labels: always include app.kubernetes.io/name, /version, /component
- Resource limits: always set requests AND limits, never use BestEffort
- SecurityContext: always runAsNonRoot, readOnlyRootFilesystem
- NetworkPolicy: deny-all default, explicit allow rules per service
- RBAC: least privilege, never use cluster-admin in application manifests

## Naming Conventions
- Namespaces: {team}-{environment} (e.g., ml-team-staging)
- Services: {app}-{component} (e.g., inference-api, training-worker)
- Secrets: {app}-{purpose} (e.g., inference-api-db-credentials)
- ConfigMaps: {app}-config

## Anti-Patterns (Never Generate)
- Never use latest tag for images
- Never mount ServiceAccount tokens unless explicitly needed
- Never use hostPath volumes
- Never set privileged: true
- Never disable TLS verification
- Never hardcode credentials in manifests
- Never use NodePort services in production

When this file lives in the repository, every team member's AI assistant automatically follows these conventions. The engineer who joined last week gets the same quality output as the 5-year veteran — because the context is in the repo, not in someone's head.

Team-Level Skills (Shared Prompt Library)

Skills are reusable prompt templates for common tasks. Instead of each engineer crafting their own prompt for "create a Kyverno policy," the team shares a curated library:

# .cursor/skills/kyverno-policy.md

## Generate Kyverno Policy

Context: We use Kyverno for policy enforcement. All policies must:
- Include both audit and enforce modes (deploy as audit first)
- Have a clear policy name following: {category}-{action}-{target}
- Include a description and message for violation feedback
- Be scoped to the minimum necessary (namespace, not cluster, unless required)
- Include a compliance annotation mapping to regulatory requirement

Template:
Generate a Kyverno ClusterPolicy that:
- Name: {category}-{action}-{target}
- Category: [security|compliance|operations|cost]
- Mode: audit (for initial deployment)
- Include annotations:
  policies.kyverno.io/title: [descriptive title]
  policies.kyverno.io/category: [category]
  policies.kyverno.io/severity: [low|medium|high|critical]
  compliance.openempower.com/regulation: [DORA|NIS2|AI-Act|CRA|internal]
  compliance.openempower.com/control: [specific control reference]

Test the policy against:
- A compliant resource (should pass)
- A non-compliant resource (should fail with clear message)
- An edge case (partial compliance)

# .cursor/skills/helm-chart.md

## Generate Helm Chart

Context: All services are deployed via Helm charts managed by ArgoCD.
Every chart must include:
- values.schema.json (validated by CI)
- Pod Security Standards: restricted
- NetworkPolicy (deny-all + explicit allows)
- ServiceMonitor (for Prometheus)
- HorizontalPodAutoscaler (min 2 replicas in production)
- PodDisruptionBudget (minAvailable: 1)
- Resource requests and limits (never BestEffort)
- SecurityContext (runAsNonRoot, readOnlyRootFilesystem)
- Liveness, readiness, and startup probes

Generate a production-ready Helm chart for: [service description]
Include comments explaining each security and operational decision.

Custom Commands: One-Key Infrastructure Operations

Cursor's custom commands (and similar features in other tools) let you bind complex operations to simple triggers:

# .cursor/commands.json
{
  "commands": [
    {
      "name": "Review Security",
      "prompt": "Review this Kubernetes manifest for security issues. Check against our .cursorrules standards. Flag any violations of Pod Security Standards restricted profile, missing NetworkPolicies, missing resource limits, privileged containers, hostPath mounts, missing RBAC constraints, and cleartext secrets. For each issue, explain the risk and provide the fix.",
      "keybinding": "ctrl+shift+s"
    },
    {
      "name": "Compliance Map",
      "prompt": "Map this infrastructure configuration to regulatory requirements. For each resource, identify which DORA, NIS2, AI Act, or CRA controls it satisfies or violates. Output a compliance matrix with: Resource, Regulation, Control ID, Status (compliant/gap/partial), and Remediation if needed.",
      "keybinding": "ctrl+shift+c"
    },
    {
      "name": "Generate Tests",
      "prompt": "Generate comprehensive tests for this Kubernetes configuration. Include: 1) Kyverno policy tests (both compliant and non-compliant inputs), 2) Helm chart tests (template rendering), 3) Integration test scenarios (what to verify after deployment). Use our naming conventions from .cursorrules.",
      "keybinding": "ctrl+shift+t"
    },
    {
      "name": "Incident Runbook",
      "prompt": "Generate an incident runbook for this service based on its Kubernetes manifests. Include: 1) Common failure modes and symptoms, 2) Diagnostic commands (kubectl, prometheus queries), 3) Recovery procedures, 4) Escalation criteria, 5) DORA incident reporting triggers if applicable.",
      "keybinding": "ctrl+shift+r"
    }
  ]
}

Now every platform engineer has one-key access to security review, compliance mapping, test generation, and runbook creation. The senior engineer's expertise is encoded in the commands. The junior engineer gets senior-level output.

Marinating Skills: The Knowledge Flywheel

"Marinating" is the process of continuously improving your rulesets and skills based on real usage. It's not a one-time setup — it's a continuous refinement loop:

1. Capture: When an engineer discovers a prompt that works exceptionally well, they submit it to the shared skills library via PR. Same workflow as code contributions
2. Review: Team reviews the skill. Does it follow conventions? Does it produce consistent, high-quality output? Does it handle edge cases?
3. Test: Run the skill against 5-10 real scenarios. Verify output quality. Compare against manually written equivalents
4. Merge: Skill joins the shared library. Every team member benefits immediately
5. Iterate: Track which skills are used most, which produce the best results, which need refinement. Monthly skill review — prune unused skills, improve popular ones

Over time, your skills library becomes the distilled expertise of your entire team. New hires inherit months of accumulated knowledge on day one. The AI becomes a force multiplier for the team's collective intelligence, not just individual productivity.

Optimising the Platform Engineering Day

With standardised rulesets, shared skills, and custom commands, the platform engineering day transforms:

Morning: Infrastructure Review (30 min → 10 min)

• Before: Manually review overnight PRs, check each manifest against mental checklist of security requirements
• After: Run "Review Security" command on each PR. AI checks against the full ruleset in seconds. Engineer reviews AI output, focuses on architectural decisions, not syntax

Mid-morning: New Service Onboarding (4 hours → 45 min)

• Before: Manually create namespace, RBAC, NetworkPolicy, Helm chart scaffold, ArgoCD application, monitoring dashboards. Copy from previous service, modify, inevitably miss something
• After: Backstage template creates the scaffold. AI generates the service-specific configuration using the Helm chart skill. Security controls are included by default. Total manual work: review and approve the generated PR

Afternoon: Policy Development (2 days → 3 hours)

• Before: Research Kyverno policy syntax, write policy, test manually against sample manifests, iterate, write documentation
• After: Use Kyverno skill to generate policy with test cases. AI produces audit-mode policy, compliant and non-compliant test inputs, and compliance annotations. Engineer validates logic, tests in staging namespace, promotes to audit-mode cluster-wide

End of Day: Documentation and Runbooks (1 hour → 15 min)

• Before: Write runbooks from scratch (or skip it because who has time)
• After: "Incident Runbook" command generates runbook from the actual service manifests. Includes real kubectl commands, real Prometheus queries, real escalation paths. Engineer reviews and publishes

Measuring the Impact

You can't improve what you don't measure. Track:

• Time-to-merge for infrastructure PRs: Are PRs being reviewed and merged faster? (AI-assisted review should cut review time by 40-60%)
• Skill library usage: Which skills are used most? Which produce PRs that pass review on first attempt?
• Security finding rate: Are AI-assisted reviews catching more issues before production? Fewer post-deploy security findings = skills are working
• Onboarding velocity: How quickly do new team members reach full productivity? With shared rulesets and skills, the ramp-up should halve
• Toil reduction: Track repetitive tasks (namespace creation, policy writing, runbook generation) and measure time savings after automation via AI skills

What Open Empower Delivers

• AI tool standardisation: Audit your team's current AI tool usage, identify gaps, and design a standardised configuration (rulesets, skills, commands) for your stack
• Ruleset engineering: Project-level and team-level rulesets encoding your infrastructure standards, security requirements, and regulatory constraints
• Skills library: Curated prompt templates for your most common platform engineering tasks — policy generation, Helm charts, security review, compliance mapping, runbooks
• Knowledge flywheel: Process and tooling for continuous skill improvement — capture, review, test, merge, iterate
• Productivity measurement: Metrics framework to track AI tool impact on platform engineering velocity, quality, and security

Your team's AI tools are only as good as the context you give them. Standardise the context, and everyone gets 10x. Let's optimise your platform engineering day.