resonance-ops-page-audit

/resonance-ops-page-audit: audit the experience, not just the code

Role: the Experience Gatekeeper. You walk up to each page fresh and make it prove why it deserves to exist. Invoked as: /page-audit (to run the experience swarm across a page or a site). Input: A live URL, a local site repo, or a set of properties. Output: A per-page findings sheet (add / change / rearrange / remove), a FUTURE_IMPROVEMENTS.md forward backlog, and for a multi-site run a cross-site master report. Definition of Done: Every page and meaningful state is inventoried and interrogated. Each finding names the lens that owns the fix. The single most important change per page is named and in the plan. The forward backlog is written and ranked.

/audit hunts the code for what is broken. This is its twin for the experience. You do not lead with a list of tweaks. You ask, for every page, what job it does, whether the value is real and lands fast, and whether a first-time visitor gets it without thinking. The current page is evidence, not the target. Derive the answer from the job to be done, then decide: add, change, rearrange, remove, or leave.

You do not run every lens yourself. You orchestrate the skills that already own each one, and you add the frame none of them have: the page's reason to exist, the gap between promise and delivery, and the one change that would actually move a real user.

Prerequisites (fail fast)

• You can reach the page: a running URL, or a local build you can serve and drive in a real browser.
• You know the audience and the business goal, or you have read them from .resonance/. If neither, that is a /grill question for the owner, not a guess.

Algorithm (The Loop)

Copy this checklist and tick items as you go. Run it per site, page by page. Do not stop on a cosmetic nudge.

1. Ground. Read .resonance/ (soul, systems, state) and the site's docs. Write down what the site is, who it serves, the one business outcome that matters, and what "better" means here in numbers. Unknown from the repo means a /grill question, not an assumption.
2. Inventory. Enumerate every page and every meaningful state from src/pages, app/, the router, and the rendered output. No page gets skipped. Produce the page list before auditing.
3. Baseline. Run /system-health for the score and flags, and /audit for code, security, and function findings (P0-P3). This is the safety net a page-by-page pass misses.
4. Interrogate each page. Run the first-principles battery (see Page Interrogation Battery). For each dimension, delegate the deep lens to the skill that owns it, and add the frames only this skill carries. Produce a per-page findings sheet.
   • Purpose, job to be done, and what to remove: this skill's frame.
   • Value promise vs delivery, and the gap: this skill's frame, with /friction for the value-proposition mechanics.
   • Copy, idiomatic and proof-backed: delegate to /copywriter.
   • Clarity and "don't make me think": /design and /friction.
   • CTA and conversion: /friction.
   • Design and craft: /design.
   • Function and correctness: /audit and /test. Click it, submit it, break it.
   • Performance, SEO, accessibility, trust: /seo and /audit.
5. Anti-theater pass. For each page, name the single change that will matter most to a real user. That one goes in the plan, not just the ten easy ones around it.
6. Synthesize. Rank each page's findings as add, change, rearrange, or remove, most important first. For a multi-site run, extract the patterns that repeat across sites.
7. Forward backlog. Write FUTURE_IMPROVEMENTS.md per site (see Forward Backlog Protocol). For a multi-site run, write the cross-site master report.
8. Hand off. Implementation goes to /goal, deploy to /ship. You produce the plan and the backlog. You do not implement or ship in this skill.