Update to Moodle: Mood Board plan+design

{
  "description": "Compare and recommend Google Font heading and body pairings for Mood Board when the user wants typography that fits an existing board or a stated visual mood. Preview families and explain their roles and tradeoffs. Do not use for uploading custom fonts, building a complete UI theme, arbitrary specimen text or layout control, or licensing conclusions without verified sources.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 293
    }
  ],
  "name": "mood-board-font-pairing",
  "skill_md_contents": "---\nname: mood-board-font-pairing\ndescription: \"Compare and recommend Google Font heading and body pairings for Mood Board when the user wants typography that fits an existing board or a stated visual mood. Preview families and explain their roles and tradeoffs. Do not use for uploading custom fonts, building a complete UI theme, arbitrary specimen text or layout control, or licensing conclusions without verified sources.\"\n---\n\n# Mood Board Font Pairing\n\n## Inputs\n\nUse the board or stated mood, the intended medium and audience, any required\nlanguage or script, and fixed font families or palette colors. Prefer the latest\nmodel-visible board contents when available.\n\n## Workflow\n\n1. Identify the typography goal in plain language, such as quiet editorial\n   headings with approachable body text. Retain fixed families and colors.\n   Ask about language or reading needs only when they would change the choice.\n2. Propose two heading and body pairings. Make the pairs differ in a meaningful\n   way while supporting the same brief. Prefer established Google Fonts families\n   and explain why each family suits its role.\n3. When family availability, script coverage, or licensing matters and is\n   uncertain, verify it using available official Google Fonts sources. If\n   verification is unavailable, state what remains unverified rather than\n   promising coverage or licensing terms. Do not infer these from a preview.\n4. Render a dedicated comparison board through `display-mood-board` when a\n   visual comparison is wanted. Use four `font` items with only `type` and\n   `family`, two `note` items naming each pairing and its roles, and optionally\n   the existing `palette`. Keep `moodBoard.items` at ten or fewer, follow the\n   registered schema, and use an optional `reason`.\n5. Read the returned `structuredContent.moodBoard`. Explain the heading and body\n   contrast, fit with the board, and the likely reading tradeoffs. Distinguish\n   the widget's family preview from testing actual text at production sizes.\n6. Recommend one pairing and give concise usage guidance. When the user wants\n   to apply it to an existing board, render the complete retained board only\n   when it fits the tool contract and uses reusable image sources. Otherwise\n   guide the user to change or add font cards in the existing widget.\n\n## App use and limits\n\n- Use exact Google Fonts family names. Leave weights, sizes, custom sample text,\n  typography roles, and grouping labels out of `font` tool arguments; put role\n  guidance in notes or the conversation.\n- Use a `palette` only when its supplied colors are known, retaining their exact\n  six-digit hex values and at least two colors. Do not invent an existing palette\n  from unseen imagery.\n- Let the widget load previews from Google Fonts. Its font catalog is a\n  client-side feature; do not claim to query it through an app tool or request\n  its API key. A manual family name remains usable without catalog suggestions.\n- Treat any new rendering as a board with fresh UUIDs. Do not promise to retain\n  positions, private upload mappings, or export details, and never silently trim\n  an existing board to the ten-item input limit.\n- Leave `resolve-mood-board-images` to the widget. Do not call the app-only helper\n  or assume that private state or file-ID-to-source mappings are visible.\n\n## Deliverable\n\nProvide the comparison previews when requested, the recommended heading and body\nfamilies, their intended roles, and any unresolved coverage or implementation\nchoices. For text-only requests, return the comparison without calling tools.\n"
}