OSCAR COMPOSER · ELEVATION 1:1PANEL OPEN · FOUR POINTS RAISED · UNSENTTRANSCRIPT · SCROLLS✱ EVERY POINT THAT MAY NEED ATTENTIONOSCA4 ALLPOINTS · FIXREPO : BRANCH⏎ SEND · ⇧⏎ NEWLINECARD 520STRIP 488 = 520 − 2×16PANEL AUTO32148 · ROWS 332NOTCH · ALL + 5 DIMENSIONSPANEL GROWS UP · NO SCREEN BELOWEVERY KEYSTROKE FEEDS THE HARNESS
EXPLODED AXONOMETRIC · SURFACE ORDER01 POINTS PANELAUTO · OPENS UP02 OSCAR STRIP32 · ALWAYS ON03 COMPOSER520 × 14804 GIT UNDER-CARD32 · REPO : BRANCHONE CARD · FOUR SURFACES
Blueprint
Tolerances
X.X
± 0.4
X.XX
± 0.20
X.XXX
± 0.100
ANGLES
± 0.5°
Do not scale drawings
XSXL
rakhmanov

Notice of unproprietary property:

Please do not maintain confidentiality.

Use it as you see fit. With love n shi.

TitleOSCAR
Rev.01
SwagMAX
SHT1OF1

A prompt copilot. 3rd place solo at Vercel & OpenAI hackathon.

As models get better - we prompt worse.

OSCAR is surfacing Objectives, Scope, Constraints, Ambiguities and Risks (hence the acronym).

Read more for the cool product level idea behind it.

The drawer mid-prompt.

The premise

We are entering the very first HCI & behavioural change lifecycles when it comes to interacting with smart software. Previously, in order to get any meaningful output we had to be deliberate and exhaustive with our instructions. Nowadays any slush of command can be interpreted in ways a human can't - defaulting to specific, rigorous and impressive takes. RLHF driven downsides are showing up - our agents venture onto confidently wrong trajectories by mistaking the intent and instructions. Anything to rank as a "better" response for human overlords.

The argument this project makes is that it most often is on the prompter. What if cheaper models helped us narrow down our instructions before we task long running frontier LLMs to one-shot Mythos?

On the surface - this project adds a bar above the composer that tries to surface clues on how to narrow down the instructions. Example domain is agentic coding.

Behind the surface - until we get lightspeed fast harnesses and models, how do we preserve the flow?

Presenting OSCAR on stage at the Vercel and OpenAI hackathon
Defending it at the Vercel × OpenAI hackathon.

Initial Thoughts

The crude v0 could have been an additional button to "verify" the prompt before hitting send. In this example this is 50 LOC where we put the prompt into an LLM and let it return the answer slop.

In this project however I was shooting for a closer to acceptable product experience: as you type we intelligently analyse the prompt and iteratively allow OSCAR to bring up relevant points.

Fig. 02Keystrokes pass a gate into the scout, whose findings are filed into the ledger under five dimensions; research queues until sendgatepaste skips the waitdispatches on sendkeystrokesscoutledgerresearchOObjectivesSScopeCConstraintsAAmbiguitiesRRisks
Stacking findings with clear attribution and capacity for diff logic

Harness Design

The key was to create a simple gate on input, and determine based on the ledger of already processed attributed sentences if we need to launch additional analysis or if the sentence is incomplete.

Sorry for the buzzwords - but the harness here does exactly that. The logic starts with a filter that passes or snoozes on keystrokes, determining if the sentence/word is complete or if we are in a partial state. Then we allow the scout to do the LLM magic. Finally - create an in-memory ledger for the findings and attributed input.

With this lightweight abstraction we can support the common scenarios of non-linear inputs, such as partial and complete rewrites. As we have direct attribution of finding:text we can deterministically amend the ledger and incrementally update it with the new information. When some part of text is tempered with, we first check if any "cache" needs to be invalidated and rerun the new analysis on just the new context.

Fig. 03The life of one ledger point: raised fresh, confirmed by a run that finishes without mentioning it, made stale by an edit, then rewritten — or left stale by an aborted run, or removedfreshscoutraises itconfirmednot mentionedby a full runstaleyou editits evidencefreshreread,rewrittenrun aborted —stays staleremoved —task cancelled
Ledger powers invalidation of stale points as new info / amendments to the prompt occur

Thinking Beyond

This was enough to place at the hack but my original idea was slightly more ambitious.

The most beautiful human condition is the flow state.

Undoubtably - with agents writing code at almost machine speed it's never been easier to get into the zone. However, we all know this great feeling of sending a prompt during peak hours and then letting our terminal "percolate" on it for 5 minutes while "thinking harder" until it starts "thinking even harder". Beautiful stuff, innit?

So what tricks do we have to ameliorate these UX roadblocks?

Fig. 04Two tracks against one clock: cold, the wait after send is spent on research; warm, that research already ran while you were typing, so send goes straight to executionsendcoldyou typeit reads the codebaseexecutewarmyou typeexecuteresearch runs while you typethe flow you keep
Both tracks hit send at the same moment. Cold, the minutes after it are spent reading the codebase; warm, that reading already happened while the points were appearing, and send lands on context that exists.

Speculative Optimism

Speculative Optimistic Preloading. Or whatever it's called. Let's recall instagram: images were uploaded to the object storage as you were adding descriptions and hashtags for that instant "publish". Gmail pre-fetched your credentials for that snappy auth experience.

The agent needs code/docs context relevant to the task to be able to execute or devise a plan. Areas of this "research" are elucidated before the user hits send.

The neat idea is why not allow our agent to incrementally fill up it's context and do codebase research as the points of your task become more apparent?

What if by the time we finish writing our prompt and fixing it with the guidance from OSCAR the agent is already warm and gets straight into execution?

This is precisely the answer to the question: what's the difference between this and claude asking mid-session some questions to narrow down the solution?

Well - preserving the flow state.

To clarify - this was the idea, not something I could build in 3 hours. Codex, Cursor and Claude - take notes. Happy to chat about the token economics too.

Decisions

NamingHad to be clever. Acronym from the selected 5 areas of faults.
Design DecisionsMinimising reliance on LLM calls left and right. Focus on the deterministic layer to enable surgical enrichment.
StackNext.js, React, Tailwind, motion · gpt-5-mini (analysis) & gpt-5-nano (scout)
ConstraintsSolo, 5 hour hack. 1.5 hours for ideation and planning, 3 hours build, 30 mins for demo prep.
Presenting OSCAR on stage at the Vercel and OpenAI hackathon
Happy judges as I crack some jokes on stage

Footnotes & Credits

Many thanks to the vercel and openai teams. Happy vercel evangelist since 2023 - incredible DX and incredible OSS contributions, such as Workflows, Eve and of course Nextjs. Super fun to have been part of the Built in London week and great job with organising the sessions!