CtrlK
BlogDocsLog inGet started
Tessl Logo

confluent-tuning-advisor

Advisory-only Kafka tuning for Confluent Cloud or Confluent Platform by priority: latency, throughput, availability, or durability. Use when asked to size a planned topic or tune an existing cluster, topic, producer, or consumer for a quantified target such as lower p99 latency or no lost acknowledged writes. Inspects configuration read-only and recommends changes, trade-offs, and validation; the administrator applies them. Do NOT trigger for: WarpStream or Apache Kafka OSS-only clusters; Flink SQL or UDF authoring, tuning, or debugging (use confluent-cloud-flink-sql or flink-udf); Kafka Connect tuning; new Java/Python client implementation (use developing-kafka-java-client or developing-kafka-python-client); Kafka Streams/KStream/KTable development (use kafka-streams-programming); or CDC, Tableflow, or Iceberg pipelines (use confluent-cloud-cdc-tableflow).

70

Quality

88%

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

77%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 well-structured advisory workflow: clear sequencing, explicit validation and iteration loops, and exemplary progressive disclosure via a purpose-mapped reference table. The main cost is repetition — the advisory-only boundary and decline rules are enforced through restatement rather than a single authoritative statement, which inflates the body without adding new guidance.

Suggestions

State the advisory-only/no-writes boundary once authoritatively (e.g. in the intro blockquote or the Security section) and refer back to it from Steps 5–7 instead of restating it in each step — this alone would trim a substantial number of lines.

Consolidate the duplicated decline-rule text in Step 2 (the Flink hard stop and the general handoff rule each repeat their closing sentence) into one statement of the rule.

Include one concrete, verified example of the read-only describe operation per channel (CLI/MCP/REST) in Step 3, which would lift actionability from 4 toward 5.

DimensionReasoningScore

Conciseness

Mostly efficient, skill-specific guidance with no filler about concepts Claude already knows, but it could be tightened: the advisory-only/no-writes rule is restated at least five times (intro blockquote, Step 5, Step 6, Step 7, and the Security section), and Step 2 repeats the decline rule almost verbatim ("Declining is the whole response" appears twice in one section, plus the Flink stop is restated from the description). This matches 'mostly efficient but includes some unnecessary explanation or could be tightened', not the 'minor instances that could be trimmed' of 4.

3 / 5

Actionability

The fill-in recommendation template in Step 5, named metrics (UnderReplicatedPartitions, records-lag-max), and named tools (kafka-producer-perf-test / kafka-consumer-perf-test) give mostly executable, concrete guidance for an instruction-only skill. It stops short of 5 because actual command syntax is deliberately deferred to 'the current documentation' rather than given, leaving minor gaps the administrator must fill; it is well above the pseudocode level of 3.

4 / 5

Workflow Clarity

The 8-step workflow is clearly sequenced with explicit validation checkpoints (Step 3 baseline inspection, Step 7 validation metrics, Step 8 iterate-and-refine feedback loop when the target isn't met), and edge cases like un-inspectable baselines and planned-but-uncreated topics are handled. This matches the top anchor's 'explicit validation steps; feedback loops for error recovery' without needing the simple-skill exception.

5 / 5

Progressive Disclosure

A 'When to read which file' table maps each situation to exactly one of four real reference files (verified present in references/), each one level deep with content actually in the file (cross-links are between siblings, not chains), and the body explicitly says 'Do not read all of these upfront — pull in only what the current step needs'. This fits the 'clear overview with well-signaled one-level-deep references' anchor.

5 / 5

Total

17

/

20

Passed

Description

92%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 description: concrete capabilities, explicit 'Use when' triggers, third-person voice, and an unusually thorough exclusion list that sharply reduces mis-trigger risk against sibling Confluent skills. The only weakness is a handful of missing natural synonyms (optimize, performance, lag) in the trigger vocabulary.

Suggestions

Add one or two common user phrasings to the trigger clause, e.g. "optimize Kafka performance" or "fix consumer lag", so the description matches how users naturally phrase tuning requests.

Optionally note that "tuning" here means configuration changes (not code refactoring) in a few words, to further separate it from the client-development skills it already excludes.

DimensionReasoningScore

Specificity

The description lists multiple concrete, distinct actions in third person — "Advisory-only Kafka tuning for Confluent Cloud or Confluent Platform by priority", "Inspects configuration read-only and recommends changes, trade-offs, and validation" — covering sizing, tuning, inspection, and recommendation comprehensively within its scope. It clearly matches the 'lists multiple specific concrete actions; comprehensive coverage' anchor and does not fall to 4, which would require minor gaps in coverage.

5 / 5

Completeness

It explicitly answers both what ("Inspects configuration read-only and recommends changes, trade-offs, and validation; the administrator applies them") and when ("Use when asked to size a planned topic or tune an existing cluster, topic, producer, or consumer for a quantified target such as lower p99 latency"), with concrete trigger phrases. It matches the top anchor exactly; the 'when could be more explicit' caveat of the 4-anchor does not apply.

5 / 5

Trigger Term Quality

Strong natural terms users would say — "tune an existing cluster, topic, producer, or consumer", "size a planned topic", "lower p99 latency", "no lost acknowledged writes" — but a few common phrasings are absent (e.g. "optimize", "performance", "consumer lag", "scaling"). This is 'good keyword coverage; a few natural terms missing', above the midpoint but short of the comprehensive-with-synonyms anchor at 5.

4 / 5

Distinctiveness Conflict Risk

A clear niche (Confluent Cloud/Platform Kafka tuning only) with an explicit "Do NOT trigger for" clause routing each adjacent domain (Flink, Connect, client development, Streams, CDC/Tableflow) to a named sibling skill. Conflict risk is minimal; this fits the 'clear niche with distinct triggers' anchor and is not merely 'mostly distinct' as at 4.

5 / 5

Total

19

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
confluentinc/agent-skills
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.