Our bug reports live in Slack. Not in Linear, where they'd actually be useful — in a channel called #something-bugs, where someone types "mascot disappeared??" at 11pm, three people react with 👀, and then nothing happens for two weeks.
I've tried the usual fixes. A Slack workflow that pushes messages into Linear, which mostly produced tickets titled "mascot disappeared??" with no description. A rule that whoever reports it files it, which lasted four days. A weekly triage meeting, which is where good intentions go to die.
So last week I tried something dumber: I described the tool I wanted out loud and let an agent build it. This is what came out, warts included.
The prompt that started it
I opened Something, hit New agent, and typed one sentence with a typo in it:
"make me a agent which helps me create linear issues, manage them and all. also helps create issues from bugs reported on slack"
That's the entire spec. No user stories, no schema, no list of screens. It came back with two questions — who's this for? (Just me) and how do you want to work with it? (Dashboard + Chat) — and then one line that told me it had understood the actual job: I'll need access to Slack — click Connect above to grant it.
Two taps on preset buttons. That was the whole requirements phase.
What it built without asking me
Sixty seconds later there was a project tree in the middle panel, and it wasn't scaffolding — it was the app. A React frontend split into an IssuesView and a ChatView, an IssueCard and a StatsBar, a Python agent.py on the backend, and the part I keep coming back to: agent/system_prompt.md, sitting in the file tree as an editable Markdown file like any other source file.
That last one matters more than it sounds. The agent's behaviour isn't buried in a settings panel behind a dropdown labelled "personality". It's a text file I can open, read, and rewrite when the thing does something stupid. I did exactly that twice.
There's also _history.json and _outstanding.json — the build's own memory and its to-do list. Reading _outstanding.json is a slightly uncomfortable experience, like finding your contractor's private notes about your kitchen.
Arguing about the theme, then shipping
The first version was dark. I wanted light. Rather than hunting for a theme toggle in a config screen, I typed:
"make it fully light themed pls. not dark themed"
It rewrote the app and answered with one line: Done — the whole app is now light themed. Deploy whenever you're ready to push it live! I asked "deployed?" and got a real answer — about 30 seconds — and then a URL at young-kelly-peach.trysomething.site, which is a slightly ridiculous name I have grown genuinely fond of.
The other change in that same stretch was cosmetic and my favourite one. The tool calls were rendering as raw function names, which is fine for me and meaningless to anyone else. I asked for friendly chips instead — Creating issue, Reading Slack, Fetching image — capped at two visible with a "+N more" expander, and no mention of the underlying integration layer anywhere in the interface. An internal tool that looks like an internal tool gets used by exactly one person.
The dashboard: 9 issues, 2 from Slack
Here's the deployed app doing its actual job. Nine issues across two Linear teams, filter tabs for In Progress / To Do / Backlog / Done, a From Slack button that reads the bug channel on demand, and a New Issue button for the times you just want to type a ticket like a normal person.
The two with the Slack badge came in without me writing a word of them:
| Issue | ID | Status | Source |
|---|---|---|---|
| Per-Product Data Isolation Not Enforced — Legal Exposure Risk | SOM-27 | Backlog | Slack |
| Deployment & Launch Surface Missing — Cannot Ship Apps, APIs, or Mobile | SOM-26 | Backlog | Slack |
| Vibe Coding Failures — Security & Guardrails Cross-Check Needed | SOM-3 | Backlog | |
| Version Rollback Loses Implemented Changes | SOM-6 | Backlog |
Compare "Per-Product Data Isolation Not Enforced — Legal Exposure Risk" to what someone actually types in Slack at 11pm. The rewrite is the whole product. Anything can move a string from one API to another; the useful part is turning a complaint into a title an engineer can pick up cold three weeks later.
Pulling four bugs out of Slack in one message
The chat tab is where the thing earns its keep. I asked it to go through #something-bugs, and it came back with four issues already created — not a summary, not a proposal, actual Linear tickets with IDs and links:
- SOM-6 — Version Rollback Loses Implemented Changes · Urgent
- SOM-5 — Mascot Regression, Disappeared Without Notice · High
- SOM-4 — App Transition from Backend to Frontend Failing · Urgent
- SOM-3 — Vibe Coding Failures, Security & Guardrails Check · High
It assigned those priorities itself. I didn't ask it to, and I don't fully agree with them — a missing mascot is not High — but I'd rather argue down a priority than set nine of them from scratch.
Then I tested the other direction, closing the loop in the language I'd use with a teammate: "UI Styling Issue on Platform this is done. mark as done". No ID, no status enum, no clicking into the ticket. It matched the title, flipped SOM-1 to Done, showed me the field table it had changed, and updated the dashboard behind it.
Worth stealing — Every write action replies with a table of what changed — ID, title, status, priority, assignee, link. It sounds like a small formatting choice. It's the difference between trusting the agent and re-opening Linear to check its work every single time.
What it actually cost
Most build-in-public posts stop before this part, which is the part I always want to read. The Analytics tab keeps a running tab per agent, so here's the whole thing after a month:
| Linear Issue Manager | ee0e7794f242 |
|---|---|
| Total turns | 35 |
| Tokens in / out | 3.0M / 41.8k |
| Distinct users | 2 |
| Heaviest end-user turn | 5,054 credits |
| Lightest end-user turn | 54 credits |
| Credits spent | 35,131 |
| USD charged | $35.13 |
One month of building and using the agent, 8 Jul – 6 Aug 2026. Screenshot below.
Thirty-five dollars, and the shape of it is more interesting than the total. 3.0M tokens in against 41.8k out — this is a reading job, not a writing job. Almost all the spend is context: the agent loading the codebase while building, and loading a Slack channel while running.
The two end-user turns tell the same story. Reading a channel and creating four issues cost 5,054 credits, roughly five dollars. Marking one issue as done cost 54, about five cents. Batch your triage; the expensive part is the reading, and you pay for it whether you file one issue or four.
Most of the $35 was me building, not the app running. Once it settled down, a week of normal use was small change.
Four things that broke
1. It filed the same bug in two different teams
Look at the bottom of the issues board: SOM-1 and CHI-29, both titled "UI Styling Issue on Platform", living in two different Linear teams. I'd been sloppy about which team I meant and it did the reasonable thing with an unreasonable input. Fix: pin a default team in system_prompt.md, and make it search existing issues by title before creating anything new.
2. Priorities didn't survive the trip
The chat confidently reported SOM-6 as Urgent and SOM-5 as High. On the board, both show None. So priority is being set in the reply text without being written to the Linear field — the kind of gap you only catch by looking at both screens at once. Everything else wrote through fine.
3. The counters lie
The header says 0 open · 0 done · 2 from Slack while nine issues sit right underneath it. Backlog isn't being counted as open. A five-second fix in StatsBar.tsx, but a stat bar that's wrong is worse than no stat bar.
4. Everything lands in Backlog
Every created issue defaults to Backlog with no assignee, which means an urgent bug and a typo report arrive in exactly the same place. The next iteration routes anything marked Urgent straight into To Do and assigns it to whoever owns that area.
None of these needed a rebuild. Three are prompt edits and one is a component fix, and both are things I can do by describing them in the same chat window I built the app in.
So is it worth building?
If your bugs already flow cleanly into a tracker, no. This solves a specific, boring, extremely common failure: the gap between where people complain and where work gets tracked. Nobody wants to open a second tab to file a ticket, so they don't, so the bug evaporates.
What surprised me wasn't that an AI could create Linear issues. It's that the whole thing — dashboard, chat, Slack connection, deployment, a live URL — took less time than the triage meeting I was trying to avoid. And when it got something wrong, fixing it meant typing a sentence, not opening a settings panel and guessing.
Nine issues that would otherwise still be sitting in Slack under a 👀 react. I'll take it.
FAQ
Do I need to know how to code to build this?
No. The app was described in plain English and the platform wrote the React frontend, the Python agent and the tool wiring. You can read and edit every generated file, and push the whole project to GitHub — but nothing forces you to.
How much does an agent like this cost to run?
This one spent 35,131 credits — about $35 — across a full month of building and using it. Most of that was build-time iteration. A Slack triage run that created four issues cost around 5,000 credits; a simple status update cost 54. Cost tracks how much context the agent has to read, not how many issues it writes.
Can it handle more than one Linear team?
It can, and that's exactly where it needs a rule. Left ambiguous, it created the same ticket in two teams. Pin a default team in the system prompt and have it check for an existing issue by title before creating a new one.
How is this different from a Zapier or Slack workflow?
A workflow fires on a trigger and maps fields. This reads a channel, decides which messages are genuine bugs, writes a proper title and description for each, sets a priority, and can be argued with afterwards in chat. The tradeoffs are cost per run and less predictability — it's judgement, not plumbing.
Can I export the code or host it myself?
Yes. There's a Push to GitHub button in the builder, and the generated workspace is an ordinary project: React components, an agent.py, a requirements.txt and a Markdown system prompt.
How long did the whole thing actually take?
Under an hour from first prompt to a live URL, including the theme rewrite and the tool-chip cleanup. Deploys ran about 30 seconds each.
Build yours in an afternoon
Describe the internal tool you keep meaning to build. Something writes it, connects it to Slack and Linear, and puts it on a live URL. Start building free →