---
name: rapid-dance
description: Add rapid LLM decision making to an application with rapid.dance, a small JSON-in, JSON-out model call with a guaranteed shape and time limit. Creates the query through the management API, tests it until the output is right, mints a call key, then wires the call into the app. Use when the user mentions rapid.dance, an rq_ or rm_ key, or wants an LLM-backed feature that must return structured JSON fast.
---

# rapid.dance

Most AI calls in a product are small: which repo did the user mean, is this ticket urgent, what should this thing be called. rapid.dance gives each of those questions its own URL as a JSON API. The app POSTs a JSON object and gets back a JSON object in exactly the shape defined, within a time limit, or a fallback object with the same shape. You set the query up and verify it; the app only ever calls it.

## Before you start

1. **Base URL.** Default `https://rapid.dance`. If the user runs their own deployment, ask for its URL.
2. **Management key.** You need an `rm_…` key in the environment as `RAPID_MANAGEMENT_KEY`. If it is missing, ask the user to create one on `<base>/app/keys` (type: management key) and put it in the environment. Do not ask them to paste it into the chat. Never print a key, never write one into a file that is committed, never use the management key inside the application.

## Steps

1. **Read the reference.** Fetch `<base>/llms.txt` (WebFetch, or `curl -s <base>/llms.txt`) and follow it. It has the exact API base for this deployment, the query object, every endpoint and code examples. Everything below assumes you have it.
2. **Check the key.** `GET <api_base>/account` with the key. Note the account slug; it is part of every query's endpoint. A 401 means the key is wrong or revoked, a 403 means it is a call key, not a management key.
3. **Design with the user's feature in mind.** Decide the input object the app will send, the smallest flat set of output fields, their defaults (the fallback the app can act on without a special error path), and the instructions. Describe every field. Start at tier S and 1000 ms.
4. **Create it.** `POST <api_base>/queries`. If the slug exists already (409), read the existing query first and decide with the user whether to PATCH it or use a new slug.
5. **Test it.** `POST <api_base>/queries/<slug>/test` with three to five realistic inputs, including one that should produce the fallback. When an output is wrong, read `reasoning`, change the instructions or field descriptions with PATCH, and run the same input again. Watch `latency_ms` against `max_time_ms`. Stop when every input gives the right output with status `ok` or an intended `empty`, and show the user the inputs and outputs you verified.
6. **Mint the app's key.** `POST <api_base>/keys` with a descriptive name. Put the returned `rq_…` key into the app's environment or secret store as `RAPID_API_KEY`, and the query's `endpoint` as `RAPID_ENDPOINT`. Do not echo it.
7. **Integrate.** Write one small function that POSTs the input to the endpoint with the call key, decodes the response, and treats the fallback values as a valid "no answer". `Content-Type` is optional. Set the HTTP timeout slightly above `max_time_ms`. Use the language example from llms.txt.
8. **Report.** Tell the user: the endpoint, the fields and their fallback values, the tier and price per request, which inputs you verified, and where the key and endpoint now live. Mention that the query, its versions and every test run are visible in the rapid.dance app.

## Rules

- Input goes in the request body; never paste user text into the instructions.
- Management calls use the `rm_` key; application code uses only the `rq_` key.
- Test runs and calls are billed per request; do not loop tests without a reason.
- If the API returns `validation_failed`, fix each item in `error.details` and retry; if it returns `bad_request` for an unknown member, check the spelling against llms.txt.