You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+17-12Lines changed: 17 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,23 +5,21 @@ Coding standards, domain knowledge, and preferences that AI should follow.
5
5
6
6
# Work Environment
7
7
8
-
This project is coded entirely in a remote development environment using GitHub Codespaces. The AI will never ask me to run Terminal commands or use a local development environment. All code changes, tests, and debugging will be done within remote repositories on GitHub.
8
+
This project is coded entirely in a remote development environment using GitHub Codespaces. All code changes, tests, and debugging will be done within remote repositories on GitHub.
9
9
10
-
Change summaries should be concise and clear, focusing on the specific changes made. The AI should not ask for confirmation before making changes, as all code modifications will be done directly in the remote environment.
10
+
The AI will never ask me to run terminal commands or use a local development environment.
11
11
12
12
# Responses
13
13
14
14
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.
15
15
16
-
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.
16
+
Responses, change summaries, and code comments should be written in American English. All communication should be clear and professional, adhering to standard English grammar and spelling conventions.
17
17
18
-
Responses should be delivered only in the chat interface. Formatting and styling should be utilized to enhance readability.
19
-
20
-
Change summaries should never be created in the form of new .md files.
18
+
Responses should be delivered only in the chat interface and should never be created in the form of new .md files. Formatting and styling within the chat window should be utilized to enhance readability.
21
19
22
20
# Code Analysis and Reading Standards
23
21
24
-
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.
22
+
You must read files completely and thoroughly, with a minimum of 2000 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. 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.
25
23
26
24
# Coding Standards and Preferences
27
25
@@ -81,16 +79,16 @@ You must read files completely and thoroughly, with a minimum of 1500 lines per
81
79
- 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.
82
80
- 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.
83
81
- 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.
84
-
-Note: changelog.txt has been removed from this project. Only maintain readme.txt (for WordPress.org) and CHANGELOG.md (for developers).
82
+
-Maintain changelogs at readme.txt (for WordPress.org) and CHANGELOG.md (for developers).
85
83
- 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.
86
-
- 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.
84
+
- I will instruct you when to update the version number, and you should not do this automatically.
87
85
- When the version number is updated, ensure that the new version number is reflected in all relevant files, as outlined in Version Locations above.
88
86
- 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.
89
87
90
88
# General Coding Standards
91
89
92
-
-The above standards are prioritized over general coding standards.
93
-
- The standards below are general coding standards that apply to all code, including WordPress code. Do not apply them if they conflict with WordPress standards.
90
+
-WordPress coding standards should be prioritized over general coding standards.
91
+
- The standards below are general coding standards that apply to all code, including WordPress code. Do not apply them if they conflict with WordPress standards and best practices.
94
92
95
93
## Accessibility & UX
96
94
@@ -150,4 +148,11 @@ You must read files completely and thoroughly, with a minimum of 1500 lines per
150
148
- Only ask for manual intervention if domain-specific knowledge is required
151
149
- Auto-lint and format code using standard tools (e.g., Prettier, ESLint, dotnet format)
152
150
- Changes should be made directly to the file in question. Example: admin.php should be modified directly, not by creating a new file like admin-changes.php.
153
-
- New files may be created when appropriate, but they should be relevant to the task at hand, so long as they are not a rewrite of an existing file. We want to avoid unnecessary duplication of files.
151
+
- New files may be created when appropriate, but they should be relevant to the task at hand, so long as they are not a rewrite of an existing file. We want to avoid unnecessary duplication of files.
152
+
153
+
# Final Step for Each Task
154
+
155
+
- After completing a task:
156
+
- Review your changes to ensure they have met the WordPress coding standards and best practices.
157
+
- Perform a final check to ensure we have not introduced any security vulnerabilities such as XSS, CSRF, or SQL injection.
158
+
- In the chat interface, deliver a summary of the security checks performed, including any potential vulnerabilities identified and how they were addressed. Do not allow yourself to skip this step as it is crucial for maintaining the security and integrity of the codebase.
@@ -98,7 +98,8 @@ along with this program. If not, see <https://www.gnu.org/licenses/>.
98
98
= 1.8.2 =
99
99
* **Critical Security Fix**: Resolved a fatal error caused by a missing `sse_get_safe_wp_cli_path()` function. This function is essential for securely locating the WP-CLI executable, and its absence prevented the database export process from running. The new function ensures that the plugin can reliably find WP-CLI in common locations, allowing the export to proceed as intended.
100
100
101
-
= Unreleased =
101
+
102
+
= 1.8.4 =
102
103
* **WordPress Coding Standards**: Comprehensive PHPCS compliance fixes across all functions
103
104
* **Code Quality**: Fixed function documentation block spacing and alignment
0 commit comments