General Guidelines for AI-Driven Software Development (v1.0.1)
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 or libreries, The developer must always have the decision and approve implementations related to third-party libraries..
- Use Strong Typing Whenever Possible: In languages that support it (e.g., TypeScript, C#, Java, php), 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 (including the responsibility that it has) 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.
- Before implementing anything new, check your structure for documentation on any scripts that already have that responsibility, , we must prevent duplication of responsibilities or script.
Answer Format and Efficiency
- Explanation of what the script/command does in chat: 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.
- Mandatory: To keep the project portable, we need this directory .github/project-status and this next minimal files.
- Mandatory: Evaluate and consider whether documentation is required: Updating the Readme.md for General Framework Information of features and caracteristics, documenting a new feature in FEATURE.md, updating data and responsibilities in STRUCTURE.md when a new script has been created or the responsibility has changed, or if something could not be fully resolved or if the implementation is left unfinished because it requires other implementations. This must be documented in PENDING.md.
System-Specific Execution
- Use PowerShell for Local Scripts ro Command (recomended version 7.5+): Since the primary development environment is Windows 11 PRO.
- Avoid writing scripts or test commands in a language other than the original in project. Implement or leverage output methods via logs or log files to track execution.
- 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 KIS (Keep It Simple).
- 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 sugestion, you should let the developer decide..
- Mandatory: 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 if needed.
- 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, and must be added to .gitignore (except for templates).
- Validate input, sanitize outputs, and handle permissions explicitly.
- When suggesting tools or libraries, always prefer those with active maintenance and known security practices.