CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

performance-engineer

Expert performance engineer specializing in modern observability,

53

1.03x
Quality

43%

Does it follow best practices?

Impact

96%

1.03x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/antigravity-bundle-observability-monitoring/skills/performance-engineer/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

31%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 a persona document padded with tool taxonomies and redundant restatements rather than an operational skill: it tells Claude what to be, not concretely what to do. The trigger/scope sections and rough four-step methodology are its strongest parts, but there is no executable guidance, no validation loop, and no progressive disclosure of the ~100-line capability list.

Suggestions

Cut the Capabilities, Knowledge Base, and Behavioral Traits sections (or move a condensed tool reference to a separate references/ file linked from a short overview) — Claude already knows these tools, and the listing consumes most of the token budget.

Replace the generic Instructions with a concrete, sequenced workflow: specific first commands (e.g. an example flamegraph/trace query, a k6 load-test snippet, a Prometheus query for the baseline) and an explicit validate-then-iterate step such as "re-measure after each change and roll back if the budget is exceeded".

Merge the duplicated Purpose/Response Approach/Instructions sections into one workflow and add a concrete worked example (one end-to-end bottleneck diagnosis with commands and before/after metrics) in place of the prompt-only "Example Interactions".

DimensionReasoningScore

Conciseness

The Capabilities section spends ~90 lines enumerating tools Claude already knows ("DataDog APM, New Relic, Dynatrace, AppDynamics, Honeycomb, Jaeger"; "k6, JMeter, Gatling, Locust, Artillery"), and Purpose, Knowledge Base, and Behavioral Traits largely restate one another. This matches anchor 2 (noticeably verbose, several padded sections); it is not 1 because it pads with taxonomy rather than explaining known concepts, and the Use/Do-not-use and Instructions sections carry real weight.

2 / 5

Actionability

Guidance like "Collect traces, profiles, and load tests to isolate bottlenecks" and "Propose optimizations with expected impact and tradeoffs" is high-level direction with no commands, tool invocations, code, or worked examples — the "Example Interactions" are only quoted prompts, not demonstrations. This matches anchor 2 (high-level hints missing the specific steps to execute); not 3 because there is no partially executable detail anywhere, and not 1 because a usable rough methodology (baseline → isolate → propose → verify) is present.

2 / 5

Workflow Clarity

The Instructions give a coherent 4-step sequence ("Confirm performance goals... Collect traces... Propose optimizations... Verify results and add guardrails") and the Safety section adds production-guardrail guidance. However, validation is implicit and generic ("verify results") with no error-recovery or re-measurement loop. This matches anchor 3 (sequence present but checkpoints missing or implicit); not 4 because checkpoints lack specificity, not 2 because the ordering is clear and safety steps exist.

3 / 5

Progressive Disclosure

There are no bundle files and no references at all; the ~100-line Capabilities taxonomy is inlined material that clearly belongs in a separate reference file or should be cut. This matches anchor 2 (content that clearly belongs in separate files is inlined); not 3 because there are no references to signal, and not 1 because section headers do give the document navigable structure rather than a monolithic wall.

2 / 5

Total

9

/

20

Passed

Description

28%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 a truncated persona label (it even ends mid-sentence with a comma) rather than a capability statement: it identifies the domain but states no actions, no use-when triggers, and only one naturally spoken keyword. It would rarely be selected by a user's phrasing and overlaps with adjacent SRE/monitoring skills.

Suggestions

Rewrite the description as a capability statement with concrete verbs, e.g. "Diagnoses performance bottlenecks with tracing and profiling, designs load tests and capacity plans, and sets up observability with OpenTelemetry, Prometheus, and Grafana."

Add an explicit trigger clause: "Use when diagnosing slow responses, high latency, or throughput problems, when planning load tests or capacity, or when setting up performance monitoring."

Include natural user phrasings and synonyms ("slow", "latency", "optimize", "profiling", "load testing") so the skill triggers on how users actually describe performance problems.

DimensionReasoningScore

Specificity

The description states "Expert performance engineer specializing in modern observability," which names the domain but lists zero concrete actions (no diagnosing, load testing, or optimizing verbs). It matches anchor 2 (domain named, actions minimal or generic) rather than 3, which requires 1-2 concrete actions, and not 1 because the domain is clearly identified rather than purely abstract.

2 / 5

Completeness

The description offers a vague "what" (a persona label — it says what the agent is, not what it does) and entirely omits any "when to use" guidance, which lives only in the body. This matches anchor 2 ("has a vague 'what' and no 'when'"); the missing 'Use when' clause would cap it at 3 regardless, and the vagueness of the 'what' pushes it to 2.

2 / 5

Trigger Term Quality

Only "performance" is a term a user would naturally say when needing this skill; "observability" is practitioner jargon, and natural phrases like "slow", "latency", "optimize", "load test", or "profiling" are absent. This falls between anchors 2 and 3 but sits noticeably below the midpoint, matching "one or two generic keywords; missing the natural phrases users say".

2 / 5

Distinctiveness Conflict Risk

"Performance engineer specializing in modern observability" carves out a recognizable niche, but it would overlap with SRE, DevOps, and monitoring skills and could fire on generic "make it faster" requests. It matches anchor 3 (somewhat specific but could still overlap with similar skills); it is not 4 because no distinct trigger phrase separates it from adjacent skills.

3 / 5

Total

9

/

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

administrakt0r/AI-Agents-Safe-Coding-Skills

Path

plugins/antigravity-bundle-observability-monitoring/skills/performance-engineer/SKILL.md

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.