PUBLIC_KEY_PEM before distributing.
If Module 2 was about displaying data, Module 3 is about collecting it. You'll use LLMs to build standalone HTML forms — surveys, feedback tools, checklists — that gather structured input and let users download the result as a file.
By the end of this module: you've identified a data collection need, generated a standalone HTML form that collects that data and exports it as a file, and improved it with a second prompt targeting validation or UX. Both versions submitted.
Most teams collect information through a mix of email threads, shared documents, and whatever form tool they have a subscription for. Each of those has friction: shared access, formatting inconsistency, or monthly cost.
A standalone HTML form has none of that friction. It's a single file anyone can open
in a browser, fill in, and click a button to download their responses as a structured file.
No login. No server. No account. You build it once with an LLM, save it as a
.html file, and distribute it however you like.
When prompting the LLM to build your form, you must explicitly ask for a download button that saves the responses as a JSON or CSV file. Without this, the form collects data but has nowhere to send it. The standalone pattern works because the form is both the interface and the data exporter.
What kinds of data collection needs work well as standalone HTML forms?
Post-meeting rating, what worked, what to change, action items. Filled out immediately after.
New project request form. Captures scope, deadline, requestor, priority. Replaces email chains.
Team member status: what's done, in progress, blocked. Structured and consistent every week.
Review checklist with pass/fail fields, notes, and reviewer signature. Exportable for records.
In Module 1 you built a tool that processes or displays information. In Module 3 you're building a tool that collects it. The prompting technique is the same — but the output is a form with a download button rather than a calculator or generator.
Two parts. Part 1: identify your data collection need, write the prompt, generate the form. Part 2: improve it — add validation, better UX, or an additional field.
Your prompt must ask the LLM to include a button that downloads or exports the form data as a file (JSON or CSV). This is what makes the form self-contained. A form with no export is just a UI exercise.
What information do you currently collect by email, paper, or verbal request? Pick one that would benefit from a consistent, structured form.
Describe the fields you need, the purpose of the form, and who will fill it in. Explicitly ask for a download/export button that saves responses as a JSON or CSV file.
Save the code as a .html file, open it, fill it in, and click download. Does the exported file contain what you expected?
What needs work? Missing validation? Unclear labels? Wrong field types? Ask the LLM to address those specific issues.
Both HTML versions, plus notes on your collection need and what improved in the second version.
All fields required. Describe what you're collecting, paste both versions of the code, and note what changed.
What information do you need to collect, from whom, and how often? What problem does this form solve?
Paste the full prompt — including role, context, field list, and the explicit instruction to include a file download/export button.
Paste the complete HTML code for the first version of your form.
Did the form work as expected? What was missing, unclear, or broken? Did the export function work?
What specific improvements did you ask for? Paste the follow-up prompt.
Paste the complete HTML from the improved version.
What specific improvements did the LLM make? Is this form now something you would actually use or distribute to others?
Your work is saved locally. Download to keep a copy for offline reference. Your work has been saved. Keep this file for offline reference.