--- name: setup-queuey description: "Set up Queuey, reliable webhook and event delivery, in a repository. Works out whether the code sends or receives events, chooses the path, writes the configuration, and connects with queuey login: the user opens one link and approves it. Use when the user wants events or webhooks delivered reliably, or asks to connect a codebase to Queuey." --- # Set up Queuey in a repository Queuey: The async queue for your API — in front of it for what comes in, behind it for what goes out. Webhooks and events are acknowledged once stored and delivered at the pace you set, with retries, ordering, replay and recovery built in. The steps below are the prompt people paste from the setup page. Follow them in order. "Me" in them is the user you are working for. ```text Set up Queuey (https://queuey.ai) in this repository. The defaults below do the whole job; ask me only where a step says so. An engineer steers with queuey plan, queuey.deploy.json and the flags: when you are done, tell me in a few lines what you set up and where those are. Where to read, as plain text. Read it when you need exact syntax; do not guess at it: - https://queuey.ai/llms.txt is the index, https://queuey.ai/llms-full.txt every page at once (if your fetch cuts it short, read single pages instead). - https://queuey.ai/docs/md/{slug} is one page as Markdown, for example https://queuey.ai/docs/md/quickstart. - https://queuey.ai/.well-known/agent-skills/index.json lists the agent skills. - queuey --help, queuey --help, and queuey advise. A sandbox that cannot reach localhost can still read queuey.ai. If I give you addresses for a local or self-hosted Queuey (API, ingress, console, docs), they win over the queuey.ai addresses in this text. 1. First, ask me once: have I decided where Queuey goes — which part sends, which part receives, or which services? If I have, follow that. If I say "see for yourself", run queuey advise --json (step 3), tell me which files it read (filesRead), and propose a place before you write any code. 2. Install the CLI if it is not there. With .NET 8 or later: dotnet tool install -g Queuey.Cli --prerelease The tool lands in ~/.dotnet/tools. If queuey is not found afterwards, put that folder on PATH as $HOME/.dotnet/tools, for example in ~/.zshrc: export PATH="$PATH:$HOME/.dotnet/tools" Not as "~/.dotnet/tools": a ~ inside quotes is not expanded, and PATH then names a folder that does not exist. No .NET? Every release ships the CLI as one self-contained file, with no runtime needed, for osx-arm64, osx-x64, linux-x64, linux-arm64 and win-x64 (.zip). On macOS or Linux, with this machine's platform in place of osx-arm64: curl -fsSL https://github.com/Queuey-AI/queuey-client/releases/latest/download/queuey-osx-arm64.tar.gz | tar -xz Then move ./queuey onto PATH, or call it as ./queuey. A 404 means there is no build for this machine: install .NET 8 and use the command above. Check it with queuey --version. This setup requires Queuey.Cli, Queuey.Client and Queuey.Edge ≥ 0.1.0-preview.9 (newer than 0.1.0-preview.8). In a .NET project, add the package for the job, with --prerelease: - Queuey.Client, to publish from a service that is online: dotnet add package Queuey.Client --prerelease - Queuey.Edge, to publish from a machine with local disk that survives a restart, where the network can drop: dotnet add package Queuey.Edge --prerelease - Queuey.Client.Waas, only to declare event streams for partners: dotnet add package Queuey.Client.Waas --prerelease Anywhere else there is no package to add: one signed POST to the ingress, as in https://queuey.ai/docs/md/quickstart and https://queuey.ai/docs/md/how-to/signed-requests. Only from server-side code — the key must never end up in a browser bundle. You use the CLI. Queuey's MCP server, https://api.queuey.ai/mcp with sign-in, is for operating Queuey from an AI client such as claude.ai or ChatGPT, not for a coding agent: https://queuey.ai/docs/md/how-to/mcp. 3. Run queuey advise --json. Tell me its reasoning in your own words. If it asks a question (usually: can the network here be trusted?), ask me. Do NOT write your own retry loop, local queue, backoff or offline buffer: that is Queuey.Edge. Then queuey advise --write-files writes queuey.deploy.json, with a secured dev workspace, and .gitignore lines for .env and queuey.json. 4. Log in: queuey login --profile dev --json With addresses I gave you, add --api-base --ingress-base . It prints a link and a code, and exits 5: it waits for me. Show me the link and the code; once I have approved it, run: queuey login --profile dev --wait Do not ask me for an API key: the login is the connection. 5. The workspace. Security goes on the workspace, and its queues inherit it; a new queue is open until its workspace has security. Then: queuey plan --profile dev queuey apply --profile dev A workspace without an environment counts as prod, where keys wait for my approval. Tell me that the security is set on the workspace. 6. The sender's signing key, the same value in Queuey and in the app: queuey keys mint --profile dev --write It writes QUEUEY_SIGNING_KEY_ID and QUEUEY_SIGNING_SECRET. The target is user-secrets in a .NET project with a UserSecretsId, else .env. If I can use neither, run it without --write: nothing is minted, and it names the variables and the console page. Tell me where the key is. Queuey.Client and Queuey.Edge read it with UseSettings(...) or UseEnvironmentVariables(), which reads .env in Development only: https://queuey.ai/docs/md/reference/dotnet-client, and for Edge on a device https://queuey.ai/docs/md/how-to/edge. 7. Configure the receiver for every queue, even if it is outside this repository. Find its actual route and environment from code and deployment settings; ask me if the address is missing. Never guess it or leave a placeholder. Set delivery.url in queuey.deploy.json: an absolute receiver URL, or a route with workspace.delivery.baseUrl. This is not Queuey's ingress address. For local delivery use delivery.kind = "localForward" and the app's route as delivery.url; queuey listen supplies the local host and port. If this code takes Queuey's deliveries, create the receiver's secret: queuey credentials generate --profile dev --write then merge signing into its delivery configuration, keeping url and kind: "delivery": { "signing": { "enabled": true, "templateKey": "queuey", "credentialRef": "" } } Verify every delivery (https://queuey.ai/docs/md/how-to/verify-deliveries), and deduplicate on the event id only with the v2 signature. A hosted Queuey never reaches localhost: to receive on this machine, forward the queue to queuey listen, as https://queuey.ai/docs/md/how-to/local-delivery shows. Run queuey plan and queuey apply with --profile dev. Read back the saved delivery configuration and check the effective receiver, including inherited settings, against the intended endpoint. Do not expose URL credentials. When you start the app to test it, stop it by the PID you started, or with lsof -ti tcp: -sTCP:LISTEN. Never use lsof -ti tcp: alone: it also finds processes connected to the port, such as Queuey delivering to the app, and kills them too. 8. Implement and verify the integration. Wire the publish call into the agreed application path. Start the app (and listener, if local), trigger a harmless representative event through it, and follow that event with: queuey verify --event --profile dev --json If its id is unavailable, use queuey verify --help to start observation before triggering the event. Wait for the final result: a started check is not a pass. Confirm delivery to the intended receiver; check its logs or stored result where accessible. Report the queue, receiver (without secrets), event id and verification outcome. A 202 at ingress or successful apply is not completion. Do not claim setup is complete until delivery is verified. If blocked, report exactly what is missing and the next action needed. 9. Never: - print, read or copy a secret, or use --show-secret; - add --replace without reading me its warning and asking first; - put a key in a command's arguments, in code as a literal, or through /tmp; - work around an approval. In prod a command exits 5 with a link (approval_required): show me the link and wait. You never need a license-wide API key; if one is ever wanted, I mint it in the console at https://app.queuey.ai (the license's Home page → API keys). ``` ## If the user only wants an analysis Change nothing: no files, no workspace, no credentials. ```text Analyse this repository for Queuey (https://queuey.ai) but change nothing. Install the CLI if needed. With .NET 8 or later: dotnet tool install -g Queuey.Cli --prerelease The tool lands in ~/.dotnet/tools. If queuey is not found afterwards, put that folder on PATH as $HOME/.dotnet/tools, for example in ~/.zshrc: export PATH="$PATH:$HOME/.dotnet/tools" Not as "~/.dotnet/tools": a ~ inside quotes is not expanded, and PATH then names a folder that does not exist. No .NET? Every release ships the CLI as one self-contained file, with no runtime needed, for osx-arm64, osx-x64, linux-x64, linux-arm64 and win-x64 (.zip). On macOS or Linux, with this machine's platform in place of osx-arm64: curl -fsSL https://github.com/Queuey-AI/queuey-client/releases/latest/download/queuey-osx-arm64.tar.gz | tar -xz Then move ./queuey onto PATH, or call it as ./queuey. A 404 means there is no build for this machine: install .NET 8 and use the command above. Then run: queuey advise Summarise what it says: do we send, receive or both; which path it recommends; and the evidence it read that from. List the files it would create, but do not create them. If it asks a question it could not answer from the code, put that question to me. ``` ## When the flow needs design decisions Ingress authentication, idempotency, ordering, retries, payloads and delivery authentication are covered by the design-event-delivery skill: https://queuey.ai/.well-known/agent-skills/design-event-delivery/SKILL.md Source: https://queuey.ai/docs/agent-setup