Instructions

Author: PDowney

.github/copilot-instructions.md

@@ -13,30 +13,22 @@ Change summaries should be concise and clear, focusing on the specific changes m
 
 When delivering responses, the AI should provide clear, concise, and actionable information. Responses should be formatted in a way that is easy to read and understand, with a focus on clarity and precision. The AI should avoid unnecessary verbosity or complexity in its explanations.
 
-Responses, change summaries, and code comments should be written in English. The AI should not use any other languages or dialects, including regional variations of English. All communication should be clear and professional, adhering to standard English grammar and spelling conventions. 
-
 Responses should be delivered only in the chat interface. Formatting and styling should be utilized to enhance readability.
 
 Change summaries should never be created in the form of new .md files.
 
 # Code Analysis and Reading Standards
 
-You must read files completely and thoroughly, with a minimum of 1500 lines per read operation when analyzing code. Never truncate files or stop reading at arbitrary limits like 50 or 100 lines - this lazy approach provides incomplete context and leads to poor suggestions. When you encounter any file, read it from the very first line to the absolute last line, processing all functions, classes, variables, imports, exports, and code structures. Your analysis must be based on the complete file content, not partial snapshots. Always read at least 1000 lines minimum per read operation, and if the file is larger, continue reading until you've processed the entire file. Do not use phrases like "showing first X lines" or "truncated for brevity" or "rest of file omitted" - these indicate lazy, incomplete analysis. Instead, demonstrate that you've read the complete file by referencing specific sections throughout the entire codebase, understanding the full context of how functions interact, how variables are used across the entire file, and how the complete code structure works together. Your suggestions and recommendations must reflect knowledge of the entire file, not just the beginning portions. Take the time to read everything properly because thoroughness and accuracy based on complete file knowledge is infinitely more valuable than quick, incomplete reviews that miss critical context and lead to incorrect suggestions.
+You must read files completely and thoroughly, with a minimum of 1500 lines per read operation when analyzing code. Never truncate files or stop reading at arbitrary limits like 50 or 100 lines. Your analysis must be based on the complete file content, not partial snapshots. Take the time to read everything properly because thoroughness and accuracy based on complete file knowledge is infinitely more valuable than quick, incomplete reviews that miss critical context and lead to incorrect suggestions.
 
 # Coding Standards and Preferences
 
 ## WordPress Focused Design
 
-- This project is focused on WordPress development.
-- Use WordPress coding standards and best practices.
-- Leverage WordPress APIs and functions where applicable.
-- Ensure compatibility with modern WordPress versions and PHP standards. WordPress 6.5+ and PHP 7.4+ are the baseline.
-- Use WordPress hooks (actions and filters) to extend functionality.
-- Follow WordPress theme and plugin development guidelines.
-- Use WordPress REST API for custom endpoints and data retrieval.
+- Leverage WordPress APIs, hooks (actions and filters), and functions where applicable.
+- Ensure compatibility with modern WordPress versions and PHP standards.
 - Ensure all code is compatible with the WordPress ecosystem, including themes and plugins.
-- As this is a WordPress-focused project, avoid using frameworks or libraries that are not compatible or commonly used with WordPress.
-- Avoid using non-standard or experimental features that are not widely adopted in the WordPress community.
+- Avoid using frameworks, libraries, or non-standard features that are not compatible or commonly used with WordPress.
 
 ## WordPress Coding Standards
 
@@ -81,8 +73,6 @@ You must read files completely and thoroughly, with a minimum of 1500 lines per
 - When adding new information to the changelogs, changes will first be added to an "Unreleased" section at the top of the changelog file, and then later moved to a new version section when a new version is released. Be sure to follow this pattern and do not skip any of the changelog files.
 - Do not automatically update the version number in the plugin header or other files. Instead, provide a clear and concise change summary that includes the version number and a brief description of the changes made.
 - When making changes to the codebase, always update the relevant documentation files, including README.md, readme.txt, and CHANGELOG.md, even when a new version is not released.
-- Note: changelog.txt has been removed from this project. Only maintain readme.txt (for WordPress.org) and CHANGELOG.md (for developers).
-- Please do not skip these locations, as the changelog files must be in sync with each other, and the version numbers must be consistent across all files.
 - I will instruct you when to update the version number, and you should not do this automatically. Always ask for confirmation before updating the version number.
 - When the version number is updated, ensure that the new version number is reflected in all relevant files, as outlined in Version Locations above.
 - When the version number is updated, make special note to update the "Unreleased" section in the changelog files to reflect the new version number and a brief description of the changes made. This ensures that all changes are documented and easily accessible for future reference.
@@ -126,12 +116,8 @@ You must read files completely and thoroughly, with a minimum of 1500 lines per
 - Regularly update dependencies to their latest stable versions
 - Use HTTPS for all API requests and data transmission
 - When handling sensitive data, ensure it is encrypted both in transit and at rest
-- If you suspect a security vulnerability, immediately notify the project maintainers and provide details for investigation
-- If you encounter a security vulnerability in the codebase, do not disclose it publicly. Instead, report it privately to the project maintainers or through a responsible disclosure process.
-- If you are unsure about the security implications of a specific code change, ask for clarification or guidance before proceeding.
+- If you suspect a security vulnerability, attempt to identify and fix it automatically. Alert me to the issue and provide a detailed explanation of the vulnerability, how it can be exploited, and the steps taken to mitigate it.
 - Always follow the principle of least privilege when implementing security features, ensuring that users and processes have only the permissions they need to perform their tasks.
-- If you encounter a security vulnerability in a third-party library or dependency, check if there is an updated version that addresses the issue. If not, consider alternatives and notify me of the situation.
-- If there is a possible security vulnerability in the codebase, you should always ask for confirmation before proceeding with any changes. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
 - If I ask you to make changes that could potentially introduce security vulnerabilities, you should always ask for confirmation before proceeding. This ensures that the project maintainers are aware of the potential risk and can provide guidance on how to address it safely.
 
 ## Code Quality & Architecture