Free · your keys · your repo

Your day is not
the build.

You already trust Claude to build your product. Then you spend the day dispatching it, checking it, unblocking it, re-prompting it.

That is operating a build, not deciding what should be in one. ekadant takes the operating over, and hands you back the part that was always yours: knowing what to build next. Runs on your own GitHub repository and your own Claude subscription. No service, no server, nothing to pay us.

Ideation becomes the interface

Once the building looks after itself, the only interesting question is what to build next — so that is what the system spends its attention on.

Every Monday the analyst reads what you have not had time to: competitor changelogs and pricing pages, app-store reviews of rival products, the forums where people describe exactly what is wrong in their own words, platform and policy shifts, and job postings — which tell you what a competitor is staffing to build months before it ships.

It comes back with at most five proposals, ranked by evidence rather than novelty. A dull complaint three customers made outranks a rival's launch nobody asked for.

Every claim about the outside world carries a dated source URL, enforced in code. Not a style rule. You will repeat these findings in a roadmap review, and an invented or three-year-stale competitor release costs you personally. A quiet week is reported as quiet rather than padded out.

You decide what happens to each one. Choosing is the job this whole thing exists to give back to you.

Ten ideas for the price of one

Point it at a one-page idea and the scout does two things in about ten minutes and a few pennies.

First it tries to talk you out of it: the genuinely hard part, who already does this, what will stop you in week three, what it will cost. A cheap no beats an expensive maybe, and an idea killed on Tuesday means you run the next one on Wednesday.

If it survives, the second thing is already done — the scout writes down what the product must actually do, and those requirements go straight into the build.

The order is the whole point

Requirements written before anyone looked hard at the problem are a feature list: they describe what someone imagined and miss the thing that breaks them later. On a real run — lending books to friends — the brief said "phone-first web app, free hosting". The scout came back with the ledger survives a phone: opening the app months later, on a different device, shows the same list, because iOS evicts web-app storage after seven days. Nothing in the brief could have told you that. It is the requirement the product lives or dies on.

Or a product you already have

Point it at an existing repository instead. It reads what is there, derives the checks from the code and tests that already exist, and tells you honestly how much of your product is covered by tests that decide anything — usually less than you would like. Then the same loop takes over: intake, build, verify, watch the market, intake again.

Why you can leave it alone

Because nobody is watching, the only thing between you and forty green checks on a broken product is what those checks mean.

So every requirement becomes a check: one observable claim plus the procedure that decides it. Progress is computed, never asserted by an agent. Claims containing fast, secure or intuitive are rejected outright — those are matters of taste, and the system is honest that only a person can settle them.

And whoever writes a test does not get to pass it. One agent turns the idea into claims, a second writes the procedure deciding each, a third makes it pass, a fourth attacks the result. That separation is enforced by the tooling, not requested in a prompt — an agent talked into cutting a corner is refused rather than trusted.

It stops before it costs you

It is spending the same Claude allowance you use all day, so the limits are structural rather than advisory.

Budget spent → nothing starts. The gate runs before each agent, because nothing can predict its own consumption once it is running.
Plan limit reached → the schedule disables itself and opens an issue. It never retries into your allowance. You should still be able to work at 2pm.
The same failure twice → it escalates with everything it tried, rather than burning another cycle on a fifth variation.
More than a handful of questions waiting → it stops. Twenty questions a day is a design failure, not a backlog.

Spend is metered per idea and across all of them, because ten projects each politely inside their own budget still empty one subscription.

Your day

07:00  the brief — what shipped, what needs you, what the world did
...    decide three things
03:00  the next unit of work runs

Mondays, the analyst reports. Questions arrive as GitHub issues and you answer them by replying. That is the entire interface.

Start

One command. The plugin is fetched for that session — nothing installed, nothing left behind:

claude --plugin-url https://ekadant.polyglyphanalytica.com/ekadant.zip

Then point it at something:

/ekadant:scout       # is this worth building?
/ekadant:adopt       # a product that already exists
/ekadant:radar       # what has the market been doing?

Leaving it running

Give an idea its own repository and let it work while you are not:

gh repo create my-idea --private --clone && cd my-idea
curl -fsSL https://ekadant.polyglyphanalytica.com/bootstrap.sh | bash

Write IDEA.md, add one secret from claude setup-token, and push. The token authenticates as you, lives only in your repository, and is never shared or pooled — that is what bring-your-own-keys means here. Setup takes about fifteen minutes.