Grok Bot for game studios: player comments filed as GitHub issues

You can give Grok Bot the job most small studios put off: read what players post and turn it into tickets your coding agent can work. This playbook follows one solo developer whose Bot files itch.io comments as GitHub issues, one per problem, with the player's hardware details attached. A coding agent then checks each one against the code, and he makes the calls on anything players would notice. It fits solo and small game studios, indie app makers, and any product team that gets feedback in public comments. It's a self-report with screenshots, and we haven't run it.

Not tested: we haven't run a comments-to-issues routine ourselves.

Who runs it#

Arda Karaduman runs Gand, which he calls "my one-person studio" in a blog post on Oct 11. His post's summary reads: "Fourteen Grok bots run the office side of my one-person studio: research, briefs, infra checks, social posts." His resume lists his day job as Systems Architect at Veltra, working remotely from Tokyo.

Disclosure: Two tools in his setup are his own projects: Reliquary, the memory server his research Bots use (his post), and tincan, which his coding agents use to message each other (his post). Both have public repos on his GitHub account, per those posts. The game in the story is his. We found no staff, partner or paid tie to Cursor, xAI or SpaceXAI on his resume or blog.

The feedback loop#

He splits the work in two: "Grok Bot is the office. The workshop is still Claude Code, which writes the actual code, and the line between them is a GitHub issue."

1. A player comments. Someone ran the Amiga version of his game HELIOBANE on real hardware and left a comment on the itch.io page with two bugs, a feature request and a question.
2. The Bot files it. His Amiga Research Bot has "a weekly itch report every Monday at 09:12, and it files player feedback as GitHub issues on gandtr/heliobane-amiga, labelled itch-feedback." Then, "On Saturday morning it read the comments on the page, split them into one issue per problem, and wrote each one up properly, with the hardware and ROM version where the player gave them." He doesn't say what started the Saturday run.
3. The coding agent measures first. Claude Code read the issues and "before touching the game it checked each one against the code." That changed some answers, for example "The engine flame (#2) was not cut to save CPU. It was never ported at all."
4. He decides. "I approve. This is the step I keep. Anything that changes how the game looks or plays waits for me."

His summary: "I didn’t write a single one of those issues." And on speed: "From the issues being filed on Saturday at 10:22 to the archive and quit fixes being merged was about nineteen hours."

What his screenshots show: one has five open issues labelled itch-feedback and a Closed count of 3, each "opened 1d ago" by his own GitHub account, c0ze. That's under his name, not a separate bot account. Another is a map of his 14 Bots that he says the Chief of Staff drew "using only connections it could verify from transcripts." His itch devlog on Oct 12 lists the fixes for the full release: "the pods and the engine flame are drawn, and Esc on the title quits to Workbench." One of the eight issues asked him to update an old warning on the itch page. The page now reads "Tested on real hardware by players: an A4000/030 with Kickstart 3.0 and a 68060 Amiga."

The rest of the office#

A Chief of Staff Bot is the front door: "It has its own email address, wakes up on new mail, and passes work to whichever bot owns it." On Mondays a Social Bot asks Games Research for Steam numbers, drafts posts, has a web agent update the site, and "queues the posts in Buffer, which sends them out to X, Bluesky and Mastodon."

Why it matters at work#

Our read: public comments are where small teams lose bug reports. They sit on a store page, mixed with praise and questions, until someone copies them out. One Bot with one job, a fixed label and a "one issue per problem" rule turns that pile into something a coding agent or a teammate can pick up. He puts the handoff this way: "An issue can be read, closed, argued with and linked from a commit. A chat message disappears."

Set it up#

These steps are ours, built from his post and the docs. He hasn't shared his prompts.

1. One Bot, one source. Cursor's docs say to create "a separate Bot when the work has a distinct goal, set of tools, working style, approval boundary, or recurring schedule" (docs). His filing Bot covers one game's itch page.
2. Connect GitHub and pick a label. Issues show up under whatever account you connect, as his screenshot shows. A label like his itch-feedback keeps them easy to filter.
3. Run it once by hand. The docs say "Start with a one-time task, make it reliable, save the method as a skill, and only then automate it" (docs). Try it on a test repo first.
4. Then schedule it. He runs his weekly. Keep the approval line where he keeps it: the Bot files, a person decides what ships.

Starter prompt (ours, untested)#

Your one job is player feedback for [game] on [itch.io page or store page]. Every Monday at [09:00, your time zone], read new comments since your last run. Split each comment into one item per problem. For each bug or feature request, open a GitHub issue on [owner/repo] with the label [player-feedback]: a short title, the player's words quoted, and any hardware, OS, version or settings they gave. Search open issues first and add a comment instead of a duplicate. Don't open issues for praise or for questions only I can answer; list those for me here. Never reply to players, promise a release or port, or close an issue. Post a list of what you filed with links.

The weekly report, one issue per problem, the label, the hardware details and keeping the port question for himself are his. The duplicate check, the praise filter and the stop rules are ours.

Gotchas#

• Test runs are real. "A test does real work. It can change files and use connected apps. Use a safe input" (Routines help). Test on a scratch repo so trial issues don't land in your real tracker.
• Your keys are shared. On the Bots' computer, "Command-line credentials are shared" and "The screens are separate work surfaces, not separate security boundaries" (docs). An itch.io API key saved for one Bot is there for all of them.
• Routines add up. "Each run spends usage, so a routine that runs often spends more than one that runs rarely" (Routines help). His own audit found "Eight routines fire between 8:52 and 10:07 on Mondays."
• One owner per stage. The docs say "Ask for a single owner at each stage; parallel handoffs create duplicate work and noisy updates" (docs). His map turned up overlaps, such as "News and Daily Recap both send morning briefs."
• A Bot can mistake its own gaps for outages. His Chief of Staff "had reported its own blind spot as an outage" when it said Google Calendar was down. Calendar was fine. That Bot just didn't have it connected.

What to watch#

• Calendar triggers. He plans to have the Social Bot act on launch and sale dates in Google Calendar. In his words, "None of that is wired up yet."
• The Monday pile-up. He hasn't decided "whether to spread the routines out or merge the bots that overlap."
• Numbers. He gives the 19-hour turnaround but no hours saved.

Related#

• Grok Bot for engineering: supervising cloud agents, PR watches, and nightly audits
• Turn built-in X search into a daily product feedback watch
• Grok Bot for support: intake that a webhook or a Slack reaction starts

Sources#

• Arda Karaduman: How I use Grok Bot to automate my business (Oct 11)
• Heliobane (Amiga) on itch.io
• Heliobane (Amiga) devlog, Oct 12: vivid colours and your fixes
• Arda Karaduman: resume
• Arda Karaduman: Introducing Reliquary
• Arda Karaduman: Introducing tincan
• Cursor Docs: Work with Grok Bot
• Cursor Help Center: Routines
• Grok Bot docs: Computer and apps