What problem does this address?

The Guidelines CPT stores site-wide editorial rules — brand voice, copy standards, image guidelines. This is one type of instructional content a site needs, but not the only one.

As AI-powered tools integrate with WordPress, a recurring need is emerging for sites to store different kinds of persistent, structured knowledge that shapes how agents interact with the site. These fall into distinct categories:

• Skills — Procedural instructions for how to perform a specific task. Reusable across sessions, authored by site owners or shipped by plugins, loaded on demand when relevant.
• Memory — Facts and observations for future recall. Agent-written, accumulated incrementally, versioned so you can trace how understanding evolved.
• Plans — Task-scoped working documents. Created for a multi-step task, archived or deleted when done.

All of these share the same structural shape as guidelines: titled, versioned, instructional documents exposed via REST API. The difference is their lifecycle and multiplicity — site-wide editorial guidelines are a singleton per site, while skills, memories, and plans are many independent documents.

Rather than introducing parallel CPTs for each document type, the existing Guidelines CPT can expand to accommodate them with a taxonomy-based type system — the same pattern WordPress core already uses.

Context:

• Guidelines Lands in Gutenberg 22.7

Parent Issue: #75171

What is your proposed solution?

Evolve the CPT in phases to support multiple document types while preserving the existing Guidelines experience.

Phase 1: Taxonomy + type-aware REST controller

1. Register wp_guideline_type taxonomy on the CPT, following the wp_template + wp_theme pattern from core. Seed four terms: content, skill, memory, plan.

2. Relax the singleton constraint to be type-scoped — the existing site-wide guidelines post retains singleton behavior for the content type. New posts with other types (skill, memory, plan) are allowed without limit.

3. Refactor the REST controller to be type-aware — today the controller is tightly built around the singleton + structured-meta pattern: get_guidelines() returns one post, create_item() rejects a second, prepare_item_for_response() builds the guideline_categories object, and the schema doesn't expose title/excerpt/post_content. The different types have different storage patterns:

   	Content (existing)	Skills / Memory / Plans (new)
   Primary data	Structured post meta (_content_guideline_copy, _content_guideline_images, etc.)	post_content (freeform)
   post_content	Unused	The actual content
   title	Hardcoded "Guidelines"	Meaningful (skill name, plan title)
   excerpt	Unused	Short description for discoverability
   Multiplicity	Singleton	Many independent posts
   REST response	guideline_categories object	Standard post fields

   The controller needs to branch on type: content preserves current singleton + guideline_categories behavior; other types use standard post fields (title, excerpt, post_content) with collection endpoints supporting pagination and filtering (?wp_guideline_type=skill).

Phase 2: Skills storage pattern

Skills use standard post fields instead of structured meta:

Versioning via native WordPress revisions — each edit tracked with diffs and rollback.

Phase 3: Plugin registration API

A wp_register_guideline() PHP API for plugins to ship default skills, similar to how themes register templates. Agents discover via REST, load on demand, and can create their own documents (scratchpad/notes) through the same endpoint.

Design considerations

• Guidelines stay unchanged — singleton behavior, structured meta in accordion sections, dedicated Settings UI all remain as-is for the content type
• Per-site scoped — guidelines are site-scoped. Activation/scoping layers (per-user, per-agent) can be built on top by consuming plugins
• Private guidelines — some guidelines (e.g., internal playbooks) may need to be hidden from end users. The meta field can carry visibility flags for this

Prior art

WordPress already uses this taxonomy-differentiated CPT pattern:

• wp_template + wp_theme taxonomy
• wp_block + wp_pattern_category taxonomy
• nav_menu_item + nav_menu taxonomy