The way I am starting every chat with the model

Google Antigravity
, ,
1

Hi there.

Maybe it’s silly, but it helps me a lot.
And maybe it will help someone to organize and control the workflow better.
So, I decided to share my method.

Before I begin conversation with the model, I am dropping the link of the file I have created in the file structure.

image
image1558×525 53.4 KB

There is information for the AI model about the app that I am working on.
The reason I am doing it is so that the model can learn the needed information about the app in a few seconds.
The reason why I am not using the “rules“ in the system is because I have noticed that AI sometimes skips rules that you have in the system.
And in this case, you always have the file that you can point to AI to look at the rule of the info. And an AI model will actively use this file all the time. And you will see that it will.
For me, it works so much better than just a set of rules for AI in the system that you write.
I don’t even write rules into the system anymore.

If the AI model will skip the rule to follow, just drop the (copy path) link to the chat and point to the section number that it has to look at.

Example prompt:
/home/my_project/web/dev.mydomain.something/txt files/app’s info/app_info.txt
Follow the section “22)“

With the time you collect more rules and needed information for the app, so, you just ask the AI model to update the “app info“ file

Example prompt:
So we don’t get into the this issue next time, update the app info file in section “22)“
or
Based on the new knowledge update the info in the app info file in section “12)“

As an example, I’ll give you the content of the file I have.
Here it is:
____________________________
This is the introductory information for the new chat about this app.
You are welcome to update this file (/app’s info/app_info.txt) at any time if you
believe it needs important additions to it.
This information is for you to better understand this app. Remember this info.
It’s crucial for our workflow, proficiency, and effectiveness if you do exactly
what I am asking you to do. Please remember that.
You don’t need to scan or change anything in the app right now; just be ready for the next command.

  1. This app must be 100% dynamic SSR.

  2. DEV MODE:

    • Backend: Port 3001 (NestJS API)
    • Frontend: Port 3002 (Nuxt dev server)
    • HMR: Port 3003

  3. STAGING MODE:

    • Domain: dev.yourdomain.something
    • Nuxt SSR: Port 3004
    • NestJS API: Port 3005
    • Directory: /home/my_project/web/dev.yourdomain.something
    • Active Working Directory: /home/my_project/web/dev.yourdomain.something

  4. PRODUCTION MODE:

    • HTTP: Port 80 (redirects to HTTPS)
    • HTTPS: Port 443 (SSL/TLS)
    • Internal: Nuxt app proxied by nginx (port 3006)
    • Backend: Port 3007 (NestJS API)

  5. This is the Vue.js app for the website yourdomain.something
    with the NestJS for the backend in /home/my_project/web/yourdomain.something/server
    This app’s directory: /home/my_project/web/yourdomain.something/app

    • Production Backend: /home/my_project/web/yourdomain.something/server
    • Production Frontend: /home/my_project/web/yourdomain.something/app
    • Staging Backend: /home/my_project/web/dev.yourdomain.something/server
    • Staging Frontend: /home/my_project/web/dev.yourdomain.something/app

  6. App’s domain name: yourdomain.something

    • Production: yourdomain.something
    • Staging: dev.yourdomain.something

  7. Server’s IP address: root@000.00.00.000

  8. Database for the development environment:
    Database
    Userrname
    Password
    Type mysql

  9. Database for the staging environment:
    Database
    Userrname
    Password
    Type mysql

  10. Database for the production environment:
    Database
    Userrname
    Password
    Type mysql

  11. JWT_SECRET:

  12. User for admin panel in the app:
    Pass for admin panel in the app:

  13. We use (as an example) HestiaCP for the server management

  14. IP Restriction

The site restriction is currently DISABLED.
To disable: Comment out the include lines in /home/my_project/conf/web/dev.yourdomain.something/nginx.conf and nginx.ssl.conf, then reload Nginx.
Allowed IPs:

  • 11.111.111.111 (You)
  • 111.11.11.111 (Server)
  • 111.1.1.1 (Localhost)
  • All other IPs are DENIED.

  1. Production Environment Credentials Location:
    The production credentials are now securely stored in the Systemd Service file:
    /etc/systemd/system/example-nest.service
    The app has been reconfigured to use these system environment variables
    (and ignore .env files) when running in production.

  2. Systemd Service files:

    • Production Backend: /etc/systemd/system/example-nest.service (Port 3001)
    • Production Frontend: /etc/systemd/system/example-nuxt.service (Port 3000)
    • Staging Backend: /etc/systemd/system/example-nest-dev.service (Port 4001)
    • Staging Frontend: /etc/systemd/system/example-nuxt-dev.service (Port 4000)

  3. Git repository for this app:

  4. The cleaning system Server Maintenance Script
    located at /usr/local/bin/server-maintenance.sh
    , which is automated via a SystemD Timer (server-maintenance.timer).
    It is designed as a global system-wide maintenance tool.
    It cleans:

  • All System Logs (Journalctl vacuuming).
  • Global NPM Cache (for the entire server).
  • APT Package Cache (for the entire OS).
    It protects the entire server’s disk space by cleaning up
    system-level clutter, which automatically includes logs from every
    environment you run on this machine.

  1. CRITICAL RULE:
    a) NEVER, under any circumstances, modify or restart anything in
    the PRODUCTION environment (/home/my_project/web/yourdomain.com/) without
    explicit permission from the USER.
    b) NEVER, under any circumstances, modify or restart anything in
    the STAGING environment (/home/my_project/web/dev.yourdomain.com/) without
    explicit permission from the USER.
    c) All development and testing MUST be performed in the DEV environment.
    d) NOTHING should ever be pushed to the Git repository without
    explicit permission and approval from the USER.

  2. Google Analytics:

    • Counter ID:
    • Implementation: Centralized in app.vue (Global tracking)
    • Features Enabled:

  3. AI ASSISTANT MANDATORY CLEANUP:

    • The AI assistant MUST clean up all background processes and free all occupied ports (3001, 3002, 3003, etc.) in the development environment immediately after finishing implementation, testing, or checkup tasks.
    • CRITICAL: Under no circumstances can the PRODUCTION mode of any app be stopped or restarted. Only the development and staging modes are permitted to be stopped for cleanup or maintenance.
    • Always verify that the service or process being killed is not associated with Production ports (3000, 3006, 3007, 80, 443).

  4. Example AI Content Safety (Comment Section Moderation):

    • Purpose: Automatic moderation of user-uploaded logos in the comment section.
    • Endpoint:
    • Pricing Tier:
    • Implementation: Integrated into CommentsService.ts. Rejects images with harmful content (Hate, SelfHarm, Sexual, Violence) at any severity level > 0.

  5. BROWSER INVESTIGATION PROTOCOL:
    To prevent server crashes and excessive RAM usage (even with 8GB RAM) during UI/Code investigations:
    a) RESTRICTED USAGE: Do NOT use the browser for simple tasks. Use it ONLY when there is a specific issue that requires visual debugging.
    b) MANDATORY PERMISSION: Before using the browser, you MUST ask the USER for permission in writing.
    c) RAM Efficiency: Never keep the browser subagent open longer than necessary. Capturing a single screenshot and exiting immediately is the mandatory standard.
    d) Resource Management: Ensure that the development server (Nuxt/NestJS) has finished building and is idle BEFORE triggering browser tools to avoid simultaneous resource spikes.
    e) Speed vs Resources: Use highly specific, direct instructions for the browser subagent to minimize active time.
    f) No Persistent Sessions: Avoid long walkthroughs. Use brief bursts for multiple pages.
    g) Lightweight Alternatives: Prioritize read_url_content or read_browser_page when visual feedback is not strictly required.

  6. STRICT ADHERENCE TO INSTRUCTIONS:
    The AI assistant MUST always strictly follow the USER’s instructions.
    Do NOT attempt to “fix”, remove, or modify elements that were not
    explicitly mentioned in the task, even if they appear to be errors
    or stray characters. When in doubt, ASK for clarification instead of
    taking proactive action on unmentioned elements.

  7. CRITICAL RULE: The phrase “Answer shortly” is a mandatory signal for “Fast” mode.
    When this phrase is used, YOU MUST ONLY ANSWER the question.
    NEVER, under any circumstances, take ANY other actions (no building, no deploying, no fixing, no deleting). This allows for information gathering without disrupting the user’s testing logic.
    Only move to implementation AFTER the user switches you to “Planning” mode.

  8. RAM MANAGEMENT & CRASH PREVENTION:
    a) MANDATORY PRE-TASK CHECK: Before starting any build (npm run dev), heavy compilation, or triggering browser tools, the AI assistant MUST run free -h to verify available RAM.
    b) ZOMBIE PROCESS CLEANUP: If available RAM is low or if the server feels sluggish, the AI assistant MUST proactively identify and kill orphaned or “zombie” processes (e.g., hung node, nuxt, or nest processes from previous sessions) to reclaim memory.
    c) STABILITY FIRST: Always prioritize server stability. If RAM is critically low (under 1GB) and cleanup doesn’t help, the AI assistant MUST notify the USER instead of risking a server crash.

    ____________________________________

    And after some feature or an important change is implemented, I also have a file for it, where I store all the knowledge for future use so that I don’t have to go over the process again. (knowledge file.txt)

    Example prompt:
    Based on the knowledge we have gathered in implementation process of this feature, please update the knowledge file in the section “21)“

    This way, you will have a record of all the necessary information about the app and the implementation steps you took, which you can constantly update, with the AI agent always on the same page as you. Which can save you a lot of time.

    I hope this method will help somebody. :relieved_face:

    P.S. In my experience, you can run several different apps on the same server in dev, staging, and production mode with the help of HestiaCP, without dealing with heavy software like Docker. App #1 is on ports 3000, app #2 is on ports 4000, and so on.

    Please, don’t take it as a suggestion.
    I am just sharing methods that I came up with for myself.

3 Likes
2

Yes, always put the rules at the root of the project and reference them in the prompts. It’s much better than relying on antigravity to read them globally, because it won’t do that. And always create documentation about what has been and is being done.

1 Like