Provides WordPress coding standards, PHP/CSS/JS style guide, code linting and static analysis (phpcs, phpstan, rector, phpcbf). Use before writing or editing PHP, CSS, or JavaScript code, when fixing lint errors, running code quality tools, or reviewing code style compliance.
Installation
Details
Usage
After installing, this skill will be available to your AI coding assistant.
Verify installation:
skills listSkill Instructions
name: code-quality description: Provides WordPress coding standards, PHP/CSS/JS style guide, code linting and static analysis (phpcs, phpstan, rector, phpcbf). Use before writing or editing PHP, CSS, or JavaScript code, when fixing lint errors, running code quality tools, or reviewing code style compliance.
Code Quality Standards for Simple History
This skill provides code quality guidelines for the Simple History WordPress plugin, including PHP, CSS, and JavaScript standards, tooling commands, and best practices.
When to Use This Skill
Invoke this skill proactively before writing code to ensure compliance with project standards.
Trigger scenarios:
- Before writing or editing PHP code
- Before writing or editing CSS code
- Before writing or editing JavaScript code
- When running code quality tools (phpcs, phpstan, rector)
- When fixing lint errors or reviewing code style
Quick Reference
PHP Standards
- PHP Version: 7.4+ compatibility required
- WordPress Coding Standards: Official WordPress standards (see phpcs.xml.dist)
- No mb_ functions*: Use standard string functions
- Array syntax: Short syntax
[]notarray() - Control structures: Always use curly braces
{}, never colon syntax - Hook prefixes: Always use
sh,simplehistory, orsimple_history
CSS Standards
- Naming Convention: SuitCSS
- Prefix:
sh - Components:
sh-ComponentName(e.g.,sh-HelpSection,sh-LogEntry) - Subparts:
sh-ComponentName-subpart(e.g.,sh-LogEntry-author)
JavaScript
- Follow @wordpress/scripts conventions
- Text domain:
simple-history - Always use braces for if/else/for/while (no single-line statements)
Detailed Guidelines
PHP Code Style
See php-standards.md for detailed PHP style guide including:
- Happy path last pattern
- Early returns over else
- Ternary operator formatting
- Control structure syntax
Tooling Commands
See tooling.md for:
- phpcs (PHP_CodeSniffer) usage
- phpstan (static analysis) usage
- rector (code modernization) usage
- npm scripts for code quality
CSS Guidelines
See css-standards.md for SuitCSS naming conventions and examples.
JavaScript Guidelines
See js-standards.md for JavaScript code style.
Essential Principles
- Always escape output - Use WordPress escaping functions
- Prefix everything - Use
sh,simplehistory, orsimple_history - Follow WordPress conventions - The "WordPress Way"
- Run quality tools - Use phpcs, phpstan after significant changes
Design Principles
DRY - Don't Repeat Yourself
Extract shared logic when you have actual duplication (3+ occurrences). But don't preemptively create abstractions.
YAGNI - You Aren't Gonna Need It
Don't implement functionality until it's actually needed. Avoid:
- Creating abstractions for hypothetical future use cases
- Building helper functions for one-time operations
- Adding configurability "just in case"
- Designing for requirements that don't exist yet
Together: DRY says extract when you have real duplication. YAGNI says wait until you actually need it. Three similar lines of code is often better than a premature abstraction.
Related Files
phpcs.xml.dist- PHP_CodeSniffer configurationphpstan.neon- PHPStan configurationpackage.json- npm scripts for code quality
More by bonny
View allRun SQL queries against the WordPress development database. Use when querying database tables, inspecting Simple History events, checking WordPress data, debugging database issues, or when the user says "run query" or "check database".
Ensures WordPress.org compliance for freemium plugins (free vs premium features, license keys, trial limits, upselling). Prevents trialware violations. Use when adding premium features, implementing upsells, checking license keys, creating teasers, reviewing code before WordPress.org submission, or when the user mentions "premium", "upsell", or "freemium".
Add an entry to the changelog in readme.txt following the project's changelog format. Use when updating readme.txt, adding to Unreleased section, documenting changes for a release, or when the user says "add changelog" or "update changelog".
Writes user-friendly logger messages in active voice for Simple History event logs. Fixes passive voice issues. Use when creating or modifying logger classes in loggers/ directory, writing getInfo() messages, fixing passive voice, reviewing log message clarity, or adding new events to the activity log.