Celebration Scene Ideas

Celebration Scene Ideas

Design scenes in which characters treat page components as props. Use this repository's Halloween scenes as a quality reference: a readable intention, action, interface reaction, unexpected resolution and restoration of the page. Respond in the user's language.

Establish the request

Use the event named in the request or already selected by the user. If missing, ask one short question while inspecting examples. Halloween is a quality reference, not the default event; the application's active event is not evidence of the user's choice.

Preserve requested characters, mood, number of ideas, duration, page elements and unwanted effects. Make reasonable choices for the rest. Ideas for an event without an existing module are valid; identify the module as additional work.

The default deliverable is an idea in the response. Do not create OpenSpec changes, scene files or images until the corresponding work is requested. If implementation is already authorized, use the concept as a brief foundation and continue without asking for the same permission again.

Implement scenes through openspec-propose (/opsx:propose, also called opsx-propose), then openspec-apply-change (/opsx:apply). Continue a suitable existing change instead of duplicating it. Include the plot, fallbacks, cleanup and numerical performance budgets in proposal/design/specs/tasks; verify them with tests and browser profiling during apply. Authorization for both proposal and implementation permits proceeding to apply without another confirmation. Archive only when requested.

Ground the idea in the repository

Paths below are relative to the AI DIAL Chat root. Follow AGENTS.md: use nx-workspace before workspace exploration and dial-docs before explaining documented behavior. If the repository is unavailable, distinguish assumptions from confirmed capabilities.

1. Read libs/celebrations/README.md and the selected event's libs/celebrations/src/<event>/event.ts or event.tsx. Check existing scenes to avoid proposing a duplicate.
2. Use the repository examples to choose one or two relevant techniques. Read their component, animation plan and target selection as needed; do not preload all of Halloween.
3. Inspect libs/celebrations/src/models/celebration.ts and apps/chat/src/context/CelebrationHost.tsx for actual host anchors and triggers. An anchor does not guarantee a visible, eligible target in the current layout.

If paths have moved, locate them with rg --files. Cite one or two inspected sources and explain the technique they demonstrate. Reading source code is not browser observation.

Build action and character

Start with an event-specific motive: what does the character want, and why does it touch the interface? Give page elements physical roles: a composer edge becomes a ledge, a button a weight, a starter card a platform, a history row a ribbon.

Build a causal sequence: entrance → intention → contact → reaction → complication or joke → departure and restoration. Specify the contact point, weight transfer or impulse, and when the prop starts moving. A carried object follows its grip; a push precedes a fall; stopping and returning have a reason. Gaze, anticipation, pauses and reactions to failure establish personality.

Each main concept needs a meaningful interaction with a page component. Snow, confetti, glow and flybys can support the plot but are not sufficient by themselves. Borrow Halloween's principles while inventing an original action for the selected event; replacing its cat with another character is not a new story.

Distinguish three kinds of interaction:

• User trigger: the event's existing decor trigger or secret phrase. A decor click selects from a pool; do not promise a particular scene without a separate configuration.
• Interface choreography: after activation, characters interact with inert visual copies or measured component geometry.
• Live user control: pointer movement, typing or dragging during playback. Decor has separate reactive behaviors, while scenes borrowing UI usually cancel on input or clicks. If a concept needs direct control, identify the contract change and how ordinary chat interaction remains usable; do not describe it as an existing feature.

SVG artwork

For new SVG characters or requests to improve drawing, volume or realism, read SVG character quality. It connects silhouette, proportions, expression, lighting and materials to animation geometry and rendering budgets. If the user asks for realism without choosing a style, propose stylized realism and inspect it at the actual scene size. Preserve an explicitly chosen style.

Separate artwork quality from motion quality. Preserve the plot, grips, supports and props when redrawing; geometry changes require contact checks. Define observable visual criteria and a numerical SVG budget before implementation. A PNG concept is not an articulated SVG asset.

Motion and existing-scene review

For character choreography and animation improvements, read motion quality. It covers easing, anticipation, coordinated movement and visual review. All guidance needed for this workflow lives in this skill and its local references.

Describe the action's feel as well as its route: anticipation, contact, weight transfer, reaction and settling. Give each beat a visual focus; secondary motion supports it. Distinguish characters through timing and movement style.

Separate confirmed defects from expressive suggestions. For each substantial finding, provide a code location or recording timestamp, observation, proposed change and verification method. Prioritize readability, correctness and cost. Without browser observation, label perceptual conclusions as hypotheses. When implementation is authorized, put selected improvements into the OpenSpec change and continue apply.

Choose the animation mechanism

For a new character-led scene, start by considering a scene-local Lottie SVG composition. Prefer it when articulated poses, several synchronized characters or props, or vector shape changes benefit from one authored timeline. Use the repository's existing light player and keep geometry, grips and UI reactions on that timeline. If the user explicitly requests Lottie, plan for Lottie unless a required interaction cannot reasonably be represented in it; explain that constraint and use a coordinated companion animation only where needed.

Use CSS/WAAPI for simple decor loops, brief element transforms or UI snapshots that need direct DOM control. Do not migrate a working scene merely to change its animation engine. Lottie is a way to author motion, not a performance or realism guarantee. Read Lottie scene quality when proposing or implementing it; include the player, composition and fallback in the scene design.