Communitygithub.com

umairmsm/wp-operate

Estágio 8 de uma construção WordPress com wp-site-kit e tudo após o lançamento – backups com cópia fora da máquina, testes de restauração, playbook de recuperação de desastres, inventário de credenciais, política de atualizações, alertas e trabalho a partir de mais de uma máquina (arquivo de ponte, médico da estação de trabalho, pacote de estado criptografado, resgate de trabalho não enviado). Use para "backup", "restore", "mover para uma nova máquina/servidor", "atualizar plugins", "e se o servidor morrer", "trabalhar a partir da caixa na nuvem", "configurar uma segunda máquina".

O que é wp-operate?

Esta skill, chamada `Operate`, representa o Estágio 8 de um kit de construção de sites WordPress (`wp-site-kit`). Seu objetivo é garantir que o site sobreviva a perda de laptop, servidor morto, atualização mal-sucedida e troca de máquina, sem que ninguém precise decorar procedimentos. Ela cobre backups automatizados com cópia fora da máquina (usando `scripts/backup.sh`), testes de restauração trimestrais, documentação detalhada de recuperação de desastres em `DISASTER_RECOVERY.md`, inventário de credenciais em `CREDENTIALS_INVENTORY.md`, e rotinas de operação (semanais, mensais, anuais) com política de atualizações e alertas em `OPERATIONS.md`. Para ambientes com múltiplas máquinas, oferece suporte através de arquivo de ponte (`BRIDGE.md`), script de verificação de paridade (`workstation-doctor.sh`), e pacote de estado criptografado (`make-state-bundle.sh`). A skill é útil para desenvolvedores que gerenciam sites WordPress e desejam automação robusta para backup, restauração, migração e continuidade operacional, sendo compatível com assistentes de IA como Claude Code, Cursor e Codex.

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

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Estágio 8: Operar

Objetivo: o site sobrevive a um laptop perdido, um servidor morto, uma atualização ruim e uma troca de máquina, e ninguém precisa lembrar como.

Passos

  1. Backups.
    • Execute scripts/backup.sh semanalmente e antes de trabalhos arriscados. Ele empacota o banco de dados, uploads, todos os branches e stashes do git e a memória do Claude.
    • Use --encrypt antes de o zip sair da máquina e mantenha uma cópia fora dela.
    • Ao vivo: os backups diários do host, mais os dumps que os scripts de implantação e conteúdo geram.
  2. Anote onde tudo vive no docs/reference/DISASTER_RECOVERY.md do projeto, seção 0. Inclua a pasta de fotos originais: ela não está no git.
  3. Teste de restauração. Restaure uma vez por trimestre em uma máquina reserva ou em um projeto DDEV novo, cronometre e registre na §5. Um backup que você nunca restaurou é uma esperança, não um backup.
  4. Credenciais: cada segredo tem uma linha em CREDENTIALS_INVENTORY.md (nome, onde vive, quem tem, quando foi rotacionado). Rotacione qualquer coisa que um agente tenha visto.
  5. Rotinas: verificações semanais, mensais e anuais, política de atualizações e alertas em docs/reference/OPERATIONS.md. Atualizações de plugins vão para o staging primeiro.
  6. Mais de uma máquina? Siga references/multi-machine.md:
    • docs/team/BRIDGE.md guarda funções, regras e o registro de passagem;
    • scripts/workstation-doctor.sh verifica paridade;
    • scripts/make-state-bundle.sh carrega a configuração ignorada pelo git, criptografada.

Portão (marque em SITE_STATUS.md)

  • Backups agendados, com cópia fora da máquina
  • Teste de restauração feito (data, minutos)
  • Rotinas de atualização e alerta escritas em OPERATIONS.md

Lições

  • O script de backup já apontou para a pasta de memória do Claude errada. As sessões rodavam da pasta pai, então a memória vivia em um caminho diferente. O script deriva o caminho, mas aceita CLAUDE_MEM= para este caso.
  • Uma caixa de build na nuvem tinha um branch e stashes que não existiam em nenhum outro lugar, e a caixa não conseguia fazer push. Extraia-os com git bundle via ssh antes que a caixa pare ou seja deletada.
  • Linhas de base visuais feitas em um SO falham em outro. Mantenha-as na imagem Docker fixa.
  • Um plano gratuito ou crédito que termina em uma data é um prazo para um teste de saída: uma semana antes, prove que você consegue reconstruir na próxima máquina a partir do git + pacote de estado + um backup.

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.

Habilidades Relacionadas