um-maybe
A hallway check that asks: um, maybe you could just…
You know the feeling. You pitch your plan in the hallway to a colleague who knows nothing about it, and their answer is “um, maybe you could just …”. Annoyingly, they’re usually right.
um-maybe gives your agent that colleague. A subagent on a weaker model sees the pitch and nothing else, and questions it. For each question the agent concedes, defends the piece with proof (something you asked for, quoted), or admits it can’t.
Install
npx skills add Fullstack-Rocks/skills --skill um-maybe -a claude-codenpx skills add Fullstack-Rocks/skills --skill um-maybe -a codexnpx skills add Fullstack-Rocks/skills --skill um-maybe -a cursornpx skills add Fullstack-Rocks/skills --skill um-maybeInstall the um-maybe skill from https://github.com/Fullstack-Rocks/skills by running npx skills add Fullstack-Rocks/skills --skill um-maybe, then run it on your plan before you implement it.It also runs from inside under-engineering, so install it together with the other three under-engineering skills.
Try saying
Transcript
> Plan a CSV export of the invoices in InvoiceList, then run the hallway check before writing code. Skill(um-maybe): two hallway rounds with a colleague agent on a lighter model. Simplified: the shared CSV module, full escaping, the extra id column and the shared download helper. Kept, with proof: the export button, the invoices already loaded, the browser download. Unproven: the header row, and how “paid” is written. Each comes with A) keep or B) a simpler option. Does the simpler plan make sense to you? Once you’ve answered the two questions above, I’ll write the code.
How does it work?
First, what counts as proof? Either something you asked for, quoted, or something you asked for that can’t work without it. “Best practice”, “future-proofing” and “it’s cleaner” are not proof.
- Write the pitch. The problem in one sentence, what you asked for (quoted), and each planned piece with its reason. It stays under 15 lines with no file paths or code, and every extra is named: validation, retries, caching, config, abstraction layers, new modules.
- Hallway rounds. A subagent on a weaker model gets the colleague prompt and the pitch, and nothing else. For each question the agent concedes, defends with proof, or says it can’t. Three rounds at most.
- Weigh each piece. Every piece lands in exactly one group: Simplified, Kept (with proof), Unproven (with every simpler option and what it gives up) or Belongs elsewhere (infrastructure, legal, product or another team).
- Ask the human. One message, and then it waits. The message holds only the unproven pieces, each with its options, and asks whether the simpler plan makes sense.
No subagents? Then the agent plays the colleague itself, using only the pitch, and tells you it did.
But does it work?
From the recording
Four of six planned pieces simplified
In the recording, the shared CSV module turned into a few lines inline in InvoiceList.tsx, full escaping became a plain join (every field is a number or true/false), and the download helper shrank to about 4 lines in the click handler. Only two questions went to the developer: the header row, and true/false vs Yes/No.
