Posted on Jul 30 • Originally published at linkedin.com

Give your coding agent a focus group

#ai #claudecode #devtools #showdev

You ship without a research function. No panel to call, no recruiter, no budget line for any of it. And the honest version of "who is this for" is a guess you made in month one and never went back to.

So the decisions stack up. Which name. Which price. Which of two framings goes at the top. Whether the onboarding reads as obvious to anyone who isn't you. Normally you pick one, ship it, and find out in six weeks. If you find out at all.

One skill changes that. You type the question the way you'd say it out loud, and a hundred people built to match your actual users answer it, without you leaving the terminal. It won't replace talking to real users. It will stop you shipping the version you'd have thrown away.

/plugin marketplace add ph3on1x/vibesight-skill
/plugin install vibesight@vibesight
/reload-plugins

Then /vibesight login once. Any one of Node, Bun or Deno on your PATH is the whole dependency list. Nothing to install, nothing to build.

The surface is one command

/vibesight <whatever you want to know>

That's it for most runs. The modes are there when you want the reins:

/vibesight group <ask> builds a cast and stops before any study
/vibesight study <groupId> <ask> points a new question at a cast you already have
/vibesight draft <ask> designs both and launches nothing
/vibesight resume picks a run back up

Underneath it, a whole studio

Your coding agent never plays your users. It writes the brief and hands it to vibesight.ai, where the room is cast and the study is run.

your agent    → reads files, writes JSON, calls the CLI
vibesight.ai  → casts the personas, runs the study across providers
every answer  → carries its persona and the model that produced it

A study is a hundred separate respondents, each answered by a model drawn from a pool that spans several providers. That's why the room doesn't collapse into one voice, the way it would if you'd just written a very long prompt.

One line, and it has a plan

You don't fill in a form. You name the decision and point at real files, and what comes back first is a checklist it holds for the rest of the run.

Paths in your ask are treated as content, not strings. It opens them, then follows what they point at. I named one HTML file. It went and found my go-to-market doc on its own.

It designs the room in front of you

Segments, weights, and a column for where every choice came from. Anything it guessed instead of read, it marks as a guess.

That column is the whole difference. You aren't describing your audience to a stranger. The description is already in your repo: the README, the positioning doc, the ICP notes you wrote six months ago and forgot. It reads them.

Ten attributes, each with a reason to exist. Then it audits its own design in front of you, before you approve anything: no attribute encodes a stance on the product, no segment is cut on likely approval, and here are the cuts it will refuse to report because the sample can't carry them.

Two keystrokes and the room is real.

Then it writes the study

Ten questions, funnel-ordered, every count paired with a why. A blocker question and a converter question, so a run can't come back carrying only praise.

You wrote none of that. You asked one question in plain English and went back to your branch. It handles the rest, then pings you when the answers land.

It comes back with an answer, not a data dump

It opens with the decision, in the terminal you're already in.

Every count comes back attached to the quote that produced it, so any number can be checked against the person who moved it. Nothing is flattened into a summary you can't take apart.

And it closes with the part research usually leaves out: a short, ranked list of what to change, each item naming the thing it fixes. You don't have to interpret it. You just make the edit.

Design, launch, read, recommend. The whole loop finished before I'd left the branch.

It keeps the receipts

Every run writes its own directory: the group body, the study body, and every id the moment it's printed. Which means a study design is a file. Diff it, re-run it against a fresh cast, keep it in version control, hand it to someone else.

Under the skill is a plain CLI: one JSON object per command on stdout. Drive it yourself if you'd rather.

There's a dashboard, for when you want one

Charts split by segment, every bar tracing down to the people underneath it. You'll live in the terminal. This is for the times you want to read the room properly.

The run in this article is public, so you can check any of it yourself. Open a chart, click a bar, read the people underneath: