test-kitchen
Scannednpx machina-cli add skill aiskillstore/marketplace/test-kitchen --openclawTest Kitchen
Parallel implementation framework with two gate skills:
| Skill | Gate | Trigger |
|---|---|---|
test-kitchen:omakase-off | Entry | FIRST on any build/create/implement request |
test-kitchen:cookoff | Exit | At design→implementation transition |
Flow
"Build X" / "Create Y" / "Implement Z"
↓
┌─────────────────────────────────────┐
│ OMAKASE-OFF (entry gate) │
│ Wraps brainstorming │
│ │
│ Choice: │
│ 1. Brainstorm together │
│ 2. Omakase (3-5 parallel designs) │
└─────────────────────────────────────┘
↓
[Brainstorming / Design phase]
↓
Design complete, "let's implement"
↓
┌─────────────────────────────────────┐
│ COOKOFF (exit gate) │
│ Wraps implementation │
│ │
│ Choice: │
│ 1. Cookoff (2-5 parallel agents) │
│ 2. Single subagent │
│ 3. Local implementation │
└─────────────────────────────────────┘
↓
[Implementation]
Key Insight
Skills need aggressive triggers to work. They can't passively detect "uncertainty" or "readiness" - they must claim specific moments in the conversation flow.
- Omakase-off: Claims the BUILD/CREATE moment (before brainstorming)
- Cookoff: Claims the IMPLEMENT moment (after design)
When Each Triggers
Omakase-off (Three Triggers)
Trigger 1: BEFORE brainstorming
- "I want to build...", "Create a...", "Implement...", "Add a feature..."
- ANY signal to start building something
- Offers choice: Brainstorm together OR Omakase (parallel designs)
Trigger 2: DURING brainstorming (slot detection)
- 2+ uncertain responses on architectural decisions
- "not sure", "don't know", "either works", "you pick", "no preference"
- Offers to explore detected slots in parallel
Trigger 3: Explicitly requested
- "try both approaches", "explore both", "omakase"
- "implement both variants", "let's see which is better"
Cookoff
- "Let's implement"
- "Looks good, let's build"
- "Ready to code"
- Design doc just committed
- ANY signal to move from design to code
Omakase Mode (Skip Brainstorming)
If user picks "Omakase" at the entry gate:
- Quick context gathering (1-2 questions)
- Generate 3-5 best architectural approaches
- Implement ALL in parallel
- Tests pick the winner
- Skip detailed brainstorming entirely
Best for: "I'm flexible, show me options in working code"
Cookoff Mode (Parallel Implementation)
If user picks "Cookoff" at the exit gate:
- Each agent reads the same design doc
- Each agent creates their OWN implementation plan
- All implement in parallel
- Compare results, pick winner
Best for: "I want to see different implementation approaches"
Key Distinction
| Omakase-off | Cookoff | |
|---|---|---|
| Gate | Entry (before/during brainstorming) | Exit (after design) |
| Question | HOW to explore? | HOW to implement? |
| Parallel on | Different DESIGNS | Same design, different PLANS |
| Triggers | Build request, indecision detection, explicit | "let's implement" signal |
| Skips | Brainstorming (optional via short-circuit) | Nothing - always after design |
Slot Detection (During Brainstorming)
When omakase-off delegates to brainstorming, it passively tracks architectural decisions where user shows uncertainty:
Detection signals:
- "not sure", "don't know", "either works", "both sound good"
- "you pick", "whatever you think", "no preference"
- User defers 2+ decisions in a row
Slot classification:
| Type | Examples | Worth exploring? |
|---|---|---|
| Architectural | Storage engine, framework, auth method | Yes - different code paths |
| Trivial | File location, naming, config format | No - easy to change |
At end of brainstorming:
- If architectural slots exist → offer parallel exploration
- If no slots → hand off to cookoff for implementation
Source
git clone https://github.com/aiskillstore/marketplace/blob/main/skills/2389-research/test-kitchen/SKILL.mdView on GitHub Overview
Test Kitchen enables feature work to run in parallel through two gate skills: omakase-off (entry) and cookoff (exit). It relies on aggressive triggers at concrete moments in the conversation to route from brainstorming to implementation. This framework supports parallel design exploration or parallel implementations, helping you compare approaches efficiently.
How This Skill Works
When a build/create/implement trigger occurs, Test Kitchen activates either omakase-off (entry gate) or cookoff (exit gate). In omakase-off mode, you generate 3-5 architectural approaches and implement them in parallel for evaluation. In cookoff mode, the same design doc is read by multiple agents who create their own implementations in parallel, then results are compared to pick a winner.
When to Use It
- Before brainstorming: a build/create/implement trigger such as 'I want to build...' starts the entry gate for parallel exploration.
- During brainstorming: if there are 2+ uncertain architectural responses, use omakase-off to explore in parallel.
- Explicitly request: user says 'try both approaches', 'omakase', or 'explore both'.
- Transition to code: signals like 'let's implement' or a completed design doc indicate move from design to implementation.
- Design complete and ready for evaluation: move to cookoff to run parallel implementations and compare results.
Quick Start
- Step 1: Identify the trigger (build/create/implement) or explicit request to explore.
- Step 2: Choose a mode: omakase-off (entry) or cookoff (exit) based on your needs.
- Step 3: Run parallel designs or implementations, evaluate results, and select a winner.
Best Practices
- Use aggressive triggers and avoid waiting for passive readiness; claim concrete moments in the flow.
- At omakase-off, produce 3-5 architectural approaches and implement all in parallel.
- At cookoff, ensure all agents read the same design doc and pursue their own implementations in parallel.
- Capture results and rationale for each approach to enable an informed winner selection.
- Choose mode based on flexibility: omakase-off for exploring designs, cookoff for comparing implementations.
Example Use Cases
- Evaluating authentication strategies by generating multiple design patterns in parallel and testing them against requirements.
- Comparing data fetching architectures (REST vs GraphQL) with parallel prototypes and performance tests.
- Testing caching strategies (in-memory vs distributed) by implementing both in parallel against the same feature.
- Exploring frontend state management approaches (Redux vs Zustand) with parallel implementations and UI tests.
- Designing a feature rollout where multiple UX interaction flows are prototyped simultaneously for user feedback.