Use cases
shipcue is for any team where the people who find problems and the agents that fix them are not the same, and you want one queue between them instead of a group chat.
Hackathon teams running many agents
At a hackathon everyone is building at once, and now each person has two or three coding agents going as well. The hard part stops being writing code and becomes coordination: two agents fixing the same bug, one agent's change undoing another's, a teammate asking in the chat "is anyone on the login bug?" and nobody being sure.
With shipcue the whole team files bugs and feature ideas through the button in the app you are building. Every agent pulls from the same queue, and a claim is atomic, so once an agent has a report nobody else can take it. When it is done it closes the report with the PR link, so the team can see what shipped without asking.
Set up: create the table in the Supabase, InsForge or Neon database you already have for the project, mount the handler, add the button, and run claude mcp add shipcue on each teammate's machine with the same URL and token. It takes about ten minutes, so it is worth doing in the first hour.
Tip: give each teammate's agent its own name with SHIPCUE_AGENT (for example claude@maya), so the queue shows whose agent is on what.
Founders with early users
Early users will tell you what is broken, but usually in a DM, in a call, or in a screenshot with no context. The button lets them report from the page where it happened, and shipcue attaches the page address, the browser and a snapshot of app state you choose, so the report is already close to a task an agent can act on.
Point Claude Code or Codex at the queue and let it work through the most urgent reports first. Each one arrives as a task prompt: reproduce it, write a failing test, fix it, close it with the PR. You stay the reviewer, not the person retyping bug reports into prompts.
Internal tools and dashboards
Internal tools collect small annoyances that nobody files because filing is a hassle. Put the inline button in the header, require sign-in with getReporter so every report has a name on it, and use onReport to post new reports to Slack or email the team. Reports stay in your own database, which matters when the tool touches member or customer data.
Beta tests and dogfooding sessions
Get the team or a group of testers to click through the app for thirty minutes and report everything they hit. Areas (the parts of your app you list) and priority keep the pile sorted, so when the session ends the queue is already in order: blocking bugs first, then high, then the rest by age. Agents can start on the top of the list while you are still reading the bottom.
Feature requests, not just bugs
The same button takes feature requests. An agent can claim one and draft it as a PR, or you can close it as won't fix with a short reason in the resolution, so the person who asked is not left wondering.
Several kinds of agents on one codebase
shipcue does not care which agent claims a report. Claude Code, Codex and a teammate working by hand can all pull from the same queue over MCP or the HTTP API. If an agent gets stuck, it releases the report and it goes back to the queue for someone else.
When it is not the right fit
- You want a public roadmap with voting today. shipcue is an inbox for your team; an optional voting board is on the roadmap.
- Your team already lives in Linear or GitHub Issues and is happy there. Forwarding reports to them is planned for Cloud; for now you can do it yourself in
onReport. - You do not have a Postgres database and do not want one. Cloud is meant for that, and it is not built yet.