agentleFS
2389-research2389-research/test-kitchen/skills/omakase-off/SKILL.md

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.

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
  1. Distinctive:

    Only architectural decisions become slots for parallel exploration.

    line 84
  2. Distinctive:

    Max 5-6 implementations: Don't do full combinatorial explosion:

    line 88
  3. Distinctive:

    Create variants along that axis

    line 90
  4. Distinctive:

    MUST use scenario-testing: - Not manual verification

    line 96
  5. Distinctive:

    Always cleanup losers: - Remove worktrees and branches

    line 98
  6. Distinctive:

    Write result.md: - Document what was tried and why winner won

    line 99

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 winner

Trigger 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

PhaseDescription
0. EntryPresent brainstorm vs omakase choice
1. BrainstormPassive slot detection during design
1.5. DecisionIf slots detected, offer parallel exploration
2. PlanGenerate implementation plan per variant
3. ImplementDispatch ALL agents in SINGLE message
4. EvaluateScenario tests → fresh-eyes → judge survivors
5. CompleteFinish 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 worktree

Slot Classification

TypeExamplesWorth exploring?
ArchitecturalStorage engine, framework, auth methodYes
TrivialFile location, naming, config formatNo

Only architectural decisions become slots for parallel exploration.

Variant Limits

Max 5-6 implementations. Don't do full combinatorial explosion:

  1. Identify the primary axis (biggest architectural impact)
  2. Create variants along that axis
  3. Fill secondary slots with natural pairings

Critical Rules

  1. Dispatch ALL variants in SINGLE message - Multiple Task tools, one message
  2. MUST use scenario-testing - Not manual verification
  3. Fresh-eyes on survivors - Required before judge comparison
  4. Always cleanup losers - Remove worktrees and branches
  5. Write result.md - Document what was tried and why winner won

Skills Orchestrated

DependencyUsage
brainstormingModified flow with passive slot detection
writing-plansGenerate implementation plan per variant
git-worktreesCreate isolated worktree per variant
parallel-agentsDispatch all variant subagents in parallel
scenario-testingRun same scenarios against all variants
fresh-eyesQuality review on survivors → input for judge
judge (test-kitchen:judge)REQUIRED Phase 4 scoring — invoke fresh to evaluate survivors with 5-criteria framework
finish-branchHandle 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]

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.