skills: drift audit (2026-09)

[micheleRP]

Monthly full re-verification of the source-grounded skills against current source, rather than against recent commits. Nine corrections across five skills. No volatile detail added — every fix replaces a stale or wrong stable fact.

Verified against Redpanda Core v26.2.2 (current stable) and Redpanda Connect v4.107.2 (current stable).

rpk — -X reference (skills/rpk/references/x-flags-and-config.md)

The "Default" column had been filled in from a test-example field in the rpk config source rather than from the real defaults. Four values were wrong:

-X option	was	now
globals.command_timeout	30s	10s
globals.request_timeout_overhead	10s	5s
globals.retry_timeout	30s	11s
globals.prompt	bg-red "%n"	unset (empty)

Sources: redpanda-data/redpanda src/go/rpk/pkg/config/rpk_yaml.go (RpkGlobals.GetCommandTimeout()) and src/go/rpk/pkg/kafka/client_franz.go (the kgo.RequestTimeoutOverhead / kgo.RetryTimeout options rpk applies over the franz-go defaults). globals.dial_timeout, globals.fetch_max_wait, globals.kafka_protocol_request_client_id and globals.no_default_cluster were checked and are correct.

Also in the same file:

• Address defaults are 127.0.0.1:9092 / 127.0.0.1:9644 / 127.0.0.1:8081, not localhost-prefixed (src/go/rpk/pkg/config/params.go, which fills 127.0.0.1 plus the default port, and states the same in rpk -X help).
• An unset sasl.mechanism falls back to SCRAM-SHA-256 for the Kafka API as well, not only for Admin API basic auth (src/go/rpk/pkg/kafka/client_franz.go).
• rpk -X list prints each key's accepted value format, not its default — the discovery section said "short list with defaults". Added a line making live introspection authoritative over the static table.
• references/SOURCES.md now records that rpk has no -X defaults struct, and names the authoritative source for each key's default, so this class of error does not recur.

rpk-security + streaming-admin-api — superuser and SASL configuration

superusers, enable_sasl and kafka_enable_authorization are cluster configuration properties, and all three carry needs_restart: no. The skills described them as node properties in redpanda.yaml requiring a broker restart, and told the reader they could not manage superusers with rpk at all.

• Replaced the redpanda.yaml + restart guidance with rpk cluster config set, noting that array-valued properties take a quoted list. Pre-boot seeding goes in the cluster bootstrap file, not redpanda.yaml.
• Reordered the SASL bootstrap flow: create the superuser before enabling authentication. The documented order (enable SASL, restart, then create the admin user) locks the operator out of the cluster they were securing.
• Noted that kafka_enable_authorization is nullable and follows enable_sasl when left unset.
• Made the Admin API auth-level table say that the level spelled authenticated in the docs is the user enum member.

Sources: redpanda-data/redpanda src/v/config/configuration.h and configuration.cc (all three declared on the cluster configuration class with needs_restart::no), the config::shard_local_cfg().superusers() call sites in src/v/security/authorizer.cc and src/v/kafka/server/connection_context.cc, and src/v/redpanda/admin/server.cc, which re-reads the value on a cluster-config update touching superusers — direct evidence no restart is involved. Files touching these facts elsewhere (streaming-admin-api/references/cluster-config.md, rpk-cluster/references/config.md) already had it right; the repo was internally inconsistent.

rpk-security + connect-debugging — broken -X examples

Two examples used -X sasl.username= / -X sasl.password=, which are not rpk -X keys and would be rejected. The keys are user and pass (src/go/rpk/pkg/config/params.go). Fixed in rpk-security/references/users.md and connect-debugging/references/failure-modes.md.

Swept mechanically as a cross-check: every -X key occurrence in every skill was extracted and diffed against the authoritative key list. These two were the only invalid ones. The -X sasl.username= lines in cloud-dedicated/references/data-plane.md are kcat invocations, where that spelling is correct librdkafka syntax, and were left alone.

cloud-byoc — networks and cloud provider access

Three surfaces existed in the API but were absent from the skill:

• Network update. PATCH /v1/networks/{network.id} was undocumented; the reference had only create, get/list and delete. Added an "Updating a Network" section covering the body/update_mask shape and the operation it returns, with the caveat that both settable fields are PREVIEW. (The skill already cited this operation's type value in the Dedicated reference, so the enum was known but the endpoint was not.)
• public_subnets on the AWS customer-managed-resources table — PREVIEW, optional, needed only for a dual-listener cluster, and write-once.
• Cloud-provider-access prerequisites. A fifth endpoint on that service returns the external ID and Redpanda principal ARN you need to build the IAM role's trust policy. The skill documented four endpoints and told the reader to take the external ID from the create response and add it to the trust policy afterwards — but the role must already trust Redpanda for the create to work. The reference now leads with the prerequisites call and the endpoint tables list it.

---

Full provenance, including the sources for the private-source fixes and the items left as TODOs for human review, is in the routine's private report. That report also records this pass's coverage explicitly: the SQL skills and most of the Connect and Core command skills were not re-verified this month and carry over.

---

🤖 Generated with Claude Code