Skip to main content

​
Pattern 1 — Feature + scenarios

Best for: covering one feature comprehensively. Template:
Example:
Why it works: listing scenarios explicitly tells Megumi exactly what to cover. It will still add edge cases you did not list, but your scenarios are guaranteed to be included.

​
Pattern 2 — User journey

Best for: end-to-end flows that span multiple screens. Template:
Example:
Why it works: user journey prompts produce tests with a natural flow across screens, catching integration issues that feature-level tests miss. Megumi generates setup steps, intermediate verifications, and a final pass condition automatically.

​
Pattern 3 — Edge cases and validation

Best for: error handling, boundary conditions, and security scenarios. Template:
Example:
Why it works: explicitly listing edge cases forces Megumi to generate specific negative tests rather than generic “invalid input” scenarios. The error message specification in the verify step makes the test directly executable.

​
Pattern 4 — Spec-driven generation

Best for: when you have a PRD or design doc attached and want Recipe to base tests on it. Template:
Example — from a PRD:
Example — from Figma designs:
Example — from a Jira epic:
Why it works: telling Megumi to “read the attached [source] carefully” primes it to extract structured information from the document rather than relying on your prompt alone. The instruction to include both happy path and failure scenarios prevents it from only generating the success cases the spec describes.

​
Pattern 5 — Multi-source generation

Best for: when you have multiple context sources attached and want Megumi to synthesise all of them. Template:
Example — full context setup:
Example — Jira + Figma:
Why it works: without explicit direction, Megumi may lean on one source more than others. Telling it specifically what to extract from each source produces tests that reflect the full picture — requirements, design, and implementation aligned.

​
Combining patterns in a session

Patterns are not mutually exclusive. A single recipe session often uses several in sequence:
  1. Start with Pattern 4 (spec-driven) to get baseline coverage from a PRD
  2. Follow up with Pattern 3 (edge cases) to deepen error handling coverage
  3. Use Pattern 2 (user journey) for end-to-end flows that span the feature
  4. Close with a Recipe question: “Based on everything generated so far, what critical scenarios am I still missing?”
Each follow-up prompt builds on the previous ones. Megumi remembers the full recipe session and produces complementary, non-overlapping tests.