EBP-3105: Add Python API routing and the guaranteed pub/sub Quickstart

plugins/solace-messaging-skills/evals/trigger-evals.json

@@ -12,9 +12,14 @@
   {"skill":"solace-application-development","prompt":"For the logistics platform we run in Java on our Solace event broker, a ShipmentTracker service publishes a DeliveryException event whenever a package misses its checkpoint. Three separate services each need to act on it independently: a CustomerNotifier emails the customer, a ReroutePlanner recalculates the route, and an AnalyticsIngest service records it for reporting. Each is owned by a different team, each needs its own full copy of every event, and none of them can miss one even if that service is down for maintenance. How should I structure the messaging so every one of these services reliably receives every event on its own?","should_trigger":true,"must_pass":true},
 
   {"skill":"solace-application-development","prompt":"We've standardized on the Solace JMS API. How do I create a JMS ConnectionFactory and a MessageProducer to send to a queue in Java?","should_trigger":false},
-  {"skill":"solace-application-development","prompt":"I'm writing my Solace client in Python with the solace-pubsubplus library. How do I set up the messaging service and a persistent receiver?","should_trigger":false},
-  {"skill":"solace-application-development","prompt":"We've got a warehouse-robotics system where two Python services communicate through our Solace event broker using the solace-pubsubplus library. A RobotDispatcher publishes task assignments and a RobotController consumes them and must not lose any while a robot reboots. How should I structure the messaging between these two Python services?","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"I'm writing my Solace client in Python with the solace-pubsubplus library. How do I set up the messaging service and a persistent receiver?","should_trigger":true},
+  {"skill":"solace-application-development","prompt":"We've got a warehouse-robotics system where two Python services communicate through our Solace event broker using the solace-pubsubplus library. A RobotDispatcher publishes task assignments and a RobotController consumes them and must not lose any while a robot reboots. How should I structure the messaging between these two Python services?","should_trigger":true,"must_pass":true},
   {"skill":"solace-application-development","prompt":"Show me how to publish to a Solace topic from C# using the .NET messaging API.","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"I'm writing a Go service with the Solace PubSub+ Messaging API for Go. How do I build a persistent message publisher and handle publish receipts?","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"I'm on the Solace Messaging API for Java (com.solace:solace-messaging-client). How do I set up a MessagingService and a PersistentMessageReceiver in my Java service to consume from a durable queue?","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"In our browser dashboard we use the solclientjs library. How do I subscribe to a Solace topic from JavaScript and update the page when messages arrive?","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"I have a Python asyncio service that calls a few REST APIs concurrently. How do I limit it to five requests in flight at once with a semaphore?","should_trigger":false},
+  {"skill":"solace-application-development","prompt":"I'm using confluent-kafka in Python. How do I write a consumer that commits offsets only after each message has been processed?","should_trigger":false},
   {"skill":"solace-application-development","prompt":"I need a Kafka producer and consumer in Java for our clickstream pipeline. How do I configure the KafkaProducer with the right key and value serializers?","should_trigger":false},
   {"skill":"solace-application-development","prompt":"How do I provision a durable queue named q.orders.intake and set its max-spool-usage on our Solace broker through the SEMP API and PubSub+ Manager? I'm configuring the broker, not writing a client.","should_trigger":false},
   {"skill":"solace-application-development","prompt":"How do I model our order and shipment events and the relationships between them in Solace Event Portal?","should_trigger":false},

plugins/solace-messaging-skills/skills/solace-application-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: solace-application-development
-description: "Use when the user mentions JCSMP, the com.solacesystems:sol-jcsmp library, JCSMPSession, publishing to a Solace topic, consuming from a Solace queue, or guaranteed messaging, OR asks broadly to build or design a Solace messaging app in Java (publisher, consumer, pub/sub). This is the single front door for Solace API development: it grounds the work in canonical Solace docs and routes the request to the right API (JCSMP today), helping choose a messaging pattern or generate a runnable Maven app. Do NOT trigger for an explicitly named non JCSMP API, which beats the generic Java signal: Solace JMS, or the Solace Python, Go, .NET, or JavaScript APIs. Also do NOT trigger for Apache Kafka, broker administration and configuration, Solace Event Portal event modeling, Schema Registry, OpenTelemetry tracing, or topic-architecture and topic-hierarchy design questions (use solace-topic-best-practices)."
+description: "Use when the user mentions JCSMP, the com.solacesystems:sol-jcsmp library, JCSMPSession, the Solace Python API (solace-pubsubplus), MessagingService, PersistentMessageReceiver, publishing to a Solace topic, consuming from a Solace queue, or guaranteed messaging, OR asks broadly to build or design a Solace messaging app in Java or Python (publisher, consumer, pub/sub). This is the single front door for Solace API development: it grounds the work in canonical Solace docs and routes to the right API, helping choose a messaging pattern or generate a runnable app. Do NOT trigger for an explicitly named other Solace API, which beats the generic Java signal: Solace JMS, the Solace Messaging API for Java, or the Solace Go, .NET, or JavaScript APIs. Also do NOT trigger for Apache Kafka (any language), broker administration and configuration, Solace Event Portal event modeling, Schema Registry, OpenTelemetry tracing, or topic-architecture and topic-hierarchy design questions (use solace-topic-best-practices)."
 allowed-tools: Read Write Edit Bash Grep Glob WebFetch
 ---
 
@@ -13,6 +13,7 @@ This skill is the front door for building Solace messaging applications grounded
 **Do NOT read all reference files upfront. Read ONLY what you need, when you need it.**
 
 - User wants a JCSMP application (design help or code generation) then read `references/jcsmp.md`, which selects the right mode within the JCSMP API.
+- User wants a Solace Python API application (design help or code generation) then read `references/python.md`, which selects the right mode within the Python API.
 - Read a mode file only at the moment a step needs it.
 - Most requests need the API's entry file plus one mode file, not the whole tree.
 
@@ -30,22 +31,25 @@ Determine which Solace API the developer is building against, then read that API
 
 | User intent | API | What to do |
 |---|---|---|
-| Anything about JCSMP, the `com.solacesystems:sol-jcsmp` library, a Java publisher or consumer, publishing to a topic, or consuming from a queue with guaranteed messaging | **JCSMP** | Read `references/jcsmp.md` |
+| Anything about JCSMP, the `com.solacesystems:sol-jcsmp` library, `JCSMPSession`, or a Java publisher or consumer (publishing to a topic, or consuming from a queue with guaranteed messaging) | **JCSMP** | Read `references/jcsmp.md` |
+| Anything about the Solace Python API, the `solace-pubsubplus` library, `MessagingService`, `PersistentMessageReceiver`, or a Python publisher or consumer | **Python** | Read `references/python.md` |
 
-If the API is unclear but the request is clearly about Solace messaging in Java, default to **JCSMP**. Mode detection (Design, Implement) then happens in that API's entry file.
+If the API is unclear but the request is clearly about Solace messaging in Java, default to **JCSMP**. If the API is unclear but the request is clearly about Solace messaging in Python, default to **Python**. If the request names no language at all (for example "build me a Solace publisher"), ask one question before anything else: JCSMP (Java) or Python? Files in the workspace (a `pom.xml`, `.py` files, a `requirements.txt`) are facts to report while you ask, never the answer. The one exception is a saved `solace-design.md` that the developer asks you to build from: its title (`Solace JCSMP Design Summary` or `Solace Python Design Summary`) names the API, so read that API's entry file, whose design-contract gate restates the summary and takes the developer's confirm. The Solace Messaging API for Java (`com.solace:solace-messaging-client`) shares class names such as `MessagingService` and `PersistentMessageReceiver` with the Python API, but it is neither JCSMP nor Python: when a Java request names that API or its `com.solace` package, say in one line that this skill does not cover it yet, and stop. Mode detection (Design, Implement) then happens in that API's entry file.
 
 ## Invariants
 
 Non-negotiable rules that apply across every API. Apply all.
 
 1. **Content sourcing**: Every named entity (API, parameter, configuration value) must be traceable to a canonical Solace source. Do not assert behavior, defaults, or best practices that are not in the grounding documentation.
-2. **WebFetch-on-demand doc grounding**: This skill bundles no documentation. When a step needs documentation content to ground a generation or design decision, WebFetch the live canonical page on demand (its `docs.solace.com` `.md` URL, the same link the reference files carry), then quote or summarize the fetched page. Do not answer from memory and do not paraphrase guidance the page does not contain. Do not restate doc content in the skill; link the live `.md` URL. Never substitute another channel for that WebFetch: grounding taken from a docs chatbot, a search tool, or decompiling a jar does not satisfy this invariant, and a page never fetched in the session must never be cited as grounding. A short list of references stays live for the same reason it always has (Javadoc HTML, the JCSMP API Release Notes, Maven Central, the tutorials, and the GitHub samples) because those have no `docs.solace.com` `.md` form.
-3. **No hardcoded versions**: Never pin a library version anywhere in skill content. The generated build resolves the latest release of every dependency at generation time from the AUTHORITATIVE Maven repository metadata; each API's entry file names the exact coordinate and carries the exact lookup command. Never read a version from the legacy `search.maven.org/solrsearch` index: it lags the repository metadata and reports stale versions. Security floors (a minimum version below which known CVEs live) are enforced as checks on the resolved result, never as pins.
-4. **AI-assisted disclaimer header**: Every source file generated under this skill starts with this exact line: `AI-assisted code. Review before production use.` Directly below it: `See the verification checklist: solace-verification-checklist.md`. This applies to EVERY generated source file, including custom builds, web apps, and embedded shapes that adapt the reference samples outside the canonical generator. The pom and other non-source artifacts are exempt; the bundled reference samples themselves carry no header.
-5. **Verification artifacts, always**: Any session that generates Solace code from this skill writes a tailored `solace-verification-checklist.md` beside the code as generation output, copies the bundled `verify.sh` (plus its generated `verify-hooks.sh`) into the project, and ends in a real verify run or the compile-only fallback with the exact handed-back commands. The `VERIFY:` markers are non-optional in generated Solace messaging code, whatever the app shape. An improvised check (for example curl against the app's own HTTP API) may TRIGGER traffic but never renders the verdict; the verdict comes from the markers and the verify exit code.
-6. **Live-broker heads-up**: Immediately before starting ANY process that will connect to a live broker — verify.sh, `java -jar`, a `mvn` run, a run script, anything — print one line that names the broker host and states the actual broker-side effects of this run (the queues it provisions, the connections it opens, the messages it publishes), scaled to the real app. Environment discovery is never consent and never an answer: a running local broker, an existing config file, or found credentials are facts to report, not answers to consume; report them, then still ask which broker the developer wants to target.
+2. **WebFetch-on-demand doc grounding**: This skill bundles no documentation. When a step needs documentation content to ground a generation or design decision, WebFetch the live canonical page on demand (its `docs.solace.com` `.md` URL, the same link the reference files carry), then quote or summarize the fetched page. Do not answer from memory and do not paraphrase guidance the page does not contain. Do not restate doc content in the skill; link the live `.md` URL. Never substitute another channel for that WebFetch: grounding taken from a docs chatbot, a search tool, or decompiling a jar does not satisfy this invariant, and a page never fetched in the session must never be cited as grounding. A short list of references stays live for the same reason it always has (the JCSMP Javadoc and the Python API reference, the JCSMP and Python API Release Notes, Maven Central and PyPI, the tutorials, and the GitHub samples) because those have no `docs.solace.com` `.md` form. Each API's entry file lists its own live exceptions.
+3. **No hardcoded versions**: Never pin a library version anywhere in skill content. The generated build resolves the latest release of every dependency at generation time from the API's AUTHORITATIVE registry: the Maven repository metadata for JCSMP, the PyPI JSON `info.version` for Python. Each API's entry file names the exact coordinate and carries the exact lookup command. Never read a JCSMP version from the legacy `search.maven.org/solrsearch` index: it lags the repository metadata and reports stale versions. Security floors (a minimum version below which known CVEs live) are enforced as checks on the resolved result, never as pins.
+4. **AI-assisted disclaimer header**: Every source file generated under this skill starts with this exact line: `AI-assisted code. Review before production use.` Directly below it: `See the verification checklist: solace-verification-checklist.md`. This applies to EVERY generated source file, including custom builds, web apps, and embedded shapes that adapt the reference samples outside the canonical generator. Build files (the pom, `requirements.txt`) and other non-source artifacts are exempt; the bundled reference samples themselves carry no header.
+5. **Verification artifacts, always**: Any session that generates Solace code from this skill writes a tailored `solace-verification-checklist.md` beside the code as generation output, copies the API's own bundled verify script (plus its generated `verify-hooks.sh`) into the project, and ends in a real verify run or the compile-only fallback with the exact handed-back commands. The API's entry file names its verify script. An API that does not bundle a verify script yet (Python, until its `verify.sh` lands) ends in the compile-only fallback every time, and its implement-mode file defines that fallback; never claim a verified run without the script. The `VERIFY:` markers are non-optional in generated Solace messaging code, whatever the app shape and whatever the API. An improvised check (for example curl against the app's own HTTP API) may TRIGGER traffic but never renders the verdict; the verdict comes from the markers and the verify exit code.
+6. **Live-broker heads-up**: Immediately before starting ANY process that will connect to a live broker — verify.sh, `java -jar`, a `mvn` run, a `python` run, a run script, anything — print one line that names the broker host and states the actual broker-side effects of this run (the queues it provisions, the connections it opens, the messages it publishes), scaled to the real app. Environment discovery is never consent and never an answer: a running local broker, an existing config file, or found credentials are facts to report, not answers to consume; report them, then still ask which broker the developer wants to target.
 
 ## Reference Files (read on-demand only)
 
 - `references/jcsmp.md`: the JCSMP entry file (mode detection, the JCSMP coordinate, and the live JCSMP doc links); read this for any JCSMP request.
 - `references/jcsmp/`: all JCSMP API content (mode files, the reference samples, the verify script, and the compile fixture), reached through `references/jcsmp.md`.
+- `references/python.md`: the Python entry file (mode detection, the `solace-pubsubplus` coordinate, and the live Python doc links); read this for any Solace Python API request.
+- `references/python/`: all Python API content (mode files and the reference samples), reached through `references/python.md`.

plugins/solace-messaging-skills/skills/solace-application-development/references/jcsmp/prerequisites.md

@@ -11,7 +11,7 @@ Read this when a developer does not yet have a broker to build against. Both Des
 
 You need one reachable broker. The primary, recommended choice is [Solace Cloud](https://docs.solace.com/Get-Started/Getting-Started-Try-Broker.md): it is the simplest path to a running broker for a greenfield app and for the run-and-observe round-trip. Default to it unless the developer has a reason not to.
 
-As brief alternatives, the same page also documents a self-hosted Software Broker (run locally via container or VM) and an Appliance (existing hardware the developer already operates) for developers who cannot use Solace Cloud.
+As a brief alternative, the same page also covers setting up a free broker locally, for developers who cannot use Solace Cloud.
 
 The skill does not provision or configure the broker. It assumes the broker is reachable and that the developer has connection details (host, message VPN, client username, password). A broker discovered running in the environment (for example a local container) is a fact to report, never an answer: still ask which broker the developer wants to target.