Update to Product Design

{
  "name": "audit",
  "description": "Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings from that evidence. Default to an inline report; use a canvas for a visual walkthrough when requested or clearly implied by the ongoing task. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 261
    },
    {
      "relative_path": "references/design-audit-framework.md",
      "size_in_bytes": 2028
    }
  ],
  "skill_md_contents": "---\nname: audit\ndescription: \"Audit or critique a product flow, journey, workflow, funnel, onboarding path, checkout path, settings path, screen, or multi-step product experience by capturing screenshots first, then reporting UX, design, and accessibility findings from that evidence. Default to an inline report; use a canvas for a visual walkthrough when requested or clearly implied by the ongoing task. Use when the user asks to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product experience.\"\n---\n\n# Audit\n\nUse this skill when the user wants to audit, review, critique, inspect, assess, analyze, evaluate, or give feedback on a product flow, journey, funnel, onboarding path, checkout path, settings path, screen, or other product experience.\n\nRecognize that intent from the ongoing task; the user need not name the audit skill.\n\nThe output is not a loose opinion. The output is:\n\n- Screenshots of the flow\n- Those screenshots presented in a report or a visual walkthrough on the user's chosen canvas\n- A numbered step list\n- UX and design findings tied to steps or screenshots\n- Accessibility risks tied to steps or screenshots\n- Clear limits on what could not be checked from screenshots alone\n\n## Critical Overrides\n\n- Refer to the Plugin router [$index](../index/SKILL.md) before proceeding.\n- Follow [$critical-overrides](../../references/critical-overrides.md).\n\n## User Context\n\nBefore starting, load [$user-context](../user-context/SKILL.md) and run its preflight script when local shell access is available.\n\nUse saved product URLs, Figma files, screenshots, reference images, codebase paths, Storybook, tokens, design systems, brand assets, component refs, browser preferences, and share targets as grounding material when relevant.\n\nDo not inspect every saved reference. Inspect only what the current task needs.\n\n## Route\n\nBefore auditing:\n\n1. Identify the product or surface.\n2. Identify the flow or task.\n3. Choose the capture tool.\n4. Capture the flow.\n5. Save and inspect each screenshot.\n6. Present the accepted screenshots and findings in the user's chosen format, defaulting to an inline report.\n\nOutput rules:\n\n- Honor the output format and canvas already stated or clearly implied by the ongoing task. Proceed without reasking settled choices; if a canvas walkthrough is chosen but its destination is unclear, ask only which canvas to use.\n- If no output format is established, default to a concise inline report with screenshots rendered in the chat.\n- Saving screenshots and notes in the workspace is an internal implementation detail. Do not ask the user to choose a local folder.\n- Let the user choose a report with screenshots or a visual walkthrough: screenshots laid out step by step on a canvas, with notes beside each screen.\n- Only if no output format has been established or declined, offer a canvas walkthrough at most once. With no established tool preference, ask: `Would you like these screenshots laid out step by step on a canvas, with notes for each screen?`\n- Within that single offer, suggest Figma or another design tool only when the user's request or relevant saved context or memory indicates they use it and available tools can create the walkthrough. Tool availability alone is not a reason to promote it; saved tool usage alone does not select a canvas output.\n- If the user chooses a canvas walkthrough, follow their chosen tool's skills to arrange the screenshots and notes in flow order. Return a link and concise summary inline; include a full inline report only if requested.\n\nCapture rules:\n\n- Follow the Browser Choice rule in [$index](../index/SKILL.md#browser-choice).\n- If none of those can capture valid screenshots or control the flow, stop and report the blocker.\n\nBrowser capture order:\n\n1. Load the Browser skill before browser work.\n2. Connect to the browser and use the current tab when it already shows the target.\n3. Do not reload or navigate away unless the audit needs a fresh start.\n4. Observe the visible state before acting.\n5. Before each click, type, or key press, use the latest DOM snapshot to target one clear control.\n6. After each action, take the cheapest fresh check that proves what changed: DOM for structure, screenshot for visual state.\n7. Save and inspect the accepted screenshot before using it as audit evidence.\n\nCanvas rules:\n\n- Load the chosen tool's skills before creating or editing the canvas.\n- Keep a local copy of every screenshot even when the canvas succeeds.\n- Do not upload a screenshot until the saved local file has been inspected and accepted.\n- The walkthrough is not done until the screenshots and notes are visibly placed on the canvas.\n- Render or inspect the canvas and confirm every flow step has the correct screenshot and its notes visible together in flow order.\n- If an image is missing, misplaced, blank, or only uploaded as an unused asset, fix it before handoff.\n- If the chosen tool cannot create the canvas or place images, return the inline audit and explain the missing capability.\n\nEvidence rules:\n\n- Use only evidence captured in the current audit run.\n- Do not use memory, prior chats, old traces, cached screenshots, or prior generated artifacts as audit evidence unless the user explicitly provides them.\n- Do not audit until the product, flow, and capture tool are known.\n- Do not claim full accessibility compliance from screenshots alone.\n\n## Capture And Audit The Flow\n\nYou are an expert design, UX, and accessibility auditor. For each step in the flow, capture what the user sees, observe how the screen behaves, inspect the screenshot, and write audit notes before moving on.\n\nFollow [references/design-audit-framework.md](references/design-audit-framework.md) when deciding what to inspect and how to describe strengths, UX issues, accessibility risks, limits, and recommendations.\n\nScreenshot source rule:\n\n- Use the screenshot you actually saw.\n- Save that exact screenshot to the local audit folder.\n- Open or inspect the saved file before accepting it.\n- If the saved file shows the wrong window, wrong state, blank page, crop, or loading screen, reject it and capture again.\n- When a canvas is the destination, upload that accepted local file.\n- After upload, verify the canvas shows the same step.\n- Do not replace a Browser, Chrome, or Computer Use screenshot with an OS screenshot unless you first prove the saved file shows the same window and state.\n\nFor every step:\n\n1. Move to the next step in the requested flow.\n2. Wait until the screen is loaded and visually stable.\n3. Check for loading spinners, blank areas, login walls, error pages, blocked states, cookie dialogs, and half-rendered content.\n4. Capture the screenshot.\n5. Inspect the screenshot before accepting it.\n6. Reject the screenshot if it is blank, loading, cropped, blocked, or showing the wrong state.\n7. Observe behavior that matters for the audit, such as navigation, focus, loading, validation, error handling, empty states, motion, and whether the next action is clear.\n8. Write notes for that step.\n9. In the notes, report strengths, UX issues, accessibility risks, and any limits that made the step difficult to audit.\n10. Save accepted screenshots with numbered names, such as `01-start.png`, `02-form-filled.png`, and `03-confirmation.png`.\n11. Inspect the saved screenshot file before upload or handoff.\n12. Keep each accepted screenshot and its notes together for the report or canvas walkthrough.\n13. If the user requested a canvas walkthrough, add each accepted screenshot and its notes to the canvas immediately.\n\nDefault inline report:\n\n- Render accepted screenshots in flow order.\n- Keep the report pithy: overall verdict, numbered steps, highest-impact changes, and evidence limits.\n- Tie every finding to the screenshot or step that supports it.\n\nIf the user requested a canvas walkthrough:\n\n- Place screenshots in order, left to right on the same row, with 200px between each one. Go to a new row every 15 screenshots, and separate those rows by 600px.\n- Underneath the screenshot, add text with the Step number and its name, and notes.\n- Keep a local folder copy even when the canvas succeeds.\n- Give the walkthrough a title and group its assets in a section or equivalent container supported by the chosen tool.\n\nAcceptance checks:\n\n- Every important step in the requested flow has a valid screenshot or a named blocker.\n- Screenshots are saved in order.\n- Screenshots are visible in the chosen output: inline in the report or arranged in flow order on the canvas.\n- For a canvas walkthrough, every accepted screenshot and its notes are visibly placed together in flow order and verified on the completed canvas.\n- Every note points to the screenshot or step it describes.\n- Notes explain strengths, UX issues, accessibility risks, and evidence limits when those apply.\n- Accessibility risks say what can be seen from screenshots and what still needs testing.\n- The final screenshot set and notes are enough to support the requested audit.\n\nBlockers:\n\n- The flow cannot be completed.\n- A required step cannot be screenshotted.\n- The source changes in a way that makes the flow unclear.\n- Screenshots cannot be saved or displayed in the chosen output.\n- Notes cannot be written.\n- The requested claim would require evidence that screenshots cannot provide.\n- Do not claim an audit if the actual flow could not be accessed and captured. Help Center pages, web searches, and other indirect evidence are research, not an audit.\n\n## Final Response\n\nAfter the flow is captured and notes are written, list every step in the final response.\n\nThe final step list MUST include:\n\n- step number\n- short description of the step\n- general health of that step\n\nAlso include where the full output was saved or placed.\n\nKeep the language direct. Do not use broad design jargon when a plain phrase works.\n"
}