Moodle: Mood Board plan+design

View saved version →

---
name: compare-mood-board-directions
description: "Compare two or three creative directions in Mood Board when the user wants alternative visual routes, help choosing an aesthetic, or a structured comparison before committing to a board. Hold shared requirements constant and deliver comparable boards plus tradeoffs. Do not use for a single straightforward board request, a cohesion review, or widget layout changes."
---

# Compare Mood Board Directions

## Inputs

Use the project brief, audience, intended impression, fixed ingredients, and any
supplied references. Use the latest model-visible board contents when the user
is exploring alternatives to an existing board.

## Workflow

1. Establish the shared brief and the criteria for choosing a route. Retain
   fixed colors, references, wording, and other stated constraints across all
   alternatives. Ask a focused question if a missing constraint would materially
   change the routes; otherwise state reasonable assumptions.
2. Develop two routes by default, or three when requested. Give each a name and
   a one-sentence idea. Make the alternatives differ in at least two meaningful
   ingredients, such as palette, typography, imagery, or materials.
3. Use the same ingredient categories and a similar item count for each route
   so the comparison is fair. Target four to six items per route. Include a
   `note` naming the route and its defining idea; add a palette, font previews,
   and any relevant references that have reusable image sources.
4. Render one complete board per route through `display-mood-board`, using the
   registered schema, at most ten `moodBoard.items` per call, and an optional
   `reason`. Omit output IDs and unsupported title, grouping, or position fields.
   Use the note card to identify each route and the returned
   `structuredContent.moodBoard` to describe what was rendered.
5. Compare the routes in a short table against the shared criteria. Explain
   their audience fit, strongest benefit, and practical tradeoff. Recommend the
   route that best fits the user's priorities without inventing numerical scores.
6. Ask the user to choose a route or a specific combination when the choice is
   still open. If they already chose one, refine that route directly while
   retaining the fixed anchors and using the latest visible contents.

## Image and state handling

- Use source URLs rather than signed delivery URLs. Describe references only
  when visible or described by the user. If imagery is unavailable, represent
  the intended imagery in a note and render concrete palette and font items.
- For attachments without reusable image URLs, guide the user to upload the
  selected images into the route's widget. Never fabricate a hosted source or
  pass file IDs as URL arguments.
- Use separate search or generation tools only when available and appropriate
  to an additional user request. Do not present them as Mood Board capabilities.
- Treat route boards as separate renderings with fresh item UUIDs. Do not
  promise an in-place update, retained positions, transferred private upload
  mappings, persistent versions, or a side-by-side comparison interface.
- Leave the app-only `resolve-mood-board-images` helper to the widget. Do not
  assume access to `privateContent` or inspect unseen imagery from URL names.

## Deliverable

Provide the named route boards, the compact comparison, and one recommendation
with its reason. Preserve a text-only comparison when the user requests text
only or no tools; do not render solely because this skill was selected.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: curate-mood-board-references
description: "Select, organize, and explain supplied visual references for Mood Board when the user asks which images to keep, wants to reduce a crowded reference collection, or needs a purposeful image-led board. Identify motifs, remove redundancy, and explain each selection. Do not use for open-ended image search, image generation, literal color extraction, or a general board critique."
---

# Curate Mood Board References

## Inputs

Use supplied images, current model-visible image and gallery items, or explicit
image descriptions, together with the project purpose and must-keep references.
Separate visual evidence from the availability of a reusable rendering URL.

## Workflow

1. Inventory the available references. Give them short labels such as R1 and R2
   in the conversation, and retain their known source URLs or user descriptions.
   Describe only images that are actually visible or described. If neither is
   available, request the references rather than inferring imagery from filenames
   or URL paths.
2. Identify each reference's useful signal: palette, material, lighting,
   composition, typography, or mood. Connect that signal to the brief and note
   any required ingredients the collection does not cover.
3. Select a small set with distinct roles, usually a main reference and a few
   supporting details. Preserve must-keep references. Remove redundant or
   conflicting references with concrete reasons tied to the intended direction.
4. Explain the keep and omit decisions before organizing the board. Distinguish
   an aesthetic judgment from an unknown reference that needs inspection.
5. When a board is requested, use `image` items for individual references,
   `gallery` items for related references, and concise `note` items for their
   roles. Submit the full `moodBoard.items` through `display-mood-board`, with at
   most ten items and an optional `reason`. Follow the registered schema;
   conversation labels and captions are not additional image item fields.
6. Read the returned `structuredContent.moodBoard` when rendering succeeds.
   Summarize the chosen references and the remaining reference gaps. Suggest
   specific subjects for missing references rather than inventing image links.

## Source handling

- Supply reusable public HTTP(S) image URLs, not webpage links, file IDs, or
  invented hosted sources. Keep original source URLs; allow the widget to resolve
  delivery URLs through its app-only `resolve-mood-board-images` helper.
- If selected attachments have no reusable URLs, deliver the curation first.
  Guide the user to upload those images into image or gallery cards. If they
  requested a fresh canvas, `display-mood-board` can render an empty `items`
  array or concrete note items to support that manual upload workflow.
- When working from an existing board, prefer its latest model-visible contents
  over earlier tool output. New renderings receive fresh UUIDs and do not carry
  private upload mappings or saved positions; use widget edit guidance when
  those must be retained.
- Apply the ten-item tool limit to a rerendered board even if the user has added
  more items manually. Never silently discard retained ingredients to fit.

## Deliverable

Return the selected references with their roles and reasons, a brief account of
omitted references, and any missing subjects. Include a curated widget when
requested and sources permit, or exact upload and organization steps.

## Boundaries

Treat image search and generation as separate capabilities, used only when
available and relevant to an additional request. Do not claim Mood Board can
find images, inspect unseen URLs, measure palette colors, recover private file
mappings, or arrange cards programmatically. Respect requests for text only.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: mood-board-cohesion-review
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."
---

# Mood Board Cohesion Review

## Inputs

Use the latest board contents, the intended mood or audience, and any ingredients
the user wants to retain. Use attached images only when they are actually visible.

## Workflow

1. Read the latest model-visible `modelContent.moodBoard`. Use
   `structuredContent.moodBoard` from the latest tool result only when newer user
   edits are unavailable. If no board contents are visible, request them; do not
   claim to retrieve them through a tool.
2. State the intended direction in one sentence and identify fixed anchors such
   as exact colors, font families, references, or wording. Infer a tentative
   direction from the conversation when reasonable and label that inference.
   Ask a focused question only when a missing aim would change the review.
3. Assess palette hierarchy, typography tone, reference consistency, repetition,
   and whether notes or quotes reinforce the direction. Describe only imagery
   you can see or that the user has described. Separate observed ingredients
   from judgments about their effect.
4. Select up to three changes with the greatest benefit. Identify each target
   by its content or family name, explain the conflict, and give a concrete
   replacement, removal, or adjustment. Keep the user's anchors intact.
5. Render a revision when the user requests refinement. For a critique-only
   request, return the review without rendering. Follow the rendering rules
   below; provide precise widget edit instructions when a new rendering cannot
   preserve what the user needs.
6. After rendering, use the returned `structuredContent.moodBoard` as the new
   baseline and summarize the changes against the intended direction.

## Rendering rules

- Call `display-mood-board` with the complete `moodBoard.items`, at most ten
  items, and an optional `reason`. Follow the registered item schema and omit
  output IDs and response metadata from the input.
- Carry every retained ingredient into the complete payload. Never silently
  truncate a board that the user expanded beyond ten items in the widget;
  provide widget edit instructions or ask which subset to render.
- Treat the result as a new rendering with fresh item UUIDs. Do not promise to
  patch the existing widget, retain dragged positions, or preserve private
  upload and export bookkeeping.
- Use reusable source image URLs. If an uploaded image has no reusable source,
  guide edits within the existing widget instead of inventing a URL or assuming
  a file ID can be passed as an image URL. Do the same when the user requires
  the existing layout or uploaded-file associations to remain intact.
- Leave remote image delivery to the widget. Never call the app-only
  `resolve-mood-board-images` helper or substitute its signed delivery URLs for
  source URLs.

## Deliverable

Return the direction and retained anchors, followed by up to three prioritized
changes with their reasons. Include the revised board when requested and
representable, or concrete instructions for editing the current widget.

## Boundaries

Review semantic contents rather than hidden card geometry. Do not assume access
to `privateContent` or treat image IDs and URL names as visual evidence. Keep
layout changes, uploads, display modes, and export as widget actions. Respect
requests for text only or no tools.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: mood-board-font-pairing
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."
---

# Mood Board Font Pairing

## Inputs

Use the board or stated mood, the intended medium and audience, any required
language or script, and fixed font families or palette colors. Prefer the latest
model-visible board contents when available.

## Workflow

1. Identify the typography goal in plain language, such as quiet editorial
   headings with approachable body text. Retain fixed families and colors.
   Ask about language or reading needs only when they would change the choice.
2. Propose two heading and body pairings. Make the pairs differ in a meaningful
   way while supporting the same brief. Prefer established Google Fonts families
   and explain why each family suits its role.
3. When family availability, script coverage, or licensing matters and is
   uncertain, verify it using available official Google Fonts sources. If
   verification is unavailable, state what remains unverified rather than
   promising coverage or licensing terms. Do not infer these from a preview.
4. Render a dedicated comparison board through `display-mood-board` when a
   visual comparison is wanted. Use four `font` items with only `type` and
   `family`, two `note` items naming each pairing and its roles, and optionally
   the existing `palette`. Keep `moodBoard.items` at ten or fewer, follow the
   registered schema, and use an optional `reason`.
5. Read the returned `structuredContent.moodBoard`. Explain the heading and body
   contrast, fit with the board, and the likely reading tradeoffs. Distinguish
   the widget's family preview from testing actual text at production sizes.
6. Recommend one pairing and give concise usage guidance. When the user wants
   to apply it to an existing board, render the complete retained board only
   when it fits the tool contract and uses reusable image sources. Otherwise
   guide the user to change or add font cards in the existing widget.

## App use and limits

- Use exact Google Fonts family names. Leave weights, sizes, custom sample text,
  typography roles, and grouping labels out of `font` tool arguments; put role
  guidance in notes or the conversation.
- Use a `palette` only when its supplied colors are known, retaining their exact
  six-digit hex values and at least two colors. Do not invent an existing palette
  from unseen imagery.
- Let the widget load previews from Google Fonts. Its font catalog is a
  client-side feature; do not claim to query it through an app tool or request
  its API key. A manual family name remains usable without catalog suggestions.
- Treat any new rendering as a board with fresh UUIDs. Do not promise to retain
  positions, private upload mappings, or export details, and never silently trim
  an existing board to the ten-item input limit.
- Leave `resolve-mood-board-images` to the widget. Do not call the app-only helper
  or assume that private state or file-ID-to-source mappings are visible.

## Deliverable

Provide the comparison previews when requested, the recommended heading and body
families, their intended roles, and any unresolved coverage or implementation
choices. For text-only requests, return the comparison without calling tools.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: mood-board-to-creative-brief
description: "Turn an existing or edited Mood Board into a concise creative brief when the user asks for a designer handoff, a written art direction, or a summary of the board's design decisions and constraints. Ground the brief in model-visible contents and visible references. Do not use for generating a fresh board, a cohesion critique, or a photography shot list."
---

# Mood Board to Creative Brief

## Inputs

Use the latest board, the project and audience, the intended use, and any known
constraints or approved decisions. Distinguish established requirements from
ideas that still need a decision.

## Workflow

1. Prefer the latest model-visible `modelContent.moodBoard` over an earlier
   `structuredContent.moodBoard` tool result. If no contents are available,
   request them. Do not claim that the app exposes a board retrieval tool.
2. Extract exact palette values, font family names, note text, quote attribution,
   and reference sources. Describe image contents only when the image is visible
   or the user supplied a description. Leave undocumented details undecided.
3. Connect each ingredient to the project purpose. Label suggested color roles,
   typography roles, and imagery principles as proposals unless already
   established by the user. Preserve fixed anchors verbatim.
4. Write a concise, copy-ready brief with the following sections, omitting
   sections that have no useful evidence:
   - Project objective, audience, and intended deliverable.
   - Direction in one sentence and three defining characteristics.
   - Palette with exact hex values and established or proposed roles.
   - Typography with family names and established or proposed roles.
   - Imagery, materials, and styling principles tied to visible references.
   - Concrete do and avoid guidance grounded in the board.
   - Fixed constraints and unresolved production decisions.
5. Identify the few questions that would materially affect execution. Do not
   invent budget, measurements, deadlines, asset ownership, or approval status.
6. When the user needs a visual attachment, guide them to click **Export**, then
   **View**, in the widget. Describe the export as a JPEG. Treat export completion
   and the downloadable file as unknown unless the user provides them.

## App use

Consume existing board state without rerendering merely to write the brief.
Use `display-mood-board` only if the user also requests an annotated board.
In that case, submit the full `moodBoard.items` with at most ten items, an optional
`reason`, and only registered input fields. Read the returned
`structuredContent.moodBoard` and account for fresh UUIDs.

For annotations that need the original positions or uploaded-file associations,
give instructions for adding or editing a note within the existing widget.
Never drop retained ingredients to fit the tool limit or assume private upload
mappings transfer to a new rendering. Leave `resolve-mood-board-images` to the
widget; it is app-only.

## Deliverable

Return the brief in the conversation, ready to copy into a handoff. Make
established choices, proposals, and unresolved decisions easy to distinguish.
Include the short Export and View instructions only when useful for the handoff.

## Boundaries

Do not assume access to private layout, export file IDs, or export URLs. Do not
claim to export, upload, send, or attach the brief through the app. Avoid
inventing PDF or document-generation capabilities. Respect text-only requests
and keep external sharing subject to the user's explicit instructions.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: mood-board-to-shot-list
description: "Translate an existing Mood Board into a photography shot list when the user asks how to shoot its campaign, product, editorial, or lifestyle direction. Ground each planned shot in visible references or supplied descriptions and specify framing, lighting, styling, and palette consistency. Do not use for a general creative brief, video storyboarding, booking a shoot, or generating finished photographs."
---

# Mood Board to Shot List

## Inputs

Use the latest board, the photography objective and subject, visible references
or user descriptions, and known delivery constraints such as format, shot count,
available props, or location. Keep unknown production details explicit.

## Workflow

1. Read the latest model-visible `modelContent.moodBoard`, or the latest
   `structuredContent.moodBoard` when no newer edits are available. If there is
   no board evidence, request it rather than claiming to retrieve private state.
2. Extract the shared visual rules: mood, exact supplied palette values,
   materials, lighting character, and composition cues. Describe only references
   you can see or that the user has described. Label creative extrapolations as
   proposals rather than observations.
3. Establish the subject, purpose, and required output. Ask a focused question
   if a missing subject or format would materially change the shots. State
   reasonable assumptions for less consequential details and preserve all fixed
   constraints.
4. Plan six shots by default, or the requested count. Cover distinct purposes
   such as a main image, context, a detail, or a human interaction when relevant
   to the brief. Avoid repeating the same composition with superficial changes.
5. Write a shot table with:
   - Shot ID and purpose.
   - Reference label, description, or known source.
   - Framing and composition.
   - Proposed lighting approach.
   - Subject styling, backdrop, and props.
   - Palette or consistency cue.
6. Identify essential shots, optional additions, reusable setup choices, and
   unresolved production needs. Keep equipment, location, staffing, and timing
   as proposals or unknowns unless the user supplied them.
7. Return the shot list in the conversation. Add an annotated board only when
   the user requests one, following the app use rules below.

## App use

Consume the existing board without rendering merely to produce the shot list.
For a requested annotated board, call `display-mood-board` with the complete
retained `moodBoard.items` and concise `note` items summarizing the shot direction.
Use at most ten items, an optional `reason`, and only registered input fields;
shot IDs and lighting fields belong in note text or the conversation.

Read the returned `structuredContent.moodBoard` and account for fresh UUIDs.
Never silently omit retained ingredients to fit the input limit. Guide the user
to add or edit a note in the existing widget when its layout, uploaded-file
associations, or a board larger than ten items must be retained. Do not invent
reusable image URLs or assume file IDs can be submitted as URL arguments.
Leave the app-only `resolve-mood-board-images` helper to the widget.

## Deliverable

Return the visual rules, the copy-ready shot table, essential versus optional
shots, and a short list of unresolved production decisions. Tie each shot to
actual board evidence or a clearly labeled creative proposal.

## Boundaries

Do not infer shooting order or storyboard sequence from hidden card positions.
Do not claim to schedule a shoot, book services, buy props, generate photographs,
or operate widget export through this app. Use source descriptions honestly and
respect requests for text only or no tools.

Referenced files: 1 — file references are metadata, not package contents.