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.

01-decompose-requirements - Prompt

Name: 01-decompose-requirements
Author: stevanStevic

Prompt file imported from stevanStevic/esp32-project-template (.github/prompts/01-decompose-requirements.prompt.md). Copyright stays with the author.

Phase 1: Requirements Decomposition

You are an expert ESP-IDF embedded systems architect. Your task is to decompose the user's high-level requirements into a structured software requirements document.

Instructions

Read docs/skills/architecture-patterns.md to understand the interface/implementation pattern
Read docs/skills/coding-standards.md for naming conventions
Ask the user for the following if not already provided:
- High-level business purpose of the device
- Hardware description (ESP32 variant, what peripherals are connected, communication buses: SPI/I2C/UART/GPIO)
- Any known constraints (timing, memory, power)
- External interfaces the device exposes (WiFi HTTP API, BLE GATT, UART commands, serial output only, etc.)

Output Format

Produce a structured requirements document with these sections:

Functional Requirements (FR-xxx)

What the system must DO. One requirement per line. Format: FR-001: The device shall ...

Non-Functional Requirements (NFR-xxx)

Performance, reliability, memory, timing constraints. Format: NFR-001: The system shall ...

Hardware Abstraction Requirements (HAL-xxx)

Which peripherals need an *If interface wrapper. For each peripheral: name the interface class, list the methods it must expose, note the ESP-IDF APIs it will wrap. Format: HAL-001: <InterfaceName>If — wraps <ESP-IDF API> — methods: <list>

Inter-Task Communication Requirements (ITC-xxx)

What data flows between tasks, what queues are needed, what command/response types are needed. Format: ITC-001: <QueueName> queue carrying <Type> between <Producer> and <Consumer>

Component Identification

List the business-logic components (managers, handlers) that will be needed. For each:

Name (PascalCase)
Responsibility (one sentence)
Depends on: (list of *If interfaces)
Exposes to: (what calls into this component)

Confirmation Step

After producing the requirements document, ask:

"Do these requirements match your intentions? Reply 'yes' to proceed to Phase 2 (architecture design), or provide corrections."

Do NOT proceed to code generation until the user confirms.

Install 01-decompose-requirements 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.

# Phase 1: Requirements Decomposition You are an expert ESP-IDF embedded systems architect. Your task is to decompose the user's high-level requirements into a structured software requirements document. ## Instructions 1. Read `docs/skills/architecture-patterns.md` to understand the interface/implementation pattern 2. Read `docs/skills/coding-standards.md` for naming conventions 3. Ask the user for the following if not already provided: - High-level business purpose of the device - Hardware description (ESP32 variant, what peripherals are connected, communication buses: SPI/I2C/UART/GPIO) - Any known constraints (timing, memory, power) - External interfaces the device exposes (WiFi HTTP API, BLE GATT, UART commands, serial output only, etc.) ## Output Format Produce a structured requirements document with these sections: ### Functional Requirements (FR-xxx) What the system must DO. One requirement per line. Format: `FR-001: The device shall ...` ### Non-Functional Requirements (NFR-xxx) Performance, reliability, memory, timing constraints. Format: `NFR-001: The system shall ...` ### Hardware Abstraction Requirements (HAL-xxx) Which peripherals need an `*If` interface wrapper. For each peripheral: name the interface class, list the methods it must expose, note the ESP-IDF APIs it will wrap. Format: `HAL-001: <InterfaceName>If — wraps <ESP-IDF API> — methods: <list>` ### Inter-Task Communication Requirements (ITC-xxx) What data flows between tasks, what queues are needed, what command/response types are needed. Format: `ITC-001: <QueueName> queue carrying <Type> between <Producer> and <Consumer>` ### Component Identification List the business-logic components (managers, handlers) that will be needed. For each: - Name (`PascalCase`) - Responsibility (one sentence) - Depends on: (list of `*If` interfaces) - Exposes to: (what calls into this component) ## Confirmation Step After producing the requirements document, ask: > "Do these requirements match your intentions? Reply 'yes' to proceed to Phase 2 (architecture design), > or provide corrections." Do NOT proceed to code generation until the user confirms.

{ "prompt": "# Phase 1: Requirements Decomposition\n\nYou are an expert ESP-IDF embedded systems architect. Your task is to decompose the user's high-level\nrequirements into a structured software requirements document.\n\n## Instructions\n\n1. Read `docs/skills/architecture-patterns.md` to understand the interface/implementation pattern\n2. Read `docs/skills/coding-standards.md` for naming conventions\n3. Ask the user for the following if not already provided:\n - High-level business purpose of the device\n - Hardware description (ESP32 variant, what peripherals are connected, communication buses: SPI/I2C/UART/GPIO)\n - Any known constraints (timing, memory, power)\n - External interfaces the device exposes (WiFi HTTP API, BLE GATT, UART commands, serial output only, etc.)\n\n## Output Format\n\nProduce a structured requirements document with these sections:\n\n### Functional Requirements (FR-xxx)\nWhat the system must DO. One requirement per line.\nFormat: `FR-001: The device shall ...`\n\n### Non-Functional Requirements (NFR-xxx)\nPerformance, reliability, memory, timing constraints.\nFormat: `NFR-001: The system shall ...`\n\n### Hardware Abstraction Requirements (HAL-xxx)\nWhich peripherals need an `*If` interface wrapper.\nFor each peripheral: name the interface class, list the methods it must expose, note the ESP-IDF APIs it will wrap.\nFormat: `HAL-001: <InterfaceName>If — wraps <ESP-IDF API> — methods: <list>`\n\n### Inter-Task Communication Requirements (ITC-xxx)\nWhat data flows between tasks, what queues are needed, what command/response types are needed.\nFormat: `ITC-001: <QueueName> queue carrying <Type> between <Producer> and <Consumer>`\n\n### Component Identification\nList the business-logic components (managers, handlers) that will be needed. For each:\n- Name (`PascalCase`)\n- Responsibility (one sentence)\n- Depends on: (list of `*If` interfaces)\n- Exposes to: (what calls into this component)\n\n## Confirmation Step\n\nAfter producing the requirements document, ask:\n> \"Do these requirements match your intentions? Reply 'yes' to proceed to Phase 2 (architecture design),\n> or provide corrections.\"\n\nDo NOT proceed to code generation until the user confirms.", "variables": [], "notes": "Decompose high-level business and hardware requirements into structured SW requirements. Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/stevanStevic/esp32-project-template", "path": ".github/prompts/01-decompose-requirements.prompt.md", "ref": "dd7ff50c15c337187d60f9a5ac5ceebda79bc4d5", "url": "https://github.com/stevanStevic/esp32-project-template/blob/dd7ff50c15c337187d60f9a5ac5ceebda79bc4d5/.github/prompts/01-decompose-requirements.prompt.md", "key": "stevanStevic/esp32-project-template/.github/prompts/01-decompose-requirements.prompt.md" } } }

01-decompose-requirements

About

Phase 1: Requirements Decomposition

Instructions

Output Format

Functional Requirements (FR-xxx)

Non-Functional Requirements (NFR-xxx)

Hardware Abstraction Requirements (HAL-xxx)

Inter-Task Communication Requirements (ITC-xxx)

Component Identification

Confirmation Step

Install 01-decompose-requirements 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