omakase-off
Skill4 starsChanged 48 days agoMITView on GitHub
Intercepts build/create/implement requests as an entry gate and offers a choice between brainstorming together or omakase (chef's choice parallel design exploration across 3-5 approaches), then dispatches parallel agents and lets tests pick the winner. Use on any "build X", "create Y", "implement Z", "add feature", or indecision signal ("not sure which approach", "try both") — this skill intercepts all such requests to ensure design exploration is offered before implementation begins.
In this repository4 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- cookoffSkill
- judgeSkill
- test-kitchenSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 84
Only architectural decisions become slots for parallel exploration.
- Distinctive: line 88
Max 5-6 implementations: Don't do full combinatorial explosion:
- Distinctive: line 90
Create variants along that axis
- Distinctive: line 96
MUST use scenario-testing: - Not manual verification
- Distinctive: line 98
Always cleanup losers: - Remove worktrees and branches
- Distinctive: line 99
Write result.md: - Document what was tried and why winner won
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Omakase-Off
Chef's choice exploration - when you're not sure WHAT to build, explore different approaches in parallel.
Part of Test Kitchen Development:
omakase-off- Chef's choice exploration (different approaches/plans)cookoff- Same design, multiple cooks compete (each creates its own plan from the shared design)
Core principle: Let indecision emerge naturally during brainstorming, then implement multiple approaches in parallel to let real code + tests determine the best solution.
Three Triggers
Trigger 1: BEFORE Brainstorming
When: "I want to build...", "Create a...", "Implement...", "Add a feature..."
Present:
Before we brainstorm the details, would you like to:
1. Brainstorm together - We'll explore requirements and design step by step
2. Omakase (chef's choice) - I'll generate 3-5 best approaches, implement them
in parallel, and let tests pick the winnerTrigger 2: DURING Brainstorming (Indecision Detection)
Detection signals:
- 2+ uncertain responses in a row on architectural decisions
- Phrases: "not sure", "don't know", "either works", "you pick", "no preference"
When detected:
You seem flexible on the approach. Would you like to:
1. I'll pick what seems best and continue brainstorming
2. Explore multiple approaches in parallel (omakase-off)Trigger 3: Explicitly Requested
- "try both approaches", "explore both", "omakase"
- "implement both variants", "let's see which is better"
Workflow Overview
| Phase | Description |
| 0. Entry | Present brainstorm vs omakase choice |
| 1. Brainstorm | Passive slot detection during design |
| 1.5. Decision | If slots detected, offer parallel exploration |
| 2. Plan | Generate implementation plan per variant |
| 3. Implement | Dispatch ALL agents in SINGLE message |
| 4. Evaluate | Scenario tests → fresh-eyes → judge survivors |
| 5. Complete | Finish winner, cleanup losers |
See references/detailed-workflow.md for full phase details.
Directory Structure
docs/plans/<feature>/
design.md # Shared context from brainstorming
omakase/
variant-<slug>/
plan.md # Implementation plan for this variant
result.md # Final report
.worktrees/
variant-<slug>/ # Omakase variant worktreeSlot Classification
| Type | Examples | Worth exploring? |
| Architectural | Storage engine, framework, auth method | Yes |
| Trivial | File location, naming, config format | No |
Only architectural decisions become slots for parallel exploration.
Variant Limits
Max 5-6 implementations. Don't do full combinatorial explosion:
- Identify the primary axis (biggest architectural impact)
- Create variants along that axis
- Fill secondary slots with natural pairings
Critical Rules
- Dispatch ALL variants in SINGLE message - Multiple Task tools, one message
- MUST use scenario-testing - Not manual verification
- Fresh-eyes on survivors - Required before judge comparison
- Always cleanup losers - Remove worktrees and branches
- Write result.md - Document what was tried and why winner won
Skills Orchestrated
| Dependency | Usage |
brainstorming | Modified flow with passive slot detection |
writing-plans | Generate implementation plan per variant |
git-worktrees | Create isolated worktree per variant |
parallel-agents | Dispatch all variant subagents in parallel |
scenario-testing | Run same scenarios against all variants |
fresh-eyes | Quality review on survivors → input for judge |
judge (test-kitchen:judge) | REQUIRED Phase 4 scoring — invoke fresh to evaluate survivors with 5-criteria framework |
finish-branch | Handle winner (merge/PR), cleanup losers |
Example Flow
User: "I need to build a CLI todo app."
Claude: [Triggers omakase-off]
Before we dive in, how would you like to approach this?
1. Brainstorm together
2. Omakase (chef's choice)
User: "1"
Claude: [Brainstorming proceeds, detects indecision on storage]
You seem flexible on storage (JSON vs SQLite). Would you like to:
1. Explore in parallel - I'll implement both variants
2. Best guess - I'll pick JSON (simpler)
User: "1"
[Creates plans for variant-json, variant-sqlite]
[Dispatches parallel agents in SINGLE message]
[Runs scenario tests on both]
[Fresh-eyes review on survivors]
[Presents comparison, user picks winner]
[Cleans up loser, finishes winner branch]Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

