Devguidelines.md a file everyone needs

The devguidelines.md file is frequently mentioned in this forum as a valuable tool for improving agent and assistant interactions. For those who don’t know, the file contains a set of instructions that help guide the aforementioned, making them more reliable and effective.

My aim for this post is to create a collaborative repository of best practices and standards that everyone can access and benefit from. By pooling our collective knowledge, we can establish guidelines that will enhance all experiences in Replit.

I’ll kick things off…

**devguidelines.md**

the app you’re building is a full-stack web application for <project_description>. it’s architecture is as follows:

* frontend (client/): <enter_details>
* backend (server/): <enter_details>
* database schema (db/): <enter_details>

as an expert software engineer, ensure all code meets the highest quality standards and ensure the following guidelines are followed:

## 1

follow code best practices:

* 1. write clean, modular code with single-responsibility components and clear separation of concerns
* 2. follow consistent code style and naming conventions
* 3. optimize performance through efficient code and regular refactoring

## 2

wherever possible, create ui components and store them in client/src/components instead of embedding code directly on pages. keep components focused and single-responsibility

## 3

always implement robust error handling and logging:

* use structured logging with severity levels
* implement global error boundaries
* add detailed error tracking for debugging
* create user-friendly error messages

## 4

ensure the following when creating and managing custom hooks:

* separate business logic from ui
* create reusable data fetching patterns
* handle loading/error states consistently
* implement proper cleanup

## 5

when adding new buttons, forms and fields prevent overflow and ensure everything fits properly for small screen devices with the following approaches:

* all forms and calendar pickers must be more responsive
* adjust grid layouts to prevent overflow
* ensure all text content wraps properly

## 6

changes must be documented in changelog.md. maintain the document with all changes and detailed entries for each commit including; a title, the date, what was changed, which files were the changes in, what lines of code were changed and why

## 7

make sure the express in server/index.ts is configured as follows:

* Set the port number to 5000 (const PORT = 5000)
* Start listening for incoming connections on that port
* Allow connections from any IP address ("0.0.0.0" instead of localhost)

**you must never update or change these settings. if the server is unresponsive forget and move on**
4 Likes

Great work!

So, I’ve read some articles backed by scientific papers that show how LLM outputs can be drastically improved via invoking emotional elements. Now bear with me, the theory is that since LLMs are trained on human language, that human emotions can drastically affect an LLMs output.

Since I’m not a coder, this is something I can experiment with. Would you be open to letting me play with that concept (while maintaining your technical inputs)? I’d basically be attempting to butter up the LLM and imbuing a sense of importance to the work.

thank you for this, do you recommend we make the file devguidelines.md and instruct it to refer these practices before any new features or iterations?

once the agent has completed building your initial idea / prompt and the core codebase is in place, i add the file. i would refer the agent / assistant to the doc whenever you were about to prompt a new feature or considered iteration.

It’s also super helpful to ask Claude or ChatGPT to create a Product Requirement Document ( PRD )

Ask it to break it down into phases and suggest using the Replit Agent or Replit Assistant and it does a pretty nice job of breaking it down.