agentleFS
Sign inStart free
ForgeyClapForgeyClap/Forge-Core/.claude/skills/forge-cms/SKILL.md

forge-cms

Skill2 starsChanged 5 days agoMITView on GitHub

Playbook for WordPress and headless CMS: themes, plugins (gebruik bij een CMS).

1 other project uses a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use for: WordPress and headless CMS builds: content model, editor safety, the CMS attack surface, backup and migration.

    line 11
  2. Very specific:

    Not for: the rendered front-end (forge-website) or API/secret/webhook plumbing (forge-integration).

    line 12
  3. Very specific:

    No secrets in the theme/repo.

    line 39

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Forge playbook — CMS (WordPress · headless)

When to use

  • Use for: WordPress and headless CMS builds: content model, editor safety, the CMS attack surface, backup and migration.
  • Not for: the rendered front-end (forge-website) or API/secret/webhook plumbing (forge-integration).
  • Domain framing, team roles and honesty rule: references/overview.md.

Hard rules (non-negotiable)

  • Content model first.
  • No secrets in the theme or repo.
  • WordPress output/input safety.
  • Headless token + webhook hygiene.
  • Backup before change; reversible, staged migrations.
  • Keep it patched; least privilege.
  • Performance + accessibility are gates, not extras.

Full text of every rule: references/hard-rules.md.

Team (conditional)

Lead: build-boss (theme/plugin build) or integration-boss (headless integration + webhooks). Full roster: references/team-and-tools.md.

Skills / commands / MCP

Skills, commands, MCP and opt-in dependencies: references/team-and-tools.md.

Fan-out & flow

L2 for a single theme or headless integration; L3 for a full site with custom post types + migration + multiple templates. Serial: content model → backup → theme/plugin or headless integration → migration (reversible, on staging) → performance + a11y pass → SEO. Parallel: independent templates/components ∥ content-type definitions ∥ SEO / a11y / performance audits on rendered output (independent once the content model is fixed).

Domain gates

  • Content model defined (post types / fields / taxonomies or headless schema); editors can edit content without code.
  • No secrets in the theme/repo; wp-config values + API tokens in env; wp-config.php not committed.
  • WordPress: output escaped, input sanitized, $wpdb->prepare used; nonces + capability checks on state-changing actions; child theme (no core edits); third-party plugins vetted + version-pinned.
  • Headless: server-side tokens not exposed to the client; CMS→build webhooks signature-verified; CORS locked to known origins.
  • Backup taken before any migration/update; migrations reversible + tested on staging; serialized data changed with a serialization-safe tool (wp search-replace).
  • Performance (caching, image optimization, CWV budget — see ~/.claude/rules/ecc/web/performance.md) and a11y (semantic, alt text, heading order, contrast) verified on rendered output.
  • Core/themes/plugins on patched versions; user roles least-privilege.

Ship-readiness (unique)

Evidence checklist before handoff: references/ship-readiness.md.

Safety, approval and honesty

  • Approval / safety: back up DB + uploads before any plugin/theme/core update or content migration; migrate on staging first.
  • Approval / safety: no secrets in the theme or repo; wp-config.php with real values never in git; headless tokens server-side only.
  • Honest failure: without PHP + MySQL + WP-CLI (owner-side), mark backup, migration and live verification not-run.
  • Shared gates for every playbook (honesty, owner approval, secrets, reviews): .claude/docs/forge-reference/playbook-template.md.

References

  • references/overview.md — domain framing paragraph(s) from under the title.
  • references/hard-rules.md — full text of every hard rule.
  • references/team-and-tools.md — full team roster, skills, commands, MCP and opt-in runtimes.
  • references/ship-readiness.md — full ship-readiness evidence checklist.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free