How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

new-product-event - Prompt

Name: new-product-event
Author: vellezz

Prompt file imported from vellezz/dotnet_template (.github/prompts/new-product-event.prompt.md). Copyright stays with the author.

Start with the repository tool: dotnet superapp add product-event {Contract}V1 creates the forwarder consumer (identifiers, time and user only), the name in ProductEventNames and the Contracts reference; review the properties against the rules below.

Rules (ADR-0036, docs/przewodnik/21-analityka-i-feature-flags.md, .github/instructions/worker-contracts.instructions.md):

Product events are produced only by src/Analytics/SuperApp.AnalyticsForwarder from an existing integration event in {Service}.Contracts. Do not touch the domain service: no PostHog SDK, no analytics code, no new command. If no integration event carries the fact, stop and propose adding one to the service first (domain event → translator → {Fact}V{n} through the outbox).
Before writing code, list every proposed property with its value type and state why it is allowed. Allowed: names, identifiers of catalog objects, categories. Never: titles, user-entered text, e-mail, sub, sleep diary data (dates, durations, ratings are health data). Flag the list for a privacy review in the summary.

Steps:

Events/ProductEventNames.cs: a constant {service}_{object}_{past-tense verb} in snake case with complete XML docs (when it is sent, subject, properties). Never rename existing names.
Consumers/{Event}Consumer.cs: public sealed class, IConsumer<{Event}V{n}>, one IProductEventSink.Capture(new ProductEvent(...)) with the time of the fact from the message, context.MessageId, the user's sub as subject (or null for system facts) and an explicit property dictionary with snake case keys. No other logic. Follow MaterialPublishedConsumer.
If the integration event comes from a service the forwarder does not reference yet, add a project reference to that service's {Service}.Contracts only (architecture rule 10).
Test in SuperApp.AnalyticsForwarder.Tests/ConsumerMappingTests.cs on the MassTransit test harness: event name, subject and the exact set of property keys.
Add the queue analytics-{event} to keda.queues in deploy/helm/superapp-analytics-forwarder/values.yaml.
Update docs/przewodnik/21-analityka-i-feature-flags.md (event catalog) and docs/architektura.md §5.6 if the catalog is listed there.
Run dotnet build SuperApp.slnx and dotnet test --solution SuperApp.slnx (including architecture tests); summarize the new event and its properties for the privacy review.

Install new-product-event and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

Add a new backend product event sent to PostHog. Ask for missing details: which fact (integration event and service), why the product team needs it, whether it belongs to a user or is a system fact, and which properties are wanted. Start with the repository tool: `dotnet superapp add product-event {Contract}V1` creates the forwarder consumer (identifiers, time and user only), the name in `ProductEventNames` and the Contracts reference; review the properties against the rules below. Rules (ADR-0036, `docs/przewodnik/21-analityka-i-feature-flags.md`, `.github/instructions/worker-contracts.instructions.md`): - Product events are produced only by `src/Analytics/SuperApp.AnalyticsForwarder` from an existing integration event in `{Service}.Contracts`. Do not touch the domain service: no PostHog SDK, no analytics code, no new command. If no integration event carries the fact, stop and propose adding one to the service first (domain event → translator → `{Fact}V{n}` through the outbox). - Before writing code, list every proposed property with its value type and state why it is allowed. Allowed: names, identifiers of catalog objects, categories. Never: titles, user-entered text, e-mail, `sub`, sleep diary data (dates, durations, ratings are health data). Flag the list for a privacy review in the summary. Steps: 1. `Events/ProductEventNames.cs`: a constant `{service}_{object}_{past-tense verb}` in snake case with complete XML docs (when it is sent, subject, properties). Never rename existing names. 2. `Consumers/{Event}Consumer.cs`: `public sealed class`, `IConsumer<{Event}V{n}>`, one `IProductEventSink.Capture(new ProductEvent(...))` with the time of the fact from the message, `context.MessageId`, the user's `sub` as subject (or `null` for system facts) and an explicit property dictionary with snake case keys. No other logic. Follow `MaterialPublishedConsumer`. 3. If the integration event comes from a service the forwarder does not reference yet, add a project reference to that service's `{Service}.Contracts` only (architecture rule 10). 4. Test in `SuperApp.AnalyticsForwarder.Tests/ConsumerMappingTests.cs` on the MassTransit test harness: event name, subject and the exact set of property keys. 5. Add the queue `analytics-{event}` to `keda.queues` in `deploy/helm/superapp-analytics-forwarder/values.yaml`. 6. Update `docs/przewodnik/21-analityka-i-feature-flags.md` (event catalog) and `docs/architektura.md` §5.6 if the catalog is listed there. 7. Run `dotnet build SuperApp.slnx` and `dotnet test --solution SuperApp.slnx` (including architecture tests); summarize the new event and its properties for the privacy review.

{ "prompt": "Add a new backend product event sent to PostHog. Ask for missing details: which fact (integration event and service), why the\nproduct team needs it, whether it belongs to a user or is a system fact, and which properties are wanted.\n\nStart with the repository tool: `dotnet superapp add product-event {Contract}V1` creates the forwarder consumer (identifiers, time and\nuser only), the name in `ProductEventNames` and the Contracts reference; review the properties against the rules below.\n\nRules (ADR-0036, `docs/przewodnik/21-analityka-i-feature-flags.md`, `.github/instructions/worker-contracts.instructions.md`):\n\n- Product events are produced only by `src/Analytics/SuperApp.AnalyticsForwarder` from an existing integration event in `{Service}.Contracts`.\n Do not touch the domain service: no PostHog SDK, no analytics code, no new command. If no integration event carries the fact, stop and\n propose adding one to the service first (domain event → translator → `{Fact}V{n}` through the outbox).\n- Before writing code, list every proposed property with its value type and state why it is allowed. Allowed: names, identifiers of\n catalog objects, categories. Never: titles, user-entered text, e-mail, `sub`, sleep diary data (dates, durations, ratings are health\n data). Flag the list for a privacy review in the summary.\n\nSteps:\n\n1. `Events/ProductEventNames.cs`: a constant `{service}_{object}_{past-tense verb}` in snake case with complete XML docs (when it is\n sent, subject, properties). Never rename existing names.\n2. `Consumers/{Event}Consumer.cs`: `public sealed class`, `IConsumer<{Event}V{n}>`, one `IProductEventSink.Capture(new ProductEvent(...))`\n with the time of the fact from the message, `context.MessageId`, the user's `sub` as subject (or `null` for system facts) and an\n explicit property dictionary with snake case keys. No other logic. Follow `MaterialPublishedConsumer`.\n3. If the integration event comes from a service the forwarder does not reference yet, add a project reference to that service's\n `{Service}.Contracts` only (architecture rule 10).\n4. Test in `SuperApp.AnalyticsForwarder.Tests/ConsumerMappingTests.cs` on the MassTransit test harness: event name, subject and the exact\n set of property keys.\n5. Add the queue `analytics-{event}` to `keda.queues` in `deploy/helm/superapp-analytics-forwarder/values.yaml`.\n6. Update `docs/przewodnik/21-analityka-i-feature-flags.md` (event catalog) and `docs/architektura.md` §5.6 if the catalog is listed there.\n7. Run `dotnet build SuperApp.slnx` and `dotnet test --solution SuperApp.slnx` (including architecture tests); summarize the new event and its\n properties for the privacy review.", "variables": [], "notes": "Add a backend product analytics event (PostHog) to the analytics forwarder, following ADR-0036 Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/vellezz/dotnet_template", "path": ".github/prompts/new-product-event.prompt.md", "ref": "1f19aae8fbfbfda706e661dac4be2d9560718b38", "url": "https://github.com/vellezz/dotnet_template/blob/1f19aae8fbfbfda706e661dac4be2d9560718b38/.github/prompts/new-product-event.prompt.md", "key": "vellezz/dotnet_template/.github/prompts/new-product-event.prompt.md" } } }

new-product-event

About

Install new-product-event and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews