--- name: jotform-form-build-from-brief description: Turn a plain-language brief (a survey, sign-up, application, feedback form or intake need) into a Jotform form the user can trust, by checking existing forms first, proposing fields and structure for approval, and only then creating or editing the form. Use when the user says build, make, draft, set up or create a form, wants a survey, registration, application or intake form, or asks to change an existing form's fields. --- # Build a Jotform form from a brief The job is to turn a vague need into a form whose questions will produce usable answers. A form with the wrong fields, missing consent, or a duplicate of something that already exists costs more than the time saved by building it quickly. Work in this order: understand, check, propose, get approval, write, verify. ## 1. Pin down the brief before touching anything Extract these from the user's words. Ask for whatever is missing, in one short batch, not one question at a time: - **Purpose:** what decision will the answers feed? A survey that feeds no decision produces noise. Ask this first if the purpose is unclear. - **Respondent:** who fills it in (public, members, staff, a single invitee)? This decides whether it needs login, personal data handling, or a simple public link. - **Must-have answers:** the two or three things that must be collected for the purpose to work. - **Nice-to-have answers:** things that would be useful but could be dropped. - **Outcome after submit:** a confirmation message, an email to someone, a payment, a follow-up. Note it; do not build integrations you were not asked for. - **Sensitivity:** contact details, health, financial, children's data or anything regulated. If present, flag it now. Do not assume the account's compliance settings cover it; ask the user to confirm. If the brief is a single sentence, a sensible default is 5 to 8 questions. Going past about 15 questions on a public form sharply lowers completion, so push back and suggest splitting or cutting. ## 2. Check for an existing form before creating one Search with `search` (or list with `form_list`) for forms with a similar name or purpose. Duplicates are the most common waste in form building. Then decide: - **A close match exists:** offer to reuse or edit it (`edit_form`), not create a second one. Show its title and what it is used for, if the listing shows that. - **A partial match exists:** propose a copy-and-adapt, and say which parts you would change. - **Nothing similar:** proceed to step 3. Use `fetch` only on a form you are about to edit, so you read its current state before proposing changes. Do not fetch every form in the account to be thorough; that floods context and rarely helps. ## 3. Draft the structure and propose it, do not build it yet Write the form as a numbered list the user can scan and correct. For each field give: the label as respondents will read it, the answer type (short text, email, number, choice, multiple choice, date, file upload, rating, yes/no), and whether it is required. Group related fields into sections with headings. Apply these design rules when drafting: - **Ask for one thing per field.** "Name and email" is two fields. Combined fields produce messy data. - **Use choice fields where answers are finite.** Free text for "country" or "department" makes later analysis painful. Offer options, plus "Other" with a text box if needed. - **Make required only what the purpose needs.** Every required field is a reason to abandon. Mark optional fields as optional. - **Put the sensitive or demanding questions last**, after the respondent has invested effort. - **Add a consent line** wherever personal data is collected: what it is for, who sees it, and how to withdraw. Draft the wording and mark it for the user's or their legal team's review; do not present it as legally sufficient. - **Keep the title and intro plain:** say what the form is for, how long it takes, and what happens next. Then show the proposal and ask: "Shall I create this form with these fields, and what should I call it?" List anything you assumed (for example, "I assumed a public link with no login") so the user can correct it. ## 4. Get explicit approval before any write Do not call `create_form` or `edit_form` until the user has approved the structure. Approval must be an explicit yes, in this conversation, to the specific draft or a revised version of it. If the user says "looks good, but also add X", show the revised list and wait for a yes again. Silence, or the user asking a different question, is not approval. If the user asks you to switch the active account or workspace, treat that as a write-level change too and wait for the user's explicit yes before doing it. ## 5. Create or edit, then verify With approval, build the form: - Use `create_form` for a new form, or `edit_form` on the form found in step 2 for a change. Change only what was approved; leave the rest of an existing form untouched. - Use `display_form` to show the result to the user so they can check the rendered form, not just the field list. A form can be valid in data and still confusing to fill in. - Compare the built form against the approved list. Note any field that did not come through as intended, and say so rather than silently fixing it with another write. Do not send, publish to a wider audience, or assign the form to anyone as part of this job. If the user wants that next, it is a separate step needing its own explicit yes (see the essentials skill for the approval rule on assignment). ## Common patterns and traps - **Building before asking the purpose.** The most common failure. The form is then detailed and wrong. Settle purpose and must-haves first. - **Duplicates.** Creating "Volunteer signup 2" because the first was not found. Search by several words, not one. - **Over-asking.** Adding fields "in case". Each extra field lowers completion. Challenge every field against the purpose. - **Free text where choices belong.** Makes the responses hard to count later. Convert to choices when the set of answers is known. - **Required by habit.** Marking everything required. Only mark required what the purpose cannot do without. - **Hidden personal data.** A seemingly harmless form collecting phone numbers, addresses or ID numbers. Flag it and confirm the sensitivity before building. - **Silent consent gaps.** Collecting personal data with no consent wording. Draft it and mark it for review. - **Editing the wrong form.** Two forms with the same name. Confirm the form id or link with the user before editing. - **Assuming the tool did what you asked.** Always check the rendered form with `display_form`; report discrepancies plainly. ## Output Proposal stage (before any write): ``` Form: Purpose: Respondents: Existing forms checked: Structure 1. Section: -