When to use the chat
The chat is the default. Reach for it first when you want to make a change. Cases where the chat shines:- Cross-file changes — “Add a search field to the orders page and wire it to filter the list” (touches the page, the form component, and the data hook)
- Refactors — “Pull the order summary into a shared component and use it on both the cart and the checkout pages”
- Pattern matching — “Match the styling of the dashboard cards on the settings page”
- Logic — “When the cart is empty, show the empty state instead of the items grid”
- Data shape changes — “Show only the user’s own orders, not all orders”
How chat edits work
When you describe a change, Archie:- Reads the project structure and finds files relevant to your change
- Plans the edit — files to touch, code to add, code to modify
- Generates the changes
- Shows a diff for review
- Applies the changes when you accept
Writing good chat prompts
The chat works well with concrete, scoped requests. Compare:- “Make it look better” → vague, hard to interpret
- “Add more spacing between the order rows in the orders table” → concrete, scoped
Multi-turn conversations
The chat keeps context across turns. Once you have steered to the right area, follow-up turns can be brief: “Now do the same for the products list” or “Make the spacing tighter.” When the context drifts (you switch features), start a new chat thread to keep things clean. Old threads remain in your project history.What the chat cannot do
- Change the blueprint — restructuring (adding modules, changing user types) lives in the Blueprint, not the chat.
- Run code or migrations — the chat generates code; running it (deploys, migrations) happens through dedicated surfaces.
- Access third-party services not in your blueprint — to add a new integration, edit the blueprint and rebuild. See Editing integrations.