[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DRK641W03RKB050P9YDNJQ":3,"skill-same:01M6DRK641W03RKB050P9YDNJQ":106},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":6,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":68,"updatedAt":69,"install":70,"resources":83},"01M6DRK641W03RKB050P9YDNJQ","confluent-tuning-advisor",null,"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\u002FPython client implementation (use developing-kafka-java-client or developing-kafka-python-client); Kafka Streams\u002FKStream\u002FKTable development (use kafka-streams-programming); or CDC, Tableflow, or Iceberg pipelines (use confluent-cloud-cdc-tableflow).","confluentinc\u002Fagent-skills","confluentinc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F9439498?v=4","01M6DRHHXAPZ51S955GTK4NG5H","Confluent Inc.","01M6DRHJ1QGVS341XSPAW6G0QF",64,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"tuning","confluent tuning advisor","confluent","advisor","sql","debugging","connect","apache","iceberg","server","testing","api","access","read","only","mcp server","local","scripts","cli","MCP","2026-11-10 10:12:30",false,"---\nname: confluent-tuning-advisor\ndescription: \"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\u002FPython client implementation (use developing-kafka-java-client or developing-kafka-python-client); Kafka Streams\u002FKStream\u002FKTable development (use kafka-streams-programming); or CDC, Tableflow, or Iceberg pipelines (use confluent-cloud-cdc-tableflow).\"\ncompatibility: Advisory \u002F read-only, no bundled scripts. Inspection uses the Confluent CLI (`confluent`) logged in, a configured Confluent MCP server, or the Kafka REST v3 \u002F REST Proxy v3 API (config reads) and Cloud Metrics API \u002F Platform JMX (metric reads). Needs read access to Confluent Cloud or Confluent Platform; local Docker with `confluent-local` or `cp-all-in-one` is supported for development testing.\nmetadata:\n  author: confluent\n  version: \"1.0.1\"\n  last_updated: \"2026-09-06\"\n---\n\n# Confluent Tuning Advisor\n\nTurns a workload's priority (latency, throughput, availability, or durability) into a concrete,\nplatform-appropriate **recommendation**: which Kafka settings to change, from what to what, why,\nwhat it trades against, and how the administrator should validate it afterward. Targets\n**Confluent Cloud** and **Confluent Platform** only. **Kafka only** — Flink (including Flink SQL\njob tuning) is out of scope; see the \"Do NOT trigger\" clause in the description.\n\nThese four priorities are not independent — every recommendation trades against at least one\nother axis. The core job of this skill is to make that trade-off explicit, not to pretend a\nfree lunch exists.\n\n> **Advisory-only — this skill never changes anything.** It may inspect configuration and runtime\n> state (read-only) and propose changes. It must **never** apply changes, run write\u002Fproduce\n> operations, or otherwise mutate a broker, topic, or client — the administrator or developer is\n> solely responsible for reviewing and applying any recommendation. Keep recommendation and\n> execution strictly separate: present the proposed change, do **not** ask for permission to apply\n> it, do **not** apply it, and never state or imply that a change has been made. This skill ships no\n> executable scripts; the only actions it takes are **read-only** config\u002Fmetric inspection via the\n> Confluent CLI, an MCP server, or the Kafka REST v3 \u002F REST Proxy v3 and Cloud Metrics APIs.\n\n## When to read which file\n\n| Situation | Read this |\n|---|---|\n| User is targeting Confluent Cloud | [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) |\n| User is targeting Confluent Platform (self-managed) | [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) |\n| Any config knob lookup by priority (producer\u002Fconsumer\u002Ftopic\u002Fbroker) | [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) |\n| Verifying a **Platform** change, or choosing which broker JMX metric proves it worked (Step 7) | [references\u002Fmonitoring.md](references\u002Fmonitoring.md) |\n| Verifying a **Cloud** change, or choosing which metric proves it worked (Step 7) | [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) for server-side metrics; use [references\u002Fmonitoring.md](references\u002Fmonitoring.md) only for the client-metrics sections |\n\nDo not read all of these upfront — pull in only what the current step needs.\n\n## Core workflow\n\n1. Capture the workload and priority\n2. Detect platform (Cloud vs Platform) and read the matching reference file\n3. Inspect the current effective config as a baseline (read-only)\n4. Look up recommendations in `references\u002Ftuning-parameters.md`\n5. Present the recommendation — proposed changes with rationale, impact, risks, prerequisites, and\n   validation steps (do not ask to apply, do not apply)\n6. Hand off to the administrator, who reviews and applies it themselves\n7. Give the administrator the validation steps to confirm the change once they apply it\n8. Iterate on the recommendation if the target still isn't met\n\n---\n\n## Step 1: Capture the workload and priority\n\nAsk, in one pass:\n\n1. **Primary priority** — exactly one of: latency, throughput, availability, durability.\n   A user may name a secondary priority too; make clear the primary always wins when they conflict.\n2. **What \"good\" looks like, quantified** — e.g. \"p99 producer-to-consumer latency under 20ms\",\n   \"sustain 200 MB\u002Fs\", \"survive loss of one AZ with zero downtime\", \"zero data loss even if a\n   broker dies mid-write\". Vague goals (\"make it fast\") should be pushed back on — ask for a number.\n3. **Workload shape** — approximate message size, expected messages\u002Fsec, number of\n   producers\u002Fconsumers, whether messages are transactional\u002Fexactly-once, current topic name(s)\n   and partition count if they already exist.\n4. **What's actually hurting today**, if this is an existing workload (a specific symptom beats a\n   guess).\n\nIf the user only says which axis matters and nothing else, proceed with the interview above\nbefore touching any reference file — the recommendation depends on the quantified target, not\njust the axis name.\n\n## Step 2: Detect platform\n\nAsk which platform this workload runs on: **Confluent Cloud** or **Confluent Platform**\n(self-managed). This skill does not cover WarpStream or unmanaged Apache Kafka — say so and stop\nif the user names one of those. It also does not cover **Kafka Connect** (connector or worker\ntuning) — if the request is about a connector or Connect worker, say it's out of scope and stop.\n\n**Flink is a hard stop.** If the request mentions Flink at all — a Flink SQL job, a Flink pipeline,\nparallelism, checkpointing, state backend, a lagging\u002Fslow Flink statement, a UDF — this skill does\nnot apply. Say it's out of scope and route the user to `confluent-cloud-flink-sql` (Flink SQL) or\n`flink-udf` (Flink UDFs), then **stop**. Do **not** proceed into the workflow, and do **not** offer\nto tune the underlying Kafka topic\u002Fproducer\u002Fconsumer as a fallback or consolation — declining is the\nwhole response. (If the user later comes back with a request that is solely about Kafka topic or\nclient configuration, with no Flink tuning ask, treat that as a fresh in-scope request.)\n\n**Every out-of-scope handoff follows that same rule.** Whenever this skill declines — new client\napplication code (`developing-kafka-java-client`, `developing-kafka-python-client`), Kafka Streams\n(`kafka-streams-programming`), Kafka Connect, CDC\u002FTableflow (`confluent-cloud-cdc-tableflow`),\nWarpStream, or Apache Kafka OSS — name the right skill and stop. Do not attach tuning\nrecommendations, default values, or \"worth deciding up front\" configuration advice to the handoff.\nOffering `acks`, partition-count, or any other setting alongside a decline is still a tuning\nrecommendation, and it is exactly what makes the handoff fail. Declining is the whole response.\n\nRead the matching reference file now:\n- Confluent Cloud → [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) — cluster\n  tier limits, what Confluent manages vs. what you can set, quota mechanics.\n- Confluent Platform → [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) —\n  broker-level knobs, rack awareness, JVM\u002FOS-level factors that matter for tail latency.\n\n## Step 3: Inspect the current config as a baseline (read-only)\n\nBefore recommending anything, capture what's actually configured today — recommendations phrased\nas diffs are easier to reason about and to confirm than absolute values. This is a **read-only**\ninspection (a `describeConfigs`); it changes nothing. Use whichever of these the environment\nalready has:\n\n- **CLI**: use the current Confluent CLI documentation to find the read-only topic-description\n  operation for the target platform and installed CLI version.\n- **MCP tools**: discover a read-only topic-description or topic-config listing tool from the\n  configured Confluent MCP server — preferred for discovery when available.\n- **REST**: use the read-only topic-config listing operation in the current\n  [Confluent Cloud Kafka REST v3 API reference](https:\u002F\u002Fdocs.confluent.io\u002Fcloud\u002Fcurrent\u002Fapi.md#tag\u002FCluster-(v3))\n  or [Confluent Platform REST Proxy v3 API reference](https:\u002F\u002Fdocs.confluent.io\u002Fplatform\u002Fcurrent\u002Fkafka-rest\u002Fapi.md#rest-proxy-v3),\n  as appropriate. A Kafka bootstrap address is not an HTTP endpoint; use the cluster's advertised\n  REST endpoint.\n\nFor a planned topic that does not exist, do not attempt to describe it. Record its topic config as\n\"not created\", then inspect only the cluster defaults and capacity limits needed to size it. In\nStep 5, present proposed initial values rather than a current → recommended diff for that topic.\n\nFor broker\u002Fcluster-level baselines (Platform only — Cloud does not expose these), use the CLI\u002FREST\nequivalent of `describeConfigs` against the **broker** resource. Capture the values you'll be\nproposing to change, so Step 5 can be written as a clean current → recommended diff.\n\nIf a required client or broker baseline cannot be inspected or the user has not supplied it, do\nnot infer a remembered default and present it as current state. Ask for the missing effective\nvalues, or limit the response to diagnostic directions and clearly labeled candidate changes until\nthe baseline is available.\n\nTwo rules govern every value the recommendation reports:\n\n- **Source each claim.** Every current value, platform capability, and cluster-type behavior must\n  trace to an inspected result, current documentation, or the user's own statement. If it traces to\n  none of those, it is not a fact — raise it as an open question under Prerequisites instead of\n  asserting it.\n- **Respect read-only results.** When inspection reports a key as read-only (`is_read_only=true`),\n  never propose changing, removing, or overriding it. Note that the platform manages it and move on.\n\n## Step 4: Look up recommendations\n\nOpen [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) and read the row for\neach config surface relevant to the workload (producer, consumer, topic\u002Freplication,\nbroker\u002Fcluster). It gives, per priority, the recommended value and the one-line reason. Do not\ncopy every row blindly — reconcile with the quantified target from Step 1. For example, an\n\"availability\" priority with only 2 brokers available changes what `min.insync.replicas` can\nsafely be set to; say so explicitly rather than recommending a value the cluster can't sustain.\n\n## Step 5: Present the recommendation\n\nProduce a recommendation, not a request to act. **Do not ask \"should I apply this?\" and do not\napply anything** — the administrator owns execution. Use this format:\n\n```\nTuning recommendation — priority: \u003Clatency|throughput|availability|durability>\nTarget: \u003Cthe quantified goal from Step 1>\nPlatform: \u003CConfluent Cloud | Confluent Platform>\n\nProposed changes (current → recommended):\n  \u003Cconfig.key>            \u003Ccurrent value>  →  \u003Crecommended value>   (why: \u003Cone line>)\n  \u003Cconfig.key>            \u003Ccurrent value>  →  \u003Crecommended value>   (why: \u003Cone line>)\n  ...\n\nFor `replication.factor` changes, follow the topic-creation and reassignment guidance in\n[references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md).\nNever recommend deleting and recreating an existing topic solely to change its replication factor;\non Confluent Platform, preserve the topic and use an explicit replica reassignment after confirming\nbroker and rack capacity.\n\nExpected impact: \u003Cwhat should measurably improve, tied to the Step 1 target>\nTrade-off \u002F risk: \u003Cwhat gets worse on another axis, stated plainly — e.g.\n  \"min.insync.replicas 3→2 improves availability during a single-broker outage but\n  means a write can be acknowledged with one fewer copy durably stored\">\nPrerequisites: \u003Canything that must be true\u002Fchecked first — e.g. broker.rack configured,\n  cluster tier supports multi-zone, enough brokers to sustain the new min.insync.replicas>\n\nHow to apply (for the administrator to run — this skill does not run these):\n  1. \u003Cdescription>\n     Command\u002Ftool: \u003Coperation and current documentation link; include exact syntax only after\n       verifying it against the installed CLI, discovered MCP tool, or current API documentation>\n  2. ...\n\nValidation (Step 7) — how the administrator confirms it worked after applying:\n  Server-side metric: \u003Ca metric name confirmed available on this platform — a Platform JMX MBean,\n    or a Cloud metric returned by live descriptor discovery. When the target is Cloud and\n    descriptors are unavailable, name no server-side metric here and emit exactly this line:\n    Server-side metric validation: pending descriptor access>\n  Client\u002Fapplication signal: \u003Can accessible client metric or application-level SLI>\n  Benchmark (optional, administrator-run): \u003Cthe before\u002Fafter measurement from Step 7>\n```\n\nPresent the \"How to apply\" commands as reference material the administrator executes on their own\nauthority — never as something this skill will run, and never phrased as a request for permission\nto run them. If the user pushes back or asks for a different balance, revise the recommendation and\nre-present it.\n\n## Step 6: Hand off for execution (the administrator applies, not this skill)\n\n**This skill does not apply the change.** It stops at the recommendation. The administrator or\ndeveloper reviews it and applies it themselves, on their own authority, using whatever tooling they\nalready have. The \"How to apply\" block in Step 5 lists the exact operations *for them to run* — so\nthey can review and execute without guesswork — using one of:\n\n- **MCP tools** — a discovered topic-config update tool, if their Confluent MCP server exposes one.\n- **CLI** — the current documented topic-config update operation for the target platform and\n  installed CLI version.\n- **REST \u002F Admin API** — use the current Confluent Platform documentation for broker-level changes;\n  Cloud does not expose broker configuration.\n\nWhen the change is disruptive (e.g. a broker restart, or a broker-level default that affects every\ntopic on the cluster), say so and recommend the administrator apply it one broker at a time and\nconfirm cluster health between brokers — as guidance in the recommendation, not as an action this\nskill takes. Never run any of these operations yourself, and never say a change \"has been applied\";\nat most, note what the administrator will observe once *they* apply it.\n\n## Step 7: Give the administrator validation steps\n\nHand the administrator a way to confirm the change actually moved the target metric — don't let\nthem just trust that the config took effect. These are steps *they* run after applying; this skill\ndoes not run them (a benchmark produces and consumes records, which is a write\u002Fmutation, and is out\nof scope for an advisory-only skill).\n\nTwo parts to the validation you recommend:\n\n1. **A metric to watch (and keep alerted).** Name the specific metric that proves the change worked,\n   per priority, from [references\u002Fmonitoring.md](references\u002Fmonitoring.md) — e.g.\n   `UnderReplicatedPartitions` for availability\u002Fdurability, the request-latency breakdown for\n   latency, `records-lag-max` for consumer throughput. On Confluent Platform these are JMX MBeans;\n  on Confluent Cloud, use the available Metrics API equivalents and client metrics rather than\n  assuming every broker JMX MBean is exposed. When giving Platform JMX names, label them as\n  Platform-only and include this Cloud distinction explicitly, even if the current target is\n  Platform. This is read-only and is the primary validation.\n\n  **Cloud validation hard stops:** validation for Confluent Cloud must never include stopping,\n  restarting, killing, isolating, or otherwise fault-injecting a managed broker — not as an\n  administrator step, optional test, hypothetical procedure, or future recommendation. Do not\n  describe such a procedure in the response. Validate only through the documented cluster-type\n  guarantee, effective topic and producer configuration, accessible client\u002Fapplication signals,\n  and server-side metrics confirmed by live Metrics API descriptor discovery. Never reuse a\n  Platform JMX MBean name as a Cloud metric name unless discovery returns that exact name. If\n  cluster-type metadata, Metrics API credentials, or descriptors are unavailable, explicitly mark\n  those parts of validation pending; do not replace them with broker manipulation or inferred\n  metric names.\n\n2. **An optional before\u002Fafter benchmark the administrator runs themselves.** If they want a\n   measured before\u002Fafter, recommend they run it with their own tooling — this skill ships nothing\n   and runs nothing (benchmarking produces\u002Fconsumes records, a write, which is the administrator's\n   to do). Point them at whatever they already have:\n   - `kafka-producer-perf-test` \u002F `kafka-consumer-perf-test` (ship with Kafka\u002FConfluent Platform).\n   - or their existing load-test harness against a staging topic.\n\n   Recommend running it once before applying and once after, comparing **p99 (tail) latency** (not\n   just the average — SLAs are written against the tail) and achieved throughput, measuring\n   end-to-end latency as producer `send()` → consumer `poll()`.\n\nFrame the result against the Step 1 target and restate the trade-off from Step 5, so the\nadministrator knows what to expect to improve and what to expect to get worse. There is no one-size-fits-all config, so\n**the administrator's own before\u002Fafter measurement, not the recommendation table, is the proof.**\n\n## Step 8: Iterate on the recommendation\n\nIf, after the administrator applies and validates a recommendation, the target still isn't met,\nre-inspect the new baseline (Step 3) and refine the recommendation (Step 4). Common reasons a\nsingle pass isn't enough: partition count is a bottleneck (throughput), client-side batching\nsettings weren't also changed to match the new broker\u002Ftopic config, or the workload is bound by\nsomething outside Kafka entirely (serialization cost, network path, downstream consumer processing\ntime) — say so rather than continuing to recommend Kafka knobs that won't help.\n\n---\n\n## Security and data handling\n\n- **Never read `.env` file contents** with `cat`, `Read`, `head`, `grep`, or any other tool.\n  Reference variables by name only (e.g. `$BOOTSTRAP_SERVERS`) and verify presence with\n  `test -n \"$VAR\"`, never by printing the value.\n- Add `.env` to `.gitignore` to avoid accidentally committing credentials.\n- Eval prompts, fixtures, and any example data in this skill use synthetic values only —\n  `example.com`\u002F`.example` names, fabricated cluster\u002Ftopic ids. Never substitute real customer\n  identifiers, hostnames, or credentials when adapting this skill's examples.\n- **Advisory-only, no writes.** This skill must never apply changes, run write\u002Fproduce\u002Falter\n  operations, or mutate a broker, topic, or client — not even a \"safe\" or \"dry-run then confirm\"\n  apply, and not even if the user says to proceed. It ships **no executable scripts**; its only\n  actions are **read-only** config\u002Fmetric inspection via the Confluent CLI, an MCP server, or the\n  Kafka REST v3 \u002F REST Proxy v3 API (topic-config reads) and the Cloud Metrics API \u002F Platform JMX\n  (metric reads). Any benchmarking produces\u002Fconsumes\n  records and is therefore the **administrator's** to run, never this skill. Recommend; never\n  execute. Never request permission to apply, and never claim or imply a change was applied — if\n  asked to make the change, restate that applying it is the administrator's responsibility and\n  provide the exact operation for them to run.\n\n## Reference files\n\n- [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) — cluster tier trade-offs, what\n  Confluent Cloud manages vs. exposes, quota mechanics, multi-zone, and Cluster Linking DR\n  (RPO\u002FRTO reality).\n- [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) — broker-level configs,\n  rack awareness, the hardware\u002FOS\u002FJVM baseline (heap, page cache, GC, disks, file descriptors),\n  and multi-datacenter DR.\n- [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) — the producer\u002Fconsumer\u002F\n  topic\u002Fbroker config matrix (one row per setting, one column per priority), partition sizing, and\n  benchmarking\u002Fservice-goal method.\n- [references\u002Fmonitoring.md](references\u002Fmonitoring.md) — the JMX\u002FMetrics-API metrics that prove a\n  tuning change worked, grouped by priority, with the baseline set to always alert on.\n","# Confluent Tuning Advisor\n\nTurns a workload's priority (latency, throughput, availability, or durability) into a concrete,\nplatform-appropriate **recommendation**: which Kafka settings to change, from what to what, why,\nwhat it trades against, and how the administrator should validate it afterward. Targets\n**Confluent Cloud** and **Confluent Platform** only. **Kafka only** — Flink (including Flink SQL\njob tuning) is out of scope; see the \"Do NOT trigger\" clause in the description.\n\nThese four priorities are not independent — every recommendation trades against at least one\nother axis. The core job of this skill is to make that trade-off explicit, not to pretend a\nfree lunch exists.\n\n> **Advisory-only — this skill never changes anything.** It may inspect configuration and runtime\n> state (read-only) and propose changes. It must **never** apply changes, run write\u002Fproduce\n> operations, or otherwise mutate a broker, topic, or client — the administrator or developer is\n> solely responsible for reviewing and applying any recommendation. Keep recommendation and\n> execution strictly separate: present the proposed change, do **not** ask for permission to apply\n> it, do **not** apply it, and never state or imply that a change has been made. This skill ships no\n> executable scripts; the only actions it takes are **read-only** config\u002Fmetric inspection via the\n> Confluent CLI, an MCP server, or the Kafka REST v3 \u002F REST Proxy v3 and Cloud Metrics APIs.\n\n## When to read which file\n\n| Situation | Read this |\n|---|---|\n| User is targeting Confluent Cloud | [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) |\n| User is targeting Confluent Platform (self-managed) | [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) |\n| Any config knob lookup by priority (producer\u002Fconsumer\u002Ftopic\u002Fbroker) | [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) |\n| Verifying a **Platform** change, or choosing which broker JMX metric proves it worked (Step 7) | [references\u002Fmonitoring.md](references\u002Fmonitoring.md) |\n| Verifying a **Cloud** change, or choosing which metric proves it worked (Step 7) | [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) for server-side metrics; use [references\u002Fmonitoring.md](references\u002Fmonitoring.md) only for the client-metrics sections |\n\nDo not read all of these upfront — pull in only what the current step needs.\n\n## Core workflow\n\n1. Capture the workload and priority\n2. Detect platform (Cloud vs Platform) and read the matching reference file\n3. Inspect the current effective config as a baseline (read-only)\n4. Look up recommendations in `references\u002Ftuning-parameters.md`\n5. Present the recommendation — proposed changes with rationale, impact, risks, prerequisites, and\n   validation steps (do not ask to apply, do not apply)\n6. Hand off to the administrator, who reviews and applies it themselves\n7. Give the administrator the validation steps to confirm the change once they apply it\n8. Iterate on the recommendation if the target still isn't met\n\n---\n\n## Step 1: Capture the workload and priority\n\nAsk, in one pass:\n\n1. **Primary priority** — exactly one of: latency, throughput, availability, durability.\n   A user may name a secondary priority too; make clear the primary always wins when they conflict.\n2. **What \"good\" looks like, quantified** — e.g. \"p99 producer-to-consumer latency under 20ms\",\n   \"sustain 200 MB\u002Fs\", \"survive loss of one AZ with zero downtime\", \"zero data loss even if a\n   broker dies mid-write\". Vague goals (\"make it fast\") should be pushed back on — ask for a number.\n3. **Workload shape** — approximate message size, expected messages\u002Fsec, number of\n   producers\u002Fconsumers, whether messages are transactional\u002Fexactly-once, current topic name(s)\n   and partition count if they already exist.\n4. **What's actually hurting today**, if this is an existing workload (a specific symptom beats a\n   guess).\n\nIf the user only says which axis matters and nothing else, proceed with the interview above\nbefore touching any reference file — the recommendation depends on the quantified target, not\njust the axis name.\n\n## Step 2: Detect platform\n\nAsk which platform this workload runs on: **Confluent Cloud** or **Confluent Platform**\n(self-managed). This skill does not cover WarpStream or unmanaged Apache Kafka — say so and stop\nif the user names one of those. It also does not cover **Kafka Connect** (connector or worker\ntuning) — if the request is about a connector or Connect worker, say it's out of scope and stop.\n\n**Flink is a hard stop.** If the request mentions Flink at all — a Flink SQL job, a Flink pipeline,\nparallelism, checkpointing, state backend, a lagging\u002Fslow Flink statement, a UDF — this skill does\nnot apply. Say it's out of scope and route the user to `confluent-cloud-flink-sql` (Flink SQL) or\n`flink-udf` (Flink UDFs), then **stop**. Do **not** proceed into the workflow, and do **not** offer\nto tune the underlying Kafka topic\u002Fproducer\u002Fconsumer as a fallback or consolation — declining is the\nwhole response. (If the user later comes back with a request that is solely about Kafka topic or\nclient configuration, with no Flink tuning ask, treat that as a fresh in-scope request.)\n\n**Every out-of-scope handoff follows that same rule.** Whenever this skill declines — new client\napplication code (`developing-kafka-java-client`, `developing-kafka-python-client`), Kafka Streams\n(`kafka-streams-programming`), Kafka Connect, CDC\u002FTableflow (`confluent-cloud-cdc-tableflow`),\nWarpStream, or Apache Kafka OSS — name the right skill and stop. Do not attach tuning\nrecommendations, default values, or \"worth deciding up front\" configuration advice to the handoff.\nOffering `acks`, partition-count, or any other setting alongside a decline is still a tuning\nrecommendation, and it is exactly what makes the handoff fail. Declining is the whole response.\n\nRead the matching reference file now:\n- Confluent Cloud → [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) — cluster\n  tier limits, what Confluent manages vs. what you can set, quota mechanics.\n- Confluent Platform → [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) —\n  broker-level knobs, rack awareness, JVM\u002FOS-level factors that matter for tail latency.\n\n## Step 3: Inspect the current config as a baseline (read-only)\n\nBefore recommending anything, capture what's actually configured today — recommendations phrased\nas diffs are easier to reason about and to confirm than absolute values. This is a **read-only**\ninspection (a `describeConfigs`); it changes nothing. Use whichever of these the environment\nalready has:\n\n- **CLI**: use the current Confluent CLI documentation to find the read-only topic-description\n  operation for the target platform and installed CLI version.\n- **MCP tools**: discover a read-only topic-description or topic-config listing tool from the\n  configured Confluent MCP server — preferred for discovery when available.\n- **REST**: use the read-only topic-config listing operation in the current\n  [Confluent Cloud Kafka REST v3 API reference](https:\u002F\u002Fdocs.confluent.io\u002Fcloud\u002Fcurrent\u002Fapi.md#tag\u002FCluster-(v3))\n  or [Confluent Platform REST Proxy v3 API reference](https:\u002F\u002Fdocs.confluent.io\u002Fplatform\u002Fcurrent\u002Fkafka-rest\u002Fapi.md#rest-proxy-v3),\n  as appropriate. A Kafka bootstrap address is not an HTTP endpoint; use the cluster's advertised\n  REST endpoint.\n\nFor a planned topic that does not exist, do not attempt to describe it. Record its topic config as\n\"not created\", then inspect only the cluster defaults and capacity limits needed to size it. In\nStep 5, present proposed initial values rather than a current → recommended diff for that topic.\n\nFor broker\u002Fcluster-level baselines (Platform only — Cloud does not expose these), use the CLI\u002FREST\nequivalent of `describeConfigs` against the **broker** resource. Capture the values you'll be\nproposing to change, so Step 5 can be written as a clean current → recommended diff.\n\nIf a required client or broker baseline cannot be inspected or the user has not supplied it, do\nnot infer a remembered default and present it as current state. Ask for the missing effective\nvalues, or limit the response to diagnostic directions and clearly labeled candidate changes until\nthe baseline is available.\n\nTwo rules govern every value the recommendation reports:\n\n- **Source each claim.** Every current value, platform capability, and cluster-type behavior must\n  trace to an inspected result, current documentation, or the user's own statement. If it traces to\n  none of those, it is not a fact — raise it as an open question under Prerequisites instead of\n  asserting it.\n- **Respect read-only results.** When inspection reports a key as read-only (`is_read_only=true`),\n  never propose changing, removing, or overriding it. Note that the platform manages it and move on.\n\n## Step 4: Look up recommendations\n\nOpen [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) and read the row for\neach config surface relevant to the workload (producer, consumer, topic\u002Freplication,\nbroker\u002Fcluster). It gives, per priority, the recommended value and the one-line reason. Do not\ncopy every row blindly — reconcile with the quantified target from Step 1. For example, an\n\"availability\" priority with only 2 brokers available changes what `min.insync.replicas` can\nsafely be set to; say so explicitly rather than recommending a value the cluster can't sustain.\n\n## Step 5: Present the recommendation\n\nProduce a recommendation, not a request to act. **Do not ask \"should I apply this?\" and do not\napply anything** — the administrator owns execution. Use this format:\n\n```\nTuning recommendation — priority: \u003Clatency|throughput|availability|durability>\nTarget: \u003Cthe quantified goal from Step 1>\nPlatform: \u003CConfluent Cloud | Confluent Platform>\n\nProposed changes (current → recommended):\n  \u003Cconfig.key>            \u003Ccurrent value>  →  \u003Crecommended value>   (why: \u003Cone line>)\n  \u003Cconfig.key>            \u003Ccurrent value>  →  \u003Crecommended value>   (why: \u003Cone line>)\n  ...\n\nFor `replication.factor` changes, follow the topic-creation and reassignment guidance in\n[references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md).\nNever recommend deleting and recreating an existing topic solely to change its replication factor;\non Confluent Platform, preserve the topic and use an explicit replica reassignment after confirming\nbroker and rack capacity.\n\nExpected impact: \u003Cwhat should measurably improve, tied to the Step 1 target>\nTrade-off \u002F risk: \u003Cwhat gets worse on another axis, stated plainly — e.g.\n  \"min.insync.replicas 3→2 improves availability during a single-broker outage but\n  means a write can be acknowledged with one fewer copy durably stored\">\nPrerequisites: \u003Canything that must be true\u002Fchecked first — e.g. broker.rack configured,\n  cluster tier supports multi-zone, enough brokers to sustain the new min.insync.replicas>\n\nHow to apply (for the administrator to run — this skill does not run these):\n  1. \u003Cdescription>\n     Command\u002Ftool: \u003Coperation and current documentation link; include exact syntax only after\n       verifying it against the installed CLI, discovered MCP tool, or current API documentation>\n  2. ...\n\nValidation (Step 7) — how the administrator confirms it worked after applying:\n  Server-side metric: \u003Ca metric name confirmed available on this platform — a Platform JMX MBean,\n    or a Cloud metric returned by live descriptor discovery. When the target is Cloud and\n    descriptors are unavailable, name no server-side metric here and emit exactly this line:\n    Server-side metric validation: pending descriptor access>\n  Client\u002Fapplication signal: \u003Can accessible client metric or application-level SLI>\n  Benchmark (optional, administrator-run): \u003Cthe before\u002Fafter measurement from Step 7>\n```\n\nPresent the \"How to apply\" commands as reference material the administrator executes on their own\nauthority — never as something this skill will run, and never phrased as a request for permission\nto run them. If the user pushes back or asks for a different balance, revise the recommendation and\nre-present it.\n\n## Step 6: Hand off for execution (the administrator applies, not this skill)\n\n**This skill does not apply the change.** It stops at the recommendation. The administrator or\ndeveloper reviews it and applies it themselves, on their own authority, using whatever tooling they\nalready have. The \"How to apply\" block in Step 5 lists the exact operations *for them to run* — so\nthey can review and execute without guesswork — using one of:\n\n- **MCP tools** — a discovered topic-config update tool, if their Confluent MCP server exposes one.\n- **CLI** — the current documented topic-config update operation for the target platform and\n  installed CLI version.\n- **REST \u002F Admin API** — use the current Confluent Platform documentation for broker-level changes;\n  Cloud does not expose broker configuration.\n\nWhen the change is disruptive (e.g. a broker restart, or a broker-level default that affects every\ntopic on the cluster), say so and recommend the administrator apply it one broker at a time and\nconfirm cluster health between brokers — as guidance in the recommendation, not as an action this\nskill takes. Never run any of these operations yourself, and never say a change \"has been applied\";\nat most, note what the administrator will observe once *they* apply it.\n\n## Step 7: Give the administrator validation steps\n\nHand the administrator a way to confirm the change actually moved the target metric — don't let\nthem just trust that the config took effect. These are steps *they* run after applying; this skill\ndoes not run them (a benchmark produces and consumes records, which is a write\u002Fmutation, and is out\nof scope for an advisory-only skill).\n\nTwo parts to the validation you recommend:\n\n1. **A metric to watch (and keep alerted).** Name the specific metric that proves the change worked,\n   per priority, from [references\u002Fmonitoring.md](references\u002Fmonitoring.md) — e.g.\n   `UnderReplicatedPartitions` for availability\u002Fdurability, the request-latency breakdown for\n   latency, `records-lag-max` for consumer throughput. On Confluent Platform these are JMX MBeans;\n  on Confluent Cloud, use the available Metrics API equivalents and client metrics rather than\n  assuming every broker JMX MBean is exposed. When giving Platform JMX names, label them as\n  Platform-only and include this Cloud distinction explicitly, even if the current target is\n  Platform. This is read-only and is the primary validation.\n\n  **Cloud validation hard stops:** validation for Confluent Cloud must never include stopping,\n  restarting, killing, isolating, or otherwise fault-injecting a managed broker — not as an\n  administrator step, optional test, hypothetical procedure, or future recommendation. Do not\n  describe such a procedure in the response. Validate only through the documented cluster-type\n  guarantee, effective topic and producer configuration, accessible client\u002Fapplication signals,\n  and server-side metrics confirmed by live Metrics API descriptor discovery. Never reuse a\n  Platform JMX MBean name as a Cloud metric name unless discovery returns that exact name. If\n  cluster-type metadata, Metrics API credentials, or descriptors are unavailable, explicitly mark\n  those parts of validation pending; do not replace them with broker manipulation or inferred\n  metric names.\n\n2. **An optional before\u002Fafter benchmark the administrator runs themselves.** If they want a\n   measured before\u002Fafter, recommend they run it with their own tooling — this skill ships nothing\n   and runs nothing (benchmarking produces\u002Fconsumes records, a write, which is the administrator's\n   to do). Point them at whatever they already have:\n   - `kafka-producer-perf-test` \u002F `kafka-consumer-perf-test` (ship with Kafka\u002FConfluent Platform).\n   - or their existing load-test harness against a staging topic.\n\n   Recommend running it once before applying and once after, comparing **p99 (tail) latency** (not\n   just the average — SLAs are written against the tail) and achieved throughput, measuring\n   end-to-end latency as producer `send()` → consumer `poll()`.\n\nFrame the result against the Step 1 target and restate the trade-off from Step 5, so the\nadministrator knows what to expect to improve and what to expect to get worse. There is no one-size-fits-all config, so\n**the administrator's own before\u002Fafter measurement, not the recommendation table, is the proof.**\n\n## Step 8: Iterate on the recommendation\n\nIf, after the administrator applies and validates a recommendation, the target still isn't met,\nre-inspect the new baseline (Step 3) and refine the recommendation (Step 4). Common reasons a\nsingle pass isn't enough: partition count is a bottleneck (throughput), client-side batching\nsettings weren't also changed to match the new broker\u002Ftopic config, or the workload is bound by\nsomething outside Kafka entirely (serialization cost, network path, downstream consumer processing\ntime) — say so rather than continuing to recommend Kafka knobs that won't help.\n\n---\n\n## Security and data handling\n\n- **Never read `.env` file contents** with `cat`, `Read`, `head`, `grep`, or any other tool.\n  Reference variables by name only (e.g. `$BOOTSTRAP_SERVERS`) and verify presence with\n  `test -n \"$VAR\"`, never by printing the value.\n- Add `.env` to `.gitignore` to avoid accidentally committing credentials.\n- Eval prompts, fixtures, and any example data in this skill use synthetic values only —\n  `example.com`\u002F`.example` names, fabricated cluster\u002Ftopic ids. Never substitute real customer\n  identifiers, hostnames, or credentials when adapting this skill's examples.\n- **Advisory-only, no writes.** This skill must never apply changes, run write\u002Fproduce\u002Falter\n  operations, or mutate a broker, topic, or client — not even a \"safe\" or \"dry-run then confirm\"\n  apply, and not even if the user says to proceed. It ships **no executable scripts**; its only\n  actions are **read-only** config\u002Fmetric inspection via the Confluent CLI, an MCP server, or the\n  Kafka REST v3 \u002F REST Proxy v3 API (topic-config reads) and the Cloud Metrics API \u002F Platform JMX\n  (metric reads). Any benchmarking produces\u002Fconsumes\n  records and is therefore the **administrator's** to run, never this skill. Recommend; never\n  execute. Never request permission to apply, and never claim or imply a change was applied — if\n  asked to make the change, restate that applying it is the administrator's responsibility and\n  provide the exact operation for them to run.\n\n## Reference files\n\n- [references\u002Fconfluent-cloud.md](references\u002Fconfluent-cloud.md) — cluster tier trade-offs, what\n  Confluent Cloud manages vs. exposes, quota mechanics, multi-zone, and Cluster Linking DR\n  (RPO\u002FRTO reality).\n- [references\u002Fconfluent-platform.md](references\u002Fconfluent-platform.md) — broker-level configs,\n  rack awareness, the hardware\u002FOS\u002FJVM baseline (heap, page cache, GC, disks, file descriptors),\n  and multi-datacenter DR.\n- [references\u002Ftuning-parameters.md](references\u002Ftuning-parameters.md) — the producer\u002Fconsumer\u002F\n  topic\u002Fbroker config matrix (one row per setting, one column per priority), partition sizing, and\n  benchmarking\u002Fservice-goal method.\n- [references\u002Fmonitoring.md](references\u002Fmonitoring.md) — the JMX\u002FMetrics-API metrics that prove a\n  tuning change worked, grouped by priority, with the baseline set to always alert on.\n",{"name":5,"metadata":57,"description":7,"compatibility":60},{"author":34,"version":58,"last_updated":59},"1.0.1","2026-09-06","Advisory \u002F read-only, no bundled scripts. Inspection uses the Confluent CLI (`confluent`) logged in, a configured Confluent MCP server, or the Kafka REST v3 \u002F REST Proxy v3 API (config reads) and Cloud Metrics API \u002F Platform JMX (metric reads). Needs read access to Confluent Cloud or Confluent Platform; local Docker with `confluent-local` or `cp-all-in-one` is supported for development testing.","main","204b36f10e9be41819557988e8f5291711fda986","skills\u002Fconfluent-tuning-advisor",11,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills","https:\u002F\u002Fgithub.com\u002Fconfluentinc","https:\u002F\u002Fconfluent.io","Real-time streams powered by Apache Kafka®","2026-10-27 13:08:16",{"source":8,"skillName":5,"commands":71,"prompt":81,"zipAvailable":82},[72,75,78],{"tool":73,"command":74},"npx","npx skills add confluentinc\u002Fagent-skills --skill confluent-tuning-advisor",{"tool":76,"command":77},"bunx","bunx skills add confluentinc\u002Fagent-skills --skill confluent-tuning-advisor",{"tool":79,"command":80},"pnpm","pnpm dlx skills add confluentinc\u002Fagent-skills --skill confluent-tuning-advisor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002FSKILL.md",true,[84,90,94,98,102],{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"evals\u002Fevals.json","REFERENCE","参考文档",52129,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002Fevals\u002Fevals.json",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fconfluent-cloud.md",12143,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002Freferences\u002Fconfluent-cloud.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fconfluent-platform.md",8487,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002Freferences\u002Fconfluent-platform.md",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fmonitoring.md",14643,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002Freferences\u002Fmonitoring.md",{"path":103,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Ftuning-parameters.md",24988,"https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fconfluent-tuning-advisor\u002Freferences\u002Ftuning-parameters.md",[107,133,158,186,205,221],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":115,"publishedAt":52},"01M6DRM9K8G3X7H4N445JGEVPT","msk-migration","Use this skill to assess and plan a migration from AWS MSK (Managed Streaming for Apache Kafka) to Confluent Cloud. Triggers on user intent like \"migrate MSK to Confluent Cloud\", \"move off MSK\", \"MSK to CC cutover\", \"Zero-Cut migration from MSK\", \"kcp scan my MSK\", or any discussion of MSK-to-CC assessment, planning, cluster sizing, Cluster Linking setup, Gateway-based switchover, or post-cutover validation. Do NOT trigger for non-MSK Kafka sources (open-source Kafka, Aiven, Confluent Platform, Redpanda) — this skill is MSK-only. Do NOT trigger for greenfield Confluent Cloud projects with no existing Kafka source. Do NOT trigger for general Kafka programming questions (producer\u002Fconsumer code, Kafka Streams) unrelated to migration.","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fmsk-migration\u002FSKILL.md",[113,114],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[116,117,118,119,39,120,121,122,123,124,125,46,126,127,128,129,130,34,131,132],"migration","msk migration","assessment","code","streaming","gateway","open","migrate","plan","projects","unrelated","intent","cc","do","cut","confluent cloud","kafka streams",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":140,"publishedAt":52},"01M6DRM48N8ZCGTA0MSNADJXJ9","kafka-streams-programming","Architect, build, and debug Kafka Streams apps (JVM-embedded stream processing). Use when user mentions KStream, KTable, topology, TopologyTestDriver, StreamsBuilder, interactive queries, GlobalKTable, joins\u002Fwindows\u002Faggregations, or debugging issues (rebalancing, state stores, lag, deserialization errors). Also use when user wants to optimize Kafka Streams for WarpStream or tune Kafka Streams client configuration for WarpStream. Do NOT trigger for Flink, connectors, CDC, or plain producer\u002Fconsumer.","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fkafka-streams-programming\u002FSKILL.md",[139],{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[141,142,132,143,144,145,146,37,147,148,149,150,151,152,153,129,154,155,156,157],"kafka","programming","kafka streams programming","windows","debug","connectors","issues","stream processing","cdc","topology","architect","interactive","use","optimize","jvm","trigger","apps",{"skillNo":159,"name":160,"nameZh":6,"description":161,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":168,"publishedAt":52},"01M6DRKX6HCEW6QC3TSJD47R3X","kafka-schema-registry","Scan a project to identify Kafka applications, extract schemas from data models, tag PII fields, generate Terraform for Confluent Schema Registry registration, and produce a migration report with rollout ordering. Use this skill when a user asks to analyze a folder or repo for Kafka usage, extract schemas, audit producer\u002Fconsumer configurations, or generate Terraform for Schema Registry.","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fkafka-schema-registry\u002FSKILL.md",[164,167],{"categoryNo":165,"categoryName":166,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[169,141,170,171,172,173,174,175,176,177,178,179,180,153,181,116,182,183,184,185],"registry","schema","kafka schema registry","generate","report","produce","audit","data","pii","applications","analyze","repo","rollout","models","registration","scan","project",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":195,"publishedAt":52},"01M6DRKR2J9MFM4HSSPJBX26SD","flink-udf","Build and deploy Apache Flink user-defined functions (UDFs) in Java for stream processing over Kafka. Use this skill when users want to create scalar UDFs, user-defined table functions (UDTFs), or process table functions (PTFs) in Java, deploy them to Confluent Cloud or local Docker environments, and invoke them from Flink SQL or the Table API. Trigger on: Flink UDF, custom Flink function, process table function, PTF, UDTF, Flink user defined, extend Flink SQL, stateful stream processing with Flink. Do NOT trigger for: Kafka Streams UDFs (use kafka-streams-programming skill), general Flink job development without custom functions, CDC streaming data piplines that include Flink (prefer the confluent-cloud-cdc-tableflow skill), Flink connector setup, or Kafka producer\u002Fconsumer code.","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fflink-udf\u002FSKILL.md",[192,193,194],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":165,"categoryName":166,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[196,197,198,199,200,119,39,201,148,120,141,43,142,153,202,203,204,129,48,156],"flink","flink udf","docker","development","create","java","Connector","general","functions",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":212,"publishedAt":52},"01M6DRKJ5YMXKVD7BG52K68NK6","developing-kafka-python-client","Use when the user wants to build a Python Kafka producer or consumer, add Schema Registry to existing Python code, migrate from raw JSON to schema-backed serialization, or scaffold a confluent-kafka-python project for Confluent Cloud, local Docker, or WarpStream. Also use when user wants to optimize Python Kafka client configuration for WarpStream.","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeveloping-kafka-python-client\u002FSKILL.md",[211],{"categoryNo":165,"categoryName":166,"taxonomyType":21,"taxonomyTypeDesc":22},[213,141,214,198,119,169,215,216,123,217,218,153,170,219,220,154,48,185,34,131],"python","developing kafka python client","serialization","cloud","json","user","build","configuration",{"skillNo":222,"name":223,"nameZh":6,"description":224,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":225,"categories":226,"keywords":228,"publishedAt":52},"01M6DRKCFWR3TXQDYCNBPBPTCK","developing-kafka-java-client","Use when the user wants to integrate a Kafka client into an existing application or scaffold a Java Kafka client project (Maven or Gradle based) for Confluent Cloud, local Docker, or WarpStream. Covers the Apache Kafka Java clients (KafkaProducer\u002FKafkaConsumer\u002FKafkaShareConsumer) with Avro, JSON Schema, or Protobuf serializers. Also use when the user wants to optimize Java Kafka client configuration for WarpStream. Do NOT trigger for Kafka Streams apps (use kafka-streams-programming), Flink, connectors, or Kafka Python client (use developing-kafka-python-client).","https:\u002F\u002Fgithub.com\u002Fconfluentinc\u002Fagent-skills\u002Fblob\u002Fmain\u002Fskills\u002Fdeveloping-kafka-java-client\u002FSKILL.md",[227],{"categoryNo":165,"categoryName":166,"taxonomyType":21,"taxonomyTypeDesc":22},[201,141,229,213,198,230,231,39,232,233,129,154,48,185,234,156,157,34,131,132],"developing kafka java client","json schema","protobuf","maven","integrate","gradle"]