Update to DXD Skills

{
  "name": "paper-design",
  "description": "Create, edit, or review native editable designs in Paper using an available direct Paper integration. Use when a user names Paper, shares a Paper file, requests Paper artboards, or wants implementation and Paper designs aligned.",
  "included_files": [],
  "skill_md_contents": "---\nname: paper-design\ndescription: >-\n  Create, edit, or review native editable designs in Paper using an available\n  direct Paper integration. Use when a user names Paper, shares a Paper file,\n  requests Paper artboards, or wants implementation and Paper designs aligned.\n---\n\n# Paper Design\n\n## Goal\n\nCreate coherent, editable Paper designs while preserving the confirmed file\nscope and the product's existing design system.\n\n## When to Use\n\nUse when the task concerns a Paper file, Paper artboards, Paper components, a\nPaper design system, or synchronization between Paper and an application.\n\n## Workflow\n\n1. Discover the available Paper connection and its current guidance. Use direct\n   Paper operations when they are available. If they are not, report the\n   limitation and use another method only when the user chooses it.\n2. Open the requested file, page, and nodes. Inspect existing pages, artboards,\n   components, and tokens before making changes; preserve everything outside\n   the confirmed scope.\n3. When mirroring an application, inspect the relevant product states and\n   design tokens. Map requested states to artboards and report any meaningful\n   omission.\n4. Create or update native editable layers. Reuse existing tokens and shared\n   structures where they fit, and name artboards and layers for their product\n   state.\n5. Review changed screens at an appropriate level of rigor. Use screenshots or\n   the native preview when available to check hierarchy, contrast, spacing,\n   clipping, typography, and consistency across related states.\n6. Report the changed file locations, artboards, design-system decisions, and\n   anything that could not be verified.\n\n## Guardrails\n\n- Never substitute a different design surface for direct Paper work unless the\n  user chooses it.\n- Never delete, replace, or restyle Paper content outside the confirmed scope.\n- Never overwrite an existing design system without making the change clear in\n  the handoff.\n- Never claim cross-screen consistency without reviewing the changed screens.\n- Never expose credentials or private product data outside the local working\n  environment.\n\n## Completion Checklist\n\n- [ ] The active Paper integration and requested scope were established.\n- [ ] Changes use native editable Paper objects.\n- [ ] Requested states are represented or any omissions are reported.\n- [ ] Changed screens were reviewed for visual consistency.\n- [ ] The handoff identifies changed artboards and unverified details.\n"
}