Communitygithub.com

umairmsm/wp-operate

Étape 8 de la construction WordPress wp-site-kit : sauvegardes, restauration, plan de reprise après sinistre, inventaire des identifiants, politique de mise à jour, alertes et travail multi-machine.

Qu'est-ce que wp-operate ?

Ce skill (umairmsm/wp-operate) représente l'étape 8 – Opération – du kit de construction WordPress wp-site-kit. Il couvre tout ce qui se passe après le lancement : sauvegardes régulières avec copie hors-machine, exercices de restauration trimestriels, un runbook de reprise après sinistre, un inventaire complet des identifiants, une politique de mise à jour des plugins (d'abord en staging), des alertes, et la capacité à travailler depuis plusieurs machines. Il est conçu pour Claude Code et tout agent capable d'exécuter des scripts bash et de suivre des instructions markdown. L'utilisateur peut demander 'backup', 'restore', 'move to a new machine/server', 'update plugins', 'what if the server dies', 'work from the cloud box', ou 'set up a second machine'. Le skill propose des scripts (backup.sh, workstation-doctor.sh, make-state-bundle.sh) et des fichiers de référence (DISASTER_RECOVERY.md, CREDENTIALS_INVENTORY.md, OPERATIONS.md, BRIDGE.md). Il apprend des leçons concrètes sur les pièges courants (mauvais dossier mémoire Claude, branches perdues sur une VM cloud, baselines visuelles dépendantes de l'OS).

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/umairmsm/wp-site-kit/tree/HEAD/skills/wp-operate

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Étape 8 : Opération

Objectif : le site survit à un ordinateur perdu, un serveur mort, une mauvaise mise à jour et un changement de machine, et personne n'a besoin de se souvenir comment faire.

Étapes

  1. Sauvegardes.
    • Exécutez scripts/backup.sh chaque semaine, et avant tout travail risqué. Il empaquette la base de données, les uploads, chaque branche git et stash, ainsi que la mémoire de Claude.
    • Utilisez --encrypt avant que le zip ne quitte la machine, et conservez une copie hors de celle-ci.
    • En production : les sauvegardes quotidiennes de l'hébergeur, plus les dumps que les scripts de déploiement et de contenu génèrent.
  2. Notez où tout se trouve dans le fichier docs/reference/DISASTER_RECOVERY.md du projet, section 0. Incluez le dossier des photos originales : il n'est pas dans git.
  3. Exercice de restauration. Restaurez une fois par trimestre sur une machine de rechange ou un projet DDEV vierge, chronométrez-le, et consignez-le dans la §5. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas une sauvegarde.
  4. Identifiants : chaque secret a une ligne dans CREDENTIALS_INVENTORY.md (nom, où il se trouve, qui l'a, date de rotation). Faites pivoter tout ce qu'un agent a vu.
  5. Routines : vérifications hebdomadaires, mensuelles et annuelles, politique de mise à jour et alertes dans docs/reference/OPERATIONS.md. Les mises à jour de plugins passent d'abord par la staging.
  6. Plusieurs machines ? Suivez references/multi-machine.md :
    • docs/team/BRIDGE.md contient les rôles, les règles et le journal de passation ;
    • scripts/workstation-doctor.sh vérifie la parité ;
    • scripts/make-state-bundle.sh emporte la configuration ignorée par git, chiffrée.

Porte (cocher dans SITE_STATUS.md)

  • Sauvegardes planifiées, avec une copie hors-machine
  • Exercice de restauration effectué (date, durée)
  • Routines de mise à jour et d'alerte rédigées dans OPERATIONS.md

Leçons

  • Le script de sauvegarde a un jour pointé vers le mauvais dossier mémoire de Claude. Les sessions s'exécutaient depuis le dossier parent, donc la mémoire se trouvait sous un chemin différent. Le script dérive le chemin mais accepte CLAUDE_MEM= pour ce cas.
  • Une machine de build cloud avait une branche et des stashes qui n'existaient nulle part ailleurs, et la machine ne pouvait pas pusher. Extrayez-les avec git bundle via SSH avant que la machine ne soit arrêtée ou supprimée.
  • Les baselines visuelles faites sur un OS échouent sur un autre. Conservez-les dans l'image Docker épinglée.
  • Un plan gratuit ou un crédit qui expire à une date donnée est une date limite pour un exercice de sortie : une semaine avant, prouvez que vous pouvez reconstruire sur la machine suivante à partir de git + du bundle d'état + d'une sauvegarde.

Individual skills in this repo

This repo contains 7 individual skills — each has its own dedicated page.

umairmsm/wp-build

Stage 3 of a wp-site-kit WordPress build - local DDEV site, the core must-use plugin (modules), the presentation-only child theme with skins, the content model (custom post types, meta, WP_Query, render functions), and the enquiry pipeline that saves leads before forwarding. Use when building or changing features, templates, content types, forms or plugin modules on a wp-site-kit site.

umairmsm/wp-content

Stage 4 of a wp-site-kit WordPress build - real copy and photos. Content truth (facts only from the owner), AI drafts and owner approval, claims audits, banned words and fake proof, legal pages, the photo pipeline (dedupe, real-only, EXIF strip, WebP sizes, alt text, AI image register), and recorded content changes. Use for "write the copy", "add photos", "the owner sent new photos", "check for duplicates", "update prices or text on the live site", "legal pages".

umairmsm/wp-design

Stage 2 of a wp-site-kit WordPress build - design direction, a static HTML/CSS prototype with design tokens, owner sign-off with screenshots, self-hosted fonts, and porting the approved look into a swappable WordPress skin. Use for "design the site", "new look", "redesign", "change colours or fonts", "make a new skin", "port the prototype to WordPress".

umairmsm/wp-kickoff

Stage 1 of a wp-site-kit WordPress build. Use when starting a new WordPress website or taking over or rebuilding an existing one - discovery brief, stack decision, creating the project with bin/wp-site-new, locked decisions, private repo and credentials inventory. Triggers - "new WordPress site", "start a client website", "rebuild this site", "take over this WordPress site".

umairmsm/wp-seo

Stage 5 of a wp-site-kit WordPress build - titles and descriptions, canonical URLs, one schema owner and JSON-LD, sitemaps, robots.txt and llms.txt, AI crawler access, redirects (301 vs 302), legacy URL maps, Search Console, and adding languages one pilot at a time with Polylang (hreflang, .po/.mo strings, native review). Use for "SEO", "schema", "redirect", "old URLs", "translate the site", "add French/Spanish", "hreflang", "canonical".

umairmsm/wp-ship

Stage 7 of a wp-site-kit WordPress build - staging behind Cloudflare Access, server hardening, safe deploys from a commit (scripts/deploy-safe.sh), database content changes, the launch audit, DNS cutover without breaking a running business, and the first week after launch. Use for "deploy", "set up staging", "go live", "launch", "cutover", "move DNS", "harden the server".

umairmsm/wp-site

Start here for any WordPress website built with wp-site-kit, from an empty folder to a live site. Use when someone says "build a WordPress site", "new website for a client", "where are we on the site", "what is next before launch", or asks to continue a site project. Finds the current stage from SITE_STATUS.md, applies the hard rules, and hands over to the right stage skill.

Skills associés