The problem

Once you can actually design and build things fast, the bottleneck stops being execution and becomes choice: which of the twenty ideas floating around is actually worth the next two weeks. Most people answer that with whatever’s loudest in their head that morning, or by asking an LLM to “suggest the best idea,” which just produces a plausible-sounding answer nobody pressure-tested. Teams have the same problem at bigger scale — an automation backlog picked by whoever complained most recently in Slack, a roadmap built on anecdote rather than on how often a given task actually recurs and how much it actually costs when it does.

I built this because I’d solved the “can I build it” problem and was left with the harder one: which projects are actually worth the time, and how do I stop that decision from being vibes.

The approach

The tool runs as a staged pipeline (built on the automation-discovery skill, installed and driven from inside a Claude Code session): Stage 0 audits which of my own work surfaces it can actually read — right now that’s AI session history under my Claude Code projects folder, with Slack, tickets, and other surfaces explicitly marked “excluded” until connected, so it never quietly overclaims coverage. Stage 1 fans out parallel subagents to ingest that history — in my case ~3,431 session files across 76 projects over a 90-day window — sampling 3-4 representative events per templated cluster instead of reading every single one (some clusters were huge: ~887 relevance-gate sessions, ~425 LinkedIn drafts, ~424 blog drafts, ~404 YouTube summaries, ~401 batch translations). Stage 2 groups those events into candidate recurring jobs and applies a hard filter: a candidate needs at least 3 independent occasions on separate dates, not just high volume, before it’s allowed to become a proposal. Stage 3 turns the survivors into an actual offer sheet — for me, 10 candidates became 4 concrete build proposals, each with a plain description of what it does, a setup/ongoing cost estimate, and a testable acceptance checklist (e.g. “run twice on the same input, the second run should detect the duplicate instead of redoing the work”). I pick which offer to build; nothing gets built automatically. There’s also an independent audit pass that opens the real source transcripts for every event and checks the tool’s claims against them before any of it is trusted — it caught a coverage gap in my own run and flagged near-miss candidates that looked recurring but weren’t.

Concretely, my first run surfaced things like a session-start context briefing (reads git log + TODO/DONE files + last session transcript, writes a short “where we left off” markdown instead of me manually recapping), a glossary-based batch translator, a content-draft queue runner, and a batch generator for a recurring legacy-system analysis task — and it was honest enough to help me realize one of those (the content-draft runner) wasn’t actually the right fix, because the real pain was backlog triage in a different project, not drafting itself.

What I learned

The valuable part wasn’t the ranking — it was the rejection discipline. Raw session volume is a terrible proxy for “this is worth automating”: 401 translation sessions turned out to be one two-day batch (one occasion, not a recurring job), and a spreadsheet-update task with two events 22 minutes apart looked automatable purely because the numbers were big, until the >=3-independent-occasions gate threw it out. If I’d just asked an LLM to eyeball my history and rank ideas, both of those would have looked like slam dunks. The gate — and the separate audit pass that reopens the raw transcripts and checks the tool’s own claims against them — is what makes the output something I can actually act on instead of another confident-sounding LLM summary I still have to fact-check myself.

Where this could go

The same pattern generalizes past my own Claude Code history: point Stage 1 at a team’s Jira/ticket tracker, Slack, and support queue instead of (or alongside) AI session logs, and you get the same thing companies actually lack — an automation and project backlog ranked by evidenced, recurring pain with an audit trail behind every claim, instead of a roadmap built on whoever escalated loudest to a VP last week. The “run once, propose 4 offers, human picks one, only the chosen one gets built” shape also maps cleanly onto how an engineering org should triage an automation backlog: cheap discovery and evidence-gathering up front, real build effort spent only on the item a human explicitly signed off on with a testable acceptance bar attached.

Takeaway

Prioritization stops being guesswork the moment you force every candidate to survive an independent-evidence gate and an audit pass before it earns your time — that discipline is worth more than any ranking algorithm.