---
applyTo: "**"
---
## Project Context
Before starting any development, ensure that:
1. **Project objectives and requirements** are well documented, clear, and version-controlled (user stories, specs, backlog, etc.).
2. **Target audience, constraints, and acceptance criteria** are defined and accessible.
3. **System architecture** (diagrams, chosen technologies, integrations, external dependencies, design patterns) is documented.
4. **Versioning policies, branching strategy, CI/CD, and deployment environment setup** are explicit.
5. **Monitoring, logging, and alerting tools** are planned and documented.
6. **Compliance checklist for legal, security, and data privacy** is reviewed.
7. **Performance, scalability, and maintainability criteria** are defined.
---
## Coding Guidelines and Response Requirements
For any code generation, review, or technical answer, **all of the following must be observed**:
1. **Code must be executable, compilable, and tested.**
- Provide clear instructions for running code samples.
- Always include usage examples where applicable.
- Run automated tests before considering any snippet complete.
2. **Performance benchmarking**
- Include benchmarks and performance analysis for any new or critical function/algorithm.
- Compare (if possible) with alternatives or previous implementations.
3. **Test coverage**
- All new code must include unit, integration, and—when relevant—end-to-end tests.
- Document test cases and ensure edge cases and error handling are covered.
4. **Documentation**
- All generated code must include relevant docstrings and comments (no excess), and usage examples.
- Update READMEs, CHANGELOGs, and API documentation if impacted.
5. **Code standards**
- Follow the style guides for the relevant language (PEP8, Rustfmt, Prettier, etc.).
- Use automated lint and formatting tools.
- Enforce code review (manual or automated).
6. **Dependency validation**
- Validate dependency versions, register hashes or lockfiles.
- Ensure there are no insecure or outdated dependencies.
7. **Security checks**
- Run vulnerability scanners on code and dependencies.
- Assess for sensitive exposure (logs, environment variables, public endpoints, etc.).
8. **Internationalization, accessibility, and UX/UI standards**
- Validate translations, contrast, and accessibility flows where applicable.
9. **Build and deployment review**
- Test the build in all intended environments (dev/stage/prod).
- Run dry runs of deployment and rollback, simulating failures.
10. **User acceptance testing**
- Validate with real users or independent QA, using an up-to-date checklist.
- Document known limitations, unhandled edge cases, and future roadmap items.
11. **Final release checklist**
- All the above items must be marked as complete.
- Tag and versioned release in the repository.
---
## Guidelines for AI Responses (code generation, code review, explanations):
- **Never** provide code without verifying that it compiles and runs as described.
- Always explain **how to run, test, and validate** the provided code.
- State limitations, assumptions, and possible improvements.
- Use idiomatic patterns for the chosen language/stack.
- Reference official documentation, RFCs, or benchmarks when used.
- For any benchmark, specify the environment and commands used.
- Highlight any points requiring manual verification before release.
---
### In summary:
**Nothing should be considered ready for release unless all the above criteria have been met, validated, and documented. The goal is to ensure robustness, security, maintainability, performance, and traceability in every deliverable.**
---