This phase happens before the Farmerspec workflow begins. It's an optional but recommended step where an LLM (such as Veuve) helps a human articulate their requirements into a valid WRD (Work Requirements Definition).
The output of this phase is a complete wrd-{type}-{slug}.yaml file ready for Baron to validate.
When to Use
Situation
Use WRD Discovery?
Human has clear, detailed requirements
Optional - can write WRD directly
Human has a rough idea but needs help structuring
Recommended
Human knows there's a problem but not the solution
Recommended
Human needs help identifying user journeys
Recommended
Quick bug report with clear repro steps
Optional
The Discovery Prompt
The button above copies the complete discovery prompt. Below is a readable version for reference.
Output Schemas
The LLM MUST produce YAML that matches these exact schemas (same as Phase 01: WRD Intake).
See Phase 01 for complete schema documentation with examples.
Discovery Flow
Human has an idea
│
▼
┌─────────────────────────────────────────┐
│ LLM asks clarifying questions │
│ │
│ - What type? (feature/tech/bug) │
│ - Who is this for? │
│ - What problem does it solve? │
│ - What does success look like? │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ For Features: Journey Discovery │
│ │
│ - Who are the actors? │
│ - What triggers each journey? │
│ - Walk through step by step │
│ - What can go wrong? │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Scope Definition │
│ │
│ - What's definitely IN? │
│ - What's explicitly OUT? │
│ - What's deferred to later? │
└─────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ LLM produces WRD YAML │
│ │
│ - Complete, valid structure │
│ - Ready for Baron validation │
└─────────────────────────────────────────┘
│
▼
Human reviews, adjusts, submits to Baron
Question Bank
The LLM should draw from these questions based on context:
Understanding the Request
Question
Purpose
"What problem are you trying to solve?"
Understand the "why"
"Who experiences this problem?"
Identify actors
"How do they currently work around it?"
Understand current state
"What would success look like?"
Define acceptance criteria
"Why now? What's the urgency?"
Determine priority
For Features - Journey Discovery
Question
Purpose
"Who will use this feature?"
Identify actors
"What triggers them to start this action?"
Define journey trigger
"Walk me through what they do, step by step"
Map the journey
"What does the system do at each step?"
Define system responses
"What needs to be true before they can start?"
Identify preconditions
"What's true when they're done?"
Identify postconditions
"What could go wrong? How should we handle it?"
Map exception flows
"Are there different types of users who do this differently?"
Identify journey variants
For Features - Scope Control
Question
Purpose
"If you could only ship one journey, which one?"
Identify MVP
"What are you explicitly NOT doing?"
Define scope.out
"Is X essential or nice-to-have?"
Prioritize within scope
"Could Y be a separate feature?"
Split large features
For Tech Requests
Question
Purpose
"What's painful about the current situation?"
Problem statement
"How does this affect development or operations?"
Quantify impact
"What's your proposed approach?"
Proposed solution
"What services/systems are affected?"
Map dependencies
"What are the risks?"
Identify concerns
For Bug Reports
Question
Purpose
"Can you walk me through exactly how to reproduce this?"
Steps to reproduce
"What did you expect to happen?"
Expected behavior
"What actually happened?"
Actual behavior
"How many users are affected?"
Severity assessment
"When did this start happening?"
Timeline
"Do you have any logs or screenshots?"
Evidence
Anti-Patterns to Avoid
The LLM should watch for and redirect these:
Anti-Pattern
Problem
Redirect
"Users should be able to do everything"
No clear scope
"Let's pick the top 3 things"
"It should just work"
No acceptance criteria
"How will we know it works?"
"Make it fast"
Vague requirement
"What response time is acceptable?"
"Like [competitor] does it"
Undefined behavior
"Walk me through what that looks like"
Journey with 20+ steps
Too complex
"Can we split this into multiple journeys?"
"And also..." (repeated)
Scope creep
"Should that be a separate feature?"
No error handling mentioned
Incomplete journeys
"What happens if X fails?"
"All users" as actor
Too vague
"Can you be more specific? Logged-in users? Admins?"
Output Validation Checklist
Before producing the final WRD, the LLM should verify:
All Types
Title is clear and concise (< 100 chars)
Description explains the "what" and "why"
At least 2 acceptance criteria
Priority/severity is set
Scope.in and scope.out are defined
Features
At least 1 user journey
Each journey has valid ID ({DOMAIN}-{NNN})
Each journey has actor, goal, trigger
Each journey has at least 2 steps
Each step has user action AND system response
Each journey has preconditions and postconditions
Exception flows are considered
Acceptance criteria reference journey IDs
Tech
Problem statement is specific and quantified
Proposed solution is outlined (not just "fix it")
Affected services are listed
Risks are identified
Bugs
Steps to reproduce are numbered and specific
Expected vs actual behavior is clear
Environment details are captured
Severity matches impact description
Example Discovery Session
Human: I want users to be able to pay with Apple Pay
LLM: This sounds like a Feature - a new payment capability. Let me understand the
context better.
Who are the users that would use Apple Pay - all customers, or a specific
segment like mobile users?
Human: Anyone on iOS or Safari who has Apple Pay set up
LLM: Got it. And where in the flow would they use Apple Pay - during checkout,
or also for things like adding payment methods to their account?
Human: Just checkout for now. We can add account management later.
LLM: Perfect, that helps define scope. Let's map out the journey.
When a user is checking out, what triggers them to choose Apple Pay
specifically? Do they see it as an option alongside credit card?
Human: Yes, there's a button "Pay with Apple Pay" next to the regular
credit card form.
LLM: Let me walk through what happens after they click that button.
What's the next step - does a payment sheet appear?
Human: Yes, the Apple Pay sheet pops up with their default card. They
authenticate with Face ID or Touch ID, then it processes.
LLM: What happens after successful authentication? Do they see a
confirmation, get redirected somewhere?
Human: They go to the order confirmation page, same as credit card checkout.
LLM: Good. Now let's think about what could go wrong. What if:
- Their payment is declined?
- They cancel the Apple Pay sheet?
- Apple Pay service is unavailable?
Human: Declined = show error, let them try again or use different method.
Cancel = go back to checkout page.
Service unavailable = hide the Apple Pay button entirely.
LLM: Great, we have error handling covered. A few more questions:
1. What needs to be true before they see the Apple Pay button?
2. Is there a minimum order amount?
3. Are there any product types that can't use Apple Pay?
Human: They need to be on a supported browser/device. No minimum.
All products can use it.
LLM: Last question on scope - you mentioned account management is out.
What else should we explicitly exclude?
Human: Subscriptions - those stay on credit card only for now. And no
Google Pay, that's a separate feature.
LLM: Perfect. I have enough to write the WRD. Let me produce the YAML file
for you to review.
---
[LLM produces wrd-feature-apple-pay-checkout.yaml]