jbvc/kubernetes-architect
Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration. Masters EKS/AKS/GKE, service mesh (Istio/Linkerd), progressive delivery, multi-tenancy, and platform engineering. Handles security, observability, cost optimization, and developer experience. Use PROACTIVELY for K8s architecture, GitOps implementation, or cloud-native platform design.
48
48%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
72%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is strong on trigger terms and distinctiveness, covering a wide range of Kubernetes and cloud-native technologies that would help Claude select this skill appropriately. However, it reads more like a professional bio than a skill description — using phrases like 'Expert architect specializing in' and 'Masters' rather than describing concrete actions the skill performs. The 'when to use' clause exists but is too brief relative to the extensive technology list.
Suggestions
Replace resume-style language ('Expert architect specializing in', 'Masters') with concrete action verbs describing what the skill does (e.g., 'Designs Kubernetes architectures, implements GitOps workflows with ArgoCD/Flux, configures service meshes')
Expand the 'Use PROACTIVELY for...' clause with more specific trigger scenarios, e.g., 'Use when the user asks about deploying to Kubernetes, setting up CI/CD with GitOps, configuring Istio/Linkerd, managing EKS/AKS/GKE clusters, or designing multi-tenant platforms'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (Kubernetes, cloud-native) and lists many technology areas (EKS/AKS/GKE, service mesh, GitOps, etc.), but the actual actions are vague — 'Masters', 'Handles', 'specializing in' are not concrete actions like 'deploy', 'configure', 'troubleshoot'. It reads more like a resume than a list of specific capabilities. | 2 / 3 |
Completeness | The 'what' is partially covered through technology enumeration, and there is a 'Use PROACTIVELY for...' clause at the end, but it's quite brief and generic ('K8s architecture, GitOps implementation, or cloud-native platform design'). The 'when' guidance lacks specificity about user scenarios or trigger conditions beyond broad categories. | 2 / 3 |
Trigger Term Quality | Strong coverage of natural keywords users would say: 'Kubernetes', 'K8s', 'ArgoCD', 'Flux', 'EKS', 'AKS', 'GKE', 'Istio', 'Linkerd', 'GitOps', 'service mesh', 'cloud-native', 'container orchestration'. These are terms users would naturally use when seeking help in this domain. | 3 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to Kubernetes and cloud-native infrastructure, with distinct technology names (ArgoCD, Flux, Istio, Linkerd, EKS/AKS/GKE) that clearly carve out a niche. It's unlikely to conflict with other skills unless there are multiple Kubernetes-related skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill reads as a persona description or role-play prompt rather than an actionable skill document. It is overwhelmingly verbose, listing dozens of tools and concepts Claude already knows without providing any concrete code, commands, configuration examples, or executable workflows. The content would need a fundamental restructuring to become useful—replacing capability catalogs with specific, actionable patterns and examples.
Suggestions
Replace the extensive 'Capabilities' bullet lists with 2-3 concrete, executable examples (e.g., a sample ArgoCD Application manifest, a Kustomize overlay structure, or a Helm values pattern for multi-tenancy).
Add specific validation steps to the workflow, such as 'Run `kubectl diff -f manifests/` to preview changes before applying' or 'Verify rollout health with `kubectl rollout status deployment/app`'.
Move detailed tool catalogs to a separate REFERENCE.md file and keep SKILL.md focused on decision frameworks and actionable patterns (e.g., 'When to use Kustomize vs Helm' with concrete criteria).
Remove 'Behavioral Traits', 'Knowledge Base', and 'Purpose' sections entirely—these describe Claude's persona rather than providing actionable instructions, and waste significant token budget.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive lists of tools, concepts, and capabilities that Claude already knows. The 'Capabilities' section is essentially a catalog of Kubernetes ecosystem knowledge that adds no actionable value—Claude already knows what Prometheus, Istio, Helm, etc. are. 'Behavioral Traits' and 'Knowledge Base' sections describe personality rather than providing instructions. | 1 / 3 |
Actionability | No concrete code, commands, or executable examples anywhere. The entire skill is abstract descriptions and bullet-point lists of technologies. The 'Instructions' section has four vague steps like 'Define cluster topology, networking, and security boundaries' with no specifics on how. 'Example Interactions' are just prompts, not worked examples with outputs. | 1 / 3 |
Workflow Clarity | The four-step 'Instructions' workflow is extremely high-level and lacks any validation checkpoints, specific commands, or feedback loops. 'Validate with staging' is mentioned but with no concrete steps. The 'Response Approach' is a 9-step list of abstract directives with no sequencing logic, error handling, or decision points. | 1 / 3 |
Progressive Disclosure | Monolithic wall of text with no references to external files. All content is inline in one massive document with 12+ subsections under 'Capabilities' alone. No links to detailed guides, reference materials, or examples files. The content would benefit enormously from splitting detailed tool lists into separate reference documents. | 1 / 3 |
Total | 4 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents