WordPress Plugin Skill Master

Author: Dante Testa
Version: 3.0
Slug suggestion: wordpress-plugin-skill-master

---

name: wordpress-plugin-skill-master

description: "Use when designing, planning, generating, reviewing, or refactoring WordPress plugins whose PRIMARY purpose is to create a fully isolated application-like dashboard that runs inside the WordPress ecosystem but NOT inside the wp-admin chrome. The plugin may add a shortcut inside the native admin menu, but the real system must run on its own friendly routes, with its own layout, auth screens, API flows, and modern product-grade UI."

compatibility: "Targets WordPress 6.9+ and PHP 8.1+. Assumes modern plugin architecture, namespaces, REST/AJAX/admin-post support, scalable storage strategy, i18n-ready strings, production-grade performance and security, and maintainable long-term evolution."

Non-negotiable core rule

This skill exists for one specific class of plugin:

• the plugin may add a shortcut entry inside the native WordPress admin menu
• clicking that shortcut must take the user to a fully isolated application
• that application must not render inside the visual chrome of wp-admin
• that application must have its own shell, sidebar, header, layout, auth screens, assets, route handling, and UX
• the app must run on friendly routes
• the app must not use query-string-heavy admin URLs as its primary user experience

If the generated solution renders as a normal WordPress admin page wrapped by wp-admin UI, it is incorrect.

Purpose

This skill is for creating WordPress plugins that:

• register one or more entries inside the WordPress admin menu only as shortcuts or access points
• open a fully isolated admin application with its own shell
• do not visually depend on wp-admin CSS
• do not render inside the wp-admin frame/chrome
• use their own layout, sidebar, topbar, navigation, forms, tables, filters, drawers, modals, and dashboards
• can reimplement management flows inside the isolated dashboard while still leveraging core WordPress systems where appropriate
• are designed for high data volume, high traffic, and long-term maintainability
• behave like real software products inside WordPress, not like loose admin pages

The plugin should behave like a WordPress-native product at the integration boundary, but like an independent software system inside the plugin experience.

Primary operating principle

Treat the plugin as two connected layers.

1) WordPress integration layer

Responsible for:

• plugin bootstrap
• activation, deactivation, uninstall
• menu registration
• capabilities and permissions
• native users, roles, and capabilities
• REST, AJAX, admin-post, cron, settings, hooks, integration with WP APIs
• rewrite registration and route integration
• migrations and schema versioning
• localization loading
• compatibility with WordPress ecosystem expectations

2) Isolated application layer

Responsible for:

• app shell
• own admin layout
• internal sidebar and topbar
• route manager
• controllers, services, repositories, jobs, queues
• own assets and Tailwind build
• own tables, forms, CRUDs, dashboards, filters, reports, uploads, settings, diagnostics
• reimplemented UI flows for users or plugin-managed entities inside the custom dashboard
• login, register, forgot password, reset password, account flows when the product requires those flows

Never let the isolated UI become a chaotic pile of admin pages. It must be treated like a real software product.

Critical architecture correction

This skill must not default to add_menu_page() output as the primary application renderer.

That is only acceptable for:

• a lightweight launcher page
• a safe redirect page
• a diagnostics shortcut
• a permissions gate

The real application should run on a dedicated pretty route architecture, such as:

• /app-slug
• /app-slug/login
• /app-slug/register
• /app-slug/forgot-password
• /app-slug/reset-password
• /app-slug/dashboard
• /app-slug/users
• /app-slug/settings/cache

The WordPress admin menu entry is only a convenience entry point. The application itself is separate.

Route and hosting model

Preferred model:

1. register a WordPress admin menu shortcut
2. that shortcut points to the isolated application entry URL
3. register friendly routes using WordPress rewrite infrastructure
4. resolve those routes into the plugin's isolated app controller
5. render a plugin-owned shell with no wp-admin chrome
6. use plugin-owned API endpoints for interactions

The plugin may live inside the WordPress site and ecosystem, but the application UX must not live inside the normal admin wrapper.

Core strategic assumptions

Unless the user explicitly says otherwise, assume:

• the plugin may grow to 1,000,000+ records
• the plugin may face high traffic and concurrent usage
• the admin interface may be used heavily on mobile and tablet
• performance matters from day one
• architecture should favor scale, maintainability, and clean evolution
• WordPress native identity and permission systems should be preferred when possible
• the system must remain responsive as hardware improves, not rely on brute force to hide poor software design

Performance-first principle

This skill must think beyond “the feature works”.

It must design for:

• high data volume
• high traffic volume
• efficient reads and writes
• efficient memory usage
• efficient network payloads
• efficient rendering
• efficient background processing
• predictable query behavior
• scalable hardware usage

A correct solution should not become slow simply because the business succeeds.

The skill must reason across the whole performance chain:

• schema design
• indexes
• query shapes
• cache design
• payload size
• rendering cost
• pagination
• queues and jobs
• imports and exports
• asset loading
• browser performance
• cleanup and maintenance routines

Enterprise quality principle

This skill must also think beyond code generation.

It must design for:

• observability
• debuggability
• operational support
• failure recovery
• QA and testing
• accessibility
• future localization
• upgrade safety
• maintainable admin UX consistency

A plugin is not complete just because screens render. It is complete when it remains operable, diagnosable, maintainable, and safe under real use.

Use this skill when

Use this skill when the request involves one or more of these:

• plugin with custom isolated dashboard
• app-like backoffice inside WordPress but outside wp-admin chrome
• Tailwind-based admin shell
• friendly internal routes
• large CRUD systems
• business software inside WordPress
• operational workflows with relationships and filters
• dashboards with KPIs, charts, and date filters
• performance-sensitive data modeling
• custom tables, custom storage, or scale concerns
• user, role, or operator management inside a custom plugin UI
• public pages generated by the plugin that need technical SEO
• custom auth flows with WordPress-native user backend

Questions to answer before implementation

Before coding, determine:

1. What is the main entity or entities?
2. How many records may exist after 6 months, 1 year, and 3 years?
3. Is the data content-like or operational/transactional?
4. Will users search, filter, aggregate, sort, and relate records heavily?
5. Are writes frequent?
6. Are reads mostly transactional, analytical, or both?
7. Does the system need logs, queues, history, snapshots, or auditability?
8. Does the system need background jobs, exports, imports, or recalculation routines?
9. Should the solution use native WordPress users, roles, and capabilities?
10. Will the plugin create public-facing pages that need SEO?
11. Does the admin experience need multiple modules under one isolated sidebar?
12. Would long forms benefit from multistep UX?
13. Does the product need CLI operations for seed, maintenance, repair, or migration tasks?
14. What failures would hurt most in production, and how should they be logged or surfaced?
15. Does the system require its own login, register, or reset screens while still using native WordPress users?

If the user does not provide scale expectations, assume high scale.

Absolute route rules

The isolated application must use friendly routes as first-class UX.

Required principles:

• do not build the main app around ?page=...&tab=...&action=...
• do not use long parameterized URLs as the primary navigation model
• do not expose wp-admin wrappers as the real app shell
• use route paths that map to app screens cleanly
• support route guards and capability checks
• support direct linking to internal screens where appropriate

Preferred routes:

• /plugin-slug/login
• /plugin-slug/register
• /plugin-slug/forgot-password
• /plugin-slug/reset-password
• /plugin-slug/dashboard
• /plugin-slug/users
• /plugin-slug/clients
• /plugin-slug/products
• /plugin-slug/reports
• /plugin-slug/settings/general
• /plugin-slug/settings/cache

Auth and user model rules

When the system requires accounts, access, or authenticated actors, prefer the native WordPress user system.

Required principles:

• do not create a second user table just to support login
• use native WordPress users as the identity layer
• use roles and capabilities as the authorization foundation
• create custom roles only when the product clearly benefits from them
• use native login state and WordPress cookies unless the product explicitly requires a different session architecture
• build custom login/register/reset screens visually inside the isolated app when needed
• keep the underlying persistence in the native WordPress user system
• use user meta only for modest profile extensions
• move heavy operational user-related data to dedicated custom tables while keeping identity in native users

This means

The plugin may offer:

• custom login screen
• custom register screen
• custom forgot password screen
• custom reset password screen
• custom account profile screens
• custom user CRUD inside the isolated app
• role assignment inside the isolated app

But the data backbone for users should still be the WordPress user system unless there is a compelling reason not to.

Storage decision rules

Use wp_options when

Use options only for:

• plugin settings
• feature flags
• compact configuration values
• API keys and credentials handled safely
• small derived summaries when appropriate

Do not store operational datasets in options.

Use transients or object cache when

Use cache for:

• expensive dashboard counters
• repeated summary queries
• lookup lists that can be rebuilt
• repeated derived aggregates
• safe, read-heavy computations

Do not use cache as source of truth.

Use CPT + taxonomy + post meta when

Use this only when the entity is truly content-like and benefits from WordPress-native content behavior such as:

• editorial workflows
• revisions
• content integrations
• native taxonomies
• compatibility with plugins expecting posts
• relatively modest scale and low operational complexity

Be careful: postmeta-heavy designs degrade badly for large operational workloads.

Use custom tables when

Custom tables should be the default for app-like, high-scale, filter-heavy, operational plugins.

Prefer custom tables when:

• records can grow substantially
• multiple filters and joins are required
• search and reporting are important
• relationships matter
• dashboard analytics matter
• unique constraints are needed
• predictable performance matters
• large imports or exports exist
• batch jobs exist
• event logs, queues, states, or histories are central

If the plugin behaves like a SaaS inside WordPress, custom tables are usually the right foundation.

Database design rules

When using custom tables:

• prefix with $wpdb->prefix
• define explicit primary keys
• use meaningful status columns where lifecycle matters
• include created_at and updated_at when appropriate
• store timestamps in UTC
• design indexes for real query patterns
• use composite indexes intentionally
• avoid over-indexing write-heavy tables
• plan migrations from day one
• use schema versioning

High-scale query discipline

For large-scale plugins:

• query only the columns needed
• avoid SELECT * on large tables
• shape indexes from real access paths
• avoid naive %LIKE% strategies on massive text columns unless intentionally designed
• distinguish transactional queries from analytical queries
• treat count queries carefully on large datasets
• prefer deterministic indexed filters
• reduce round-trips when batching is possible
• use reporting strategies when real-time analytics become too expensive

Common table families for app-like plugins

Common structures may include:

• primary entity table
• child/detail table
• pivot/relation table
• logs or audit table
• queue or jobs table
• import batches table
• derived reporting table when needed

API-first interaction model

This skill must prefer an API-driven app architecture.

Preferred behavior:

• forms submit through intentional APIs or handlers
• tables fetch through API endpoints
• dashboard widgets fetch through API endpoints
• relationship lookups use async API search
• route transitions may hydrate through API payloads
• validation responses should be structured and predictable

The app should not depend on old-style parameterized form workflows as its main architecture unless the request explicitly calls for that.

Internal API strategy rules

The skill should be intentional about communication patterns inside the plugin.

Prefer defining:

• when to use REST routes
• when to use AJAX handlers
• when admin-post is sufficient
• payload contracts
• normalized success and error response shapes
• endpoint permission callbacks
• predictable validation behavior
• endpoint versioning when the surface grows

Do not mix transport strategies randomly without reason.

UI isolation rules

The isolated admin app must:

• explicitly control its own CSS and JS
• avoid inheriting wp-admin visual styles
• not render inside the standard wp-admin frame
• enqueue its own assets only for its own routes
• render its own shell with sidebar, header, content, notifications, and states
• load only what each route needs when practical

If the interface still looks like a normal WordPress admin page with WordPress chrome around it, the solution is wrong.

Visual design quality rules

The isolated app must not default to dated or generic admin visuals.

Preferred direction:

• modern product-style admin interface
• clean spacing system
• high visual hierarchy
• strong card/table/form consistency
• polished empty, loading, and error states
• responsive sidebar patterns
• drawer and modal patterns that feel contemporary
• visual inspiration from modern app systems, not classic wp-admin aesthetics

Component inspiration rule

When choosing UI patterns, prefer inspiration from modern component systems and modern admin products.

Good inspiration directions include:

• shadcn/ui-style composition thinking
• Radix-style accessibility and primitives thinking
• polished SaaS dashboard patterns
• modern B2B product interface conventions

The goal is not to clone a library blindly, but to deliver a modern, product-grade dashboard rather than an old-fashioned admin page.

Tailwind and component rules

• use a dedicated Tailwind build
• do not rely on CDN Tailwind for production deliverables
• purge correctly
• keep design tokens for colors, spacing, radius, typography, shadows
• build reusable primitives such as cards, tables, form fields, alerts, badges, pagination, tabs, drawers, modals
• maintain responsive admin UX
• define a consistent component vocabulary before building many screens

Design system and UI consistency rules

The isolated admin should behave like a coherent product.

Prefer a minimum design system with:

• consistent spacing scale
• reusable button variants
• reusable form components
• reusable filter bars
• reusable table wrappers
• standardized modals and drawers
• standardized status badges and notices
• consistent empty, loading, and error states

Do not let every screen invent its own patterns.

Security rules

Always apply:

• capability checks on every entry point and action
• nonces for state-changing operations
• sanitize on input
• escape on output
• prepared SQL with $wpdb->prepare()
• strict upload validation when uploads exist
• server-side permission enforcement even if UI hides controls
• safe user-facing error messages
• detailed logs where appropriate

Never trust:

• route parameters
• hidden fields
• client-computed permissions
• JavaScript-only validation
• unchecked HTML

Concurrency and idempotency rules

For critical mutations, the skill should think about duplicate requests, race conditions, and repeated execution.

Prefer:

• UI-level duplicate-submission prevention
• request-level idempotency for sensitive actions when practical
• safe retry behavior
• unique constraints where business rules require uniqueness
• guardrails for concurrent imports, exports, recalculations, and batch actions
• job locks or coordination when simultaneous processing would corrupt state

A correct design should not assume the user or the network behaves perfectly.

File and media lifecycle rules

If uploads exist, the full file lifecycle must be designed.

Rules:

• no orphan files after replacement, deletion, or abandoned flows
• every persisted file must map to a valid entity or temporary session
• replacing an asset must safely retire the previous one
• deleting an entity must trigger configured cleanup rules
• gallery reordering and featured-image changes must keep references consistent
• temporary uploads must expire and be cleaned
• all file operations must validate permission and ownership

Prefer a media manager abstraction instead of scattering file logic across controllers.

Upload and image UX rules

Treat upload UI as a complete workflow, not just a file input.

Prefer:

• preview before save
• drag-and-drop ordering for galleries
• explicit primary image logic when relevant
• multi-upload with stable ordering
• replace and remove actions with clear feedback
• mobile-friendly interactions
• no hidden file accumulation

If the user asks for a gallery but not a separate featured image, the skill may assume the first gallery image becomes the primary image, but should state that assumption.

Client-side image processing rules

When practical, prefer client-side preprocessing for better UX and lower server load.

This may include:

• crop before upload
• resize before upload
• compression before upload
• format conversion when reliable
• preview of final framing

However:

• do not assume every browser can safely perform every transformation
• keep server-side fallback when compatibility or fidelity require it
• always validate server-side after upload

Default image output assumptions

If the user does not specify image rules:

• prefer AVIF when well supported in the environment and workflow
• otherwise prefer WebP
• keep dimensions aligned with real usage
• avoid storing oversized originals when unnecessary
• optimize for clarity and storage efficiency

Async feedback and action safety rules

Whenever the interface triggers asynchronous or delayed work, the UI must provide immediate feedback and protect the action.

Required patterns:

• visible loading state for async actions
• inline button loading states such as Carregando or Aguarde
• section or screen preloaders for heavy loads
• disable submit and action buttons after the first valid click
• prevent duplicate submissions for forms, AJAX actions, and destructive actions
• restore button state safely after success or recoverable error
• show clear success, failure, and retry messaging

For long-running operations, prefer:

• step indicators
• progress states
• queued status
• polling or refresh strategies where appropriate

This protection must apply at both UI level and request-handling level whenever duplicate mutation is possible.

Form UX rules

Forms should be safe, fast, and friction-aware.

Preferred defaults:

• input masks where appropriate
• validation hints where useful
• accessible error states
• mobile-friendly spacing and targets
• server-side validation always enforced

Long-form and multistep form rules

When a form becomes long or cognitively heavy, consider multistep structure.

Use multistep reasoning when:

• many fields exist
• fields group naturally
• mobile usability would suffer in one long screen
• staged validation improves clarity

Preferred multistep behavior:

• clear thematic steps
• visible progress indication
• safe data preservation between steps
• back navigation without data loss
• validation by step
• final submit protected against duplicate submission

Multistep forms are not mandatory, but the skill should suggest them when they improve completion and usability.

Field masking rules

Use masks or specialized inputs for:

• CPF
• CNPJ
• phone numbers
• postal codes where relevant
• monetary values
• other structured identifiers when locale indicates clear benefit

Phone field rules

Phone fields should be international-ready unless the product is explicitly single-country.

Preferred behavior:

• use a mature international phone input with country picker
• allow automatic default country suggestion when appropriate
• if the user does not specify a country, a default may be suggested using locale or IP-derived heuristics when available and legally appropriate
• always allow manual country override
• store normalized phone values where practical while presenting user-friendly formatting

For Brazilian flows, account for formatting differences between mobile and landline patterns.

Password field rules

Password flows should improve usability without weakening security.

Prefer:

• show or hide password toggle
• strong password generation when appropriate
• clear strength guidance when policy matters
• reset-request success messaging that clearly tells the user that instructions were sent by email

Monetary field rules

Whenever the product includes prices, totals, discounts, fees, commissions, billing, or financial calculations, monetary fields must be localized and masked.

Rules:

• never use raw free-text money input when localized money entry is expected
• do not rely on bare numeric fields alone for user-facing money entry
• apply locale-aware decimal and thousand separators
• clearly show currency context
• parse and normalize safely before persistence
• store normalized numeric values suitable for calculation
• validate rounding and precision consistently across create, edit, import, and API flows

Default reasoning:

• if the interface is in Brazilian Portuguese and no other currency is specified, prefer BRL-style formatting
• if the interface is in English and the product indicates USD, prefer USD-style formatting
• if the user specifies another currency or locale, follow that explicitly
• when multiple currencies are possible, separate stored numeric value from presentation formatting

Large dataset UX rules

When an entity can grow substantially, the UI must avoid naive components.

Always apply:

• never use a plain select loaded with thousands of related records
• for high-volume relations, use async searchable selects or autocomplete pickers
• relation fields must query the server on demand with debounced search
• result sets must be capped or paginated
• selected values should store IDs while displaying human-readable labels
• include loading, empty, and no-result states

Examples:

• linking a product to a client
• linking an order to a vendor
• linking a ticket to an operator

Do not render massive dropdowns for enterprise-style plugins.

CRUD listing rules

All CRUD list screens must be designed for large datasets.

Required behaviors:

• server-side pagination
• searchable columns based on efficient query paths
• sortable columns only where database support is reasonable
• compact filter bar for common filters
• batch actions only with explicit permission and confirmation
• responsive behavior
• empty, loading, and error states

Never assume all rows can be safely loaded into the browser.

Pagination rules

Pagination must be compact, progressive, and mobile-friendly.

Preferred behavior:

• limited window of nearby pages
• first and last page access preserved
• ellipsis for skipped ranges
• moving middle window as the user advances
• previous and next always obvious
• lower visual density on small screens

Do not print giant blocks of page numbers.

Dashboard and analytics rules

Default dashboards should be operational, not decorative.

When measurable entities exist, the dashboard should usually include:

• KPI cards or counters
• charts based on filtered data
• period filter controls
• summaries by status, category, owner, or trend when relevant
• recent activity or alerts when useful

Dashboard filters must apply consistently across:

• counters
• charts
• summary tables
• trends

Dashboard date filter logic

Date filters should be practical and data-aware.

General rule:

• avoid presenting useless date choices that always return empty results unless that is genuinely useful
• prefer data-aware period suggestions when that improves usability
• allow open date ranges when the workflow needs analytical flexibility
• handle empty states gracefully

In all cases:

• use indexed date columns when possible
• share a common filter state across dashboard widgets
• cache or pre-aggregate expensive analytics when needed

Settings area rules

Production-grade isolated apps should include a structured settings area organized into tabs or clearly separated sections.

Common tab suggestions:

• General
• Permissions
• Integrations
• Cache & Performance
• Diagnostics
• Seed Data
• Import/Export
• Developer Tools

Do not force every tab into every plugin, but proactively suggest them when useful.

Seed data and diagnostics rules

For app-like plugins, consider a diagnostics or seed-data tab.

Use cases:

• create realistic sample data
• simulate larger datasets
• validate dashboards, pagination, search, and filters
• inspect health indicators such as row counts, migration version, failed jobs, and cache status

Rules:

• sample data generation must be permission-guarded
• destructive reset must require confirmation
• production usage should be restricted unless explicitly intended
• generated data should follow real entity relationships

Cache and performance tab rules

When the plugin contains expensive dashboards, counters, listings, or derived summaries, consider a Cache & Performance tab.

Suggested capabilities:

• enable or disable plugin-level caches where appropriate
• display cache backend availability
• detect whether persistent object cache is available
• clear plugin-owned caches safely
• show plugin cache health or last refresh time when useful
• expose dashboard cache regeneration controls where appropriate

Only manage caches the plugin owns or can safely coordinate.

WordPress cache strategy rules

The skill should understand WordPress object caching and use it intentionally.

Principles:

• persistent object cache may or may not exist in the environment
• persistent cache availability should be detected, not assumed
• cache design needs groups, keys, TTL strategy, and invalidation rules

Use cache for:

• expensive counters
• dashboard summaries
• repeated lookup lists
• expensive derived data that can be rebuilt

Do not use cache as source of truth.

Redis-aware behavior

When persistent object cache backed by Redis or another backend is available, the plugin may benefit from deeper caching of expensive derived data.

The skill should:

• detect persistent object cache availability
• avoid making Redis a hard requirement unless explicitly needed
• degrade gracefully when persistent cache is unavailable
• avoid over-caching highly volatile data
• define invalidation after writes, imports, deletes, status changes, and batch operations

If a cache tab exists, it may show:

• persistent object cache availability
• backend status if detectable
• plugin cache health or last refresh time
• safe clear-cache actions for plugin-owned keys

Infrastructure-aware performance reasoning

The plugin should make better hardware useful, not necessary just to survive.

Required mindset:

• optimize software so stronger hardware scales the system further instead of merely compensating for waste
• keep logic compatible with efficient database engines and persistent object cache where available
• isolate expensive work from request-response flows whenever practical
• design queueable or deferred execution for imports, exports, recalculations, and mass updates
• keep admin interactions responsive even with large workloads

Rendering and payload efficiency rules

Performance is not only about the database.

The skill should also optimize:

• response size
• JSON payload size
• frontend boot payloads
• number of DOM nodes rendered at once
• chart payload volume
• image sizes
• asset bundles
• route-level boot data

Prefer:

• incremental loading
• compact API responses
• lazy rendering where appropriate
• route-level asset discipline
• avoiding unnecessary components on first render

Architecture pattern

Prefer a structure like:

• plugin-name.php minimal bootstrap
• src/Core/Plugin.php
• src/Admin/ShortcutMenu.php
• src/Routing/RewriteRegistrar.php
• src/Routing/AppRouter.php
• src/App/Kernel.php
• src/App/Controllers/*
• src/Services/*
• src/Repositories/*
• src/Database/*
• src/Capabilities/*
• src/API/*
• src/Auth/*
• src/Jobs/* or src/Queue/*
• src/Support/*
• assets/
• views/ if server-rendered
• languages/

Principles:

• the WordPress layer stays thin
• the isolated app owns the product UX
• controllers stay thin
• repositories own query strategy
• services own business rules
• jobs own deferred execution
• caches have explicit ownership and invalidation

Internationalization rules

Build the plugin in the language explicitly requested by the user, but keep the codebase translation-ready by default.

Required principles:

• do not generate multiple languages unless the user asks
• all user-facing strings should use the requested language
• all translatable strings should use proper WordPress i18n functions
• use a text domain aligned with the plugin slug
• prepare translation loading architecture cleanly
• avoid hard-coded strings across templates, JS, PHP, validation, settings, notices, and emails
• use pluralization, placeholders, and context helpers correctly where needed
• escape translated output based on context

Goal:

• single-language delivery by default
• translation-ready architecture by default

Accessibility rules

The isolated admin should be accessible by default.

Prefer:

• semantic structure
• proper labels
• keyboard navigability
• visible focus states
• sufficient contrast
• accessible error messaging
• aria usage when appropriate, not excessive
• modals and drawers with correct focus handling
• tables and filters that remain usable without pointer precision

Accessibility should be part of the default design quality, not a late patch.

Public pages and SEO rules

If the plugin creates public-facing pages, portals, profiles, directories, listings, or detail screens, SEO must be treated as a first-class concern.

The skill should design:

• semantic HTML structure
• correct titles and meta descriptions
• canonical URLs when needed
• crawl-safe pagination behavior
• structured data when relevant
• clean internal linking
• performant image output
• indexation and noindex decisions where appropriate

The skill should reason about:

• archive pages
• filtered page duplication
• thin or duplicate pages
• schema markup opportunities
• pages that should not be indexed

WordPress integration rules

The plugin must still follow WordPress best practices at the integration boundary:

• proper plugin header
• activation and deactivation hooks
• uninstall cleanup policy
• safe settings registration
• capability registration where needed
• multisite awareness when relevant
• permission callbacks on endpoints
• cron events registered and unscheduled correctly
• no unnecessary admin logic loaded on public requests
• rewrite rules registered and flushed safely when needed

Observability and diagnostics rules

The plugin should be diagnosable in production and staging.

Prefer:

• structured logs for important failures
• meaningful log levels
• logs for imports, exports, jobs, migrations, and external API failures
• safe diagnostic screens for admins
• health indicators for queue status, cache status, row counts, and migration version
• debug modes that do not expose sensitive information to unauthorized users

Observability should help explain what failed, where, and what can be done next.

Testing and QA rules

The skill should proactively think about testability and validation.

Prefer:

• unit tests for critical business rules
• integration tests for repositories, permissions, and major flows
• migration tests when schema evolution matters
• endpoint validation tests
• permission tests for privileged operations
• smoke tests for critical app routes
• performance sanity checks for large list and dashboard flows

Do not produce architecture that is impossible to test cleanly.

WP-CLI and operational tooling rules

For larger plugins, the skill should consider WP-CLI support.

Useful commands may include:

• seed sample data
• rebuild derived data
• clear plugin cache
• run maintenance routines
• inspect health or counts
• repair inconsistencies
• run migrations explicitly when appropriate

WP-CLI is especially valuable for large datasets and support operations.

Deliverable expectations

When generating or reviewing a plugin, always provide:

1. app-vs-WordPress boundary summary
2. route model summary
3. auth and user strategy
4. storage choice justification
5. table schema proposal when custom tables are used
6. index strategy
7. route map
8. capability map
9. isolated app screen map
10. security checklist
11. performance checklist
12. migration and update strategy
13. testing strategy
14. observability and diagnostics strategy
15. cache and invalidation strategy
16. assumptions made because the user did not specify enough detail

Anti-patterns to avoid

• rendering the real application inside normal wp-admin chrome
• using add_menu_page() output as the full app shell
• relying on ?page=...&tab=...&action=... as the main app UX
• creating a second user table just to implement login
• stuffing large operational data into postmeta without strong reason
• using giant dropdowns for large relation datasets
• loading all rows into the browser
• mixing rendering, SQL, and business logic in the same file
• missing nonce or capability checks
• storing operational datasets in serialized options
• ignoring migrations and schema versioning
• leaving orphan uploads behind
• using cache without invalidation rules
• exposing public pages without technical SEO planning
• hard-coding strings in ways that block translation later
• relying on brute force hardware to hide poor query design
• building UI patterns inconsistently across screens
• creating complex logic with no operational visibility
• shipping plugin architecture that cannot be tested or maintained
• shipping a visual design that feels like classic wp-admin when the requirement is a modern isolated product

Output style

When solving requests with this skill:

• think like a senior WordPress plugin architect
• think like an enterprise software engineer, not a snippet generator
• think like a UX product designer for modern admin systems
• think like a technical lead responsible for long-term maintenance
• prioritize the isolated-app requirement above convenience
• justify storage decisions clearly
• proactively replace naive UI patterns with scalable alternatives
• keep WordPress integration thin and intentional
• treat the isolated dashboard as a real software product
• assume mobile matters
• deliver architecture, not only code

Success criteria

A correct solution produced with this skill should:

• use WordPress as host platform and identity backbone where appropriate
• open a truly isolated modern application rather than a wrapped admin page
• remain secure under hostile input
• remain performant under large datasets and sustained traffic
• be easy to extend with new modules
• make explicit architectural decisions instead of guessing
• avoid waste in queries, payloads, rendering, and background processing
• scale forward as infrastructure improves instead of requiring a rewrite at the first sign of success
• remain diagnosable, testable, and operable in real-world environments
• look and feel like a modern product, not a dated admin screen