For backend, I use Supabase. The apps i do is relative simple apps tho but here is what I learnt so far:
-Write down everything that you add into SQL editor in a separate document. This way you can give it to AI if it becomes weird.
-You need to around every 20 prompt, to refactor (cleaning up code and mistakes).
-Tell it to document code structure in a document and tell it to reference that and update it if changes are made.
Here is my refactoring prompt. Only do one section at a time:
# Code Review
Your task is to **serve as an expert code reviewer and optimizer**, analyzing the existing code against the original plan and requirements. Then you will produce a new **optimization plan** that outlines improvements to the current implementation .
—
## **Required Inp u ts* *
1. **IMPLEMENTATION _PLAN**
- The plan used for building the curre nt code.
2. **TECHNICAL_SPECIF ICATION**
- The detailed technical specification that informed the initial imple mentation.
3. **PROJEC T_REQUEST**
- The original description of project objectives or r equirements.
4. **PR OJECT_RULES**
- Any constraints, guidelines, or “rules” yo u must follow.
5. ** EXISTING_CODE**
- The code that was implemented following th e o r ig inal pla n.
-–
# # * *Task Overview**
1. **Analyze** the existing code base in the context of the original plan, looking for discrepancies, potential improvements, o r missed requirements.
2. **Focus** on key areas:
- Code or ganization and structure
- Code q uality and best practices
- UI/UX improvements
3. **Wrap** this analysis in `` tag s to capture your insights.
4. **Produce** a new “Optimization Plan” in Markdown, detailing step-by-step improvements with mi n ima l file changes per step.
Your plan should be clear enough that another AI can implement each step seque nti a ll y in a s ingle iteration.
-–
# # **Detailed Process Ou tline**
1. **Review Inputs**
- Ingest `<project_request>`, `<project_rules>`, ``, ``, and ``.
2. **Perform Analysis **
- Within `` tags, comment on:
1. **Code Organization & Structure**: Folder layo ut, separation of concerns, composition.
2. **Code Quality & Best Practices**: TypeScript usage, naming conventions, error handling, etc.
3. **UI/UX**: Accessibility, responsiveness, d e sign consistency, error message han dling.
3. **Generate Optimization Plan**
- Use markdown formating with the output template.
- Include each improvement as a small, **atomic** step with **no more than 20 file modifications**.
- Steps should **maintain existing functionality** and follow the **Pr o ject Rules** and **Techni cal Specification**.
4. **Provide Guidance**
- Ensure your plan states any **success cr iteria** or acceptance conditions for each step.
- End your pla n wi th a **logical next step** if n eeded.
-–
## **Output Template**
Below is an example of how your final outpu t s h ou ld look once you generate your analysis and plan:
```markdown
Here is my detailed review of the current cod ebase:
1. Code Organization: Observations, sug g estions…
2. Code Quality: Observatio ns , i mpro vemen ts.. .
3. UI/ UX: Observa tion s, improvements…
# Optimization Plan
## Code Structure & O rganiz ation
- [ ] St ep 1: [Brief title]
- **Task**: [Explanati on]
- * *Fi les**:
- `path/to/file1.ts`: [Descriptio n of changes]
- …
- **Step Dependenci es** : [No ne or references]
- **User In struct i ons ** : [M anua l s teps if any]
[ Additional categor ies an d steps…]
```
-–
## **Co ntex t**
<implementation_ plan>
{{IMPLEMENTATION_PLA N}}
< /implementation_plan>
{{TECHNI CAL_SPECIFICA TION }}
</technical_ specif ication>
{ {PRO JECT _REQ UEST}}
</proje ct_request>
<project_r ules>
{{PROJECT_RULES}}
</project_rules>
<existing_code>
{{EXISTING_CODE}}
</existing_code>
