Update to Moodle: Mood Board plan+design

{
  "description": "Review and refine the contents of an existing Mood Board when the user asks why it feels scattered, wants a more coherent direction, or needs prioritized changes while preserving specified anchors. Use the current model-visible board and visible references. Do not use for creating unrelated concepts, spatial layout critique without a visible board image, or a designer handoff brief.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 300
    }
  ],
  "name": "mood-board-cohesion-review",
  "skill_md_contents": "---\nname: mood-board-cohesion-review\ndescription: \"Review and refine the contents of an existing Mood Board when the user asks why it feels scattered, wants a more coherent direction, or needs prioritized changes while preserving specified anchors. Use the current model-visible board and visible references. Do not use for creating unrelated concepts, spatial layout critique without a visible board image, or a designer handoff brief.\"\n---\n\n# Mood Board Cohesion Review\n\n## Inputs\n\nUse the latest board contents, the intended mood or audience, and any ingredients\nthe user wants to retain. Use attached images only when they are actually visible.\n\n## Workflow\n\n1. Read the latest model-visible `modelContent.moodBoard`. Use\n   `structuredContent.moodBoard` from the latest tool result only when newer user\n   edits are unavailable. If no board contents are visible, request them; do not\n   claim to retrieve them through a tool.\n2. State the intended direction in one sentence and identify fixed anchors such\n   as exact colors, font families, references, or wording. Infer a tentative\n   direction from the conversation when reasonable and label that inference.\n   Ask a focused question only when a missing aim would change the review.\n3. Assess palette hierarchy, typography tone, reference consistency, repetition,\n   and whether notes or quotes reinforce the direction. Describe only imagery\n   you can see or that the user has described. Separate observed ingredients\n   from judgments about their effect.\n4. Select up to three changes with the greatest benefit. Identify each target\n   by its content or family name, explain the conflict, and give a concrete\n   replacement, removal, or adjustment. Keep the user's anchors intact.\n5. Render a revision when the user requests refinement. For a critique-only\n   request, return the review without rendering. Follow the rendering rules\n   below; provide precise widget edit instructions when a new rendering cannot\n   preserve what the user needs.\n6. After rendering, use the returned `structuredContent.moodBoard` as the new\n   baseline and summarize the changes against the intended direction.\n\n## Rendering rules\n\n- Call `display-mood-board` with the complete `moodBoard.items`, at most ten\n  items, and an optional `reason`. Follow the registered item schema and omit\n  output IDs and response metadata from the input.\n- Carry every retained ingredient into the complete payload. Never silently\n  truncate a board that the user expanded beyond ten items in the widget;\n  provide widget edit instructions or ask which subset to render.\n- Treat the result as a new rendering with fresh item UUIDs. Do not promise to\n  patch the existing widget, retain dragged positions, or preserve private\n  upload and export bookkeeping.\n- Use reusable source image URLs. If an uploaded image has no reusable source,\n  guide edits within the existing widget instead of inventing a URL or assuming\n  a file ID can be passed as an image URL. Do the same when the user requires\n  the existing layout or uploaded-file associations to remain intact.\n- Leave remote image delivery to the widget. Never call the app-only\n  `resolve-mood-board-images` helper or substitute its signed delivery URLs for\n  source URLs.\n\n## Deliverable\n\nReturn the direction and retained anchors, followed by up to three prioritized\nchanges with their reasons. Include the revised board when requested and\nrepresentable, or concrete instructions for editing the current widget.\n\n## Boundaries\n\nReview semantic contents rather than hidden card geometry. Do not assume access\nto `privateContent` or treat image IDs and URL names as visual evidence. Keep\nlayout changes, uploads, display modes, and export as widget actions. Respect\nrequests for text only or no tools.\n"
}