Cms integration
Skill Gekkos-tech/agency-os/plugins/agency-core/skills/cms-integration
The complete Claude Code toolkit for web & advertising design agencies — 6 plugin bundles for the full agency workflow
npx -y skills add Gekkos-tech/agency-os --skill cms-integrationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Choose and integrate the right CMS for a client website — decision tree (client editing needs, budget, hosting, stack) plus integration patterns for Payload, Sanity, Storyblok, Strapi, Decap, and headless WordPress, and a client-handover checklist. Use when the user asks "which CMS", "add a CMS", "the client wants to edit content themselves", "Kunde soll Inhalte selbst pflegen", "WordPress or something modern", "headless CMS", or when the BUILD phase reveals editable content requirements. Covers selection, modeling content from the design handoff, preview setup, and editor training. NOT for building the site's frontend (BUILD phase skills), NOT for content strategy or SEO content (seo-content), NOT for one-off static sites where nothing needs client editing — recommending "no CMS" is a valid outcome of this skill.
SKILL.md
4.3 KB, as published. Nobody here has run it
CMS Integration
Most client sites need SOME editable content — and most agencies either over-engineer (full CMS for two text fields) or under-engineer (client calls you for every typo). This skill picks the right tier and integrates it without breaking the design handoff.
Step 1 — Establish what actually needs editing
Before naming any system, list the editable surfaces from the brief/concept:
- Which content changes, how often, and by whom? (opening hours weekly ≠ legal pages yearly)
- Structured data (menu items, team members, jobs) or free-form pages?
- Does the client add PAGES, or only edit content within existing ones?
- Media uploads? Multilingual? Scheduled publishing? Multiple editors/roles?
If the honest answer is "a phone number and opening hours twice a year" — recommend no CMS: keep content in typed config/content files, offer a maintenance retainer instead. Say this explicitly; it's often the right call.
Step 2 — Decision tree
| Situation | Recommendation |
|---|---|
| Few fields, rare edits, technical-ish client | No CMS (content files + retainer) |
| Git-based site, budget-sensitive, simple editing | Decap CMS (free, edits commit to the repo) |
| Next.js project, client edits structured content, self-hosted preferred | Payload (TypeScript-native, lives in the repo, DSGVO-friendly self-hosting) |
| Content-heavy, multiple editors, real-time collaboration, budget exists | Sanity (hosted, excellent editor UX, GROQ) |
| Marketing team edits page LAYOUTS (visual composition), multi-language | Storyblok (visual editor, EU-hosted option) |
| Client insists on the WordPress admin they know / migration from WP | Headless WordPress (WP admin + REST/WPGraphQL, frontend stays yours) |
| Self-hosted requirement + non-JS backend team | Strapi |
DACH note: for DSGVO-sensitive clients, prefer self-hosted (Payload, Strapi,
Decap, WP on German hosting) or EU-region SaaS (Storyblok EU, Sanity EU
dataset) — and record the choice + data location in the privacy policy via
pre-launch-checklist.
Step 3 — Integration rules
- Model content FROM the handoff, not from the CMS's defaults. Every design section that contains editable content becomes a typed block/document with exactly the fields the design needs — no generic "rich text everything" fields that let editors break the layout.
- Constrain the editor. Character limits matching the design (headline lengths!), image fields with required aspect ratios, no free-form color or font options. The design system survives editors only if the schema enforces it.
- Preview before publish. Wire draft preview (framework preview mode or the CMS's preview URL) so the client sees changes in the real design.
- Keep the frontend the source of truth for presentation. CMS delivers content; components decide rendering. Never store HTML/CSS in the CMS.
- Plan the QA impact. CMS-driven pages need one extra QA pass with deliberately hostile content: longest realistic headline, missing image, empty optional field. See per-system patterns and the handover checklist in references/systems.md.
Step 4 — Handover
A CMS without editor training is a support contract you didn't price. Deliver: a 1-page editor guide per content type (in the client's language), a 15-minute walkthrough, and a named fallback contact. Details + checklist in references/systems.md.