Update to RefreshAgent

{
  "description": "Safely inspect, preview, apply, verify, and roll back SEO title and metadata changes on WordPress sites connected to RefreshAgent.",
  "included_files": [],
  "name": "wordpress-seo-execution",
  "skill_md_contents": "---\nname: wordpress-seo-execution\ndescription: Safely inspect, preview, apply, verify, and roll back SEO title and metadata changes on WordPress sites connected to RefreshAgent.\n---\n\n# WordPress SEO execution\n\nUse RefreshAgent as the controlled execution layer between SEO evidence and WordPress. The host model supplies the reasoning. Never skip the preview/approval step.\n\n## Safety contract\n\nFor any WordPress mutation:\n\n1. Establish the evidence first. Use Search Console/GA4 tools when the requested change is based on SEO performance.\n2. Call `list_wordpress_sites` if the target WordPress connection is ambiguous.\n3. When SEO evidence identifies a URL rather than a WordPress ID, call `wordpress_resolve_url`.\n4. Call `wordpress_get_content` when the page body materially affects the recommendation.\n5. Call `wordpress_inspect_seo` before recommending an edit.\n6. Call `wordpress_preview_seo_change` with the exact proposed fields.\n7. Show the user the meaningful before/after diff and the reason for the change.\n8. Do **not** call `wordpress_apply_seo_change` until the user explicitly approves that exact preview.\n9. Pass the unchanged `expected_fingerprint` returned by preview when applying.\n10. After apply, immediately call `wordpress_verify_seo_change` and report both database state and live-rendered verification.\n11. Offer rollback when the user asks to undo the specific change. Use `wordpress_rollback_seo_change`; never manufacture a reverse edit manually.\n\nIf apply reports a stale-preview error, inspect and preview again. Do not reuse the old fingerprint.\n\nIf rollback reports a conflict, stop. That means the affected fields changed after RefreshAgent's edit and rollback would risk overwriting later work.\n\n## Supported fields\n\nThe MVP execution surface supports:\n\n- WordPress post/page title;\n- SEO title;\n- meta description.\n\nSEO metadata is provider-aware:\n\n- Yoast SEO;\n- Rank Math;\n- RefreshAgent fallback when neither is active.\n\nIf provider resolution is ambiguous, inspect first and explicitly select the intended provider rather than guessing.\n\n## Evidence-led CTR workflow\n\nFor a request such as \"fix my best CTR opportunity\":\n\n1. `find_ctr_opportunities`\n2. choose the relevant page/query based on returned evidence;\n3. `wordpress_resolve_url` using the returned page URL;\n4. `wordpress_get_content` when page context is needed;\n5. `wordpress_inspect_seo`;\n6. reason about a proposed title/meta change;\n7. `wordpress_preview_seo_change`;\n8. show evidence + exact diff;\n9. wait for explicit approval;\n10. `wordpress_apply_seo_change`;\n11. `wordpress_verify_seo_change`.\n\nDo not claim that a title/meta change will improve rankings or CTR. Describe it as a hypothesis tied to observed evidence and measure the later outcome.\n\n## Read vs write access\n\nInspection, preview, and verification use read access. Apply and rollback require RefreshAgent's separate `seo:write` OAuth scope. A client without write permission should still be able to diagnose and preview changes.\n"
}