These are natural-language guidelines for agents to follow when developing the Decker WordPress plugin.
- Follow WordPress Coding Standards:
- PHP code: 4 spaces indentation, PSR‑12 style where compatible, proper escaping, sanitization, use WP APIs.
- Use English for source code (identifiers, comments, docblocks).
- Use Spanish for user‑facing translations/strings and test assertions to check no untranslated strings remain.
- Use TDD (Test‑Driven Development) with factories to create test fixtures.
- Tests live under
/tests/and use factory classes. - Use
make lint(PHP lint) andmake fix(beautifier) to enforce standards. - Use
make testto run all unit tests. - Use
make check-untranslatedto detect any untranslated Spanish strings.
- Develop plugin within
@wordpress/envenvironment. - Use Alpine‑based Docker containers if setting up with Docker.
- For Linux commands: assume Ubuntu Server.
- On macOS desktop (when relevant): use Homebrew to install tools.
- Use
vimas terminal editor, notnano.
- In admin or public UI, use Bootstrap 5 and jQuery consistently.
- Keep frontend assets minimal: enqueue properly via WP APIs, use minified versions.
- All PHP functions and methods must have English docblock comments immediately before declaration.
- Prefer simplicity and clarity: avoid overly complex abstractions.
- Load translation strings properly (
__(),_e()), text domain declared in main plugin file. - Keep plugin bootstrap file small (
decker.php), modularize into separate files/classes with specific responsibility.
- Always load
AGENTS.mdas conventions file: e.g./read AGENTS.mdor via config. - Do not expect Aider to modify
AGENTS.mdorREADME.mdcontents. - Use
/askmode to plan large changes, then use/codeor/architectto apply. - Review every diff Aider produces, especially in architect mode before accepting.
- After planning, say “go ahead” to proceed.
- Avoid adding unnecessary files to the chat—add only those being modified.