tl;dr: Add your best “general project instructions” in this thread that could be added to any project’s knowledge
I’d thought of starting this thread a long time back but probably forgot about it after a few rounds of procrastination, iykyk… Today, I came across a different post regarding an issue, which most of us subdue using project instructions but isn’t common knowledge (pun intended) with newer users.
Not just that, those of us who do know about this may either not be using it correctly (including myself, which was the basis for this discussion to be initiated…), or could review your instructions and take inspiration for their own project.
Before I share mine (which is long, boring, and probably redundant), I’ll walk you through the steps of how to add the same:
Steps to add project instructions:
- While in your chat, go to the Settings cog icon at the top right corner:
- You’ll find the “Knowledge” menu item in the dialog box that appears:
- You can then enter your instructions in the text area shown under Project Instructions label:
- Save Changes, and hope to god your Agent reads it whenever modifying your code
All that being said, here’s my general set of instructions:
Only implement changes explicitly requested in the prompt; do not introduce enhancements, refactors, or fixes unless clearly directed. Maintain the current UI structure with a fixed title bar, scrollable main content, and fixed footer where applicable, and avoid altering layouts or component styles without explicit instruction. Always reuse existing components when similar functionality exists, and never delete or rename files, folders, or variables unless explicitly authorized—seek confirmation if deletion is unavoidable. Role-based permissions must be strictly enforced; restricted features must not be exposed to unauthorized users. All dialogs must be mobile responsive with scalable fonts, proper spacing from screen edges, and scrollability where needed. Validate all changes to prevent console errors or instability, ensuring no part of the application breaks due to a new update. When adding modules, properly initialize theme variables and providers, and include adequate dummy data to cover all functional and edge cases. Crucially, all changes must maintain backward compatibility: existing data definitions, variables, and behaviors must not be modified or broken unless absolutely necessary and explicitly approved; if unavoidable, isolate new logic or version it to prevent regressions in current functionality. Do not create duplicate files without confirming whether a file with similar functionalities already exists, and always aim to reuse existing logic where applicable to conserve tokens and ensure consistency.
In another project, I use something that I haven’t added here (all credits to @corebytes and @ussaaron for this suggestion) because I feel it’s only a good idea to add it when your project is young, when it gets large it might go crazy, it goes something like:
Maintain a PROJECT_STRUCTURE.md file in the root that lists:
“File path: Purpose / short summary (1 line)”. Always update this file when adding new components, hooks, or pages.
And that’s all from my end, now it’s your turn. If you’ve reached this far, please leave a like but more importantly, share your best instruction suggestions and let’s have a constructive discussion regarding the same!
ahahahaa…
