Omakase: Show Me

Sometimes I do not know what I want until I have something concrete to react to. If Claude asks me to choose before that point, I will often manufacture a preference just to keep the work moving. Sometimes that works. Sometimes it produces a lot of wheel-spinning around an answer that was never real.

I built omakase for that. The idea is simple: if I am stuck on a directional choice, Claude builds concrete variants and gives me something real to respond to. Not a bullet list of trade-offs. Not a tidy paragraph about pros and cons. An actual implementation I can look at, use, and judge.

There is a scene in UHF where a blind man solves a Rubik’s cube. That is what this feels like. Claude fiddles with the cube. I tell it whether the colors are right. I may not know how the pieces should fit together, but I can often tell when the thing in front of me has the wrong shape.

One small example made the value obvious to me.

I was adding a calendar view to a CLI app. It was not a giant product decision. It was one of those features that feels straightforward (“should have a calendar view”) until you realize you are pretending to have a visual preference you do not actually have. Should it be an agenda? A boxed week view? A month grid with counts? I could have spent an hour inventing criteria and more hours rationalizing the result.

Instead, I said: omakase it.

Claude built three different approaches in parallel. A simple chronological agenda with today and tomorrow labels. A boxed week view with stronger visual grouping. An ASCII month calendar with drill-down. Each one was built far enough to feel like a real candidate rather than a sketch.

The moment I saw them, my opinion crystallized.

The agenda view was right. The week view was clever but noisy. The month grid was fun, but the counts were not useful enough on their own; I needed task names. None of those judgments existed in a form I could have written down beforehand. They became obvious only after I had something to push against.

That is the core value of Omakase: not outsourcing the decision, but making the decision legible.

When the first pick breaks

I use it constantly, often multiple times on the same feature. I have been building a macOS dot-file viewer, and I spent longer than I should have bouncing around on how the editor should relate to the SVG preview. The work was not blocked because implementation was impossible. It was blocked because my current approach was close enough to defend and wrong enough to remain unsatisfying. Omakase gave me two clean architectural options, I reacted to the shape of them, picked one, and the wheel-spinning stopped.

Another example from that project was adding line numbers to the editor.

Variant A — NSTextView subclass (LineNumberTextView.swift)
- Subclasses NSTextView, draws gutter in draw(_:) override
- Uses textContainerInset + manual text container sizing to avoid the invisible text bug
- Provides scrollableLineNumberTextView() static factory
- Simplest integration - swap one line in EditorView's makeNSView()

Variant B — NSRulerView (LineNumberRulerView.swift)
- Subclasses NSRulerView, draws in drawHashMarksAndLabels(in:)
- Static installation / pinned to the scroll view
- Minimal integration: add one line after scroll view creation
- Apple's recommended approach for gutter content

Variant C — Side-by-side NSView (LineNumberGutterView.swift)
- Standalone NSView, syncs via scroll view bounds notification
- Not integrated into scroll view internals → adds a composition layer
- Most isolation: doesn't touch text view internals at all

My take: B is the cleanest — one-line integration, uses Apple's built-in infrastructure

Three approaches to line numbers. I understood maybe 30% of this. Did not matter.

Let me be clear: I do not know Swift. I have no idea what distinguishes an NSTextView subclass from an NSRulerView from a standalone gutter NSView. If Claude had just asked me to pick, I would have been guessing.

But omakase did not ask me to evaluate the technology. It showed me three working versions and asked which one felt right.

Omakase evaluated the options and recommended the NSRulerView path. On paper, it was the cleanest integration. One line to wire up. Minimal intrusion into the text view internals. I chose it.

Then it broke.

The editor text went nearly invisible because of a washed-out rendering bug that had haunted earlier attempts. In a normal workflow, that kind of failure can send you right back to the beginning. You re-open the architectural question, lose confidence in the direction, and burn time rediscovering alternatives.

But the alternatives were already there.

We swapped in the standalone gutter view instead. It avoided the fragile scroll-view internals, built cleanly, and shipped. No dramatic reset. No re-architecture spiral. The cost of being wrong had dropped because the space had already been explored.

That is an underappreciated part of the pattern. Omakase is not only useful when the recommended answer is correct. It is useful because it lowers the blast radius of a wrong first pick. Once you have seen multiple viable paths, pivoting stops feeling like failure and starts feeling like selection pressure.

How people actually use it

Across our team, people reach for this for different reasons. Sometimes the sentiment is genuine uncertainty: I literally do not know. Omakase. It better be cool. Sometimes it is simple decision fatigue: Omakase. I do not want to make this call right now. Sometimes it is earned trust: I think you have this. Use the omakase. Different triggers, same mechanism. Show me something. Let me react. Then I will decide.

That line matters to me because “I’ll know it when I see it” often gets framed as vagueness or avoidance. Sometimes it is. But sometimes it is a precise description of how judgment works. Some preferences are latent until the object exists. Once it exists, the choice is clear.

Try it

Omakase is part of the Test Kitchen plugin for Claude Code.

/plugin marketplace add 2389-research/claude-plugins
/plugin install test-kitchen