Update to DXD Skills

{
  "name": "ui-text-audit",
  "description": "Audit every user-facing screen for redundant, verbose, or unnecessary UI text and remove what doesn't help the user decide or act. Triggers on \"audit UI text\", \"trim copy\", \"remove redundant labels\", \"verbose UI\", \"too many words\", \"clean up screen text\", \"UI text review\", \"cut unnecessary copy\", or any request to tighten interface language across a project.",
  "included_files": [],
  "skill_md_contents": "---\nname: ui-text-audit\ndescription: >-\n  Audit every user-facing screen for redundant, verbose, or unnecessary UI text\n  and remove what doesn't help the user decide or act. Triggers on \"audit UI\n  text\", \"trim copy\", \"remove redundant labels\", \"verbose UI\", \"too many words\",\n  \"clean up screen text\", \"UI text review\", \"cut unnecessary copy\", or any\n  request to tighten interface language across a project.\n---\n\n# UI Text Audit\n\n## Goal\n\nFind and remove every piece of user-facing text that does not help the user make a decision or complete a task. Leave text that carries genuinely new information. The result is fewer words per screen, faster scanning, and no loss of usability.\n\n## When to Use\n\nUse this skill when the user:\n\n- Asks to audit, review, or tighten UI text across a project.\n- Says screens feel verbose, wordy, or cluttered with copy.\n- Wants redundant labels, filler descriptions, or unnecessary subheadings removed.\n- Asks to \"trim the copy\", \"clean up the UI text\", or \"cut the noise\".\n\nExample prompts:\n\n> Audit every screen for unnecessary text and remove it.\n\n> The UI is too wordy. Cut anything that doesn't help the user.\n\n> Review all the labels and descriptions — trim what's redundant.\n\n## Workflow\n\n### 1. Inventory screens\n\nIdentify every user-facing screen, page, modal, drawer, and multi-step flow in the project. List them so nothing is missed.\n\n### 2. Scan each screen against the pattern catalog\n\nFor every screen, check for each pattern below. Collect candidates — do not edit yet.\n\n#### Pattern catalog\n\n| #  | Pattern | Test | Action |\n|----|---------|------|--------|\n| 1  | **Eyebrow restates heading** — labels like \"STEP 2 OF 4\" or \"SETTINGS · ACCOUNT\" above a heading that already names the screen | Does the eyebrow add information the heading lacks (e.g. progress the heading omits)? | If no, remove the eyebrow. If yes, keep it. |\n| 2  | **Heading + subheading say the same thing** — \"Manage your team\" / \"Add, remove, and manage members of your team\" | Does the subheading add a fact or action the heading doesn't? | If no, kill the subheading or merge the pair into one line. |\n| 3  | **Explanatory text describes what's visible** — \"Use the form below to update your profile\" above a profile form | Can the user see what to do without this sentence? | If yes, remove it. |\n| 4  | **Section heading for a single item** — \"Your selection\" above one item, \"Results\" above one result | Is there only ever one item in this section? | If yes, remove the heading. If the section can have multiple items, keep it. |\n| 5  | **Confidence badge / internal-system label** — \"HIGH CONFIDENCE\", \"STRONG MATCH\" | Can the user take a different action based on this label? | If no, remove it. |\n| 6  | **Disclaimer that duplicates a confirm step** — \"Don't worry, nothing changes until you confirm\" when a confirm step exists | Does the UI already have a confirmation gate? | If yes, remove the disclaimer. If no, add a confirm step instead. |\n| 7  | **Redundant nested label** — a `<summary>` says \"Add extra notes\", the revealed `<label>` says \"Extra notes\" | Does the inner label add information beyond the summary? | If no, remove the inner label. |\n| 8  | **Same data presented multiple ways** — \"75%\", \"About 75% of items match\", \"Strong match\" | Is the same fact stated more than once? | Keep one presentation (number + brief label). Remove the rest. |\n| 9  | **Filler footer text** — \"More details will be available after this step\" | Does this text help the user decide what to do now? | If no, remove it. |\n| 10 | **Verbose button label** — \"Approve this improvement\", \"Mark as not relevant\" | Is the context already clear from the surrounding UI? | If yes, trim to verb + object: \"Approve\", \"Skip\", \"View draft\". |\n\n### 3. Validate candidates\n\nFor each candidate, ask: **does removing this text make it harder for the user to complete the task?**\n\n- If **no** → confirmed for removal.\n- If **yes** → discard the candidate. Leave the text.\n\nNever remove:\n\n- Progress indicators when the heading does not already convey progress.\n- Error messages and validation hints.\n- Accessibility labels (`aria-label`, `sr-only` text, `alt` text).\n- Text that provides genuinely new information the user needs to act.\n\n### 4. Apply changes\n\nFor each confirmed removal:\n\n1. Remove the text from the component.\n2. Remove any CSS rules, classes, or styled-component blocks that only styled the removed element.\n3. Remove unused imports introduced by the deletion.\n4. If a disclaimer was removed and no confirm step exists, add a confirm step.\n\n### 5. Verify the build\n\nRun the project's build/lint/type-check command after all changes. Fix any breakage before moving on.\n\n### 6. Report\n\nProduce a summary table:\n\n| Screen | Pattern # | What was removed | Reason |\n|--------|-----------|------------------|--------|\n\nGroup by screen. Include the pattern number so the user can cross-reference the catalog.\n\n## Guardrails\n\n- Never remove error messages, validation hints, or accessibility labels.\n- Never remove text that provides information the user cannot infer from the surrounding UI.\n- Never remove progress indicators unless the heading already conveys the same progress information.\n- Never guess whether a section can have multiple items — check the data source or ask.\n- Never restructure component hierarchy, reorder elements, or change behavior — only remove text and its dedicated styling.\n- Never introduce new copy. This skill removes; it does not rewrite (exception: merging a heading + subheading into one line, or shortening a button label).\n- Always verify the build passes after changes. Do not leave broken imports or dead CSS.\n- Report every removal so the user can review and revert if needed.\n\n## Completion Checklist\n\n- [ ] Every user-facing screen, modal, drawer, and flow step was scanned.\n- [ ] Each removal maps to a pattern in the catalog.\n- [ ] No error messages, validation hints, or accessibility labels were removed.\n- [ ] Removed CSS/imports that only served deleted elements.\n- [ ] Build/lint/type-check passes with no new errors.\n- [ ] Summary table delivered listing every change by screen and pattern.\n"
}