Remove STARTER-PROMPT.md from root directory as it's now in the wiki

Update references to Starter Prompt to point to wiki version
Update STARTER-PROMPT.md with AI IDE context recommendations and add to wiki
2025-04-18 04:25:02 +01:00 · 2025-04-18 04:24:40 +01:00 · 2025-04-18 04:12:49 +01:00 · 2025-04-18 04:04:44 +01:00 · 2025-04-18 03:57:43 +01:00 · 2025-04-18 03:47:03 +01:00
17 changed files with 2109 additions and 200 deletions
--- a/.ai-assistant.md
+++ b/.ai-assistant.md
@ -16,7 +16,7 @@ This workspace may contain multiple repository folders. Always focus ONLY on the
 - **Plugin Slug**: wp-plugin-starter-template
 - **Text Domain**: wp-plugin-starter-template
 - **Namespace**: WPALLSTARS\PluginStarterTemplate
- **Version**: 0.1.0
+- **Version**: 0.1.1
 - **Requires WordPress**: 5.0+
 - **Requires PHP**: 7.0+
 - **License**: GPL-2.0+
--- a/.ai-workflows/bug-fixing.md
+++ b/.ai-workflows/bug-fixing.md
@ -0,0 +1,202 @@
 # Bug Fixing Guide for AI Assistants
 This document provides guidance for AI assistants to help with bug fixing for the Fix Plugin Does Not Exist Notices plugin.
 ## Bug Fixing Workflow
 ### 1. Create a Bug Fix Branch
 Always start by creating a bug fix branch from the latest main branch pulled from origin (this step is mandatory):
 ```bash
 git checkout main
 git pull origin main  # Critical step - never skip this
 git checkout -b fix/bug-description
 ```
 Use a descriptive name that clearly indicates what bug is being fixed. If there's an issue number, include it in the branch name (e.g., `fix/123-plugin-activation-error`).
 For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
 ### 2. Understand the Bug
 Before fixing a bug, make sure you understand:
 - What is the expected behavior?
 - What is the actual behavior?
 - What are the steps to reproduce the bug?
 - What is the impact of the bug?
 - What is the root cause of the bug?
 ### 3. Fix the Bug
 When fixing a bug:
 - Make minimal changes necessary to fix the bug
 - Avoid introducing new features while fixing bugs
 - Maintain backward compatibility
 - Add appropriate comments explaining the fix
 - Consider adding tests to prevent regression
 ### 4. Update Documentation
 Update relevant documentation to reflect the bug fix:
 - Add a description to CHANGELOG.md under an "Unreleased" section
 - Update readme.txt if the bug fix affects user-facing functionality
 ### 5. Testing
 Test the bug fix thoroughly:
 - Verify that the bug is fixed
 - Ensure no regression in related functionality
 - Test with the latest WordPress version
 - Test with the minimum supported WordPress version (5.0)
 - Test with PHP 7.0+ (minimum supported version)
 ### 6. Commit Changes
 Make atomic commits with clear messages:
 ```bash
 git add .
 git commit -m "Fix #123: Brief description of the bug fix"
 ```
 If there's an issue number, reference it in the commit message.
 ### 7. Prepare for Release
 When the bug fix is ready to be released:
 1. Create a version branch for the release:
 ```bash
 git checkout -b v{MAJOR}.{MINOR}.{PATCH}
 ```
 2. Merge your bug fix branch into the version branch:
 ```bash
 git merge fix/bug-description --no-ff
 ```
 3. Update version numbers and changelog entries
 4. Follow the standard release process from this point
 ### 8. Push to Remote (Optional for Collaboration)
 If you need to collaborate with others on the bug fix before it's ready for release:
 ```bash
 git push github HEAD:fix/bug-description
 git push gitea HEAD:fix/bug-description
 ```
 ### 9. Create Pull Request (Optional)
 If the repository uses pull requests for code review, create a pull request from the bug fix branch to the version branch.
 ## Determining Version Increment
 After fixing a bug and confirming it works, determine the appropriate version increment:
 - **PATCH** (e.g., 1.6.0 → 1.6.1): For most bug fixes that don't change functionality
 - **MINOR** (e.g., 1.6.0 → 1.7.0): For bug fixes that introduce new features or significant changes
 - **MAJOR** (e.g., 1.6.0 → 2.0.0): For bug fixes that introduce breaking changes
 **IMPORTANT**: Don't update version numbers during initial development and testing. Only create a version branch (e.g., `v2.2.3`) and update version numbers when the fix is confirmed working.
 This approach is more time-efficient as it allows you to focus on fixing the bug without worrying about version updates until the fix is confirmed working.
 For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
 ## Testing Previous Versions
 To test a previous version of the plugin:
 ```bash
 # Checkout a specific tag for testing
 git checkout v{MAJOR}.{MINOR}.{PATCH}
 # Or create a test branch from a specific tag
 git checkout v{MAJOR}.{MINOR}.{PATCH} -b test/some-feature
 ```
 ## Hotfix Process
 For critical bugs that need immediate fixing in a released version:
 ### 1. Create a Hotfix Branch
 ```bash
 git checkout v{MAJOR}.{MINOR}.{PATCH}
 git checkout -b hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
 ```
 ### 2. Fix the Issues
 Apply the minimal fix necessary to address the critical issue.
 ### 3. Update Version Numbers
 Increment the PATCH version and update all version numbers:
 - Main plugin file (fix-plugin-does-not-exist-notices.php)
 - FPDEN_VERSION constant
 - CHANGELOG.md
 - readme.txt
 - README.md
 - languages/fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
 ### 4. Commit and Push
 ```bash
 git add .
 git commit -m "Hotfix: Brief description of the critical bug fix"
 git push github HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
 git push gitea HEAD:hotfix/v{MAJOR}.{MINOR}.{PATCH+1}
 ```
 ### 5. Create and Push Tag
 ```bash
 git tag -a v{MAJOR}.{MINOR}.{PATCH+1} -m "Hotfix release version {MAJOR}.{MINOR}.{PATCH+1}"
 git push github refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
 git push gitea refs/tags/v{MAJOR}.{MINOR}.{PATCH+1}
 ```
 ## Common Bug Types and Fixing Strategies
 ### WordPress Compatibility Issues
 - Test with the specific WordPress version where the issue occurs
 - Check for deprecated functions or hooks
 - Review WordPress changelog for relevant changes
 ### PHP Compatibility Issues
 - Test with the specific PHP version where the issue occurs
 - Check for deprecated PHP functions or features
 - Use appropriate polyfills if necessary
 ### JavaScript Issues
 - Test in different browsers
 - Check for browser console errors
 - Consider browser-specific workarounds if necessary
 ### CSS Issues
 - Test in different browsers and screen sizes
 - Use browser developer tools to inspect elements
 - Consider browser-specific workarounds if necessary
 ### Database Issues
 - Use proper database prefixing
 - Sanitize database inputs
 - Use prepared statements for queries
 - Consider database version differences
--- a/.ai-workflows/code-review.md
+++ b/.ai-workflows/code-review.md
@ -0,0 +1,163 @@
 # Code Review Guide for AI Assistants
 This document provides guidance for AI assistants to help with code review for the Fix Plugin Does Not Exist Notices plugin.
 ## Code Review Checklist
 When reviewing code, check for the following:
 ### Functionality
 - [ ] Does the code work as expected?
 - [ ] Does it handle edge cases appropriately?
 - [ ] Are there any logical errors?
 - [ ] Is error handling implemented properly?
 ### Code Quality
 - [ ] Does the code follow WordPress coding standards?
 - [ ] Is the code well-organized and easy to understand?
 - [ ] Are there any code smells (duplicate code, overly complex functions, etc.)?
 - [ ] Are functions and variables named appropriately?
 - [ ] Are there appropriate comments and documentation?
 ### Security
 - [ ] Is user input properly validated and sanitized?
 - [ ] Is output properly escaped?
 - [ ] Are capability checks used for user actions?
 - [ ] Are nonces used for form submissions?
 - [ ] Are there any potential SQL injection vulnerabilities?
 - [ ] Are there any potential XSS vulnerabilities?
 ### Performance
 - [ ] Are there any performance bottlenecks?
 - [ ] Are database queries optimized?
 - [ ] Is caching used appropriately?
 - [ ] Are assets (CSS, JS) properly enqueued?
 ### Compatibility
 - [ ] Is the code compatible with the minimum supported WordPress version (5.0)?
 - [ ] Is the code compatible with the minimum supported PHP version (7.0)?
 - [ ] Are there any browser compatibility issues?
 - [ ] Are there any conflicts with other plugins?
 ### Internationalization
 - [ ] Are all user-facing strings translatable?
 - [ ] Is the correct text domain used?
 - [ ] Are translation functions used correctly?
 ### Accessibility
 - [ ] Does the code follow accessibility best practices?
 - [ ] Are ARIA attributes used appropriately?
 - [ ] Is keyboard navigation supported?
 - [ ] Is screen reader support implemented?
 ## Code Review Process
 ### 1. Understand the Context
 Before reviewing code, understand:
 - What problem is the code trying to solve?
 - What are the requirements?
 - What are the constraints?
 ### 2. Review the Code
 Review the code with the checklist above in mind.
 ### 3. Provide Feedback
 When providing feedback:
 - Be specific and clear
 - Explain why a change is needed
 - Provide examples or suggestions when possible
 - Prioritize feedback (critical issues vs. minor improvements)
 - Be constructive and respectful
 ### 4. Follow Up
 After the code has been updated:
 - Review the changes
 - Verify that issues have been addressed
 - Provide additional feedback if necessary
 ## Common Issues to Look For
 ### PHP Issues
 - Undefined variables or functions
 - Incorrect function parameters
 - Missing return statements
 - Improper error handling
 - Inefficient loops or conditionals
 - Hardcoded values that should be configurable
 ### WordPress-Specific Issues
 - Incorrect hook usage
 - Missing or incorrect nonces
 - Missing capability checks
 - Direct database queries instead of using WordPress functions
 - Improper enqueuing of scripts and styles
 - Not using WordPress functions for common tasks
 ### JavaScript Issues
 - Undefined variables or functions
 - Event listener memory leaks
 - jQuery conflicts
 - Browser compatibility issues
 - Missing error handling
 ### CSS Issues
 - Browser compatibility issues
 - Specificity issues
 - Unused styles
 - Overriding WordPress admin styles inappropriately
 ## Example Feedback
 ### Good Feedback Example
 ```
 In function `handle_remove_reference()`:
 1. The nonce check is missing, which could lead to CSRF vulnerabilities. 
   Consider adding:
   ```php
   if (!isset($_GET['_wpnonce']) || !wp_verify_nonce($_GET['_wpnonce'], 'fpden_remove_reference')) {
       wp_die(__('Security check failed.', 'fix-plugin-does-not-exist-notices'));
   }
   ```
 2. The user capability check should be more specific. Instead of:
   ```php
   if (!current_user_can('manage_options')) {
   ```
   Consider using:
   ```php
   if (!current_user_can('activate_plugins')) {
   ```
   This is more appropriate for the action being performed.
 3. The success message should be translatable:
   ```php
   // Change this:
   add_settings_error('fpden', 'fpden_removed', 'Plugin reference removed successfully.', 'updated');
   // To this:
   add_settings_error('fpden', 'fpden_removed', __('Plugin reference removed successfully.', 'fix-plugin-does-not-exist-notices'), 'updated');
   ```
 ```
 ### Poor Feedback Example
 ```
 This code has security issues and doesn't follow best practices. Fix it.
 ```
--- a/.ai-workflows/dev-prefs-memory.md
+++ b/.ai-workflows/dev-prefs-memory.md
@ -0,0 +1,62 @@
 # Developer Preferences Memory
 This document serves as a persistent memory for developer preferences established during coding sessions. AI assistants should refer to this document to understand the developer's preferences and update it as new preferences are established.
 ## Purpose
 - Maintain a consistent record of developer preferences across coding sessions
 - Ensure AI assistants can provide assistance that aligns with the developer's preferred coding style and practices
 - Reduce the need for developers to repeatedly explain their preferences
 ## How to Use This Document
 - **AI Assistants**: Review this document before providing assistance. Update it when new preferences are established through user feedback.
 - **Developers**: Reference this document to see what preferences have been recorded. Feel free to edit it directly to add or modify preferences.
 ## Recorded Preferences
 ### File and Directory Structure
 - Prefer lowercase filenames for consistency across the codebase
 - Use unique folder names following best practices
 - Folder references should be easily identifiable when using @mentions in AI-assisted coding
 - Admin-specific functionality should be in the `admin/lib/` directory
 - Core plugin functionality should be in the `includes/` directory
 ### Code Style
 - Follow WordPress coding standards
 - Use OOP best practices for WordPress plugins
 - Create modular, maintainable, and efficient code structure
 ### Documentation
 - Prefer token-efficient documentation in `.ai-assistant.md` that references `.ai-workflows/` files
 - Document the release workflow in `.ai-assistant.md` and `.ai-workflows/release-process.md`
 - Store environment variable documentation in `.ai-workflows/local-env-vars.md`
 - Maintain consistent documentation across readme.txt, README.md, and CHANGELOG.md
 ### Asset Organization
 - Store banner, icon, and screenshot images in `.wordpress-org/assets/`
 - Store WORDPRESS_ORG files within `/wordpress-org`
 - Organize files in `/assets` into relevant `/admin` folders
 ### Version Control
 - Use standard Git practices for version control and code management
 - When updating plugin versions, create a GitHub tag and trigger GitHub actions
 - Follow a specific release process with proper tagging and GitHub releases
 - Ensure commits are merged to the main branch as Git Updater pulls data from the readme.txt file in the primary branch
 ### Plugin Development
 - Prefer simpler solutions over complex ones for plugins
 - Use a specific formatting style for the CHANGELOG.md file, using #### for section headings
 - When updating plugin versions, remember to update language files (POT/PO)
 - Comment out redundant code during testing
 ### Potential AI Assised IDE Issues
 - Check for non-standard local terminal commandline customisations that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve
 - Check for non-standard or multiple python and node.js versions, including homebrew versions, that might not be understood by the AI IDE in its terminal useage and cause errors in execution or confusion in not seeing expected results, and advise on how to resolve
--- a/.ai-workflows/feature-development.md
+++ b/.ai-workflows/feature-development.md
@ -0,0 +1,205 @@
 # 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 latest main branch pulled from origin (this step is mandatory):
 ```bash
 git checkout main
 git pull origin main  # Critical step - never skip this
 git checkout -b feature/descriptive-name
 ```
 Use a descriptive name that clearly indicates what the feature is about. If there's an issue number, include it in the branch name (e.g., `feature/123-update-source-selector`).
 For more detailed git workflow guidelines, see **@.ai-workflows/git-workflow.md**.
 ### 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
 - Review reference plugins in the `reference-plugins/` directory for inspiration and best practices
 ### 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 README.md with the new feature description
 - Update inline documentation/comments
 - Update wiki documentation in the `.wiki` directory:
  - Create or update feature-specific pages
  - Update the Home.md page if necessary
  - Add the feature to any relevant existing pages
  - Add screenshots or examples if applicable
 - Remember that any feature addition will require a version increment in all relevant files
 For detailed guidelines on maintaining wiki documentation, see **@.ai-workflows/wiki-documentation.md**.
 ### 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. Prepare for Release
 When the feature is ready to be released:
 1. Create a version branch with the appropriate version number (typically increment the minor version for features):
 ```bash
 # Example: from 2.2.0 to 2.3.0
 git checkout -b v{MAJOR}.{MINOR+1}.0
 ```
 2. Now update version numbers in all required files:
 - Main plugin file (wp-fix-plugin-does-not-exist-notices.php)
 - CHANGELOG.md (add a new version section)
 - readme.txt
 - README.md
 - languages/wp-fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
 3. Commit the version updates:
 ```bash
 git add .
 git commit -m "Version {MAJOR}.{MINOR+1}.0 - [brief description]"
 ```
 4. Tag the version as stable:
 ```bash
 git tag -a v{MAJOR}.{MINOR+1}.0-stable -m "Stable version {MAJOR}.{MINOR+1}.0"
 ```
 5. Follow the standard release process from this point
 **IMPORTANT**: Don't update version numbers during initial development and testing. Only create a version branch and update version numbers when the feature is confirmed working.
 For detailed guidelines on time-efficient development and testing, see **@.ai-workflows/incremental-development.md**.
 ### 7. Push to Remote (Optional for Collaboration)
 If you need to collaborate with others on the feature before it's ready for release:
 ```bash
 git push github HEAD:feature/descriptive-name
 git push gitea HEAD:feature/descriptive-name
 ```
 ### 8. Create Pull Request (Optional)
 If the repository uses pull requests for code review, create a pull request from the feature branch to the version 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
 ## Working in Multi-Repository Workspaces
 When developing features in a workspace with multiple repositories:
 1. **Verify Repository Context**:
   - Confirm you're working in the correct repository before suggesting or implementing features
   - Use `pwd` and `git remote -v` to verify the current repository
 2. **Feature Verification**:
   - Before implementing a feature, verify it doesn't already exist in the current repository
   - Don't assume features from other repositories should be implemented in this one
   - Use `codebase-retrieval` to search for existing functionality
 3. **Repository-Specific Implementation**:
   - Implement features appropriate for this specific plugin's purpose
   - Maintain consistency with the current repository's architecture and coding style
   - Don't copy code directly from other repositories without adaptation
 4. **Cross-Repository Inspiration**:
   - If implementing a feature inspired by another repository, explicitly note that it's a new feature
   - Adapt the feature to fit the current repository's needs and architecture
   - Document the inspiration source in code comments
 For detailed guidelines on working in multi-repository workspaces, see **@.ai-workflows/multi-repo-workspace.md**.
 ## 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
--- a/.ai-workflows/folder-structure.md
+++ b/.ai-workflows/folder-structure.md
@ -0,0 +1,59 @@
 # Folder Structure
 This document outlines the folder structure of the plugin and explains the purpose of each directory.
 ## Root Directories
 - **admin/** - Contains admin-specific functionality and assets
 - **includes/** - Contains core plugin functionality and classes
 - **languages/** - Contains translation files
 - **scripts/** - Contains build and deployment scripts
 - **.ai-workflows/** - Contains documentation for AI assistants
 - **.github/** - Contains GitHub-specific files like workflows
 - **.wordpress-org/** - Contains WordPress.org assets like banners and screenshots
 ## Admin Directory Structure
 - **admin/css/** - Admin-specific CSS files
 - **admin/js/** - Admin-specific JavaScript files
 - **admin/images/** - Admin-specific images
 - **admin/partials/** - Admin-specific template partials
 - **admin/settings/** - Admin settings functionality
 - **admin/tools/** - Admin tools functionality
 - **admin/lib/** - Admin-specific library files and helper functions
  - **admin/lib/admin.php** - Admin class for handling admin-specific functionality
  - **admin/lib/modal.php** - Modal class for handling the update source selector modal
 ## Includes Directory
 The `includes/` directory contains the core plugin functionality:
 - **includes/core.php** - Core class for handling the main plugin functionality
 - **includes/plugin.php** - Main plugin class that initializes all components
 - **includes/updater.php** - Updater class for handling plugin updates
 ## File Naming Conventions
 - All PHP files in the `includes/` directory use lowercase filenames
 - All directories use lowercase names
 - JavaScript and CSS files use kebab-case (e.g., `update-source-selector.js`)
 ## Best Practices
 1. **Unique Directory Names**: Each directory should have a unique name to avoid confusion
 2. **Logical Organization**: Files should be organized logically by function
 3. **Consistent Naming**: File and directory names should follow consistent naming conventions
 4. **Clear Separation**: Admin functionality should be separate from core functionality
 5. **Minimal Dependencies**: Files should have minimal dependencies on other files
 ## @mentions for AI Assistants
 When referring to files or directories in AI conversations, use the following format:
 - **@includes/plugin.php** - Main plugin class
 - **@includes/core.php** - Core functionality
 - **@admin/lib/admin.php** - Admin functionality
 - **@admin/lib/modal.php** - Modal functionality
 - **@includes/updater.php** - Updater functionality
 - **@admin/js/update-source-selector.js** - Update source selector JavaScript
 - **@admin/css/update-source-selector.css** - Update source selector CSS
--- a/.ai-workflows/git-workflow.md
+++ b/.ai-workflows/git-workflow.md
@ -0,0 +1,255 @@
 # Git Workflow Guide for AI Assistants
 This document provides guidance for AI assistants to help with git workflow management for the Fix Plugin Does Not Exist Notices plugin.
 ## Core Git Workflow Principles
 ### 1. Always Start from Latest Main Branch
 Before creating any new branch, always ensure you're working with the latest code from the main branch by pulling from the origin:
 ```bash
 git checkout main
 git pull origin main
 ```
 This critical step ensures that your new branch includes all the latest changes from the remote repository and reduces the chance of merge conflicts later. Never skip this step, as working from an outdated main branch can lead to integration problems.
 ### 2. One Issue Per Branch
 Create a separate branch for each issue or feature you're working on:
 - For bug fixes: `fix/issue-description` or `fix/issue-number-description`
 - For features: `feature/descriptive-name`
 - For small improvements: `patch/descriptive-name`
 - For code restructuring: `refactor/descriptive-name`
 **Important**: Use descriptive names without version numbers for development branches. This allows focusing on the changes without worrying about version updates until the changes are confirmed working.
 Only create version branches (e.g., `v2.2.3`) when changes are ready for release, and only then update version numbers in files.
 This approach keeps changes focused, makes code review easier, and provides clear rollback points if needed.
 ### 3. Pull Request for Each Issue
 Create a separate pull request for each issue or feature. This ensures:
 - Each change can be reviewed independently
 - Issues can be merged as soon as they're ready
 - Changes can be reverted individually if needed
 - CI/CD checks can run on focused changes
 ## Detailed Workflow
 ### Starting a New Task
 1. **Update Main Branch from Origin**
   ```bash
   git checkout main
   git pull origin main
   ```
   This step is mandatory before creating any new branch to ensure you're working with the latest code.
 2. **Create a New Branch**
   ```bash
   git checkout -b [branch-type]/[description]
   ```
   Examples:
   ```bash
   git checkout -b fix/123-plugin-activation-error
   git checkout -b feature/update-source-selector
   git checkout -b patch/2.2.1
   ```
 3. **Make Your Changes**
   - Make focused changes related only to the specific issue
   - Commit regularly with clear, descriptive messages
   - Reference issue numbers in commit messages when applicable
 4. **Testing Approach**
   For efficient development:
   - **Local Testing (Default)**: Test without updating version numbers
     ```bash
     # Get current version from plugin file
     CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
     # Build and deploy with current version
     ./build.sh $CURRENT_VERSION
     ```
   - **Remote Testing (When Requested)**: Push development branch to remote
     ```bash
     git add .
     git commit -m "[Brief description] for remote testing"
     git push origin [branch-name]
     ```
   - **Version Creation**: Only when changes are confirmed working
     ```bash
     # Create version branch
     git checkout -b v{MAJOR}.{MINOR}.{PATCH}
     # Update version numbers in all required files
     # Commit version updates
     git add .
     git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - Brief description"
     # Tag as stable
     git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
     ```
 5. **Push Branch to Remote (When Needed)**
   ```bash
   git push origin [branch-name]
   ```
 ### Creating a Pull Request
 1. **Ensure Tests Pass Locally**
   - Run any available tests to ensure your changes work as expected
   - Fix any issues before creating a pull request
 2. **Create Pull Request**
   - Create a pull request from your branch to the main branch
   - Include a clear description of the changes
   - Reference any related issues
   - Assign reviewers if appropriate
 3. **Address Review Feedback**
   - Make requested changes
   - Push additional commits to the same branch
   - Respond to comments
 ### CI/CD Integration
 Each pull request should pass through CI/CD checks before being merged. This ensures that all changes are compatible with the existing codebase and meet quality standards.
 1. **Automated Tests**
   - Unit tests
   - Integration tests
   - Code style checks
   - Compatibility checks
 2. **Manual Review**
   - Code review by team members
   - Functional testing in test environment
   - Verification of feature requirements
 3. **Approval Process**
   - Required approvals before merging
   - Final checks for conflicts with other pending PRs
   - Verification that all CI/CD checks have passed
 4. **Compatibility with Unmerged PRs**
   - When multiple PRs are in progress simultaneously, ensure each PR is compatible with the main branch
   - For related changes, consider using feature flags to allow independent merging
   - Document dependencies between PRs in the PR description
 ### Handling Concurrent Development
 When working on multiple issues simultaneously:
 1. **Keep Branches Independent**
   - Always create new branches from the latest main branch pulled from origin, not from other feature branches
   - This ensures each PR can be merged independently and contains all the latest changes
 2. **Handle Conflicts Proactively**
   - If main has been updated with other changes while you're working:
     ```bash
     git checkout main
     git pull origin main
     git checkout your-branch
     git merge main
     ```
   - Resolve any conflicts locally before pushing
 3. **Coordinate on Dependent Changes**
   - If changes depend on each other, note this in the PR description
   - Consider using the "Depends on #PR-number" notation in PR descriptions
 ## Release Process
 When preparing for a release:
 1. **Ensure All Required PRs are Merged**
   - All features and fixes planned for the release should be merged to main
 2. **Create a Release Branch**
   ```bash
   git checkout main
   git pull origin main
   git checkout -b v{MAJOR}.{MINOR}.{PATCH}
   ```
 3. **Follow Standard Release Process**
   - Update version numbers
   - Update changelogs
   - Create tag
   - See **@.ai-workflows/release-process.md** for complete details
 ## Contributing to External Repositories
 When working on issues for external repositories (pull/merge requests):
 ### 1. Clearly Indicate Testing Status
 In the PR description and comments, clearly indicate the testing status:
 - **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
 - **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
 - **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
 ### 2. Provide Testing Instructions
 Include clear instructions for maintainers on how to test the changes:
 - Steps to reproduce the original issue (if applicable)
 - Steps to verify the fix or feature
 - Any specific environments or configurations needed for testing
 ### 3. Be Responsive to Feedback
 Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
 ## Best Practices
 ### Commit Messages
 - Use present tense ("Add feature" not "Added feature")
 - Start with a verb
 - Keep the first line under 50 characters
 - Reference issues when relevant: "Fix #123: Resolve plugin detection issue"
 - For more complex changes, add a detailed description after the first line
 ### Branch Management
 - Delete branches after they've been merged
 - Keep branch names descriptive but concise
 - Use consistent naming conventions
 ### Code Review
 - Review code thoroughly before approving
 - Test changes locally when possible
 - Provide constructive feedback
 - See **@.ai-workflows/code-review.md** for detailed code review guidelines
 ### Suggested Improvements
 If you identify potential improvements outside the scope of the current issue:
 1. **Document the Suggestion**
   - Note the suggestion in the PR comments
   - Create a new issue for the suggestion
   - Be specific about the benefits and implementation details
 2. **Create a Separate Branch**
   - Don't include unrelated improvements in the current PR
   - Create a new branch from the latest main branch for the suggested improvement
   - Submit a separate PR for the suggestion
 3. **Ensure Compatibility**
   - Make sure the suggested improvement is compatible with any unmerged PRs
   - If the improvement depends on changes in another PR, note this dependency
   - Consider how the improvement will interact with other pending changes
--- a/.ai-workflows/incremental-development.md
+++ b/.ai-workflows/incremental-development.md
@ -0,0 +1,225 @@
 # Incremental Development and Testing Guide
 This document provides guidance for AI assistants to help with incremental development and testing for the Fix Plugin Does Not Exist Notices plugin.
 ## Time-Efficient Development Principles
 ### Branch Naming for Development
 1. **Initial Development Branches**
   - Use descriptive names without version numbers:
     - `fix/issue-description` - For bug fixes
     - `feature/descriptive-name` - For new features
     - `patch/descriptive-name` - For small improvements
     - `refactor/descriptive-name` - For code restructuring
   - **Don't update version numbers** during this phase
   - Focus on implementing and testing the changes
 2. **Version Branches**
   - Only create after changes are confirmed working:
     - `v{MAJOR}.{MINOR}.{PATCH}` (e.g., `v2.2.3`)
   - Only update version numbers at this point
   - This minimizes unnecessary version updates
 ### Version Numbering Guidelines
 1. **Patch Versions (X.Y.Z → X.Y.Z+1)**
   - Use for bug fixes and small improvements
   - Example: `v2.2.3`
 2. **Minor Versions (X.Y.Z → X.Y+1.0)**
   - Use for new features or significant improvements
   - Example: `v2.3.0`
 3. **Major Versions (X.Y.Z → X+1.0.0)**
   - Only increment when numerous features and fixes are tested and confirmed stable
   - Reserved for breaking changes or significant overhauls
   - Example: `v3.0.0`
 ### Marking Stable Versions
 When the user confirms that changes are working correctly:
 1. Create a version branch and update version numbers
 2. Tag the version branch as stable
   ```bash
   git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
   ```
 3. Document in the PR or issue that this version has been confirmed stable
 ## Local Testing Workflow
 ### 1. Create a Descriptive Branch for Development
 ```bash
 # Ensure you have the latest main branch
 git checkout main
 git pull origin main
 # Create a descriptive branch (without version numbers)
 git checkout -b fix/plugin-activation-error
 ```
 ### 2. Make Changes Without Updating Version Numbers
 During the development and testing phase:
 - Implement the necessary changes
 - **Don't update version numbers** in any files yet
 - Focus on the functionality
 ### 3. Build and Deploy Locally
 For local testing, use the current version number from the main plugin file:
 ```bash
 # Get the current version from the plugin file
 CURRENT_VERSION=$(grep -o "Version: [0-9.]*" wp-fix-plugin-does-not-exist-notices.php | cut -d' ' -f2)
 # Build and deploy with current version
 ./build.sh $CURRENT_VERSION
 ```
 This will:
 1. Create a build directory
 2. Copy required files to the build directory
 3. Deploy the plugin to your local WordPress testing environment
 **Note**: For local testing iterations, you do not need to commit changes, push to remote repositories, or create tags unless specifically requested.
 ### 4. Test and Evaluate
 Test the changes thoroughly in the local environment:
 - Verify that the specific issue is fixed or feature works as expected
 - Check for any regressions or new issues
 - Document the results
 ### 5. Based on Testing Results
 - **If changes need further refinement**: Continue working in the same branch
 - **If changes work as expected**: Proceed to version branch creation
 ### 6. Creating a Version Branch
 When changes are confirmed working and ready for release:
 1. Create a version branch with the appropriate version number:
 ```bash
 # Determine the appropriate version increment (patch, minor, or major)
 # based on the nature of the changes
 git checkout -b v{MAJOR}.{MINOR}.{PATCH}
 ```
 2. Now update version numbers in all required files:
 - Main plugin file (wp-fix-plugin-does-not-exist-notices.php)
 - CHANGELOG.md (add a new version section)
 - readme.txt
 - README.md
 - languages/wp-fix-plugin-does-not-exist-notices.pot (Project-Id-Version)
 3. Commit the version updates:
 ```bash
 git add .
 git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
 ```
 4. Tag the version as stable:
 ```bash
 git tag -a v{MAJOR}.{MINOR}.{PATCH}-stable -m "Stable version {MAJOR}.{MINOR}.{PATCH}"
 ```
 ## Remote Testing Workflow
 When the user specifically requests remote testing:
 ### 1. Commit Changes to Remote Repository
 If testing a development branch (without version updates):
 ```bash
 git add .
 git commit -m "[brief description] for remote testing"
 git push origin [branch-name]
 ```
 If testing a version branch (with version updates):
 ```bash
 git add .
 git commit -m "Version {MAJOR}.{MINOR}.{PATCH} - [brief description]"
 git push origin v{MAJOR}.{MINOR}.{PATCH}
 ```
 ### 2. Create and Push Tag (For Version Branches Only)
 ```bash
 git tag -a v{MAJOR}.{MINOR}.{PATCH} -m "Version {MAJOR}.{MINOR}.{PATCH} for remote testing"
 git push origin v{MAJOR}.{MINOR}.{PATCH}
 ```
 This will trigger GitHub Actions to build the installable ZIP file.
 ### 3. Verify Remote Build
 Check that the GitHub Actions workflow completed successfully and the ZIP file is available for download.
 ### 4. Test and Evaluate
 Test the remotely built version and document the results.
 ## Contributing to External Repositories
 When working on issues for external repositories (pull/merge requests):
 ### 1. Clearly Indicate Testing Status
 In the PR description and comments, clearly indicate the testing status:
 - **Not tested**: "This PR addresses [issue] but has not been tested locally or remotely. It's ready for community/maintainer testing."
 - **Locally tested**: "This PR has been tested in a local WordPress environment and [describe results]."
 - **Remotely tested**: "This PR has been tested with a remote build and [describe results]."
 ### 2. Provide Testing Instructions
 Include clear instructions for maintainers on how to test the changes:
 - Steps to reproduce the original issue (if applicable)
 - Steps to verify the fix or feature
 - Any specific environments or configurations needed for testing
 ### 3. Be Responsive to Feedback
 Monitor the PR for feedback from maintainers and be prepared to make additional changes if requested.
 ## Rollback Procedure
 If a change causes issues after release:
 ### 1. Identify the Last Stable Version
 Find the last version that was marked as stable:
 ```bash
 git tag -l "*-stable"
 ```
 ### 2. Create a New Branch from the Stable Version
 ```bash
 git checkout v{MAJOR}.{MINOR}.{PATCH}-stable
 git checkout -b fix/rollback-based-fix
 ```
 ### 3. Make Necessary Changes
 Implement the fix based on the stable version. Don't update version numbers yet.
 ### 4. Test the Changes
 Test thoroughly to ensure the fix resolves the issues.
 ### 5. When Confirmed Working
 Create a version branch with an incremented patch version and update all version numbers as described in the "Creating a Version Branch" section.
--- a/.ai-workflows/local-env-vars.md
+++ b/.ai-workflows/local-env-vars.md
@ -0,0 +1,19 @@
 # Local Development Environment Variables
 This file contains important paths and URLs for local development.
 ## Repository Paths
 - Local development repository: ~/Git/wp-fix-plugin-does-not-exist-notices
 - LocalWP plugin testing site storage: ~/Local/plugin-testing/app/wp-fix-plugin-does-not-exist-notices
 - LocalWP plugin testing site configuration: ~/Local/plugin-testing/conf/
 ## URLs
 - LocalWP plugin testing URL: http://plugin-testing.local/
 - PHP details: http://plugin-testing.local/local-phpinfo.php
 - XDebug info: http://plugin-testing.local/local-xdebuginfo.php
 - Adminer Evo: http://localhost:10010/?username=root&db=local
 - Mailpit: http://localhost:10000/
 ## Build and Deploy Scripts
 - Build script: ~/Git/wp-fix-plugin-does-not-exist-notices/build.sh
 - Local deploy script: ~/Git/wp-fix-plugin-does-not-exist-notices/deploy-local.sh
--- a/.wiki/Home.md
+++ b/.wiki/Home.md
@ -1,35 +1,41 @@
 # WordPress Plugin Starter Template
-Welcome to the WordPress Plugin Starter Template wiki! This documentation provides comprehensive information about using, customizing, and extending the template for your WordPress plugin development.
+Welcome to the documentation wiki for the WordPress Plugin Starter Template.
-## Overview
+This template provides a solid foundation for developing WordPress plugins with best practices for AI-assisted development.
-The WordPress Plugin Starter Template provides a solid foundation for developing WordPress plugins with AI assistance. It includes a well-structured codebase, documentation templates, and best practices to help you create high-quality WordPress plugins efficiently.
+## Quick Links
-## For Users
+- [Starter Prompt](Starter-Prompt)
 - [Installation Guide](Installation-Guide)
 - [Usage Instructions](Usage-Instructions)
 - [Frequently Asked Questions](Frequently-Asked-Questions)
 - [Contributing](Contributing)
 - [Changelog](Changelog)
- [Installation Guide](Installation-Guide): How to install and set up the plugin
+## About This Template
 - [Usage Instructions](Usage-Instructions): How to use the plugin's features
 - [Frequently Asked Questions](Frequently-Asked-Questions): Common questions and answers
 - [Troubleshooting](Troubleshooting): Solutions to common issues
-## For Developers
+The WordPress Plugin Starter Template is designed to help developers quickly create new WordPress plugins with a solid foundation of best practices. It incorporates modern coding standards, comprehensive documentation, and AI-assisted development workflows.
- [Architecture Overview](Architecture-Overview): Understanding the plugin's structure
+This template is based on the experience gained from developing the "Fix 'Plugin file does not exist' Notices" plugin and other successful WordPress plugins.
 - [Customization Guide](Customization-Guide): How to customize the template for your needs
 - [Extending the Plugin](Extending-the-Plugin): Adding new features and functionality
 - [Coding Standards](Coding-Standards): Coding standards and best practices
 - [Release Process](Release-Process): How to create and publish releases
-## For AI Assistants
+## Key Features
- [AI Workflow Documentation](AI-Workflow-Documentation): Guidelines for AI-assisted development
+- **Object-Oriented Architecture**: Well-structured, maintainable code using OOP principles
 - **Namespace Support**: Modern PHP namespacing for better organization and avoiding conflicts
 - **Comprehensive Documentation**: Detailed documentation for both users and developers
 - **Testing Framework**: PHPUnit setup for unit testing
 - **Internationalization Ready**: Full support for translation and localization
 - **Update Source Selection**: Choose between WordPress.org, GitHub, or Gitea for plugin updates
 - **AI Workflow Documentation**: Detailed guides for AI-assisted development
 - **Wiki Documentation**: Ready-to-use wiki structure for comprehensive documentation
-## Additional Resources
+## Getting Started
- [Changelog](Changelog): History of changes and updates
+To get started with this template, check out the [Starter Prompt](Starter-Prompt) for a comprehensive guide on customizing the template for your specific plugin needs.
 - [Contributing](Contributing): How to contribute to the project
-## Credits
+**Important**: For the best AI assistance, add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context. In most AI IDEs, you can pin these files to ensure they're considered in each message.
-This template is maintained by [WPALLSTARS](https://www.wpallstars.com) and is based on the experience and best practices developed while creating the [Fix 'Plugin file does not exist' Notices](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices) plugin.
+## Support
 If you encounter any issues or have questions about the template, please check the [Frequently Asked Questions](Frequently-Asked-Questions) section. If you still need help, you can [open an issue](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/issues) on GitHub.
--- a/.wiki/Starter-Prompt.md
+++ b/.wiki/Starter-Prompt.md
@ -0,0 +1,190 @@
 # WordPress Plugin Starter Template - AI Assistant Prompt
 This document provides a comprehensive prompt to help you get started with creating your own WordPress plugin using this starter template with the assistance of AI tools like GitHub Copilot, Claude, or ChatGPT.
 ## Important: Optimize AI Context
 **Before starting, add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context.** In most AI IDEs, you can pin these files to ensure they're considered in each message. This will help the AI understand the project structure and follow the established best practices.
 ## Initial Setup Prompt
 Use the following prompt to guide the AI assistant in helping you set up your new plugin based on this template:
 ```
 I'm creating a new WordPress plugin based on the wp-plugin-starter-template-for-ai-coding template. Please help me customize this template for my specific plugin needs.
 Here are the details for my new plugin:
 - Plugin Name: [YOUR PLUGIN NAME]
 - Plugin Slug: [YOUR-PLUGIN-SLUG]
 - Text Domain: [your-plugin-text-domain]
 - Namespace: [VENDOR]\[PluginName]
 - Description: [BRIEF DESCRIPTION OF YOUR PLUGIN]
 - Version: 0.1.0 (starting version)
 - Author: [YOUR NAME/ORGANIZATION]
 - Author URI: [YOUR WEBSITE]
 - License: GPL-2.0+ (or specify another compatible license)
 - Requires WordPress: [MINIMUM WP VERSION, e.g., 5.0]
 - Requires PHP: [MINIMUM PHP VERSION, e.g., 7.0]
 - GitHub Repository: [YOUR GITHUB REPO URL]
 - Gitea Repository (if applicable): [YOUR GITEA REPO URL]
 I need help with the following tasks:
 1. Updating all template placeholders with my plugin information
 2. Customizing the plugin structure for my specific needs
 3. Setting up the initial functionality for my plugin
 I've added the .ai-assistant.md and .ai-workflows/ directory to the chat context to ensure you have all the necessary information about the project structure and best practices.
 Please guide me through this process step by step, starting with identifying all files that need to be updated with my plugin information.
 ```
 ## Files That Need Updating
 The AI will help you identify and update the following files with your plugin information:
 1. **Main Plugin File**: Rename `wp-plugin-starter-template.php` to `your-plugin-slug.php` and update all plugin header information
 2. **README.md**: Update with your plugin details, features, and installation instructions
 3. **readme.txt**: Update WordPress.org plugin repository information
 4. **CHANGELOG.md**: Initialize with your starting version
 5. **composer.json**: Update package name and description
 6. **languages/pot file**: Rename and update the POT file
 7. **.github/workflows/**: Update GitHub Actions workflows with your repository information
 8. **.wiki/**: Update wiki documentation with your plugin information
 9. **.ai-assistant.md**: Update AI assistant guidance for your specific plugin
 10. **includes/plugin.php**: Update namespace and class references
 11. **includes/core.php**: Update namespace and customize core functionality
 12. **admin/lib/admin.php**: Update namespace and customize admin functionality
 ## Customization Process
 After providing the initial information, follow this process with your AI assistant:
 ### 1. File Renaming
 Ask the AI to help you identify all files that need to be renamed:
 ```
 Please list all files that need to be renamed to match my plugin slug, and provide the commands to rename them.
 ```
 ### 2. Namespace Updates
 Ask the AI to help you update all namespace references:
 ```
 Please help me update all namespace references from WPALLSTARS\PluginStarterTemplate to [VENDOR]\[PluginName] throughout the codebase.
 ```
 ### 3. Text Domain Updates
 Ask the AI to help you update all text domain references:
 ```
 Please help me update all text domain references from 'wp-plugin-starter-template' to '[your-plugin-text-domain]' throughout the codebase.
 ```
 ### 4. Function Prefix Updates
 Ask the AI to help you update any function prefixes:
 ```
 Please help me update any function prefixes from 'wpst_' to '[your_prefix]_' throughout the codebase.
 ```
 ### 5. Customizing Core Functionality
 Ask the AI to help you customize the core functionality for your specific plugin needs:
 ```
 Now I'd like to customize the core functionality for my plugin. Here's what my plugin should do:
 [DESCRIBE YOUR PLUGIN'S CORE FUNCTIONALITY]
 Please help me modify the includes/core.php file to implement this functionality.
 ```
 ### 6. Customizing Admin Interface
 Ask the AI to help you customize the admin interface for your specific plugin needs:
 ```
 I'd like to customize the admin interface for my plugin. Here's what I need in the admin area:
 [DESCRIBE YOUR PLUGIN'S ADMIN INTERFACE NEEDS]
 Please help me modify the admin/lib/admin.php file and any other necessary files to implement this.
 ```
 ### 7. Testing Setup
 Ask the AI to help you set up testing for your plugin:
 ```
 Please help me update the testing setup to match my plugin's namespace and functionality. I want to ensure I have proper test coverage for the core features.
 ```
 ## Additional Customization Areas
 Depending on your plugin's needs, you might want to ask the AI for help with:
 1. **Custom Post Types**: Setting up custom post types and taxonomies
 2. **Settings API**: Implementing WordPress Settings API for your plugin options
 3. **Shortcodes**: Creating shortcodes for front-end functionality
 4. **Widgets**: Developing WordPress widgets
 5. **REST API**: Adding custom REST API endpoints
 6. **Blocks**: Creating Gutenberg blocks
 7. **Internationalization**: Ensuring proper i18n setup
 8. **Database Tables**: Creating custom database tables if needed
 9. **Cron Jobs**: Setting up WordPress cron jobs
 10. **User Roles and Capabilities**: Managing custom user roles and capabilities
 ## Final Review
 Once you've completed the customization, ask the AI to help you review everything:
 ```
 Please help me review all the changes we've made to ensure:
 1. All template placeholders have been replaced with my plugin information
 2. All namespaces, text domains, and function prefixes have been updated consistently
 3. The plugin structure matches my specific needs
 4. The initial functionality is properly implemented
 5. All documentation (README.md, readme.txt, wiki) is updated and consistent
 Are there any issues or inconsistencies that need to be addressed?
 ```
 ## Building and Testing
 Finally, ask the AI to guide you through building and testing your plugin:
 ```
 Please guide me through the process of building and testing my plugin:
 1. How do I use the build script to create a deployable version?
 2. What tests should I run to ensure everything is working correctly?
 3. How do I set up a local testing environment?
 4. What should I check before releasing the first version?
 ```
 ## Optimizing AI Assistance
 To ensure the AI assistant has all the necessary context about your plugin's structure and best practices:
 ```
 Please add the .ai-assistant.md and .ai-workflows/ directory to your AI IDE chat context. In most AI IDEs, you can pin these files to ensure they're considered in each message. This will help the AI understand the project structure and follow the established best practices.
 ```
 ## Remember
 - This template is designed to be a starting point. Feel free to add, remove, or modify components as needed for your specific plugin.
 - The AI assistant can help you understand the existing code and make appropriate modifications, but you should review all changes to ensure they meet your requirements.
 - Always test your plugin thoroughly before releasing it.
 - Keep documentation updated as you develop your plugin.
 - Pin the .ai-assistant.md and .ai-workflows/ files in your AI IDE chat to ensure the AI has the necessary context for each interaction.
 ## Credits
 This plugin is based on the [WordPress Plugin Starter Template for AI Coding](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding) by WPALLSTARS.
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@ -1,5 +1,27 @@
 All notable changes to this project should be documented both here and in the main Readme files.
 #### [0.1.3] - 2025-04-19
 #### Added
 - Improved AI IDE context recommendations in documentation
 - Enhanced Starter Prompt with guidance on pinning .ai-assistant.md and .ai-workflows/
 #### Changed
 - Updated README.md and readme.txt with AI IDE context recommendations
 - Improved documentation for AI-assisted development
 - Moved Starter Prompt to the wiki for better organization
 #### [0.1.2] - 2025-04-18
 #### Added
 - STARTER-PROMPT.md with comprehensive guide for customizing the template
 - Additional AI workflow files for better development guidance
 #### Changed
 - Updated documentation files with improved instructions
 #### [0.1.1] - 2025-04-18
 #### Changed
 - Updated LICENSE file with correct GPL-2.0 text
 #### [0.1.0] - 2025-04-17
 #### Added
 - Initial release with basic template structure
--- a/345
+++ b/345
@ -1,7 +1,338 @@
-<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
+                    GNU GENERAL PUBLIC LICENSE
-<html><head>
+                       Version 2, June 1991
-<title>302 Found</title>
+
-</head><body>
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
-<h1>Found</h1>
+ <https://fsf.org/>
-<p>The document has moved <a href="https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt">here</a>.</p>
+ Everyone is permitted to copy and distribute verbatim copies
-</body></html>
+ of this license document, but changing it is not allowed.
                            Preamble
  The licenses for most software are designed to take away your
 freedom to share and change it.  By contrast, the GNU General Public
 License is intended to guarantee your freedom to share and change free
 software--to make sure the software is free for all its users.  This
 General Public License applies to most of the Free Software
 Foundation's software and to any other program whose authors commit to
 using it.  (Some other Free Software Foundation software is covered by
 the GNU Lesser General Public License instead.)  You can apply it to
 your programs, too.
  When we speak of free software, we are referring to freedom, not
 price.  Our General Public Licenses are designed to make sure that you
 have the freedom to distribute copies of free software (and charge for
 this service if you wish), that you receive source code or can get it
 if you want it, that you can change the software or use pieces of it
 in new free programs; and that you know you can do these things.
  To protect your rights, we need to make restrictions that forbid
 anyone to deny you these rights or to ask you to surrender the rights.
 These restrictions translate to certain responsibilities for you if you
 distribute copies of the software, or if you modify it.
  For example, if you distribute copies of such a program, whether
 gratis or for a fee, you must give the recipients all the rights that
 you have.  You must make sure that they, too, receive or can get the
 source code.  And you must show them these terms so they know their
 rights.
  We protect your rights with two steps: (1) copyright the software, and
 (2) offer you this license which gives you legal permission to copy,
 distribute and/or modify the software.
  Also, for each author's protection and ours, we want to make certain
 that everyone understands that there is no warranty for this free
 software.  If the software is modified by someone else and passed on, we
 want its recipients to know that what they have is not the original, so
 that any problems introduced by others will not reflect on the original
 authors' reputations.
  Finally, any free program is threatened constantly by software
 patents.  We wish to avoid the danger that redistributors of a free
 program will individually obtain patent licenses, in effect making the
 program proprietary.  To prevent this, we have made it clear that any
 patent must be licensed for everyone's free use or not licensed at all.
  The precise terms and conditions for copying, distribution and
 modification follow.
                    GNU GENERAL PUBLIC LICENSE
   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
  0. This License applies to any program or other work which contains
 a notice placed by the copyright holder saying it may be distributed
 under the terms of this General Public License.  The "Program", below,
 refers to any such program or work, and a "work based on the Program"
 means either the Program or any derivative work under copyright law:
 that is to say, a work containing the Program or a portion of it,
 either verbatim or with modifications and/or translated into another
 language.  (Hereinafter, translation is included without limitation in
 the term "modification".)  Each licensee is addressed as "you".
 Activities other than copying, distribution and modification are not
 covered by this License; they are outside its scope.  The act of
 running the Program is not restricted, and the output from the Program
 is covered only if its contents constitute a work based on the
 Program (independent of having been made by running the Program).
 Whether that is true depends on what the Program does.
  1. You may copy and distribute verbatim copies of the Program's
 source code as you receive it, in any medium, provided that you
 conspicuously and appropriately publish on each copy an appropriate
 copyright notice and disclaimer of warranty; keep intact all the
 notices that refer to this License and to the absence of any warranty;
 and give any other recipients of the Program a copy of this License
 along with the Program.
 You may charge a fee for the physical act of transferring a copy, and
 you may at your option offer warranty protection in exchange for a fee.
  2. You may modify your copy or copies of the Program or any portion
 of it, thus forming a work based on the Program, and copy and
 distribute such modifications or work under the terms of Section 1
 above, provided that you also meet all of these conditions:
    a) You must cause the modified files to carry prominent notices
    stating that you changed the files and the date of any change.
    b) You must cause any work that you distribute or publish, that in
    whole or in part contains or is derived from the Program or any
    part thereof, to be licensed as a whole at no charge to all third
    parties under the terms of this License.
    c) If the modified program normally reads commands interactively
    when run, you must cause it, when started running for such
    interactive use in the most ordinary way, to print or display an
    announcement including an appropriate copyright notice and a
    notice that there is no warranty (or else, saying that you provide
    a warranty) and that users may redistribute the program under
    these conditions, and telling the user how to view a copy of this
    License.  (Exception: if the Program itself is interactive but
    does not normally print such an announcement, your work based on
    the Program is not required to print an announcement.)
 These requirements apply to the modified work as a whole.  If
 identifiable sections of that work are not derived from the Program,
 and can be reasonably considered independent and separate works in
 themselves, then this License, and its terms, do not apply to those
 sections when you distribute them as separate works.  But when you
 distribute the same sections as part of a whole which is a work based
 on the Program, the distribution of the whole must be on the terms of
 this License, whose permissions for other licensees extend to the
 entire whole, and thus to each and every part regardless of who wrote it.
 Thus, it is not the intent of this section to claim rights or contest
 your rights to work written entirely by you; rather, the intent is to
 exercise the right to control the distribution of derivative or
 collective works based on the Program.
 In addition, mere aggregation of another work not based on the Program
 with the Program (or with a work based on the Program) on a volume of
 a storage or distribution medium does not bring the other work under
 the scope of this License.
  3. You may copy and distribute the Program (or a work based on it,
 under Section 2) in object code or executable form under the terms of
 Sections 1 and 2 above provided that you also do one of the following:
    a) Accompany it with the complete corresponding machine-readable
    source code, which must be distributed under the terms of Sections
    1 and 2 above on a medium customarily used for software interchange; or,
    b) Accompany it with a written offer, valid for at least three
    years, to give any third party, for a charge no more than your
    cost of physically performing source distribution, a complete
    machine-readable copy of the corresponding source code, to be
    distributed under the terms of Sections 1 and 2 above on a medium
    customarily used for software interchange; or,
    c) Accompany it with the information you received as to the offer
    to distribute corresponding source code.  (This alternative is
    allowed only for noncommercial distribution and only if you
    received the program in object code or executable form with such
    an offer, in accord with Subsection b above.)
 The source code for a work means the preferred form of the work for
 making modifications to it.  For an executable work, complete source
 code means all the source code for all modules it contains, plus any
 associated interface definition files, plus the scripts used to
 control compilation and installation of the executable.  However, as a
 special exception, the source code distributed need not include
 anything that is normally distributed (in either source or binary
 form) with the major components (compiler, kernel, and so on) of the
 operating system on which the executable runs, unless that component
 itself accompanies the executable.
 If distribution of executable or object code is made by offering
 access to copy from a designated place, then offering equivalent
 access to copy the source code from the same place counts as
 distribution of the source code, even though third parties are not
 compelled to copy the source along with the object code.
  4. You may not copy, modify, sublicense, or distribute the Program
 except as expressly provided under this License.  Any attempt
 otherwise to copy, modify, sublicense or distribute the Program is
 void, and will automatically terminate your rights under this License.
 However, parties who have received copies, or rights, from you under
 this License will not have their licenses terminated so long as such
 parties remain in full compliance.
  5. You are not required to accept this License, since you have not
 signed it.  However, nothing else grants you permission to modify or
 distribute the Program or its derivative works.  These actions are
 prohibited by law if you do not accept this License.  Therefore, by
 modifying or distributing the Program (or any work based on the
 Program), you indicate your acceptance of this License to do so, and
 all its terms and conditions for copying, distributing or modifying
 the Program or works based on it.
  6. Each time you redistribute the Program (or any work based on the
 Program), the recipient automatically receives a license from the
 original licensor to copy, distribute or modify the Program subject to
 these terms and conditions.  You may not impose any further
 restrictions on the recipients' exercise of the rights granted herein.
 You are not responsible for enforcing compliance by third parties to
 this License.
  7. If, as a consequence of a court judgment or allegation of patent
 infringement or for any other reason (not limited to patent issues),
 conditions are imposed on you (whether by court order, agreement or
 otherwise) that contradict the conditions of this License, they do not
 excuse you from the conditions of this License.  If you cannot
 distribute so as to satisfy simultaneously your obligations under this
 License and any other pertinent obligations, then as a consequence you
 may not distribute the Program at all.  For example, if a patent
 license would not permit royalty-free redistribution of the Program by
 all those who receive copies directly or indirectly through you, then
 the only way you could satisfy both it and this License would be to
 refrain entirely from distribution of the Program.
 If any portion of this section is held invalid or unenforceable under
 any particular circumstance, the balance of the section is intended to
 apply and the section as a whole is intended to apply in other
 circumstances.
 It is not the purpose of this section to induce you to infringe any
 patents or other property right claims or to contest validity of any
 such claims; this section has the sole purpose of protecting the
 integrity of the free software distribution system, which is
 implemented by public license practices.  Many people have made
 generous contributions to the wide range of software distributed
 through that system in reliance on consistent application of that
 system; it is up to the author/donor to decide if he or she is willing
 to distribute software through any other system and a licensee cannot
 impose that choice.
 This section is intended to make thoroughly clear what is believed to
 be a consequence of the rest of this License.
  8. If the distribution and/or use of the Program is restricted in
 certain countries either by patents or by copyrighted interfaces, the
 original copyright holder who places the Program under this License
 may add an explicit geographical distribution limitation excluding
 those countries, so that distribution is permitted only in or among
 countries not thus excluded.  In such case, this License incorporates
 the limitation as if written in the body of this License.
  9. The Free Software Foundation may publish revised and/or new versions
 of the General Public License from time to time.  Such new versions will
 be similar in spirit to the present version, but may differ in detail to
 address new problems or concerns.
 Each version is given a distinguishing version number.  If the Program
 specifies a version number of this License which applies to it and "any
 later version", you have the option of following the terms and conditions
 either of that version or of any later version published by the Free
 Software Foundation.  If the Program does not specify a version number of
 this License, you may choose any version ever published by the Free Software
 Foundation.
  10. If you wish to incorporate parts of the Program into other free
 programs whose distribution conditions are different, write to the author
 to ask for permission.  For software which is copyrighted by the Free
 Software Foundation, write to the Free Software Foundation; we sometimes
 make exceptions for this.  Our decision will be guided by the two goals
 of preserving the free status of all derivatives of our free software and
 of promoting the sharing and reuse of software generally.
                            NO WARRANTY
  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
 PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
 REPAIR OR CORRECTION.
  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
 POSSIBILITY OF SUCH DAMAGES.
                     END OF TERMS AND CONDITIONS
            How to Apply These Terms to Your New Programs
  If you develop a new program, and you want it to be of the greatest
 possible use to the public, the best way to achieve this is to make it
 free software which everyone can redistribute and change under these terms.
  To do so, attach the following notices to the program.  It is safest
 to attach them to the start of each source file to most effectively
 convey the exclusion of warranty; and each file should have at least
 the "copyright" line and a pointer to where the full notice is found.
    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>
    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.
    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.
    You should have received a copy of the GNU General Public License along
    with this program; if not, see <https://www.gnu.org/licenses/>.
 Also add information on how to contact you by electronic and paper mail.
 If the program is interactive, make it output a short notice like this
 when it starts in an interactive mode:
    Gnomovision version 69, Copyright (C) year name of author
    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.
 The hypothetical commands `show w' and `show c' should show the appropriate
 parts of the General Public License.  Of course, the commands you use may
 be called something other than `show w' and `show c'; they could even be
 mouse-clicks or menu items--whatever suits your program.
 You should also get your employer (if you work as a programmer) or your
 school, if any, to sign a "copyright disclaimer" for the program, if
 necessary.  Here is a sample; alter the names:
  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
  `Gnomovision' (which makes passes at compilers) written by James Hacker.
  <signature of Moe Ghoul>, 1 April 1989
  Moe Ghoul, President of Vice
 This General Public License does not permit incorporating your program into
 proprietary programs.  If your program is a subroutine library, you may
 consider it more useful to permit linking proprietary applications with the
 library.  If this is what you want to do, use the GNU Lesser General
 Public License instead of this License.
--- a/README.md
+++ b/README.md
@ -1,142 +1,224 @@
 # WordPress Plugin Starter Template for AI Coding
 [![License](https://img.shields.io/badge/license-GPL--2.0%2B-blue.svg)](https://www.gnu.org/licenses/gpl-2.0.html)
 A comprehensive starter template for WordPress plugins with best practices for AI-assisted development.
 [![WordPress Plugin Version](https://img.shields.io/wordpress/plugin/v/wp-plugin-starter-template-for-ai-coding)](https://wordpress.org/plugins/wp-plugin-starter-template-for-ai-coding/)
 [![WordPress Plugin Rating](https://img.shields.io/wordpress/plugin/rating/wp-plugin-starter-template-for-ai-coding)](https://wordpress.org/plugins/wp-plugin-starter-template-for-ai-coding/)
 [![WordPress Plugin Downloads](https://img.shields.io/wordpress/plugin/dt/wp-plugin-starter-template-for-ai-coding)](https://wordpress.org/plugins/wp-plugin-starter-template-for-ai-coding/)
 [![License](https://img.shields.io/github/license/wpallstars/wp-plugin-starter-template-for-ai-coding)](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/blob/main/LICENSE)
 ## Description
-The WordPress Plugin Starter Template provides a solid foundation for developing WordPress plugins with AI assistance. It includes a well-structured codebase, documentation templates, and best practices to help you create high-quality WordPress plugins efficiently.
+The WordPress Plugin Starter Template provides a solid foundation for developing WordPress plugins. It incorporates best practices, modern coding standards, and a comprehensive structure that makes it easy to get started with plugin development.
 This template is based on the experience gained from developing the "Fix 'Plugin file does not exist' Notices" plugin and other successful WordPress plugins.
 ### Key Features
- **Well-structured codebase** following WordPress coding standards
+* **Object-Oriented Architecture**: Well-structured, maintainable code using OOP principles
- **Modular architecture** for easy maintenance and extension
+* **Namespace Support**: Modern PHP namespacing for better organization and avoiding conflicts
- **Comprehensive documentation** templates for both users and developers
+* **Comprehensive Documentation**: Detailed documentation for both users and developers
- **AI-friendly workflows** with detailed guidance for AI assistants
+* **Testing Framework**: PHPUnit setup for unit testing
- **Git integration** with GitHub and Gitea support
+* **Internationalization Ready**: Full support for translation and localization
- **Update mechanism** with multiple source options (WordPress.org, GitHub, Gitea)
+* **Update Source Selection**: Choose between WordPress.org, GitHub, or Gitea for plugin updates
- **Internationalization** ready with proper text domain setup
+* **AI Workflow Documentation**: Detailed guides for AI-assisted development
- **Admin interface** components for building settings pages
+* **Wiki Documentation**: Ready-to-use wiki structure for comprehensive documentation
-### For Developers
+### How to Use This Template
-This template is designed to be a starting point for your WordPress plugin development. It provides:
+1. Clone or download this repository
 2. **Important**: Begin by reading the [Starter Prompt](.wiki/Starter-Prompt.md) file for detailed instructions
 3. Add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context (pin them if possible)
 4. Use the prompt in the Starter Prompt file to guide the AI in customizing the template for your plugin
 5. Rename files and update namespaces to match your plugin
 6. Customize the functionality for your specific needs
 7. Update documentation to reflect your plugin's features
 8. Build and test your plugin
- A clean, well-organized file structure
+### AI-Assisted Development
- OOP approach with namespaced classes
+
- Separation of concerns (admin, core functionality)
+This template includes comprehensive documentation for AI-assisted development:
- Documentation templates for wiki and readme files
+
- GitHub Actions workflows for automated tasks
+* **.ai-assistant.md**: Guide for AI assistants to understand the project structure
- AI workflow documentation for AI-assisted development
+* **.ai-workflows/**: Detailed workflow documentation for common development tasks
 * **Starter Prompt**: Comprehensive prompt for AI tools to help customize the template (available in the [wiki](.wiki/Starter-Prompt.md))
 **Important**: For the best AI assistance, add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context. In most AI IDEs, you can pin these files to ensure they're considered in each message.
 ## Installation
 ### From GitHub
 1. Download the latest release from the [GitHub repository](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/releases)
 2. Upload the plugin files to the `/wp-content/plugins/wp-plugin-starter-template` directory, or install the plugin through the WordPress plugins screen directly
 3. Activate the plugin through the 'Plugins' screen in WordPress
 ### Using as a Template for Your Plugin
 1. Clone or download this repository
-2. Rename the plugin directory and files to match your plugin name
+2. Read the [Starter Prompt](.wiki/Starter-Prompt.md) file for detailed instructions
-3. Update namespaces, function prefixes, and text domains
+3. Add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context
-4. Update plugin headers in the main PHP file
+4. Use the prompt in the Starter Prompt file to guide the AI in customizing the template
-5. Customize the functionality to meet your specific needs
+5. Rename files and update namespaces to match your plugin
-6. Update documentation to reflect your plugin's features
+6. Customize the functionality for your specific needs
 7. Update documentation to reflect your plugin's features
 8. Build and test your plugin
 ## Usage
-### Basic Structure
+### Getting Started
-The template follows a modular structure:
+To get started with this template, follow these steps:
- `wp-plugin-starter-template.php`: Main plugin file with plugin headers
+1. In your terminal, navigate to the folder you keep you Git repositories (eg: `~/Git/`), then clone this repository to your local machine:
- `includes/`: Core plugin functionality
+   ```bash
-  - `plugin.php`: Main plugin class that initializes everything
+   git clone https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding.git
-  - `core.php`: Core functionality class
+   ```
  - `updater.php`: Update mechanism for multiple sources
 - `admin/`: Admin-specific functionality
  - `lib/`: Admin classes
  - `css/`: Admin stylesheets
  - `js/`: Admin JavaScript files
 - `languages/`: Translation files
 - `.github/workflows/`: GitHub Actions workflows
 - `.ai-workflows/`: Documentation for AI assistants
 - `.wiki/`: Wiki documentation templates
-### Customizing for Your Plugin
+2. Open the [Starter Prompt](.wiki/Starter-Prompt.md) file and follow the instructions to customize the template for your plugin.
-1. **Rename Files and Update Namespaces**:
+3. Add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context.
   - Rename `wp-plugin-starter-template.php` to your plugin name
   - Update the namespace from `WPALLSTARS\PluginStarterTemplate` to your own
   - Update text domain from `wp-plugin-starter-template` to your own
-2. **Update Plugin Headers**:
+4. Use an AI assistant like GitHub Copilot, Claude, or ChatGPT to help you customize the template by providing the prompt from the Starter Prompt file.
   - Edit the plugin headers in the main PHP file
   - Update GitHub/Gitea repository URLs
-3. **Customize Functionality**:
+### Using with Git Updater
   - Modify the core functionality in `includes/core.php`
   - Add your own classes as needed
   - Customize admin interfaces in the `admin/` directory
-4. **Update Documentation**:
+If you've installed this plugin from GitHub or Gitea, you'll need Git Updater to receive updates:
   - Update README.md and readme.txt with your plugin information
   - Customize wiki documentation in the `.wiki/` directory
-## Documentation
+1. Install the Git Updater plugin from [git-updater.com/git-updater/](https://git-updater.com/git-updater/)
 2. Go to Settings > Git Updater > Remote Management
 3. Click the "Refresh Cache" button to ensure Git Updater recognizes the latest version
 4. Updates will now appear in your WordPress dashboard when available
-Comprehensive documentation is available in the [Wiki](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki).
+### Choosing Your Update Source
-### For Users
+This template includes functionality that allows users to choose where they want to receive updates from:
- [Installation Guide](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Installation-Guide)
+1. In the Plugins list, find your plugin
- [Usage Instructions](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Usage-Instructions)
+2. Click the "Update Source" link next to the plugin
- [Frequently Asked Questions](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Frequently-Asked-Questions)
+3. Select your preferred update source:
- [Troubleshooting](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Troubleshooting)
+   - **WordPress.org**: Updates from the official WordPress.org repository
   - **GitHub**: Updates directly from the GitHub repo
   - **Gitea**: Updates directly from the Gitea repo
 4. Click "Save" to apply your preference
-### For Developers
+## Frequently Asked Questions
- [Architecture Overview](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Architecture-Overview)
+### How do I customize this template for my plugin?
 - [Extending the Plugin](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Extending-the-Plugin)
 - [Coding Standards](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Coding-Standards)
 - [Release Process](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Release-Process)
-### For AI Assistants
+See the [Starter Prompt](.wiki/Starter-Prompt.md) file for detailed instructions on customizing this template for your specific plugin needs. Make sure to add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context for the best results.
-The `.ai-assistant.md` file and `.ai-workflows/` directory contain detailed guidance for AI assistants working with this template. These resources help ensure consistent, high-quality code and documentation when using AI tools for development.
+### What files do I need to update with my plugin information?
 The main files you need to update include:
 1. Main plugin file (rename and update header)
 2. README.md
 3. readme.txt
 4. CHANGELOG.md
 5. composer.json
 6. languages/pot file
 7. .github/workflows/
 8. .wiki/
 9. .ai-assistant.md
 10. includes/plugin.php
 11. includes/core.php
 12. admin/lib/admin.php
 ### How do I build and test my plugin?
 Use the included build.sh script to create a deployable version of your plugin:
 ```bash
 ./build.sh {VERSION}
 ```
 This will create a ZIP file that you can install in WordPress.
 ### How do I add custom functionality to my plugin?
 Customize the includes/core.php file to implement your core functionality and the admin/lib/admin.php file for admin-specific functionality.
 ## Support & Feedback
 If you need help with this template, there are several ways to get support:
 * [GitHub Issues](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/issues)
 * [Gitea Issues](https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding/issues)
 ## Contributing
-Contributions are welcome! Please feel free to submit a pull request or open an issue on the [GitHub repository](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding).
+Contributions are welcome! Please feel free to submit a Pull Request.
-### Development Process
+1. Fork the repository on [GitHub](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/) or [Gitea](https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding/)
-
+2. Create your feature branch: `git checkout -b feature/amazing-feature`
-1. Fork the repository
+3. Commit your changes: `git commit -m 'Add some amazing feature'`
-2. Create a feature branch: `git checkout -b feature/your-feature-name`
+4. Push to the branch: `git push origin feature/amazing-feature`
 3. Make your changes and commit them: `git commit -m 'Add some feature'`
 4. Push to the branch: `git push origin feature/your-feature-name`
 5. Submit a pull request
-## Credits
+## Developers
-This template is maintained by [WPALLSTARS](https://www.wpallstars.com) and is based on the experience and best practices developed while creating the [Fix 'Plugin file does not exist' Notices](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices) plugin.
+### AI-Powered Development
 This repository is configured to work with various AI-powered development tools. You can use any of the following AI IDEs to contribute to this project:
 - [Augment Code](https://www.augmentcode.com/) - AI-powered coding assistant
 - [Cursor](https://cursor.com/) - AI-first code editor
 - [v0](https://v0.dev/) - AI-powered design and development tool
 - [Windsurf](https://www.windsurf.com/) - AI coding assistant
 - [Cline](https://cline.bot/) - AI terminal assistant
 - [Roo Code](https://roocode.com/) - AI pair programmer
 - [Loveable](https://lovable.dev/) - AI development environment
 - [Bolt](https://www.bolt.new/) - AI-powered code editor
 - [Cody](https://sourcegraph.com/cody) - Sourcegraph's AI coding assistant
 - [Continue](https://continue.dev/) - Open-source AI coding assistant
 The repository includes configuration files for all these tools to ensure a consistent development experience.
 ### Git Updater Integration
 This template is designed to work seamlessly with the Git Updater plugin for updates from GitHub and Gitea. To ensure proper integration:
 1. **Required Headers**: The plugin includes specific headers in the main plugin file that Git Updater uses to determine update sources and branches:
   ```php
   * GitHub Plugin URI: wpallstars/wp-plugin-starter-template-for-ai-coding
   * GitHub Branch: main
   * Primary Branch: main
   * Release Branch: main
   * Release Asset: true
   * Gitea Plugin URI: https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding
   * Gitea Branch: main
   ```
 2. **Tagging Releases**: When creating a new release, always tag it with the 'v' prefix (e.g., `v0.1.2`) to ensure GitHub Actions can create the proper release assets.
 3. **GitHub Actions**: The repository includes a GitHub Actions workflow that automatically builds the plugin and creates a release with the .zip file when a new tag is pushed.
 4. **Update Source Selection**: The template includes a feature that allows users to choose their preferred update source (WordPress.org, GitHub, or Gitea).
 For more information on Git Updater integration, see the [Git Updater Required Headers documentation](https://git-updater.com/knowledge-base/required-headers/).
 ## Changelog
 ### 0.1.3
 * Added: Improved AI IDE context recommendations in documentation
 * Enhanced: Starter Prompt with guidance on pinning .ai-assistant.md and .ai-workflows/
 * Moved: Starter Prompt to the wiki for better organization
 * Updated: README.md and readme.txt with AI IDE context recommendations
 * Improved: Documentation for AI-assisted development
 ### 0.1.2
 * Added: STARTER-PROMPT.md with comprehensive guide for customizing the template
 * Updated: Documentation files with improved instructions
 * Added: Additional AI workflow files for better development guidance
 ### 0.1.1
 * Updated: LICENSE file with correct GPL-2.0 text
 ### 0.1.0
 * Initial release with basic template structure
 * Added: Core plugin architecture with OOP approach
 * Added: Admin interface components and styling
 * Added: Update mechanism with multiple source options
 * Added: Documentation templates for users and developers
 * Added: AI workflow documentation for AI-assisted development
 * Added: GitHub Actions workflows for automated tasks
 * Added: Wiki documentation templates
 [View full changelog](CHANGELOG.md)
 ## License
 This project is licensed under the GPL-2.0+ License - see the [LICENSE](LICENSE) file for details.
-## Changelog
+## Credits
-### 0.1.0
+This template is based on the experience gained from developing the ["Fix 'Plugin file does not exist' Notices"](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices) plugin by WPALLSTARS.
 - Initial release with basic template structure
 - Added core plugin architecture
 - Added admin interface components
 - Added documentation templates
 - Added AI workflow documentation
--- a/languages/wp-plugin-starter-template.pot
+++ b/languages/wp-plugin-starter-template.pot
@ -2,14 +2,14 @@
 # This file is distributed under the GPL-2.0+.
 msgid ""
 msgstr ""
-"Project-Id-Version: WordPress Plugin Starter Template 0.1.0\n"
+"Project-Id-Version: WordPress Plugin Starter Template 0.1.1\n"
 "Report-Msgid-Bugs-To: https://wordpress.org/support/plugin/wp-plugin-starter-template\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL@li.org>\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
 "Content-Transfer-Encoding: 8bit\n"
-"POT-Creation-Date: 2025-04-17T00:00:00+00:00\n"
+"POT-Creation-Date: 2025-04-18T00:00:00+00:00\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "X-Generator: WP-CLI 2.9.0\n"
 "X-Domain: wp-plugin-starter-template\n"
--- a/readme.txt
+++ b/readme.txt
@ -1,11 +1,11 @@
-=== WordPress Plugin Starter Template ===
+=== WordPress Plugin Starter Template for AI Coding ===
-Contributors: wpallstars, your_wp_username
+Contributors: wpallstars
-Donate link: https://www.wpallstars.com
+Donate link: https://www.wpallstars.com/
 Tags: starter, template, boilerplate, plugin development, ai coding
 Requires at least: 5.0
 Tested up to: 6.4
 Requires PHP: 7.0
-Stable tag: 0.1.0
+Stable tag: 0.1.3
 License: GPL-2.0+
 License URI: https://www.gnu.org/licenses/gpl-2.0.html
@ -13,62 +13,117 @@ A comprehensive starter template for WordPress plugins with best practices for A
 == Description ==
-The WordPress Plugin Starter Template provides a solid foundation for developing WordPress plugins with AI assistance. It includes a well-structured codebase, documentation templates, and best practices to help you create high-quality WordPress plugins efficiently.
+The WordPress Plugin Starter Template provides a solid foundation for developing WordPress plugins. It incorporates best practices, modern coding standards, and a comprehensive structure that makes it easy to get started with plugin development.
 This template is based on the experience gained from developing the "Fix 'Plugin file does not exist' Notices" plugin and other successful WordPress plugins.
 = Key Features =
-* **Well-structured codebase** following WordPress coding standards
+* **Object-Oriented Architecture**: Well-structured, maintainable code using OOP principles
-* **Modular architecture** for easy maintenance and extension
+* **Namespace Support**: Modern PHP namespacing for better organization and avoiding conflicts
-* **Comprehensive documentation** templates for both users and developers
+* **Comprehensive Documentation**: Detailed documentation for both users and developers
-* **AI-friendly workflows** with detailed guidance for AI assistants
+* **Testing Framework**: PHPUnit setup for unit testing
-* **Git integration** with GitHub and Gitea support
+* **Internationalization Ready**: Full support for translation and localization
-* **Update mechanism** with multiple source options (WordPress.org, GitHub, Gitea)
+* **Update Source Selection**: Choose between WordPress.org, GitHub, or Gitea for plugin updates
-* **Internationalization** ready with proper text domain setup
+* **AI Workflow Documentation**: Detailed guides for AI-assisted development
-* **Admin interface** components for building settings pages
+* **Wiki Documentation**: Ready-to-use wiki structure for comprehensive documentation
-= For Developers =
+= How to Use This Template =
-This template is designed to be a starting point for your WordPress plugin development. It provides:
+1. Clone or download this repository
 2. **Important**: Begin by reading the Starter Prompt file in the wiki for detailed instructions
 3. Add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context (pin them if possible)
 4. Use the prompt in the Starter Prompt file to guide the AI in customizing the template for your plugin
 5. Rename files and update namespaces to match your plugin
 6. Customize the functionality for your specific needs
 7. Update documentation to reflect your plugin's features
 8. Build and test your plugin
-* A clean, well-organized file structure
+For detailed instructions, see the [Starter Prompt](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Starter-Prompt) file in the wiki.
 * OOP approach with namespaced classes
 * Separation of concerns (admin, core functionality)
 * Documentation templates for wiki and readme files
 * GitHub Actions workflows for automated tasks
 * AI workflow documentation for AI-assisted development
-= Credits =
+= AI-Assisted Development =
-This template is based on the experience and best practices developed while creating the [Fix 'Plugin file does not exist' Notices](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices) plugin.
+This template includes comprehensive documentation for AI-assisted development:
 * **.ai-assistant.md**: Guide for AI assistants to understand the project structure
 * **.ai-workflows/**: Detailed workflow documentation for common development tasks
 * **Starter Prompt**: Comprehensive prompt for AI tools to help customize the template (available in the wiki)
 **Important**: For the best AI assistance, add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context. In most AI IDEs, you can pin these files to ensure they're considered in each message.
 = Support & Feedback =
 If you need help with this template, there are several ways to get support:
 * [GitHub Issues](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/issues)
 * [Gitea Issues](https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding/issues)
 = Contributing =
 Contributions are welcome! Please feel free to submit a Pull Request.
 1. Fork the repository on [GitHub](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/) or [Gitea](https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding/)
 2. Create your feature branch: `git checkout -b feature/amazing-feature`
 3. Commit your changes: `git commit -m 'Add some amazing feature'`
 4. Push to the branch: `git push origin feature/amazing-feature`
 5. Submit a pull request
 == Installation ==
-1. Download the plugin zip file
+1. Clone or download this repository
-2. Log in to your WordPress admin dashboard
+2. Read the Starter Prompt file in the wiki for detailed instructions
-3. Go to Plugins > Add New
+3. Add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context
-4. Click the "Upload Plugin" button at the top of the page
+4. Use the prompt in the Starter Prompt file to guide the AI in customizing the template
-5. Select the zip file and click "Install Now"
+5. Rename files and update namespaces to match your plugin
-6. Activate the plugin through the 'Plugins' menu in WordPress
+6. Customize the functionality for your specific needs
 7. Update documentation to reflect your plugin's features
 8. Build and test your plugin
 For detailed instructions, see the [Starter Prompt](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Starter-Prompt) file in the wiki.
 == Frequently Asked Questions ==
-= How do I use this template? =
+= How do I customize this template for my plugin? =
-This template is meant to be a starting point for your own plugin development. You should:
+See the [Starter Prompt](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding/wiki/Starter-Prompt) file in the wiki for detailed instructions on customizing this template for your specific plugin needs. Make sure to add the .ai-assistant.md file and .ai-workflows/ directory to your AI IDE chat context for the best results.
-1. Copy the template files to your new plugin directory
+= What files do I need to update with my plugin information? =
 2. Rename files and update namespaces to match your plugin name
 3. Update plugin headers in the main PHP file
 4. Customize the functionality to meet your specific needs
 5. Update documentation to reflect your plugin's features
-= Is this template suitable for all types of plugins? =
+The main files you need to update include:
 1. Main plugin file (rename and update header)
 2. README.md
 3. readme.txt
 4. CHANGELOG.md
 5. composer.json
 6. languages/pot file
 7. .github/workflows/
 8. .wiki/
 9. .ai-assistant.md
 10. includes/plugin.php
 11. includes/core.php
 12. admin/lib/admin.php
-Yes, this template provides a solid foundation for most WordPress plugins. It's designed to be flexible and can be adapted for various types of plugins, from simple utilities to complex applications.
+= How do I build and test my plugin? =
-= How do I contribute to this template? =
+Use the included build.sh script to create a deployable version of your plugin:
-Contributions are welcome! Please feel free to submit a pull request or open an issue on the [GitHub repository](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding).
+```bash
 ./build.sh {VERSION}
 ```
 This will create a ZIP file that you can install in WordPress.
 = How do I add custom functionality to my plugin? =
 Customize the includes/core.php file to implement your core functionality and the admin/lib/admin.php file for admin-specific functionality.
 = How do I update the namespace for my plugin? =
 You'll need to update all namespace references from WPALLSTARS\PluginStarterTemplate to your own namespace throughout the codebase.
 = How do I update the text domain for my plugin? =
 You'll need to update all text domain references from 'wp-plugin-starter-template' to your own text domain throughout the codebase.
 == Screenshots ==
@ -76,43 +131,38 @@ Contributions are welcome! Please feel free to submit a pull request or open an
 == Changelog ==
 = 0.1.3 =
 * Added: Improved AI IDE context recommendations in documentation
 * Enhanced: Starter Prompt with guidance on pinning .ai-assistant.md and .ai-workflows/
 * Moved: Starter Prompt to the wiki for better organization
 * Updated: README.md and readme.txt with AI IDE context recommendations
 * Improved: Documentation for AI-assisted development
 = 0.1.2 =
 * Added: STARTER-PROMPT.md with comprehensive guide for customizing the template
 * Updated: Documentation files with improved instructions
 * Added: Additional AI workflow files for better development guidance
 = 0.1.1 =
 * Updated: LICENSE file with correct GPL-2.0 text
 = 0.1.0 =
 * Initial release with basic template structure
-* Added core plugin architecture
+* Added: Core plugin architecture with OOP approach
-* Added admin interface components
+* Added: Admin interface components and styling
-* Added documentation templates
+* Added: Update mechanism with multiple source options
-* Added AI workflow documentation
+* Added: Documentation templates for users and developers
 * Added: AI workflow documentation for AI-assisted development
 * Added: GitHub Actions workflows for automated tasks
 * Added: Wiki documentation templates
 == Upgrade Notice ==
 = 0.1.3 =
 Added improved AI IDE context recommendations and moved Starter Prompt to the wiki with guidance on pinning .ai-assistant.md and .ai-workflows/ files.
 = 0.1.1 =
 Updated LICENSE file with correct GPL-2.0 text.
 = 0.1.0 =
-Initial release of the WordPress Plugin Starter Template.
+Initial release with basic template structure and core functionality.
 == Development ==
 The development of this plugin follows these principles:
 1. **Clean Code**: Following WordPress coding standards and best practices
 2. **Modularity**: Keeping components separate and focused
 3. **Documentation**: Comprehensive documentation for both users and developers
 4. **Testing**: Thorough testing across different WordPress versions
 5. **Accessibility**: Ensuring the plugin is accessible to all users
 6. **Internationalization**: Making the plugin translatable
 = Development Resources =
 * [GitHub Repository](https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding)
 * [WordPress Plugin Development Handbook](https://developer.wordpress.org/plugins/)
 * [WordPress Coding Standards](https://developer.wordpress.org/coding-standards/)
 = Contributing =
 We welcome contributions to improve this template. Please feel free to:
 * Report bugs or issues
 * Suggest new features or improvements
 * Submit pull requests with bug fixes or enhancements
 == Credits ==
 This template is maintained by [WPALLSTARS](https://www.wpallstars.com) and is based on the experience and best practices developed while creating the [Fix 'Plugin file does not exist' Notices](https://github.com/wpallstars/wp-fix-plugin-does-not-exist-notices) plugin.
--- a/wp-plugin-starter-template.php
+++ b/wp-plugin-starter-template.php
@ -0,0 +1,38 @@
 <?php
 /**
 * Plugin Name: WordPress Plugin Starter Template
 * Plugin URI: https://www.wpallstars.com
 * Description: A comprehensive starter template for WordPress plugins with best practices for AI-assisted development.
 * Version: 0.1.3
 * Author: Your Name & The WPALLSTARS Team
 * Author URI: https://www.wpallstars.com
 * License: GPL-2.0+
 * License URI: http://www.gnu.org/licenses/gpl-2.0.txt
 * Text Domain: wp-plugin-starter-template
 * Domain Path: /languages
 * GitHub Plugin URI: wpallstars/wp-plugin-starter-template-for-ai-coding
 * GitHub Branch: main
 * Primary Branch: main
 * Release Branch: main
 * Release Asset: true
 * Requires at least: 5.0
 * Requires PHP: 7.0
 * Update URI: https://github.com/wpallstars/wp-plugin-starter-template-for-ai-coding
 *
 * Gitea Plugin URI: https://gitea.wpallstars.com/wpallstars/wp-plugin-starter-template-for-ai-coding
 * Gitea Branch: main
 * Gitea Languages: languages
 *
 * @package WPALLSTARS\PluginStarterTemplate
 */
 // If this file is called directly, abort.
 if (!defined('WPINC')) {
    die;
 }
 // Load the main plugin class
 require_once plugin_dir_path(__FILE__) . 'includes/plugin.php';
 // Initialize the plugin
 new WPALLSTARS\PluginStarterTemplate\Plugin(__FILE__, '0.1.3');
Author	SHA1	Message	Date
marcusquinn	843696d3a8	Remove STARTER-PROMPT.md from root directory as it's now in the wiki Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details Release / Build and Release (push) Has been cancelled Details	2025-04-18 04:25:02 +01:00
marcusquinn	269626438e	Update references to Starter Prompt to point to wiki version	2025-04-18 04:24:40 +01:00
marcusquinn	0e6f9639f4	Update STARTER-PROMPT.md with AI IDE context recommendations and add to wiki Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details Release / Build and Release (push) Has been cancelled Details Sync Wiki / Sync Wiki to GitHub (push) Has been cancelled Details	2025-04-18 04:12:49 +01:00
marcusquinn	0de0b2ef05	Update version to 0.1.3 with improved AI IDE context recommendations Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details	2025-04-18 04:04:44 +01:00
marcusquinn	342eefd471	Update documentation with AI IDE context recommendations and improve starter prompt Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details Release / Build and Release (push) Has been cancelled Details	2025-04-18 03:57:43 +01:00
marcusquinn	66758ac0f8	Update documentation and add starter prompt for template users Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details Release / Build and Release (push) Has been cancelled Details	2025-04-18 03:47:03 +01:00
marcusquinn	32697533ab	Update version numbers to 0.1.1 and add changelog entries Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details	2025-04-18 03:26:12 +01:00
marcusquinn	4a7798a8c2	Update LICENSE file with correct GPL-2.0 text Some checks failed Tests / PHP 7.0 (push) Has been cancelled Details Tests / PHP 7.4 (push) Has been cancelled Details Tests / PHP 8.0 (push) Has been cancelled Details Tests / Code Style (push) Has been cancelled Details Release / Build and Release (push) Has been cancelled Details	2025-04-18 03:19:16 +01:00