Skip to the guide
All guides

Site audit and onboarding

Inventory an inherited or unfamiliar WordPress project.

app WordPress DevKit 2.0.0checked reading 4 minutes

On this page

When to use it

Inventory an inherited or unfamiliar WordPress project: stack and version discovery, ownership map, drop-ins and mu-plugins, environment doctor, risk-ranked routing to specialist skills. Read-only first pass; use a domain skill directly when the problem is already known.

Boundaries and hand-offs

This skill answers "what is this project, who owns what, what do we not know, and which specialist should look first?". It does not perform the specialist review. Route security to wp-devkit-security-review, speed to wp-devkit-performance-review, orders and checkout to wp-devkit-woocommerce-dev, saved block content to wp-devkit-block-development, upgrades and data changes to wp-devkit-migration-upgrade-review, WP-CLI operations to wp-devkit-wpcli-and-ops, pipelines to wp-devkit-ci-cd-and-release-engineering, tests to wp-devkit-test-strategy. An inventory is not a security audit, performance audit, accessibility audit or penetration test.

Ask Claude

With the plugin loaded, start a read-only review of a bounded target:

Text
/wp-devkit:onboarding-review <target-path>

The short form /wp-devkit:doctor requests a quick scan.

Ask Codex, ChatGPT or Antigravity

Name the installed skill and keep the request bounded. Replace the target with your files or journey.

Text
$wp-devkit-site-audit-and-onboarding
Review the target without editing files.
Read the project instructions and the skill's engineering contract first.
Separate confirmed findings from candidates and state the evidence and checks you could not run.

What it covers

The agent loads only the reference that matches the task:

  • doctor.md : Environment doctor
  • routing-and-deliverable.md : Routing and onboarding deliverable
  • safe-inventory.md : Safe inventory commands and version trust
  • site-audit-and-onboarding-workbook.md : Site audit and onboarding workbook
  • stack-signals-and-ownership.md : Stack signals and ownership

How a review runs

  1. Separate evidence sources: first-party source, vendored dependencies, generated or built artifacts, deployment configuration and the live site. Read project instructions (README, CONTRIBUTING, CLAUDE.md, runbooks) first.
  2. Classify the shape from several signals ( references/stack-signals-and-ownership.md ): plugin, theme (block, classic, hybrid, child), block library, WooCommerce, headless, builder-driven, multisite, composer-managed (Bedrock-style), monorepo.
  3. Discover versions with the trust order in references/safe-inventory.md : runtime evidence over lockfiles over headers over documentation. Name the source of each version and mark unknown activation, storage, hosting and deployment state as unknown.
  4. Map owners: bootstrap, content model, rendering, API, build, tests, delivery, hosting layer (drop-ins, mu-plugins, platform plugins). Keep the map short enough to guide the next task.
  5. Rank specialist follow-ups by potential impact times missing evidence ( references/routing-and-deliverable.md ). An unverified webhook, upgrade directory or eval is a candidate, not a confirmed critical.
  6. For doctor requests follow references/doctor.md : filesystem mode by default; a trusted container runtime only with explicit authorization. Read references/site-audit-and-onboarding-workbook.md first for decision rules, false positives and acceptance checks.

What you get back

Lead with the project shape in one sentence and the evidence level (static source only, source plus doctor, trusted runtime). Then: inventory table (component, version, source of the version, confidence), ownership map, hosting and runtime layers found, unknowns with the single observation that would resolve each, ranked specialist follow-ups (candidate, why, evidence needed, which skill, first command), and blockers to starting work. Label static inspection, database evidence and runtime execution separately. Never print secret values. Never call a candidate CRITICAL; severity needs a reachable path and demonstrated impact (contract). End with checks executed with exit codes and checks not executed.

Note

Reviews are read-only. A clean review covers the inspected scope; it is not a certification. Ask for implementation as a separate, bounded task with a regression check.

Where to go next

Use review to fix for a bounded implementation and Doctor and reports for environment and evidence tooling.