Documentation Index
Fetch the complete documentation index at: https://quashbugs.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
This page covers how to get the most out of every prompt you send to Megumi — how expected outcomes turn into assertions, how to leverage multiple context sources, how to ask Megumi questions beyond test generation, how to refine output without starting over, and how to structure long or complex prompts.
Including expected outcomes
This is the most commonly missed element in prompts. Without expected outcomes, tests confirm that steps ran — not that anything worked correctly.
When you include an expected outcome, Megumi turns it into the Expected Result field of the test case. Mahoraga uses this as the pass/fail criterion during execution.
| Weak prompt | Strong prompt |
|---|
| ”Test adding an item to the cart" | "Test adding an item to the cart and verify the cart count increases by one, the item name appears in the cart list, and the total price updates correctly" |
| "Test login with invalid password" | "Test login with an invalid password and verify the error message ‘Incorrect password. Try again.’ appears below the password field and the user remains on the login screen" |
| "Test form submission" | "Test submitting the form with all valid inputs and verify the success banner appears, the form clears, and the new entry appears at the top of the list” |
Using multiple context sources together
Each source you attach before prompting fills a gap the others cannot:
| Source | What it gives Megumi |
|---|
| App | Screen names, navigation structure, Guidance-built knowledge |
| GitHub branch | Real API endpoints, field names, validation logic, business rules |
| Figma | Component names, interaction states, error states, design annotations |
| Jira | Acceptance criteria, user stories, formal requirements |
| PRD / document | Feature intent, edge cases, out-of-scope definitions |
Read the attached PRD, the Figma designs for the checkout redesign, and
the feature branch code carefully. Generate comprehensive test cases for
the new checkout flow — address entry, payment selection, promo codes,
order summary, and confirmation. Include edge cases from the designs,
validate against the acceptance criteria in the PRD, and reference
the API contracts in the codebase for backend state assertions.
Asking Megumi questions
Megumi is not only a test generator. You can ask it questions about your app and your testing strategy in plain English, and it will respond using the context it has available.
Examples of questions you can ask:
What are the best practices for testing a payment flow?
Based on this PRD, what edge cases am I likely missing?
What test coverage do I have for the authentication flow so far?
What scenarios should I prioritise for the smoke test suite?
Given the Figma designs attached, are there any states I haven't tested yet?
Refining after generation
If the first output is not what you wanted, stay in the session and follow up. The agent remembers everything — you do not need to restate context.
| What you want | What to type |
|---|
| Add more tests | ”Add test cases for the forgot password flow” |
| Change priority | ”Change tests 1, 2, and 3 to Critical priority” |
| Make instructions more specific | ”Rewrite the instructions for test 4 to name the UI elements explicitly” |
| Add validation steps | ”Add assertion steps to every test that verifies the success state” |
| Remove a test | ”Remove the duplicate login test” |
| Change scope | ”Regenerate these tests at Full coverage depth” |
| Request a different format | ”Rewrite all test instructions in verbose step-by-step format with explicit tap, scroll, and wait actions” |
| Check completeness | ”Review the tests generated so far and tell me what critical scenarios are not covered” |
Structuring long prompts
For complex features, organise your prompt the way you would organise a brief. Megumi reads structure well.
Use sections for different areas:
Generate tests for the user profile feature:
Account information:
- Edit display name and verify it persists after save
- Edit email and verify a confirmation email is sent
- Change profile photo and verify the new photo appears across all screens
Privacy settings:
- Toggle each privacy option and verify the setting persists
- Verify default privacy state for a new account
Account deletion:
- Request deletion, verify confirmation dialog appears
- Confirm deletion, verify the account is deactivated
- Attempt login after deletion, verify access is denied
For all tests, include the expected outcome for both success and failure states.
Generate tests for the search feature. Prioritise in this order:
1. Basic text search with valid results
2. Search with no results — verify the empty state message
3. Search with special characters
4. Search with very long input (200+ characters)
5. Search while offline — verify the error handling
6. Search results pagination — verify loading more results on scroll
For scenarios 1-3, include at least two test cases each.
