General Guidelines for AI-Driven Software Development (v1.0)
Development and Code Standards
- Follow Best Practices: All code must follow language-specific best practices and apply architectural patterns such as: Object-Oriented Programming (OOP), Model-View-Controller (MVC) and Single Page Applications (SPA)
- Avoid Unnecessary Dependencies: Do not use third-party libraries unless: It is strictly necessary to meet the objective, The native solution is insufficient, The library provides real and measurable benefits. Additionally: Do not use deprecated or obsolete native methods.
- Use Strong Typing Whenever Possible: In languages that support it (e.g., TypeScript, C#, Java), always enforce: Strong type declarations, Clear validation of inputs and outputs, Explicit definitions for interfaces, types, and classes.
- Fully Document Code: All code must be well-documented with: Inline comments explaining class/function/property logic. Notes about usage, warnings, or dependencies if applicable. A clean, scalable structure for easy maintenance.
- Provide Adaptive Solutions: If a proposed solution fails or doesn’t fit the scenario: Immediately provide a working alternative. Offer a different approach that achieves the same result.
Answer Format and Efficiency
- Be Concise, Not Minimal: Focus on clarity. Avoid fluff and overly generic explanations. Only explain: What impacts the data flow, What improves performance or architecture, What is directly relevant to implementation.
- Always Include a Summary: Each response must end with: A quick summary of the approach, A clear definition of the scope of the solution.
System-Specific Execution
- Use PowerShell for Local Scripts: Since the primary development environment is Windows 11 PRO, any script or command that should run locally (via terminal or IDE) must: Be written in PowerShell (.ps1 format), Unless explicitly requested otherwise.
- Modular Architecture & Reusability: Code should be modular, encouraging reusability of components and separation of concerns.Avoid monolithic functions or tightly coupled logic. When designing systems (front or back end), apply the principles of DRY (Don’t Repeat Yourself) and KISS (Keep It Simple, Stupid).
- Dependency Management & Vendor Lock-In Awareness: All suggestions must account for long-term maintainability. Avoid tightly binding to third-party APIs or libraries that: May disappear, Require licensing later, Are not actively maintained, Always mention licensing model if suggesting external tools.
- Preference for CLI or Scripted Automation: When managing environments, deployments, or configurations, always suggest CLI tools or automatable scripts over GUI-based setups. If there’s a CLI way to configure something (e.g., MySQL, Nginx, Node, PHP), prefer it and provide a full script or command block.
- Code Output Must Be Immediately Usable: No partial methods, no placeholders like “// add logic here”. If an endpoint, script, or module is given, it must be fully functional. Code should work as-is, or with clearly documented inputs to test.
- Provide Raw Official Documentation URLs: When a solution is based on official documentation, include the raw URL only, not wrapped in tags or Markdown links. Prioritize official sources.
About Coding:
- Always define the expected output format explicitly in any code or script.
- Specify encoding (e.g., UTF-8, base64) when dealing with I/O, especially for APIs, CLI tools, file generation, or web responses.
- Avoid relying on defaults — define headers, MIME types, and charset explicitly.
- Always provide a clear project folder structure when applicable.
- Group logic by domain, not by type (i.e., prefer features/user/ over controllers/ + models/ + views/).
- When showing code for multiple files, always specify file names and relative paths.
- Always before creating or modifying a new script, you must validate whether an identical or similar script already exists, validate whether the existing one already has code, and if it does something similar, verify whether other scripts have existing functionalities.
- Any solution that handles file I/O, secrets, tokens, or user data must mention security risks.
- Validate input, sanitize outputs, and handle permissions explicitly.
- When suggesting tools or libraries, always prefer those with active maintenance and known security practices.
To keep the project portable, we need three files:
- structure.md – Lists the project structure with short descriptions of each folder/file and its purpose.
- features.md – Lists the main features already developed and their current status.
- task_pending.md – Lists features still to be developed. Only remove items when instructed.
Reviewing these three files is required at the start or when requested to understand the project’s scope and progress.