/
Loading...
Loading...
Woof! Don't worry about crafting the perfect prompt - just tell me what you need and we'll figure it out together. I'll ask questions if I need more info!
You don't need to be a prompt engineer to work with me. Simple requests work great - I'll ask follow-up questions when I need clarification.
The Secret?
I need a model for orders
Happy to help! A few quick questions: Which source table should I use (I see raw_orders and raw_stripe_orders)? And what type of model - staging, fact, or something else?
Use raw_orders, make it a staging model
Got it! Here's your stg_orders model with snake_case columns, proper data types, and a unique test on order_id...
Whether you give me a little or a lot of detail, I'll make it work. Here's how different prompt styles lead to great results:
Just say what you need in plain English. I'll ask clarifying questions.
"Create a staging model for customers"
I'll ask which source table, then generate a properly formatted staging model with sensible defaults.
Include specifics when you have them. Faster results, fewer questions.
"Create a staging model for the raw_customers table with email validation"
I'll generate the model with all your requirements built in.
For complex work, give me everything upfront.
"Create stg_ecommerce__customers from raw_customers. Rename to snake_case, validate email format, add tests for unique customer_id and not_null email. Use our team's standard CTE structure."
Production-ready code exactly matching your specifications, no questions needed.
Here are simple ways to ask for the most common things. No templates to memorize!
"Make a staging model for orders" or add detail: "...from raw_orders, add tests for order_id"
"Document the dim_customers model" or add detail: "...explain what customer_segment means"
"Add tests to fct_orders" or add detail: "...test that order_total is always positive"
"Why is this model returning duplicates?" or add detail: "...here's the SQL: [paste code]"
"Make this model incremental" or add detail: "...use updated_at as the timestamp"
"Should orders be a fact or dimension?" or add detail: "...we need to track order status changes"
I remember everything we've discussed. Build on our conversation instead of starting over.
Create a dim_customers model
Here's your dimension model with customer details and a surrogate key...
Add their lifetime order value
Updated! I added a lifetime_value column that sums all their orders...
Also segment them by that value
Done! Added customer_segment: vip (>$1000), regular ($100-1000), new (<$100)...
If I ask for clarification, it's because I want to get it right the first time. Here's what I might ask about:
Which source table?
When multiple tables could work
What type of model?
Staging, dimension, fact, or metric
Any naming conventions?
To match your project's style
What tests should I add?
To ensure data quality
How should I handle nulls?
When the right choice isn't obvious
Pro Tip
Say 'raw_orders' instead of 'the orders table'
Mention your warehouse type if it matters
When debugging, show me the SQL
Break big requests into steps
I'm helpful but not perfect!
I can explain my choices