omakase-off_skill

Overview

This skill is the entry gate for build/create/implement requests that guides users between stepwise brainstorming and a parallel "omakase" exploration of multiple implementation approaches. It detects indecision during planning and, when appropriate, offers to run 3–5 variant implementations in parallel, using scenario tests to determine the best result. The goal is to let real code and tests decide the winner while keeping the user in control.

How this skill works

On initial build/create/implement prompts the skill presents a choice: brainstorm together or run omakase (chef's choice parallel exploration). During brainstorming it passively detects indecision signals (repeated uncertain replies or phrases like "not sure" or "you pick") and offers parallel exploration. If omakase is chosen, it designs multiple variants, dispatches all variant agents in a single message, runs identical scenario tests against each variant, performs fresh-eyes reviews on survivors, and presents a judged winner with cleanup of losers.

When to use it

• When the user asks to build, create, implement, or add a feature and is unsure about key architectural choices
• When brainstorming reveals repeated uncertainty on major decisions (storage, framework, auth)
• When the cost of trying multiple approaches is justified by improved confidence or measurable outcomes
• When you want automated comparison by scenario tests rather than relying on guesswork
• When the user explicitly requests exploring both/multiple approaches

Best practices

• Limit parallel variants to 3–5 focusing on the primary architectural axis to avoid combinatorial explosion
• Classify slots: only treat architectural decisions as parallelizable; keep trivial choices consistent across variants
• Dispatch all variant work in a single message to enable parallel agents and reproducible orchestration
• Always run identical scenario tests for fair comparison and require a fresh-eyes review before final judgment
• Document plans, results, and why the winner was chosen; clean up loser branches/worktrees afterward

Example use cases

• User wants a CLI tool but is unsure about storage (JSON vs SQLite vs remote DB) — run 3 parallel variants and let tests pick
• Implement two competing auth strategies (JWT vs OAuth) to compare performance and developer ergonomics
• Compare two framework options (lightweight vs batteries-included) for a microservice by implementing both and running the same integration tests
• When brainstorming stalls on architecture, offer omakase to unblock decision-making by empirical evaluation