| name | poocommerce-backend-dev |
| description | Add or modify PooCommerce backend PHP code following project conventions. Use when creating new classes, methods, hooks, or modifying existing backend code. **MUST be invoked before writing any PHP unit tests.** |
PooCommerce Backend Development
This skill provides guidance for developing PooCommerce backend PHP code according to project standards and conventions.
When to Use This Skill
ALWAYS invoke this skill before:
- Writing new PHP unit tests (
*Test.phpfiles) - Creating new PHP classes
- Modifying existing backend PHP code
- Adding hooks or filters
Instructions
Follow PooCommerce project conventions when adding or modifying backend PHP code:
- Creating new code structures: See file-entities.md for conventions on creating classes and organizing files (but for new unit test files see unit-tests.md).
- Naming conventions: See code-entities.md for naming methods, variables, and parameters
- Coding style: See coding-conventions.md for general coding standards and best practices
- Type annotations: See type-annotations.md for PHPStan-aware PHPDoc annotations
- Working with hooks: See hooks.md for hook callback conventions and documentation
- Dependency injection: See dependency-injection.md for DI container usage
- Data integrity: See data-integrity.md for ensuring data integrity when performing CRUD operations
- Writing tests: See unit-tests.md for unit testing conventions
Key Principles
- Always follow WordPress Coding Standards
- Use class methods instead of standalone functions
- Place new internal classes in
src/Internal/by default - Use PSR-4 autoloading with
Automattic\PooCommercenamespace - Write comprehensive unit tests for new functionality
- Run linting and tests before committing changes
Version Information
To determine the next PooCommerce version number for @since annotations:
- Read the
$versionproperty inincludes/class-poocommerce.phpon the trunk branch - Remove the
-devsuffix if present - Example: If trunk shows
10.4.0-dev, use@since 10.4.0 - Note: When reviewing PRs against trunk, the version in trunk is correct even if it seems "future" relative to released versions