CtrlK
BlogDocsLog inGet started
Tessl Logo

ai-observability

Analyze AI model performance, GPU utilization, and cluster health on OpenShift AI. Use when: - "How is my model performing?" - "What GPUs are available in the cluster?" - "Show me inference latency for Llama" - "Check OpenShift cluster health metrics" - "Trace a slow inference request" - "Correlate errors across my inference stack" Query-driven, read-only analysis. Routes to the appropriate observability domain based on user intent. NOT for deploying models (use /model-deploy). NOT for debugging failed deployments (use /debug-inference).

72

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%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.

The body is highly actionable with an explicit, checkpoint-gated workflow and concrete tool/parameter guidance, but it carries noticeable redundancy from duplicated tool listings and leaves three bundle reference files unlinked from the main content.

Suggestions

De-duplicate the MCP tool roster: keep the full annotated list in Prerequisites and drop the repeated '(from ai-observability)' tag from each per-step tool call, or vice versa.

Link the orphaned bundle files from the body — add a 'Reference Documentation' entry for common-issues.md (and consolidate the inline Common Issues section into it), live-doc-lookup.md, and openshift-fallback-templates.md — so all bundle content is discoverable.

Remove the Step 1 trigger-phrase table or replace it with a pointer to the description's 'Use when' list to avoid restating the same triggers twice.

DimensionReasoningScore

Conciseness

Content is mostly efficient and reference-dense, but the MCP tool list is duplicated verbatim in Prerequisites and then restated per workflow step with the repeated tag '(from ai-observability)' ~20 times, and the Step 1 trigger-phrase table re-states phrases already in the description; these could be tightened.

3 / 5

Actionability

Every workflow branch names the exact MCP tool, lists parameters with REQUIRED/OPTIONAL/CONDITIONAL flags, and supplies concrete example values (e.g. time_range '15m', TraceQL '{resource.service.name="[service]"}', Korrel8r 'k8s:Pod:{...}'), giving fully executable guidance.

5 / 5

Workflow Clarity

A clearly sequenced four-step process with domain branching (Step 2a–2g) and explicit 'WAIT for user decision' validation checkpoints at every gate, plus an MCP-reachability pre-check with recovery instructions; the read-only nature means the destructive-ops cap does not apply.

5 / 5

Progressive Disclosure

Good structure with clearly signaled one-level-deep markdown links to skill-conventions.md, known-model-profiles.md, and supported-runtimes.md, but three of six bundle files (common-issues.md, live-doc-lookup.md, openshift-fallback-templates.md) are orphaned — not linked from the body — and the inline 'Common Issues' section duplicates a bundled reference file.

4 / 5

Total

17

/

20

Passed

Description

100%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.

The description is exemplary: it concisely states the skill's purpose in third person, lists comprehensive concrete actions, provides six natural trigger phrases, and draws clear boundaries against related skills. No meaningful gaps to address.

DimensionReasoningScore

Specificity

Lists multiple concrete actions — 'Analyze AI model performance, GPU utilization, and cluster health' plus routing across vLLM metrics, OpenShift health, Tempo traces, and Korrel8r correlation — giving comprehensive coverage of the skill's capabilities.

5 / 5

Completeness

Explicitly answers both 'what' ('Analyze AI model performance, GPU utilization, and cluster health on OpenShift AI... Routes to the appropriate observability domain') and 'when' via a concrete 'Use when:' trigger list, with added NOT-for boundary guidance.

5 / 5

Trigger Term Quality

The 'Use when:' block provides six natural user phrases ('How is my model performing?', 'What GPUs are available in the cluster?', 'Show me inference latency for Llama', 'Trace a slow inference request', etc.) that a user would genuinely say, covering synonyms and variations.

5 / 5

Distinctiveness Conflict Risk

Clear niche (AI observability on OpenShift AI) with distinct triggers and explicit NOT-for clauses ('NOT for deploying models (use /model-deploy)', 'NOT for debugging failed deployments (use /debug-inference)') minimizing conflict with sibling skills.

5 / 5

Total

20

/

20

Passed

Validation

93%

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

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
RHEcosystemAppEng/agentic-plugins
Reviewed

Table of Contents

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.