Activity Campaign From Ui

• Platform: H5 / Web
• Stack: HTML + CSS + JavaScript

Do not output code in other stacks.

Modes

This skill supports one skill with multiple modes.

analysis

Use when the user wants to understand the reference. Return:

• observed UI structure
• visible text
• gameplay clues
• user flow clues
• uncertainty notes

proposal

Use when the user wants a new campaign idea from the reference. Return:

• reference summary
• gameplay abstraction
• new campaign concept
• target users
• goals
• rewards and participation path
• anti-copy explanation
• visual proposal direction that reads more like an operations campaign deck than a plain memo

architecture

Use when the user wants implementation planning without full code. Return:

• page module list
• module order
• popup system
• state flow
• tracking suggestions
• delivery schema

delivery

Use when the user wants code on the fixed stack. Return:

• file structure
• index.html
• styles.css
• main.js
• mock-data.js
• visual extraction summary
• implementation notes

full

Use when the user wants the full flow. Return:

1. reference analysis
2. gameplay abstraction
3. new campaign proposal
4. page architecture
5. delivery schema
6. visual direction
7. H5/Web high-fidelity draft code

Default mode rules

If the user does not specify a mode:

• default to proposal if they want a new campaign/event idea
• default to delivery if they explicitly ask for code
• default to full if they ask for both plan and code

For delivery and full, when the brief implies poster-style character focus and the page would otherwise become too long, default to a female-led, launch-ready, tab-first H5 front-end draft.

Core job

Given one or more campaign references, do all relevant parts of the following:

1. Identify observable UI patterns
2. Separate what is observed vs inferred vs assumed
3. Abstract the gameplay and module patterns
4. Propose a new campaign instead of copying the reference
5. Design a buildable H5/Web page architecture
6. Output fixed-stack high-fidelity draft code when requested

Output rules

Prefer practical output over broad commentary.

When possible, organize the answer using these sections:

• Reference analysis
• Observed
• Inferred
• Assumed
• Gameplay abstraction
• New campaign proposal
• Page architecture
• Delivery schema
• Visual direction
• H5/Web starter files
• Uncertainties

Proposal presentation rule

For proposal, the result should feel closer to an operations campaign visual deck than a plain strategy memo.

Preferred structure:

• strong campaign name and one-line hook
• visual theme and mood direction
• hero concept and key selling point
• participation path
• reward design
• module highlights
• timeline or rollout rhythm when relevant

If the user explicitly asks for a local proposal deck and the host environment supports local execution, the skill may generate a local .pptx file with Python.

File handoff rules

Do not append executable local file-write commands.

If the user explicitly asks for local files and the host environment supports local execution, the skill may use Python to generate artifacts directly in the workspace instead of only presenting them inline.

The goal is to keep the handoff clear without asking the model to generate shell or terminal instructions from screenshot-derived content.

Mode-specific file targets:

• analysis: present the main result as one Markdown document such as campaign-analysis.md
• proposal: present the main result as one Markdown document such as campaign-proposal.md
• proposal optional local artifact: campaign-proposal.pptx when the user explicitly asks for a local visual deck and Python execution is available
• architecture: present the main result as one Markdown document such as campaign-architecture.md
• delivery: present the generated front-end files as index.html, styles.css, main.js, and mock-data.js
• full: present the planning content as one Markdown document such as campaign-full.md, and present the front-end files as index.html, styles.css, main.js, and mock-data.js

Handoff requirements:

• label each file clearly in the response body
• keep file names and section order aligned with the response body
• when the mode includes multiple files, provide each file's full content in its own clearly labeled section
• when local artifacts are generated with Python, report the exact file names and paths in plain language
• if the user explicitly asks how to save the files locally, describe the file names and where the content belongs in plain language rather than generating executable commands

Anti-copy rules

Do not simply restyle the reference.

The new campaign must change at least 2 of these 4 dimensions:

1. campaign theme
2. reward design
3. task structure
4. module order or core interaction

Do not preserve all of the following at the same time:

• same hero structure
• same gameplay loop
• same reward chain

Call out the main changes briefly in the proposal.

Reference-to-theme translation rules

Treat the reference as a source for structure, interaction pattern, density, and campaign rhythm first, and as a source for visual style only when it fits the user's target theme.

Use this decision rule:

• If the target campaign theme is close to the reference theme, you may inherit the reference's palette and styling direction.
• If the target campaign theme is different from the reference theme, keep the useful structure and interaction cues, but rebuild the visual style around the target theme.

When the target theme and reference theme conflict:

• prioritize the target festival, season, brand tone, and audience mood
• borrow layout logic, gameplay framing, and information hierarchy from the reference
• do not carry over mismatched seasonal colors or decorative symbols by default

Example:

• if the reference looks like a Spring Festival page with red and gold styling, but the new brief is for a Dragon Boat Festival campaign, do not keep the page red by default
• instead, keep the helpful campaign structure, then shift the visual direction toward Dragon Boat Festival cues such as bamboo green, jade green, lake blue, rice dumpling motifs, rope textures, water-wave shapes, or cooler early-summer contrast

Confidence rules

Always separate content into these layers when relevant:

• Observed: directly visible from the reference
• Inferred: likely based on common campaign patterns
• Assumed: filled in because the reference is incomplete

If text is blurry or a state is hidden, say so directly.

Delivery file rules

For delivery and full, default to this file set:

• index.html
• styles.css
• main.js
• mock-data.js

Optional when a character-led hero is requested and image generation is available:

• assets/hero-figure.png

If the user explicitly asks for local front-end files and the host environment supports local execution, the skill may use Python to write these files directly to the workspace or user-specified directory.

File responsibilities:

• index.html: page structure, visible module internals, decorative wrappers, and realistic placeholder copy
• styles.css: design tokens, background atmosphere, section chrome, CTA styling, popup styling, and responsive behavior
• main.js: render repeating data, event binding, state updates, popup control, and lightweight view-state changes
• mock-data.js: campaign meta, tasks, prizes, CTA text, popup data, and enough mock content to render a visually complete first screen

Optional hero asset generation

When the user wants a character-led campaign page but does not provide a source image, the skill may generate one original hero asset before front-end delivery if the host environment supports image generation.

Constraints:

• generate one original adult female hero image
• image direction should prioritize theme-matched wardrobe, dominant colors, accessories, props, and styling
• use a glamorous, attractive, stylish, slightly sexy commercial campaign poster direction
• do not generate a male hero by default
• do not generate explicit sexual content, nudity, fetish styling, or pornographic framing
• save or label the asset as assets/hero-figure.png
• if image generation is unavailable, still output the hero structure and clearly reserve the asset slot

Female-led hero default

For character-led campaign delivery, the default first-screen visual should use one adult female hero figure as the dominant visual focus.

Requirements:

• the hero figure must be an adult woman
• do not replace the hero with a male figure by default
• do not generate mixed-gender hero focus unless the user explicitly asks for it
• the wardrobe, dominant colors, accessories, props, and styling must match the campaign theme
• if the campaign is festival-based, the character styling should visibly reflect that festival rather than using a generic outfit
• prioritize glamour, attractiveness, confidence, and poster-like visual appeal
• allow stylish and slightly sexy commercial-fashion styling for stronger attention
• keep the result within public campaign standards: no nudity, no explicit sexual pose, no fetish styling, and no pornographic framing
• the female figure should remain the main first-screen anchor, with title, CTA, and reward device arranged around her

Theme examples:

• Spring Festival: red as the dominant color, with gold accents, festive dress or qipao-inspired styling, lanterns, knots, and warm holiday accessories
• Dragon Boat Festival: bamboo green, jade green, lake blue, lighter summer styling, rope knots, leaf textures, and seasonal props
• Valentine-style campaign: rose red, wine red, blush pink, elegant fitted styling, floral or gift-box props

H5 length control rule

Do not default to a full top-to-bottom stack for every module.

Prefer a tab-first H5 layout when any of the following is true:

• there are more than 5 major modules
• the page includes task lists, prize pools, records, and long rules together
• the default layout would likely become an overly long mobile page

In these cases:

• keep the first screen focused on hero + core action + one key summary module
• move secondary content into sticky tabs
• render only the active tab panel by default
• place verbose rules, records, and explanations in popups, drawers, or accordions when appropriate
• use tabs as a page-shortening strategy, not as a cosmetic decoration

Delivery schema guidance

Prefer a schema that covers both campaign config and page delivery contract.

Typical sections:

• campaignMeta
• hero
• tasks
• rewards
• lottery
• modules
• popups
• stateMachine
• tracking

Important constraints

• Stay on H5/Web + HTML/CSS/JS only
• Never pretend uncertain text is exact
• Never invent backend endpoints
• Never claim pixel-perfect parity from a blurry image
• Favor reusable modules and editable data structures

Visual fidelity rules

For delivery and full, default to a high-fidelity visual draft, not a low-fidelity wireframe.

Before writing code, extract the screenshot's likely visual language in 4 to 8 short bullets:

• palette and contrast style
• hero composition
• decoration density
• card or panel treatment
• CTA style
• icon/badge/tag style
• popup tone
• overall mood keywords

Then make the code reflect that visual language directly.

But do not follow the screenshot's visual language blindly.

Use this priority order for visual decisions:

1. explicit user brief and target campaign theme
2. target holiday/season/brand tone
3. reference layout and interaction cues
4. reference palette and decorative styling

If the reference palette conflicts with the new campaign brief, say so briefly and switch to a target-appropriate palette. In that case, the visual extraction summary should separate:

• reusable structural cues from the reference
• replaced visual cues that should be rebuilt for the new theme

Launch-ready front-end quality rule

For delivery and full, the generated result should feel like a launch-ready H5 front-end deliverable rather than a starter scaffold, plain wireframe, or demo shell.

Requirements:

• render a visually complete mobile-first first screen with strong hierarchy, atmosphere, and branded tone
• include representative internal structure for each major module instead of empty containers
• use realistic mock copy, labels, badges, numbers, CTA text, and popup content
• cover key front-end states such as active, selected, disabled, claimed, exhausted, popup-open, and tab-selected when relevant
• prefer compact, production-like H5 information architecture instead of excessive vertical stacking
• include responsive behavior, stable spacing, and usable touch targets for mobile rendering
• make CTA areas, popup layers, tab bars, and reward/task states feel polished enough for design review or front-end handoff
• keep the code editable and data-driven without inventing backend APIs or hidden business logic

Boundary:

• this means production-like front-end finish, not a fully backend-connected production deployment

HTML expectations

• Do not output only empty section containers.
• Include representative nested content for the hero, progress/task/reward modules, active tab panels, and popup shells.
• When a female-led hero is used, include an explicit figure wrapper and image slot such as assets/hero-figure.png instead of leaving the hero text-only.
• For tab-first pages, include a sticky tab bar and representative nested content inside each tab panel.
• Use realistic wrappers such as badges, ribbons, tabs, stat chips, progress nodes, reward cards, glow layers, and floating ornaments when the reference implies them.
• Keep the structure editable, but visually expressive on first render.

CSS expectations

• Start with :root tokens for major colors, gradients, shadows, radii, and spacing.
• Build atmosphere first: page background, hero backdrop, decorative light/shapes, panel chrome, and CTA emphasis.
• Prefer layered gradients, image-free ornaments, shadows, strokes, masks, and glow treatments over flat white cards.
• Style sections as distinct visual modules instead of repeating the same generic card everywhere.
• Support sticky mobile tabs, active tab states, and compact tab-panel switching for long H5 pages.
• When a female-led hero is used, style the figure area as a real visual focal point with framing, light, depth, and theme-specific ornaments.
• Include responsive handling for mobile-first rendering.

JavaScript expectations

• Render repeated lists from data, but avoid reducing the whole page to blank placeholders.
• Support interactive states that help sell the concept visually, such as active tabs, selected rewards, progress states, countdown text, and popup opening.
• Support lightweight tab switching and active panel state when the delivery uses a tab-first layout.
• Keep interactions lightweight and front-end only unless the user provides real APIs.

Mock data expectations

• Provide enough titles, subtitles, badges, numbers, and CTA text to make the page look complete.
• Use mock labels that match the proposed campaign tone instead of filler text.

Delivery anti-patterns

Avoid these default outputs unless the user explicitly asks for minimal scaffolding:

• Arial plus gray background plus white rounded cards for every module
• repetitive .section-card wrappers with empty containers
• only one-line <h1> and <p> placeholders in the hero
• visually neutral buttons with no hierarchy
• a page that reads like a wireframe rather than a campaign landing page
• a character-led brief solved with a text-only hero and no figure slot
• a long H5 page created by vertically stacking every module by default
• rules, records, and prize details all expanded on the main page without tabs or progressive disclosure
• output that looks like a bare demo, starter, or wireframe instead of a near-launch H5 front-end draft
• placeholder-only sections with weak hierarchy and incomplete module internals
• visually finished hero areas paired with unfinished lower modules that break the sense of a shippable page

Example user requests

• “参考这几个活动页，给我出一个新的 H5 活动方案。”
• “根据这个参考图，先做玩法抽象，再给我页面架构。”
• “按这个活动参考，输出 HTML + CSS + JS 版本。”
• “我想同时要策划和代码，你走 full mode。”