🎯 Goal of the day
Turn the spec (validated on Day 1 and revised in yesterday's technical visit) into a building prompt: an instruction that describes the platform the AI should generate in Lovable, not a one-off task. The distinction is central. A task prompt solves one case once — "evaluate this candidate"; a product prompt describes a whole system — screens, data, rules and integrations. In this edition's case — the recruitment process at Azul Linhas Aéreas — the goal is to describe a screening platform that takes a spreadsheet of candidates, ranks them by fit to the role, and invites the approved ones to the next stage. AI evaluation still exists, but as a component of the platform, not the whole product.
✅ Learning objectives
By the end of the day, the student should be able to:
What you'll be able to do
- Derive, from the five views of the Day 1 spec, a prompt that describes a product.
- Structure the building prompt along the seven parts (objective, users, screens and flow, data, business rules, constraints and definition of done).
- Read an architecture diagram and map each layer to the corresponding part of the prompt.
- Specify AI screening with structured output that feeds the ranking and triggers the invite.
- Recognize and mitigate bias and privacy risks in a platform that filters people.
These objectives matter because of the prompt's role in the project: in Lovable, it is the platform's blueprint. The more precise the blueprint, the closer the result. It is the bridge between the spec (Day 1) and the working MVP (Day 4).
🔀 From a request to a product
The key shift of Day 2 is to stop asking for an answer and start describing a system. The contrast below makes the difference clear.
❌ Task prompt
- Solves one case, once.
- Takes no spreadsheet, stores nothing and notifies no one.
- Not a solution the HR team at Azul uses day to day.
✅ Product prompt
- Describes screens, data, rules and integrations.
- Operates at scale: dozens of candidates per role.
- It's what Lovable turns into a real application.
📋 From the spec to the building prompt
Each element defined in the Day 1 spec corresponds to a part of the platform blueprint. Writing the prompt is therefore not starting from scratch: it is transcribing decisions already made. As a principle, nothing in the platform should appear without a source — every screen and rule traces back to a decision recorded in the spec.
| Spec element | Question it answers | Becomes in the prompt |
|---|---|---|
| Business Driver | Why the solution exists | Product objective — the platform's purpose |
| Actors | Who uses the solution | Users and screens — what each role sees and does |
| Functional Requirements | What the solution does | Features — upload, screening, invite, video |
| Entities | What the solution operates on | Data model — database fields and relations |
| Non-Functional Requirements | With what quality | Constraints — LGPD, anti-bias and usability |
🧭 The screening platform
The solution described by the prompt organizes the selection funnel into five steps. Instead of HR reading spreadsheet by spreadsheet, AI screening ranks candidates by fit to the role and automates the invitation to the next stage; the final decision stays with the HR team.
The candidate's path
- Spreadsheet upload: HR uploads an Excel/CSV file with the role's candidates.
- AI screening: the platform scores each candidate by the role's criteria and builds the ranking.
- Automatic invite: the approved candidates receive an email to record a presentation video.
- Video collection: the candidate submits the video, attached to their profile.
- Human decision: the recruiter reviews ranking and videos and decides who moves on.
🏗️ Platform architecture
The building prompt describes a layered application, and that is what Lovable generates. Understanding the layers helps write each part of the prompt with the required specificity.
| Layer | Components | Responsibility |
|---|---|---|
| Users | Recruiter (HR) and candidate | Who interacts with the platform and for what purpose. |
| Interface (Frontend) | Upload, ranking panel, video gallery | The screens generated in Lovable through which the work happens. |
| Processing | Spreadsheet ingestion → screening engine (AI) | Reads and validates the data; scores each candidate and returns score and rationale. |
| Data and integrations | Database, email service, video storage | Persists candidates and scores, sends the invite and keeps the videos. |
The screening engine is where the AI acts. It is there that the evaluation prompt — detailed next — operates as a component of the architecture, and not as the whole solution.
🔧 Anatomy of the building prompt
An effective building prompt has seven parts. Each corresponds to an element already defined in the spec and makes the instruction clear and verifiable.
The 7 parts of the building prompt
- Objective: what the platform solves and for whom.
- Users: the roles that interact with the system — recruiter and candidate.
- Screens and flow: which screens exist — upload, panel, videos — and in what order.
- Data: the entities and fields — candidate, role, evaluation.
- Business rules: how screening scores and who passes the cutoff.
- Constraints: what is not allowed — derived from the non-functional requirements (LGPD, anti-bias, usability).
- Definition of done: when the platform is considered acceptable.
Applied to the Azul case, these parts turn the spec into an operational instruction for Lovable:
Users: recruiter and candidate.
Screens: (1) spreadsheet upload, (2) ranking panel, (3) video gallery.
Data: candidate (name, email, education, answers), role, evaluation.
Rule: score each candidate 0–5 by the role's criteria; approved ones get an email to record a video.
Constraints: do not use age, gender or origin; follow LGPD.
The bracketed parts are the parameters: what changes for each role. In Lovable, each parameter becomes a configurable field.
📊 Screening under the hood: structured output
Inside the platform, the AI evaluates each candidate. For that evaluation to be useful, it must return data, not free text: free text feeds neither the ranking nor the email trigger. A fixed format — JSON or table — turns the AI's answer into something the platform sorts, filters and uses to decide the invite. Always ask for three components: score per criterion, rationale and recommendation.
Format requested in the prompt
{ "candidate": ..., "score": 0-5,
"rationale": ..., "recommendation": "invite" | "review" }
Example of what the panel receives
| Candidate | Score | Recommendation |
|---|---|---|
| Ana | 5 | Invite to video. |
| Bruno | 4 | Invite to video. |
| Carla | 2 | Review — below cutoff. |
🛡️ Responsible AI in screening
In a platform that filters people and sends emails, ethical safeguards are not accessories: they are requirements. They derive from the spec's non-functional requirements and connect to ISO/IEC 25010, under security and reliability. A good building prompt states them explicitly, both in the screening rule and in data access control.
Four mandatory safeguards
- Bias: screening disregards age, gender, origin and appearance, evaluating only what relates to the role.
- Privacy (LGPD): the spreadsheet carries personal data; use only what is needed and protect access.
- Human decision: the AI recommends, the recruiter decides. Automatic rejection of candidates is not admitted.
- Communication: the email is an invite, not a promise, and the candidate should know AI is in the process.
In practice, these safeguards enter the prompt as constraints:
🔁 Iterate in Lovable
The platform is rarely ready on the first version, and that is expected. What sets an efficient group apart is the iteration method, driven by evidence rather than random trial.
The iteration cycle
- Write the building prompt with the seven parts.
- Generate the platform in Lovable.
- Navigate the flow with a sample spreadsheet.
- Locate what broke — missing screen, wrong field or loose rule.
- Adjust only that part of the prompt and generate again.
Build a test spreadsheet
- A strong candidate, who should be invited.
- A weak candidate, who should fall below the cutoff.
- A borderline candidate or one with missing data.
- If the platform misses the edge case, the fix is in the screening rule.
Adjusting several parts at once prevents identifying what produced the improvement. That is why one part is changed per iteration.
🎛️ Parametrization and common failures
Marking what varies with brackets — {role}, {criteria}, {cutoff score} — lets the same platform serve several roles at Azul. In Lovable, each parameter becomes a configurable field. It is worth testing with different roles to ensure the solution stays valid in other selection contexts.
Some failures recur throughout the build. The table maps each failure to its likely cause and to the appropriate fix in the prompt.
| Failure | Cause | Fix in the prompt |
|---|---|---|
| Generic screen | The prompt didn't describe the fields. | List the screens and each one's fields. |
| No email sent | The trigger was not specified. | Describe: score ≥ cutoff → send invite. |
| Inconsistent screening | No criteria or examples. | Define criteria and calibrate with examples. |
| Signs of bias | No attribute constraint. | Forbid age, gender and origin in the rule. |
🧾 Building-prompt checklist
Before considering the platform ready, the group should answer "yes" to each item below.
- Does it have a clear platform objective?
- Does it define the users — recruiter and candidate?
- Does it describe the screens and flow in the right order?
- Does it specify the data — entities and fields?
- Does the screening rule say how to score and who passes?
- Does it ask for structured output — JSON or table?
- Does it describe the email invite trigger?
- Does it carry constraints for bias and privacy?
- Is it parameterized for other roles?
- Does it make clear the decision is human?
🏁 Deliverable
➡️ Next day
Day 4 — Sprint, Refinement & Tests: build the platform MVP end to end in Lovable, test against the acceptance criteria, refine the prompt and publish the link.