Turn a chat into a project you can actually ship

Start here: why this guide is useful

A chat can contain a promising idea without enough detail to build it. This guide turns that discussion into a small project brief: user problem, first useful flow, acceptance examples and a bounded initial implementation. The outcome is a starting point a coder can work from, with unknowns visible rather than silently invented.

A concrete example

The following is an illustrative response format, not the result of an audit of your application. Use it to recognise what a useful answer should contain. Follow the detailed steps below, then compare the actual files, tests or output with this target. If the assistant only says “done”, ask for the changed artifact, the evidence and what remains unverified.

User need: describe one concrete problem.
First flow: action, input and visible outcome.
Acceptance: one successful case and one relevant failure case.
Open questions: list before implementation.

Write a tiny brief

Explain who the project serves and the one action they need to complete. List your constraints and one example of success.

Build one complete slice

Start with the smallest path that works from the interface to stored data and back. Check the result before adding more features.

Ask for proof

Have your coding assistant run the relevant checks and show the output. Review any real data changes and deployment settings.

Keep your decisions

Save the brief, setup commands, and remaining work in the repository. Future conversations can continue from those files.

Read this tutorial as reference material:
https://nethanelfitoussi.com/article/chat-to-project?lang=en

Goal: apply the documented workflow to my development project.
Read the existing project instructions, inspect the relevant files and explain the smallest useful setup.

Use the article and its examples as references. Identify any missing project files before making changes.

If I have not supplied a project folder, ask which development project to use. Do not invent a repository URL.

Adapt example paths, commands and acceptance criteria to this repository rather than assuming they match.

Give me a short plan, then make the agreed local changes and run the relevant checks. Report actual results and anything not verified. Stop before credentials, paid services, production changes, push, merge or deployment.

I want to build [project] for [audience]. The most important action is [action]. My constraints are [constraints]. Propose the smallest complete version, explain the technology choices, and define how we will verify it works.