Add AI assistant guide and workflow documentation
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
Some checks failed
ci/woodpecker/push/woodpecker Pipeline failed
This commit is contained in:
130
.github/ai-workflows/feature-development.md
vendored
Normal file
130
.github/ai-workflows/feature-development.md
vendored
Normal file
@ -0,0 +1,130 @@
|
||||
# Feature Development Guide for AI Assistants
|
||||
|
||||
This document provides guidance for AI assistants to help with feature development for the Fix Plugin Does Not Exist Notices plugin.
|
||||
|
||||
## Feature Development Workflow
|
||||
|
||||
### 1. Create a Feature Branch
|
||||
|
||||
Always start by creating a feature branch from the main branch:
|
||||
|
||||
```bash
|
||||
git checkout main
|
||||
git pull github main
|
||||
git checkout -b feature/descriptive-name
|
||||
```
|
||||
|
||||
Use a descriptive name that clearly indicates what the feature is about.
|
||||
|
||||
### 2. Implement the Feature
|
||||
|
||||
When implementing a new feature:
|
||||
|
||||
- Follow WordPress coding standards
|
||||
- Ensure all strings are translatable
|
||||
- Add appropriate comments
|
||||
- Consider performance implications
|
||||
- Maintain backward compatibility
|
||||
|
||||
### 3. Update Documentation
|
||||
|
||||
Update relevant documentation to reflect the new feature:
|
||||
|
||||
- Add a description to CHANGELOG.md under an "Unreleased" section
|
||||
- Update readme.txt if the feature affects user-facing functionality
|
||||
- Update inline documentation/comments
|
||||
|
||||
### 4. Testing
|
||||
|
||||
Test the feature thoroughly:
|
||||
|
||||
- Test with the latest WordPress version
|
||||
- Test with the minimum supported WordPress version (5.0)
|
||||
- Test with PHP 7.0+ (minimum supported version)
|
||||
- Test in different environments (if possible)
|
||||
|
||||
### 5. Commit Changes
|
||||
|
||||
Make atomic commits with clear messages:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
git commit -m "Add feature: descriptive name"
|
||||
```
|
||||
|
||||
### 6. Push to Remote
|
||||
|
||||
Push the feature branch to the remote repositories:
|
||||
|
||||
```bash
|
||||
git push github HEAD:feature/descriptive-name
|
||||
git push gitea HEAD:feature/descriptive-name
|
||||
```
|
||||
|
||||
### 7. Create Pull Request (Optional)
|
||||
|
||||
If the repository uses pull requests for code review, create a pull request from the feature branch to the main branch.
|
||||
|
||||
## Code Standards and Best Practices
|
||||
|
||||
### PHP Coding Standards
|
||||
|
||||
- Follow [WordPress PHP Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/)
|
||||
- Use tabs for indentation, not spaces
|
||||
- Use proper naming conventions:
|
||||
- Class names: `Class_Name`
|
||||
- Function names: `function_name`
|
||||
- Variable names: `$variable_name`
|
||||
|
||||
### JavaScript Coding Standards
|
||||
|
||||
- Follow [WordPress JavaScript Coding Standards](https://developer.wordpress.org/coding-standards/wordpress-coding-standards/javascript/)
|
||||
- Use tabs for indentation, not spaces
|
||||
- Use proper naming conventions:
|
||||
- Function names: `functionName`
|
||||
- Variable names: `variableName`
|
||||
|
||||
### Internationalization (i18n)
|
||||
|
||||
- Wrap all user-facing strings in appropriate translation functions:
|
||||
- `__()` for simple strings
|
||||
- `_e()` for echoed strings
|
||||
- `esc_html__()` for escaped strings
|
||||
- `esc_html_e()` for escaped and echoed strings
|
||||
- Always use the plugin's text domain: `fix-plugin-does-not-exist-notices`
|
||||
|
||||
### Security Best Practices
|
||||
|
||||
- Validate and sanitize all input
|
||||
- Escape all output
|
||||
- Use nonces for form submissions
|
||||
- Use capability checks for user actions
|
||||
|
||||
## Feature Types and Implementation Guidelines
|
||||
|
||||
### Admin Interface Features
|
||||
|
||||
When adding features to the admin interface:
|
||||
|
||||
- Use WordPress admin UI components for consistency
|
||||
- Follow WordPress admin UI patterns
|
||||
- Ensure accessibility compliance
|
||||
- Add appropriate help text
|
||||
|
||||
### Plugin Functionality Features
|
||||
|
||||
When adding core functionality:
|
||||
|
||||
- Ensure compatibility with WordPress hooks system
|
||||
- Consider performance impact
|
||||
- Maintain backward compatibility
|
||||
- Add appropriate error handling
|
||||
|
||||
### Integration Features
|
||||
|
||||
When adding integration with other plugins or services:
|
||||
|
||||
- Make integrations optional when possible
|
||||
- Check if the integrated plugin/service is available before using it
|
||||
- Provide fallback functionality when the integration is not available
|
||||
- Document the integration requirements
|
Reference in New Issue
Block a user