Developer Elite

Talk through the task — get a spec an AI agent can build

What it makes

implementation spec

Development

Real output

A messy feature request, compiled into a spec

A spoken feature idea with interleaved requirements and an edge case half-mentioned.

What you said

So when someone deletes a transcript, we show a confirmation modal, that's fine. But after it deletes, there's no feedback and if they deleted wrong one, it's gone. I want like a toast at the bottom that says deleted and has undo for like 5 seconds. If they click undo it restores it. But we also must not mess up if they delete multiple transcripts fast. Also should work in light and dark themes and not be annoying.

What you got

Objective

Add a dismissible toast notification with a 5-second undo action after a transcript is deleted, providing post-deletion feedback and a lightweight recovery path.

Functional Requirements

After a transcript deletion is confirmed, display a toast at the bottom of the screen with a "Deleted" label and an "Undo" action.
The toast auto-dismisses after 5 seconds if the user takes no action.
Clicking "Undo" within the 5-second window restores the deleted transcript to its previous state and position.
Each deletion produces its own independent toast with its own 5-second countdown; multiple toasts coexist, and undoing one does not affect the others.
The toast renders correctly in both light and dark themes.

Edge Cases

Actual deletion timing: Confirm whether the transcript is soft-deleted (deferred until the undo window closes) or hard-deleted immediately with a restore call on undo — this materially affects the data model and API contract.
Rapid sequential deletion: Decide whether to cap the visible toast stack or scroll it when many deletions queue up.
Delayed restore failure: Decide how to surface an error if the restore call fails after the user clicks "Undo."

Why it’s better

Every requirement you said survives — the 5-second undo, per-delete independence, light/dark, "don't be annoying" — and the one decision that actually drives the data model (soft-delete vs. hard-delete-with-restore) is surfaced as a question to confirm, not silently invented. The full spec also includes Constraints and verifiable Acceptance Criteria. Nothing the speaker didn't say gets committed.

A removal task, with the cleanup checklist done for you

A spoken request to remove a now-pointless setting.

What you said

On the live recording page there's a recording settings button, and it opens a dropdown with three audio source options — microphone, system audio, and microphone plus system audio. We only need the microphone for live recording, so we can get rid of the others, and since microphone is the only one left there's no point having the setting at all.

What you got

Objective

Remove the audio source selection UI from the live recording page, hardcoding microphone as the only input source.

Functional Requirements

Remove the "Recording Settings" button from the recording panel on the live recording page.
Remove the audio source selection overlay and its three options (Microphone, System Audio, Microphone + System Audio).
Hardcode microphone as the active audio source for all live recordings — no selection step required from the user.

Edge Cases

Verify whether any persisted user preference for audio source exists in local storage, a database, or a session store — and confirm how to handle stale values after this UI is removed.
Confirm whether removing the "Recording Settings" button leaves the settings overlay completely empty, or whether other settings inside it must be preserved in a restructured container.
Decide whether dead code from the removed options (components, constants, handlers, types) should be fully deleted or only detached — full deletion is preferred to avoid drift.

Why it’s better

Removals are where specs leak. Developer Elite runs the checklist for you: what persisted state could go stale, whether the container is now empty, and which code becomes dead — each as a "Verify/Confirm/Decide" item rather than an assumed answer. You get the core removal plus the cleanup you'd otherwise discover mid-implementation.

What comes back

A two-line idea stays a short spec; a multi-requirement feature gets the full structure. Detail scales to your input.
It commits only what you said. Persistence, accessibility, performance, a specific mechanism — if you didn't name it, it's a question to decide, not a requirement.
For removal tasks it runs the removal checklist: what else shares the UI container, which code becomes dead, what persisted state needs cleanup.
It keeps the decision you landed on after thinking aloud and drops the alternatives you reasoned past — no resurrecting the option you rejected.

What you can count on

Won't invent — no fabricated persistence layer, design system, API, or decision you didn't make
Flags, doesn't guess — risks and ambiguities surface as "Verify…/Decide…" items with a sensible default, never as committed requirements
Built for AI agents — copy-paste-ready, single-# sections, no narrative, so a coding agent can execute it directly

Install Developer Elite and try it on your own voice.

Is this hat for you?

Shapes rough thoughts into structured technical specs and prompts.

Developer Elite turns a rambling, half-formed technical thought into a structured, implementation-ready spec an AI coding agent (Claude, Codex, ChatGPT) can execute without a dozen clarifying rounds. It captures exactly what you said — the requirements, the constraints, the decision you landed on after thinking out loud — and proactively flags the risks and edge cases you didn't mention. The discipline is the moat: anything you didn't state stays a question to decide, never an invented requirement. It won't fabricate a persistence layer, a design system, or a decision you didn't make, and it stays at your altitude — "preserve the code blocks" doesn't become a spec about language tags you never mentioned. You talk through the task; it hands you the spec.

Best for

A messy feature request — "add an undo toast after delete, don't break on rapid deletes" comes back as a structured spec with requirements, edge cases, and acceptance criteria
A removal or refactor task — it works the removal checklist: what else shares the UI, what becomes dead code, what persisted state needs cleanup
Thinking out loud toward a decision — it captures the position you landed on, not the alternatives you reasoned past
Anything you want to hand to an AI coding agent (Claude CLI, Codex, v0) and have built with minimal back-and-forth

Not for

A quick message, status update, or email — reach for Work Email, Clarity, or Casual Convo
A delegation brief for a human teammate — Delegate names an owner and keeps it light; Developer Elite writes a full technical spec
A personal journal or meeting recap — reach for Voice Journal or Meeting Notes
Brainstorming where you don't yet know the task — it specs what you said, it won't invent the idea for you

Using it

How it works

Just talk through the task — the problem, what you want, any constraints or stack details. Developer Elite compiles it into a spec.
It opens with a clear Objective and structures the rest into Functional Requirements, Constraints, Edge Cases, and Acceptance Criteria — scaled to how much you actually said.
It commits only what you stated. What you left open becomes an Assumption (with a sensible default) or an Edge Case to decide — never an invented requirement.
It proactively surfaces risks, race conditions, and failure modes you didn't mention — framed as "Verify…/Decide…" so you close the gap, not so it guesses the answer for you.

Try saying

when someone deletes a transcript, after it deletes show a toast at the bottom with undo for like five seconds, and don't break if they delete a few fast
remove the audio source dropdown from the recording page, we only need the microphone now
I keep going back and forth but let's just store the data in Postgres with a one-time import from localStorage and drop localStorage after
the team members page is just a flat list and you can't find anyone past thirty people — turn it into a filterable grid of cards with role and status filters

Tips

Mention your stack if it matters ("we're on Drizzle and Postgres") — it folds it into Constraints instead of guessing.
Talk through your reasoning out loud — it keeps the decision you land on and drops the options you reasoned past.
Don't pre-structure it in your head — say it messy. Compiling the ramble into a clean spec is exactly the job.