chore: publish from staged

This commit is contained in:
github-actions[bot]
2026-05-04 06:34:46 +00:00
parent b644d55e12
commit f503ffa543
536 changed files with 116819 additions and 294 deletions

View File

@@ -0,0 +1,106 @@
---
name: content-management-systems
description: 'Workflow for building and modifying content management systems across WordPress, Shopify, Wix, Squarespace, Drupal, WooCommerce, Joomla, HubSpot CMS Hub, Webflow, Adobe Experience Manager, and similar platforms. Use when working on CMS themes, plugins, apps, modules, admin panels, media uploads, content models, editors, markdown pipelines, or static export workflows.'
---
# Content Management Systems
Use this skill when the user is working on a content management system or on software that behaves like one.
This skill focuses on the seams that matter in CMS work:
- themes and templates
- plugins, apps, modules, and extensions
- admin and editor interfaces
- media and upload handling
- content models, taxonomy, and metadata
- render pipelines and static export flows
## When to Use This Skill
- The user mentions a CMS platform such as WordPress, Shopify, Drupal, Joomla, Webflow, Squarespace, Wix, WooCommerce, HubSpot CMS Hub, or Adobe Experience Manager.
- The task is about theme development, template changes, or design system work inside a CMS.
- The task is about plugins, modules, apps, or extension points.
- The task touches editor UX, previews, taxonomy, slugs, SEO fields, or publishing behavior.
- The task involves uploads, media libraries, authored assets, markdown rendering, or static export.
## First Pass
1. Identify the platform category: self-hosted CMS, SaaS site builder, commerce platform, or hybrid/headless system.
2. Find the owning implementation seam before editing:
- theme or template layer
- plugin, app, module, or extension layer
- admin or editor surface
- content model or storage layer
- media pipeline
- export, deploy, or rendering pipeline
3. Check platform constraints before choosing an approach:
- what is editable locally
- what is authored content versus code
- where media belongs
- whether the final site is server-rendered, static-exported, or hosted remotely
## CMS Rules
- Follow the platform's naming and folder conventions for themes, modules, template parts, or sections.
- Keep theme assets separate from user-uploaded media unless the platform explicitly combines them.
- Prefer structured content fields over storing important metadata inside presentation markup.
- Treat previews, slugs, taxonomy, excerpts, meta fields, and publish states as first-class CMS concerns.
- Prefer safe defaults and graceful fallback behavior when config, theme selection, or content input is invalid.
- When changing editor or admin behavior, trace the stored field, validation rules, preview path, and final render path together.
## Common Workflows
### Themes and Templates
- Start at the template loader or theme runtime, not at a downstream include.
- Preserve the platform's template hierarchy and partial naming conventions.
- Keep presentation changes close to templates and shared theme helpers.
### Plugins, Apps, and Modules
- Add behavior at the platform's extension seam instead of scattering logic into templates.
- Keep migrations, seed data, and configuration updates explicit and versioned.
- Document the extension's setup assumptions when the platform requires activation or registration.
### Admin and Editor UX
- Keep forms aligned with the stored content model.
- Prefer author-facing previews when content transformations are non-trivial.
- Keep validation, CSRF or equivalent safeguards, and permissions consistent with the surrounding admin code.
### Media and Uploads
- Use a dedicated upload path for authored media.
- Keep decorative or theme-owned imagery in the active theme folder.
- Default to conventional locations like `uploads/` for authored media and `img/` for theme assets unless the platform dictates a stronger convention.
- When a CMS supports configurable media directories, expose the setting with a safe fallback.
### Content Models and Migrations
- Distinguish content entities clearly: pages, posts, products, entries, collections, taxonomies, and settings.
- Prefer migration files or exportable schema definitions over ad hoc runtime mutations.
- Keep slugs, publish dates, excerpts, canonical metadata, and taxonomy relations structured.
### Markdown, HTML, and Static Export
- Decide whether markdown is authored input, intermediate content, or build output before changing the renderer.
- Pair renderer changes with preview or validation when feasible.
- For static-exported CMS systems, validate rewritten permalinks and asset paths after build changes.
## Identifying the Owning Seam
Regardless of platform, locate the owning seam before editing by mapping the codebase to these CMS roles:
- Runtime bootstrap and request routing
- Admin or editor controllers and their view templates
- Theme loading, template hierarchy, and shared template helpers
- Repositories, models, or schema/migration files for content, taxonomy, and settings
- Markdown or content transformation utilities
- Static export, deploy, or render pipeline entry points
Step to the owning seam first, then make the smallest change that preserves the CMS structure.
## Platform Notes
See `references/cms-platform-workflows.md` for a compact mapping of common CMS platforms, extension surfaces, and media conventions.

View File

@@ -0,0 +1,37 @@
# CMS Platform Workflows
This reference keeps the high-level platform map close to the skill so the agent can choose the right seam quickly.
## Platform Map
| Platform | Primary extension surfaces | Media and asset convention | Notes |
| --- | --- | --- | --- |
| WordPress | Themes, plugins, template parts, hooks | Theme assets inside the active theme; authored media under uploads-style paths | Good fit for template hierarchy, taxonomy, custom fields, and local/static export workflows |
| WooCommerce | WordPress themes and plugins plus product/catalog extensions | Same base conventions as WordPress, with product imagery as authored media | Treat it as WordPress first, then apply commerce-specific content and admin rules |
| Shopify | Themes, Liquid sections, blocks, apps, metafields | Theme assets and hosted store media are distinct concerns | Prefer app or metafield seams over theme-only hacks when data must survive redesigns |
| Wix | Site builder surfaces, apps, content collections, custom elements | Hosted media library plus editor-managed assets | Favor editor-safe changes and avoid assuming file-system level access |
| Squarespace | Templates, code injection, content collections, commerce settings | Hosted asset library managed through the platform | Expect narrower extension points and stronger hosted constraints |
| Drupal | Themes, modules, content types, views, taxonomy | Managed files and theme assets are separate | Strong fit for structured content, enterprise workflows, and migration-heavy changes |
| Joomla | Templates, modules, components, plugins | Managed media plus template-owned assets | Similar split between templates and extensions; watch routing and content component boundaries |
| HubSpot CMS Hub | Themes, modules, templates, serverless functions, CRM-linked content | Hosted file manager plus theme assets | Content, marketing, and CRM concerns are tightly coupled |
| Webflow | Designer, CMS collections, components, embeds, limited code export | Hosted assets and CMS collection media | Export constraints matter; distinguish what survives export from what depends on hosted CMS features |
| Adobe Experience Manager | Components, templates, content fragments, experience fragments, workflows | DAM-managed assets plus component resources | Enterprise governance, authoring workflows, and content fragment models drive most changes |
## Media Rule of Thumb
- Theme-owned images belong with the theme or template package.
- User-authored images belong in the platform's upload or media-library flow.
- If a project supports both, keep them distinct in config and in code paths.
## Generic CMS Responsibility Map
Most CMS codebases group behavior into the same handful of responsibilities. Use this as a checklist when locating the owning seam in any project:
- Runtime assembly and request routing
- Theme or template system and shared template helpers
- Admin and editor controllers with their view templates
- Content, taxonomy, and settings persistence (repositories, models, schema/migrations)
- Content transformation utilities (markdown, shortcodes, block renderers)
- Static export, deploy, or render pipeline entry points
Map the project to these responsibilities first, then make the smallest change that preserves the platform's structure.