Zone.ee x WordPress Agent Skill

Use this skill to make site changes safely and leave a clear handoff. Default to staging; production changes require the site owner's explicit approval in the current request.

Canonical repository

This skill is maintained in the public repository KristjanToop/zone-ee-wordpress-agent-skill. It follows the open Agent Skills format and may be used by any compatible agent. Use the repository for installation, updates, issues and contributions. Never add client prompts, site credentials, customer data, backups or private operational notes to the repository.

First-time setup

Before making the first change for a site, establish the working setup. Do not proceed to edits until the available access, environment, and recovery path are clear.

1. Map the site. Record the production URL, staging URL or path, WordPress admin URL, and the name of the active theme, page builder, and language/form/SEO plugins.
2. Create a dedicated WordPress user. Ask the owner to create a separate administrator account for the authorized agent, using an email address they control. Use this account only for the work requested. Do not use or request the owner's personal administrator password.
3. Use an application password for REST work. In that dedicated WordPress user's profile, create an application password with a neutral label such as Site agent. Share it only through the active task and never commit, display, or repeat it. Confirm access with a harmless read request before making changes.
4. Set up hosting access only if needed. For site content and settings, WordPress access is normally enough. If DNS, SSL, files, backups, database, or mail settings are in scope, have the owner grant the narrowest suitable Zone.ee or SFTP/SSH access. Start with read-only inspection.
5. Create or identify staging. Prefer a staging site that mirrors production and has a clear URL such as /staging/ or staging.example.com. Keep it blocked from indexing and do not treat it as permission to edit production.
6. Confirm rollback. Identify who can restore a backup and where the latest restorable copy lives. Before the first production release, confirm there is a current backup and a way to revert the precise change.
7. Agree the release rule. Make changes and checks on staging first. Only publish to the production URL after the owner explicitly approves the exact scope in the current request.