output format
This commit is contained in:
+16
-7
@@ -259,18 +259,27 @@ If your app needs multi-step AI workflows, tool-calling loops, or human-in-the-l
|
||||
|
||||
## Output Format
|
||||
|
||||
The goal of the output is to produce an output
|
||||
|
||||
Return:
|
||||
1. A short architecture explanation.
|
||||
2. Full file tree.
|
||||
3. Complete contents for each file.
|
||||
4. Run instructions (dev and prod).
|
||||
5. A brief section explaining how to add a new page module in `pages/`.
|
||||
- A concise, high-level architecture explanation.
|
||||
- An explanation of how the different parts of the concept will fit into this structure
|
||||
- What are the core services?
|
||||
- What are the main ui pages?
|
||||
- What are the main ui components?
|
||||
- Whether a database will be involved and whether the app owns the database
|
||||
- Whether any AI will be used and what the workflow looks like
|
||||
- A concrete implementation plan in the form of a checklist, organized into sections by concept which should roughly mirror the structure of sub-packages.
|
||||
- Key functions/classes
|
||||
- Configuration/settings available
|
||||
- Migration or rollout notes (if relevant)
|
||||
|
||||
## Guardrails
|
||||
|
||||
- Prefer not to put all pages in one file.
|
||||
- Avoid relying on implicit globals for app setup.
|
||||
- Do not put all pages in a single file.
|
||||
- Never use globals, implicit or otherwise.
|
||||
- Keep code minimal but production-minded.
|
||||
- Being clear and concise is a higher priority than being verbose.
|
||||
- Prefer clarity and maintainability over clever abstractions.
|
||||
|
||||
## Source Documentation (recommended references)
|
||||
|
||||
Reference in New Issue
Block a user