wp-devkit-acf-and-content-modeling
Skill0 starsChanged 34 days agoMITView on GitHub
Design, debug or review WordPress content models and ACF. Use for CPT vs taxonomy vs field choices, Local JSON/PHP schema drift, missing or unformatted values, ACF validation and REST exposure, meta_query slowness and safe field renames or backfills.
In this repository20 other files it gives its agents.
- docs/llms.txtllms.txt
- wp-devkit-accessibility-reviewSkill
- wp-devkit-admin-ui-developmentSkill
- wp-devkit-block-developmentSkill
- wp-devkit-ci-cd-and-release-engineeringSkill
- wp-devkit-headless-and-wpgraphqlSkill
- wp-devkit-migration-upgrade-reviewSkill
- wp-devkit-performance-reviewSkill
- wp-devkit-phpstan-reviewSkill
- wp-devkit-playground-developmentSkill
- wp-devkit-plugin-developmentSkill
- wp-devkit-rest-api-developmentSkill
- wp-devkit-security-reviewSkill
- wp-devkit-site-audit-and-onboardingSkill
- wp-devkit-test-strategySkill
- wp-devkit-theme-developmentSkill
- wp-devkit-ui-designSkill
- wp-devkit-wcag-reviewSkill
- wp-devkit-woocommerce-devSkill
- wp-devkit-wpcli-and-opsSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 8
Read references/engineering-contract.md first.
- Very specific: line 36
Check every write path (admin, acf_form, REST, import, WP-CLI, update_field calls) enforces the same domain rules.
- Distinctive: line 46
Write the migration idempotent, resumable and dry-run by default.
- Distinctive: line 47
Update every consumer in the same change set (templates, blocks, REST/GraphQL, imports).
- Distinctive: line 48
Run the acceptance checks.
- Distinctive: line 52
Read-only leads from the project root.
- Very specific: line 61
No match does not prove absence (helpers, generated code, JSON-only schemas).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Editorial models and field evolution
Read references/engineering-contract.md first. Review requests stay read-only: assess, explain and recommend without edits, schema or data changes, wp acf json sync|import, backfills, or running untrusted code. Use the implementation path only when the request authorizes changes.
Applicability
Confirm that ACF or Secure Custom Fields is active, or that its registrations exist (acf/init, acf_add_local_field_group, an acf-json/ folder, get_field). If not, report Not used in this project for the ACF parts. Review plain post type and taxonomy modeling only when the request asks for it.
Inputs to establish
ACF edition and version (or Secure Custom Fields), WordPress version, where field definitions live (database, Local JSON path, PHP), field keys and names involved, return formats, record volume per post type, consumers of the data (templates, blocks, REST, GraphQL, feeds, imports), multisite and translation plugin use, and whether a disposable copy of the site exists.
Inspect project evidence before asking. State material assumptions.
Route the task
| Question | Read |
| Is this a CPT, taxonomy, field, options page or block? Post type, capability or REST registration arguments? | references/content-modeling-decisions.md |
| Field group missing/different between environments; JSON vs PHP vs database; sync; keys vs names | references/schema-authority-and-sync.md |
Wrong or unformatted value, update_field result, validation, REST/GraphQL exposure, escaping, ACF Blocks | references/values-validation-and-output.md |
Slow archive or filter, meta_query, date/number comparison, rename a field, backfill, remove old data | references/meta-queries-and-field-migrations.md |
Hand off: block structure and Interactivity API to wp-devkit-block-development; WPGraphQL schema and caching to wp-devkit-headless-and-wpgraphql; REST route design and permissions to wp-devkit-rest-api-development; deployment of schema changes to wp-devkit-ci-cd-and-release-engineering; broad data upgrade strategy to wp-devkit-migration-upgrade-review; XSS or authorization defects with a reachable path to wp-devkit-security-review; measured whole-site slowness to wp-devkit-performance-review.
Code Review Workflow
- Name the entities, their lifecycle needs and their consumers. Check the modeling choice against the decision table before judging field types.
- Find the schema authority (database, Local JSON, PHP) and verify duplicates, load paths and key/name stability. Do not conclude from one file.
- Trace each value from storage through formatting to the sink. Check return format, reference meta, escaping at output and exposure through REST/GraphQL.
- Check every write path (admin,
acf_form, REST, import, WP-CLI,update_fieldcalls) enforces the same domain rules. - For queries, count participating records, inspect key/type/format, and measure or EXPLAIN before calling a query slow.
- For a model change, map old to new, list consumers, and define backfill, dual-read, verification and rollback. Review does not run them.
A finding needs a reachable path and impact. A different modeling opinion without a demonstrated cost is INFO. Insufficient evidence (no data volume, no access to the production schema) is a valid outcome: say what is missing and how to get it.
Implementation workflow
- Define expected behavior and the smallest affected boundary; name the schema authority you will edit.
- Edit definitions in the authority (JSON/PHP), never only in a production admin screen. Keep field keys; change names only with a migration.
- Write the migration idempotent, resumable and dry-run by default; test on a copy; keep the old data until verified.
- Update every consumer in the same change set (templates, blocks, REST/GraphQL, imports).
- Run the acceptance checks; report unavailable checks as unexecuted. Deployment and live data changes need their own task scope and a backup.
Search Patterns for Quick Detection
Read-only leads from the project root; matches are candidates, not findings. Exit 0 means a match, 1 none, 2 an error.
rg -n -g '*.php' -g '!vendor' -g '!node_modules' -e 'register_post_type|register_taxonomy|register_(post|term)_meta|show_in_rest|capability_type|map_meta_cap' .
rg -n -g '*.php' -g '*.json' -g '!vendor' -g '!node_modules' -e 'acf_add_local_field_group|acf/settings/(save|load)_json|acf/json/|return_format|"key": "(field|group)_' .
rg -n -g '*.php' -g '!vendor' -g '!node_modules' -e 'update_field|add_row|update_row|acf/validate_value|acf/save_post|acf_form' .
rg -n -g '*.php' -g '!vendor' -g '!node_modules' -e "meta_query|'meta_key'|orderby.*meta_value|LIKE|get_field\(|the_field\(|get_sub_field\(" .No match does not prove absence (helpers, generated code, JSON-only schemas). Output escaping is judged at the final sink, not by the presence of get_field.
Acceptance checks
- Schema:
wp acf json status(ACF 6.8+, read-only) or compareacf-jsonagainst the database list; a fresh checkout plus sync reproduces the schema on a disposable site. - Values:
wp post meta list <id>for stored value and reference; render the page; compareget_field( $name, $id, false )and formatted output. - Validation: an invalid value rejected on each write path (admin form, REST, import).
- REST:
GET /wp-json/wp/v2/<type>/<id>?acf_format=standardas anonymous and as a low-privilege user; no unintended fields. - Queries:
EXPLAINor Query Monitor numbers before and after, on realistic volume. - Migration: counts old vs new vs mismatched equal expectations; rollback path tested before old data is deleted.
- Static:
phpcsWordPress standards and project PHPStan, if configured.
A pass proves the tested paths, volume and versions. It does not prove production data cleanliness, untested write paths, other consumers of the old field, or behavior of a different ACF/SCF edition.
Output Format
Review: result and scope first. Each confirmed finding: severity per the contract, file:line, actor, trigger, reachable path, impact, confidence, minimal remediation, regression check. Candidates and missing evidence in a separate list. Modeling recommendations state the decision, the reason, affected consumers and migration needs.
Implementation: changed boundaries, schema authority edited, migration steps with dry-run output, commands run with exit status, checks not run, residual risk, rollback.
References
references/content-modeling-decisions.md: read for CPT/taxonomy/field choice and registration arguments.references/schema-authority-and-sync.md: read for Local JSON, PHP, database, sync and drift.references/values-validation-and-output.md: read for reads, writes, validation, REST, escaping, blocks.references/meta-queries-and-field-migrations.md: read for meta-query cost, renames, backfills.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

