k8s-platform-change

Modifies Kubernetes-facing operator, CRD, deployment-profile, or DSL translation behavior for semantic-router platform integration. Use when changing operator APIs or controllers, deployment stack manifests, profile-owned platform wiring, or router-to-Kubernetes translation layers.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A tight, well-structured instruction skill with concrete commands, explicit validation gates, and clean progressive disclosure. The two minor gaps are directional high-level steps in the workflow and the absence of an explicit fix-and-retry feedback loop after the CI gate.

Suggestions

Add an explicit error-recovery loop after `make agent-ci-gate` (e.g., 'If the gate fails, fix the reported constraint violations and re-run `agent-ci-gate` until it passes before verifying the platform contract') to strengthen the feedback loop for destructive platform changes.

Tighten Workflow step 2 by pointing at where the modification entry points live (specific operator controller, deployment-profile path, or DSL translation module) so the step is concrete rather than purely directional.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence — it never explains what a CRD, operator, or deployment manifest is, and every section (Trigger, Workflow, Gotchas, Must Read, Standard Commands, Acceptance) earns its place.	5 / 5
Actionability	Concrete, executable commands are provided (`make agent-report ENV=cpu CHANGED_FILES="..."`, `make agent-ci-gate`, `make agent-feature-gate`), but Workflow step 2 ("Modify the operator, deployment profile, or DSL translation behavior") and step 5 ("Verify...") stay directional without pointing at concrete entry points, leaving a minor gap below 5.	4 / 5
Workflow Clarity	A clear 5-step sequence with explicit validation checkpoints (agent-report surfaces impact, agent-ci-gate validates constraints, step 5 verifies the platform contract), but no spelled-out error-recovery loop ("if the gate fails, fix and re-run") keeps it just under 5 for a destructive platform-change context.	4 / 5
Progressive Disclosure	Well-organized overview with a clearly signaled one-level-deep "Must Read" reference list (change-surfaces.md, module-boundaries.md, testing-strategy.md) and no nested or buried references; navigation is easy and content is appropriately split into short sections.	5 / 5
	Total	18 / 20 Passed

Description

87%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong, third-person description that concretely states what it does and when to use it with explicit trigger guidance and a clearly delineated niche. The only soft spot is action-verb variety and missing synonyms/extensions, which keep specificity and trigger_term_quality at 4.

Dimension	Reasoning	Score
Specificity	Names several concrete capability areas ("operator, CRD, deployment-profile, or DSL translation behavior") rather than vague language, though the single verb "Modifies" means it lists domains more than multiple distinct actions, keeping it just below a 5.	4 / 5
Completeness	It explicitly answers both "what" ("Modifies Kubernetes-facing operator, CRD, deployment-profile, or DSL translation behavior for semantic-router platform integration") and "when" ("Use when changing operator APIs or controllers, deployment stack manifests...") with concrete trigger phrases.	5 / 5
Trigger Term Quality	The "Use when changing operator APIs or controllers, deployment stack manifests, profile-owned platform wiring, or router-to-Kubernetes translation layers" clause gives good keyword coverage of terms a user in this codebase would say, but lacks synonyms or file extensions (e.g. .yaml) that would push it to 5.	4 / 5
Distinctiveness Conflict Risk	The description carves a clear niche scoped to semantic-router Kubernetes-facing integration, and the body's Gotchas explicitly routes sibling work to `config-platform-change`, leaving minimal overlap risk.	5 / 5
	Total	18 / 20 Passed

Validation

87%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 3 suspicious	Warning

	Total	14 / 16 Passed

Repository: vllm-project/semantic-router
Path: tools/agent/skills/k8s-platform-change/SKILL.md
Commit: e73c772

Reviewed: 9 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.