Wp Project Triage

Wp Project Triage

Use when you need a deterministic inspection of a WordPress repository (plugin/theme/block theme/WP core/Gutenberg/full site) including

Category: design Source: WordPress/agent-skills

What Is This?

Overview

Wp Project Triage is a deterministic inspection skill for WordPress repositories. It analyzes any WordPress codebase, whether a plugin, theme, block theme, WP core fork, Gutenberg extension, or full site installation, and produces a structured JSON report that captures tooling configurations, test setups, version hints, and project type classifications. The skill operates as a filesystem-based agent using bash and Node.js, making it suitable for automated pipelines and developer workflows alike.

The core value of this skill is consistency. Rather than manually browsing a repository to understand its structure, dependencies, and compatibility requirements, Wp Project Triage runs a standardized inspection pass and returns predictable, machine-readable output. This output can then drive downstream decisions such as which linting rules to apply, which test runner to invoke, or whether a project meets deployment guardrails.

The skill targets WordPress 6.9 and above, with PHP 7.2.24 as the minimum runtime requirement. Some advanced workflows, particularly those involving database-aware inspections or plugin activation checks, require WP-CLI to be available in the environment.

Who Should Use This

  • WordPress plugin developers who need to audit unfamiliar codebases before contributing or extending them
  • Theme developers working with block themes or full site editing setups who need to verify template structure and tooling alignment
  • DevOps engineers building CI/CD pipelines that must gate deployments based on project type and compatibility metadata
  • Agency developers onboarding new client repositories and needing a fast, reliable summary of project configuration
  • Open source maintainers reviewing pull requests or community submissions that touch multiple project types
  • QA engineers who need structured metadata to configure test environments correctly before running test suites

Why Use It?

Problems It Solves

  • Manual repository inspection is slow and error-prone, especially when a developer encounters an unfamiliar WordPress project with no documentation
  • Inconsistent environment setup causes test failures and deployment errors when the project type is misidentified or tooling versions are overlooked
  • Automated pipelines lack reliable signals to determine which workflows to trigger for a given repository, leading to wasted compute or skipped checks
  • Version compatibility issues go undetected until runtime, creating bugs that could have been caught during the inspection phase
  • Onboarding friction increases when teams cannot quickly classify whether a repository is a classic theme, block theme, plugin, or full site installation

Core Highlights

  • Produces a structured JSON report for machine-readable consumption in CI/CD and agent workflows
  • Detects project type automatically across plugins, themes, block themes, WP core, Gutenberg, and full site installations
  • Extracts version hints from package.json, composer.json, style.css headers, and plugin file headers
  • Identifies test tooling including PHPUnit, Jest, Playwright, and wp-scripts configurations
  • Maps build tooling such as webpack, Vite, and @wordpress/scripts setups
  • Operates deterministically, meaning the same repository always produces the same report structure
  • Integrates with WP-CLI for extended inspection capabilities when available
  • Compatible with bash and Node.js environments without requiring a running WordPress installation

How to Use It?

Basic Usage

To run a triage inspection on a local WordPress repository, invoke the skill against the repository root. The agent scans the filesystem and returns a JSON report.

wp-triage --path ./my-plugin --output report.json

A minimal report output looks like this:

{
  "project_type": "plugin",
  "php_min": "7.2.24",
  "wp_min": "6.9",
  "test_tooling": ["phpunit", "jest"],
  "build_tooling": ["@wordpress/scripts"],
  "has_block_json": true
}

Specific Scenarios

For a block theme repository, the skill checks for a theme.json file, a templates directory, and the presence of block.json files within parts and patterns folders. It flags missing required files as warnings in the report.

For a full site installation, the skill maps active plugin directories, identifies mu-plugins, and checks for a wp-config.php to confirm environment configuration completeness.

Real-World Examples

A CI pipeline uses the JSON report to conditionally run PHPUnit only when test_tooling includes phpunit, skipping the step entirely for JavaScript-only projects. An agency developer runs triage on a client handoff repository and immediately identifies that the project uses a deprecated classic theme structure, prompting an upgrade conversation before work begins.

Important Notes

Requirements

  • WordPress 6.9 or higher as the target project version
  • PHP 7.2.24 or higher in the execution environment
  • bash and Node.js available in the agent environment
  • WP-CLI installed for workflows that require database-aware or activation-level inspection