Add marketplace scaffolding and healthypress - #1
Merged
Merged
Conversation
Turns this repo into a Claude Code plugin marketplace of WordPress use cases, where each plugin teaches an agent to use stock WordPress as the substrate for a specific real-world job. HealthyPress is the first: a private WordPress.com site as a personal health record. Marketplace scaffolding: - .claude-plugin/marketplace.json declares everything inline (house style; no per-plugin plugin.json), with explicit skills and commands arrays because an omitted path silently disables the component. - CI validates the manifest, asserts every declared path exists, warns about on-disk components that aren't declared, checks SKILL.md frontmatter, checks the dual MCP tool-name prefixes, and checks the duplicated guardrail block is byte-identical. - docs/use-case-template/ is an inert copy-me skeleton; CONTRIBUTING covers the core-only rule, runtime schema discovery, and skill shape. - docs/wpcom-mcp-notes.md records what's settled about the WordPress.com MCP and, separately, seven open questions with the check for each. HealthyPress (5 commands, 4 skills, core-only — no PHP, no custom post types, no companion WordPress plugin): - The content model: a post is an event at a point in time, a page is a current-state projection derived from posts. Closed hierarchical category list, namespaced entity tags, required excerpts, the event date as the post date with midpoint sentinels for fuzzy dates. - /setup gates on privacy: status, launch, set Private, set blog_public, then read back — and stops hard if the read-back isn't Private. No content is written before that. Idempotent, so it doubles as an audit. - /log, /backfill, /share, /review round out the workflow. /share only runs on a private site and states the Editor edit/trash tradeoff in plain language. - The recorder stance (no diagnosis, no treatment advice, no interpretation of results, with an acute-emergency exception) is duplicated verbatim in all four skills and all five commands, because skill loading is probabilistic. CONTRIBUTING and CLAUDE.md both say not to DRY it away. - The README states plainly that HIPAA does not apply, that transcripts are a second copy of the data, that media URLs on private sites are unverified, where the data model breaks down, and that a local encrypted notes file is the better answer for some users. Three of the seven open MCP questions are load-bearing (backdating alongside private status, exact privacy ordering, media URL protection). They are unresolved pending a live site, so the commands discover schemas at runtime and verify writes by reading them back rather than trusting a success response.
First live run of /healthypress:setup against a real site (and a real install of the plugin) falsified several assumptions the plan treated as settled. Most of these were only discoverable by actually calling the API, which is why the design mandated runtime discovery and read-back verification in the first place. The dangerous one — the privacy gate no longer launches the site: The plan asserted that a freshly provisioned site sits in Coming Soon and that Private only becomes selectable after launching, so setup ran launch -> privatize -> verify. A new site actually reports visibility: private, launch_status: unlaunched, is_private: true. Launching is unnecessary and moves the site *toward* live, so the command as shipped would have caused the exact exposure the gate exists to prevent. Setup now reads status, changes visibility only when it is not already private, and never launches. The same launch-first ordering is corrected in the wpcom-mcp-operations skill. Authorization is a tool-driven handshake, not native: An unauthenticated server exposes only `authenticate` and `complete_authentication` — the facade tools are absent entirely, so an unauthorized server looks like one with no capabilities. Claude Code's native OAuth for http servers does not complete it. All five commands now perform the handshake themselves, opening the URL in the user's browser, rather than sending them off to configure /mcp. The OAuth grant is also account-wide rather than site-scoped, which is now disclosed in the README and before the consent prompt. Setup no longer picks sites: /healthypress:setup creates a dedicated site by default and never lists existing ones. Passing a site argument means audit mode: re-harden and re-verify a site HealthyPress already set up, refusing to touch one without HealthyPress structure. Removes both the friction and the footgun of pointing setup at a real site. Capabilities that do not exist, now reported as gaps instead of claimed: - No `default_category` field, so needs-triage cannot be made the site default. That safety net rests entirely on /log assigning a leaf. - No `default_comment_status` / `default_ping_status`, so comments and pingbacks cannot be disabled site-wide. Only "require login to comment" exists. - `users_can_register: false` returns success with a before/after transition and never persists. Reproduced twice. A false success report, not a dropped parameter — the strongest argument yet for reading every write back rather than trusting its response. Answered two of the seven open questions, and recorded eleven findings in docs/wpcom-mcp-notes.md with dates and methods: privacy ordering (2) and per-write user_confirmed semantics (5), the latter confirming the backfill design of batching the asking rather than the writing. Questions 1, 3, 4, 6 and 7 remain open, with question 1 — backdating alongside private status — still the one that decides whether /backfill is viable. Taxonomy creation stays in setup, now written against the verified API: `parent` takes a numeric category ID rather than a slug, so containers must be created first and their IDs threaded into the leaves.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
First commit that is creating scaffolding. HealthPress use case not fully functional. Tested through setup command and ensured that site gets created alongside categories, but needs more testing and polish.