Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
7 changes: 7 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
node_modules/
dist/
.astro/
.blume/
.blume-content/
frontend/src/generated/
frontend/public/media/
22 changes: 17 additions & 5 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,12 +1,14 @@
# WP Docs

This repository is an active experiment for generating WordPress core and canonical plugin documentation with `docs-agent`.
This repository publishes WordPress.com developer documentation and WordPress.org documentation from a Git-managed Markdown corpus.

The goal is to produce comprehensive, massively useful WordPress documentation that is accurate, source-verified, and pleasant to navigate. The output should meet the quality bar set by the best modern documentation sites while fitting the WordPress.org documentation ecosystem.

## Current Direction
## Publishing Model

This repo is being reset around the generation workflow, content policy, provenance model, and future publishing surface. Earlier generated material has been preserved for reference, but `main` is now the working surface for the next iteration.
Markdown in Git is canonical. Markdown Database Integration (MDI) primary mode gives WordPress Studio and wp-admin a local editing interface for that same corpus; Studio Code is an optional client, not a dependency.

Blume reads `content/runtime/` directly and owns the generated Astro presentation, local search, and static SEO output. Spacefast receives only the checked `dist/` artifact through `sf deploy dist --prebuilt`. Hosted WordPress and Push MD are migration inputs, not steady-state build or publishing dependencies.

## Repository Layout

Expand All @@ -15,7 +17,10 @@ This repo is being reset around the generation workflow, content policy, provena
- `content/` — generated and reviewed documentation outputs plus page-level metadata.
- `recipes/` — project-specific WP Codebox recipes for reproducible generation and review runs.
- `provenance/` — lightweight provenance conventions that belong with this corpus.
- `theme/wp-docs/` — prototype WordPress block theme for the docs experience.
- `content/runtime/` — canonical MDI Markdown corpus: 89 WordPress.com documents and 314 WordPress.org HelpHub articles.
- `blume.config.ts` — Blume presentation, navigation, SEO, AI, and static deployment configuration.
- `studio/` — local MDI/Studio authoring contract.
- `scripts/` — build adapters and approval-gated publishing command.
- `docs/` — project architecture, decisions, and operating notes.

The full-coverage generation plan is tracked in `docs/full-coverage-generation-plan.md`.
Expand Down Expand Up @@ -44,4 +49,11 @@ That archive is useful as seed material and historical context, but it is not th

- `docs-agent` owns reusable agent behavior, prompts, and bundle mechanics.
- `wp-codebox` owns isolated WordPress execution, recipes, previews, and artifact bundles.
- This repo owns WordPress core and canonical plugin docs inputs, generated content, project-specific recipes, and publishing direction.
- This repo owns WordPress core and canonical plugin docs inputs, generated content, project-specific recipes, the Studio-to-static build, and publishing direction.

## Verify A Fresh Checkout

1. Install Node.js 22.12 or newer and run `bash tests/verify-studio-spacefast.sh`.
2. Inspect `dist/documentation/developer-tools/wp-cli/common-commands/index.html` and `dist/helphub_article/search-block/index.html` for representative nested and HelpHub routes.
3. Blume builds from Git Markdown without a running Studio site. Use Studio's MDI primary mode to edit the corpus locally, then commit those Markdown changes and rerun the build.
4. Before any human-approved publication, run `npm run publish:spacefast -- --dry-run`, which invokes `sf deploy dist --prebuilt --dry-run`. An approved publication invokes `sf deploy dist --prebuilt`; the wrapper only considers `dist/` and makes no mutation without `WP_DOCS_ALLOW_PUBLISH=1`.
32 changes: 32 additions & 0 deletions blume.config.ts
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
import { defineConfig } from 'blume';

export default defineConfig({
title: 'WP Docs',
description: 'WordPress.com developer documentation and WordPress.org documentation.',
content: {
root: '.blume-content'
},
github: {
owner: 'chubes4',
repo: 'wp-docs',
branch: 'feat/studio-spacefast-headless'
},
navigation: {
tabs: [
{ label: 'WordPress.com developer documentation', path: '/documentation' },
{ label: 'WordPress.org documentation', path: '/helphub_article' }
],
sidebar: { display: 'page' }
},
search: { provider: 'orama' },
ai: { llmsTxt: true },
seo: {
sitemap: true,
robots: true,
structuredData: true
},
deployment: {
output: 'static',
site: 'https://wp-docs.view.fast/'
}
});
2 changes: 1 addition & 1 deletion content/_meta/navigation-search.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Navigation and Search Metadata

The theme can render docs navigation from published WordPress page hierarchy. When that content is not available yet, it falls back to the committed pilot fixture at `theme/wp-docs/assets/docs-index.json`.
The static frontend renders navigation from published WordPress Page hierarchy. The deterministic build fixture is `frontend/fixtures/pages.json`; it is for CI and review only, not an authoring fallback.

Search/navigation entries use this shape:

Expand Down
13 changes: 13 additions & 0 deletions content/runtime/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# WP Docs Runtime Corpus

This directory is the Markdown Database Integration export from the `wp-docs-runtime` WordPress site.

- Source project: `wp-docs-runtime`
- Exported: 2026-07-15
- MDI mode: `primary`
- `documentation/`: 89 published WordPress.com documentation records
- `helphub_article/`: 314 published WordPress.org HelpHub records

The files preserve MDI frontmatter, WordPress identity and hierarchy, source URLs, taxonomy metadata, and Markdown bodies. Git Markdown is canonical: MDI primary mode makes the same files available to local Studio/wp-admin editing, while Blume reads them for presentation. The hosted runtime was used to migrate this snapshot and is not required to build or publish it.

Two `wp_guideline` records are not part of the publishable documentation corpus. MDI rejected them because their declared block format did not match their raw content, so they were not coerced into this snapshot.
115 changes: 115 additions & 0 deletions content/runtime/documentation/agent-skills.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
---
type: document
title: Agent Skills
description: ""
resource: "https://bountiful-impassioned-hygiea.wpcloudstation.dev/developer-wordpress-com-documentation/agent-skills/"
tags:
timestamp: "2026-06-16T19:29:18+00:00"
wordpress:
id: 2431
status: publish
type: documentation
author: 0
date: "2026-06-16 19:29:18"
date_gmt: "2026-06-16 19:29:18"
modified: "2026-06-16 19:29:18"
modified_gmt: "2026-06-16 19:29:18"
slug: agent-skills
parent: 0
menu_order: 0
comment_status: closed
ping_status: closed
guid: "https://bountiful-impassioned-hygiea.wpcloudstation.dev/developer-wordpress-com-documentation/agent-skills/"
comment_count: 0
---

Agent Skills are a curated set of reusable “skills” (prompt/tooling packages) you can add to an AI coding agent’s toolbox to help it work more effectively on WordPress-related development tasks.

They standardize *how* an AI agent is instructed to perform common WordPress workflows, so you don’t have to re-explain context every time (e.g., how to approach UI design, static analysis, caching, and database optimization, etc.).

They aim to make agents:

- Safer, because they bake in best practices and guardrails
- More consistent and accounts for repeatable workflows
- Faster to onboard, as agents get immediate context

## How they’re installed

Agent Skills are pulled into your agent’s environment in one of two ways:

1. **Project-local install**: Skills live inside your project directory, so everyone on the project can use the same behaviors.
2. **Global install**: Skills live in the user’s coding agent configuration directory, so they apply across all projects.

In both cases, the coding agent reads the skills from disk and incorporates them into its operating instructions.

Because skills are content files, the safest update model is:

- Treat skills as versioned assets
- Periodically pull updates
- Review diffs before rolling them out broadly (especially for team-wide/shared setups)

If you’re using [WordPress Studio](https://developer.wordpress.com/docs/developer-tools/studio), check out our [Agent Skills in WordPress Studio doc](https://developer.wordpress.com/docs/developer-tools/studio/agent-skills-wordpress-studio/) to learn how to install skills globally or per site.

## What WordPress Agent Skills are available?

The list of available Agent Skills may change, so be sure to visit the[ public repo ](https://github.com/WordPress/agent-skills/)for the most up-to-date information.

There are skills for many WordPress fundamentals, including:

- Block development
- Plugin development
- REST API
- WordPress Playground
- Performance
- Interactivity API
- Design

## Installation options

There are a few ways to integrate `agent-skills`, depending on your environment and how you prefer to manage dependencies.

### Option 1: skills.sh

If you want a quick install without cloning and building the repo manually, use [skills.sh](https://skills.sh/), an installation helper that makes it easy to add agent skill files into your local environment.

Prerequisite: [Node.js](https://nodejs.org/en) (so you can run npx commands)

1. [Choose the skills](https://github.com/WordPress/agent-skills#available-skills) you want to install. You can also run `npx skills add https://github.com/WordPress/agent-skills --list` to view the names of all available skills.
2. Install skills. For example, the following would install `wordpress-router`, `wp-project-triage`, `wp-block-development`, `wp-block-themes`, and `wp-plugin-development` for Claude Code:

```
npx skills add https://github.com/WordPress/agent-skills
--agent claude-code
--skill wordpress-router
--skill wp-project-triage
--skill wp-block-development
--skill wp-block-themes
--skill wp-plugin-development
```

To target a different agent, swap `--agent claude-code` for your agent (for example, `--agent cursor`). You can also install to multiple agents by passing multiple `--agent` arguments.

During installation, you’ll be asked whether to install the skills globally or per project. Install skills globally by default by using the `--global` argument

To remove a skill, run `npx skills remove wp-block-themes`, swapping `wp-block-themes` for the skill you wish to remove.

To check for updates, run `npx skills check` and then `npx skills update` to update.

When removing skills or running updates, use the same scope as when you installed them. Global installs (`--global`) affects your machine-wide skills, while project installs affect the skills checked stored alongside that codebase.

### Option 2:

If you need full control, or you’re contributing to the skills themselves, [clone the skills repo](https://github.com/WordPress/agent-skills) and follow [the manual build/install steps](https://github.com/WordPress/agent-skills?tab=readme-ov-file#quick-start).

## Choosing skills: “all” vs “relevant” skills

You may not need all of the available Agent Skills for your project. Instead, you can add skills based on what you’re working on. For example:

- **Blocks / Gutenberg development**: `wp-block-developmen`t and `wp-interactivity-api`
- **Block themes/site editing**: `wp-block-themes` and `wpds`
- **Plugin development**: `wp-plugin-development` and `wp-abilities-api`

Install all skills when you’re:

- Doing broad refactors across multiple areas (blocks + themes + plugins), or
- Building platform tooling where you want maximum coverage.
26 changes: 26 additions & 0 deletions content/runtime/documentation/api/developer-console.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
type: document
title: Developer console
description: ""
resource: "https://bountiful-impassioned-hygiea.wpcloudstation.dev/developer-wordpress-com-documentation/developer-console/"
tags:
timestamp: "2026-06-16T19:29:27+00:00"
wordpress:
id: 2498
status: publish
type: documentation
author: 0
date: "2026-06-16 19:29:27"
date_gmt: "2026-06-16 19:29:27"
modified: "2026-06-16 19:29:30"
modified_gmt: "2026-06-16 19:29:30"
slug: developer-console
parent: 2499
menu_order: 0
comment_status: closed
ping_status: closed
guid: "https://bountiful-impassioned-hygiea.wpcloudstation.dev/developer-wordpress-com-documentation/developer-console/"
comment_count: 0
---


Loading