Take an agent-built form to its first saved response

Generating JSX is only the first step. A working form needs a published schema, the right project, a successful submission, and a response someone can retrieve. Give your coding agent that complete outcome.

Give the agent the workflow

Use Fillo's agent setup to connect your preferred coding tool. The CLI and MCP server use the same workspace and project boundaries. Install the customer skill when working from the terminal:

npx @usefillo/cli@latest skill install

Then use this prompt in an existing app:

Read https://fillo.so/agents and follow the installed build-with-fillo skill.
Add a product feedback form to this app using its existing UI components.
Use a required message field and an optional reply email.
Confirm the workspace, project, and allowed development origin.
Stage the schema and show me the diff before publishing.
After publication, submit one clearly labeled test response with my approval,
retrieve it from Fillo, and report the form ID, response ID, and what you verified.
Keep management tokens and identity secrets out of browser code and commits.
If a human connection or approval is needed, give me the specific next step.

Use fictional content for the test response. Don't copy customer feedback into a public demo or issue.

Establish the project before editing

The agent should check its authenticated workspace and selected project, then the available capabilities. A browser publishable key is for schema sync; it isn't a management credential. If setup hands you a private claim or approval URL, complete that handoff yourself and keep it out of screenshots and logs.

For file fields, check storage capability before building the upload path. If a person needs to connect storage, keep the file requirement and surface the connection step. Don't silently replace the file field with a URL input.

Stage and review

With a saved schema file and an authenticated CLI:

npx @usefillo/cli@latest push form.json --handle product-feedback --stage

Review field IDs, required fields, success text, and the project target. A staged schema is not yet the public version. Publishing makes the reviewed version available to respondents. See the CLI reference and code-defined lifecycle for the commands and project setup.

An MCP connection can perform the equivalent workflow. A successful initialization handshake or whoami call proves connectivity; it doesn't prove that a form is published or saving responses.

Verify the full loop

1. Open the form inside the app and inspect the native controls at desktop and mobile widths.
2. Submit it empty and verify useful validation errors and keyboard focus.
3. Publish the reviewed schema, then submit a labeled test message.
4. Retrieve the accepted response through the CLI, MCP, API, or Responses screen. Match its values and form ID to the test you just sent.
5. If a response destination is enabled, inspect its delivery separately. Saving a response and delivering it to Notion or n8n are different outcomes.
6. Disable the network for another test, then retry. Confirm that typed values survive and that success is shown only after acceptance.

Record the first saved response as your setup milestone. Prompt copies, package installs, successful API discovery, and staged forms are useful steps, but none of them is a collected response.

Hand the result to the team

Keep the schema in the app repository and preserve IDs after responses arrive. Tell teammates how to review answers and repair delivery failures. A nontechnical teammate should be able to operate the responses without editing the renderer.

Related

• Custom layout example: Compare native controls and host-owned layout.
• shadcn feedback form: Use your existing controls.
• Notion feedback inbox: Give the team a triage workflow.
• Client intake with uploads: Keep files in connected storage.