From almedia-code
Use for any Freecash design work — producing mockups, prototypes, HTML artifacts, React components, or UI code; critiquing designs against the system; or turning meeting notes, briefs, or specs into design ideations. Triggers on prompts to design, build, mock up, prototype, wireframe, sketch, ideate, visualize, or iterate on any Freecash screen, flow, or component, including the core surfaces (Earn, Deals, My Offers, Cashout, Quests) and component-level work (deal cards, buttons, bottom navigation, offer rows, progress bars). Also triggers on exploratory phrasing like "help me design X," "I'm thinking about a feature for Y," "what could Z look like," or when the prompt provides meeting notes, Slack threads, or briefs needing structure. Always load this skill when the word "Freecash" appears alongside any design or UI intent. Always produces full HTML artifacts (not inline previews) so the user can evaluate at native mobile viewport size.
How this skill is triggered — by the user, by Claude, or both
Slash command
/almedia-code:freecash-designThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill produces Freecash-accurate design output: mockups, prototypes, HTML artifacts, and component code. It handles two distinct request types — exploratory ideation (where the user wants to think through a problem and see options) and direct execution (where the user already knows what they want built). The skill routes between these modes automatically based on the prompt.
This skill produces Freecash-accurate design output: mockups, prototypes, HTML artifacts, and component code. It handles two distinct request types — exploratory ideation (where the user wants to think through a problem and see options) and direct execution (where the user already knows what they want built). The skill routes between these modes automatically based on the prompt.
Everything needed to produce on-brand output lives inside this skill folder. No external tools, MCP connections, Figma calls, or visualize tools are required for HTML/React rendering. Files in this folder are sufficient and authoritative.
Decide which mode applies based on the user's prompt:
Ideation mode — full structured flow (classify → intake → confirm → directions → normalize → render). Triggers when the user:
Execution mode — skip ideation, normalize the prompt, then render. Triggers when the user:
When uncertain, default to ideation mode and offer the user an escape hatch on the first turn. False starts are cheap; rendering the wrong thing is expensive.
Sequential, interactive. Walk the user through one phase at a time. Never batch phases. Never skip the classification step.
Use ask_user_input_v0 to ask:
"Before I dig in, how big is this change?"
Options:
STOP after this tool call. End your turn. Wait for the user's selection.
Route based on answer:
Ask in a single message:
"Quick context:
- Which screen or component are we changing?
- What's the change, and the goal in one sentence?
- Anything specific I should NOT change?"
Wait for the answer. Then run the Confirmation protocol below.
Ask in a single message:
"Answer what you can — leave blanks if unsure:
- What's the user problem? (What's broken, missing, or suboptimal today?)
- What surface are we designing on? (Which screen, tab, or flow — or new surface?)
- What does success look like? (A metric, behavior change, or qualitative goal)
- Any constraints or anti-goals? (Technical, legal, tracking, past attempts to avoid)"
Wait for the answer. Then run the Confirmation protocol below.
Never skip. Never batch with rendering.
Write a prose summary — 2-3 sentences for small changes, 3-4 for larger. Format as a single paragraph the user could paste into a ticket.
Call ask_user_input_v0:
Question: "Does this capture it accurately?"
Options:
STOP. End your turn. Do not render, do not generate directions, do not take any further action until the user selects an option.
Only on "Yes, proceed" → advance: small changes → Variant detail + Normalize + Render; larger changes → Phase 3 (with 3 directions).
Produce 3 genuinely divergent directions — different solutions to the problem, not variations of one solution.
Good divergence:
Bad divergence (reject internally): same structure, different colors / radii / button counts.
For each direction, provide:
Then proceed to Normalize, then Render.
For each variant, provide:
Then proceed to Normalize, then Render.
No classification, no intake, no confirmation phase — the user has already specified what they want. Proceed directly to Normalize, then Render. If the prompt is genuinely underspecified, ask one targeted clarifying question first; otherwise normalize and proceed.
⚠️ Normalize runs before every render, in both ideation mode and execution mode. It exists because user prompts written in natural language consistently leak two failure modes:
Structural drift — "create a banner for the Earn tab" gets rendered as a banner on a generic dark screen, losing the canonical Bubbles + Active Offer Header + reward sections that define the My Offers Earn tab. The prompt didn't explicitly require those, so they got dropped.
Visual drift — "bold," "promotional," "premium," "playful" pull Claude toward generic web/marketing design language (saturated brand-color block fills, text underlines, gradient backgrounds spanning the whole card). The Freecash system has its own vocabulary for emphasis, and natural-language tone words don't map to it.
Normalize translates the user's prompt into a structured form that anchors against canonical files and uses Freecash-specific vocabulary. The structured prompt is shown to the user for a single confirmation, then becomes the binding spec for render.
If the user's prompt already contains all three of the following anchors, normalization is unnecessary and the skill proceeds directly to render:
examples/ (e.g. "use examples/my-offers.html as the structural baseline")If any of the three is missing, run the full normalization. Auto-skip is for users who already speak the structured format; everyone else gets normalized.
Identify which archetype the user's prompt falls into. Each has its own template.
1. Additive change — adding a component to an existing surface. Verbs: "add," "insert," "place," "include." Example: "add a banner to the Earn tab."
2. Full screen — building a new surface or substantially redesigning an existing one. Verbs: "design," "build," "create," "redesign." Example: "design a new Quests screen."
3. Component-only — work on a single component out of context. Verbs: "make a card," "build a row," "design a button." Example: "make a deal card with a countdown."
4. Critique — evaluating an existing design against the system. Verbs: "review," "critique," "what's wrong with," "audit." Example: "critique this Cashback screen."
If the prompt is ambiguous between two archetypes, default to additive change — it's the most constraining and lowest-risk default.
Use these as the structural rewrite of the user's prompt. Fill the brackets from the user's prompt + the design system files. Replace tonal language ("bold," "promotional") with token-named structural language using the Vocabulary translation table below.
TASK: Add [component] to [surface].
STRUCTURAL BASELINE: examples/[file].html — preserve all existing
components, positions, and density exactly. The new component sits
[position relative to existing landmarks].
VISUAL APPROACH: Match the emphasis level of [reference component
in the example file]. The loudest element should be [specific
token-backed treatment]. Surfaces should use [specific token].
ANTI-PATTERNS — do NOT:
- [list 3-5 specific failure modes, drawn from common drift]
REQUIREMENTS:
- [component-specific requirements: copy, behavior, states]
DELIVERABLE: Render the full surface with the new component in
place at native mobile viewport, so the addition can be evaluated
in real context. Do not substitute or simplify any existing
components.
TASK: Design [surface] with the goal of [user-stated goal].
ARCHETYPE: [feed | reward-list | cashback | quests | cashout | other]
— follow the archetype's required body structure per layouts.md.
REFERENCE SCREENS: [examples/earn.html and/or examples/my-offers.html]
— use these for component density, spacing, and visual treatment.
Header pattern (108px) and Bottom TabBar are mandatory.
VISUAL APPROACH: Standard Freecash dark theme. Primary CTAs are
green per components.md `Button` component. Yellow/gold reserved
for `button_special` (rewards-tier high-emphasis only).
ANTI-PATTERNS — do NOT:
- Substitute generic cards for documented components
- Invent visual treatments not present in the example files
- Render a primary CTA in yellow/gold (that's button_special only)
REQUIREMENTS:
- [screen-specific requirements]
DELIVERABLE: Full HTML artifact at 390px viewport, scrollable to
natural content height, with Header + Bottom TabBar.
TASK: Build [component] as a standalone component.
REFERENCE: components.md section [name]. If the component is
documented, follow the documented anatomy, props, density, and
token usage exactly. If it's a new pattern, flag it inline as
[candidate for components.md V1.1] and note the gap.
VISUAL APPROACH: [token-backed treatment]. Primary CTAs use the
green Button per components.md. Reserve yellow/gold for
button_special (rewards-tier only).
ANTI-PATTERNS — do NOT:
- Invent props or variants not in components.md
- Use values outside tokens.md without flagging them
REQUIREMENTS:
- [component-specific requirements]
DELIVERABLE: Component in isolation on a dark surface
(--color-grey-blue-900) at appropriate viewport width.
TASK: Critique [target] against the Freecash design system.
REFERENCE FILES: tokens.md, components.md, layouts.md,
examples/earn.html, examples/my-offers.html — these define
correctness. Anything not in these files is improvisation.
OUTPUT FORMAT: For each issue found:
- What's wrong (specific element + why it diverges)
- What it should be (token, component, or example file reference)
- Severity (blocking / should-fix / minor)
ANTI-PATTERNS — do NOT:
- Critique on subjective taste alone — every issue must reference
a token, component, layout rule, or example file
- Suggest "improvements" that introduce new visual language
After producing the normalized prompt, show it to the user via ask_user_input_v0:
Question: "Here's how I'm reading the brief. Confirm before I render."
Options:
STOP after this tool call. Do not proceed to render until the user confirms.
If the user selects "Adjust scope" or "Adjust visual approach," ask what specifically and re-run normalize.
The normalized prompt is read by designers, PMs, and other team members — not just the original prompter. Write it in a way that someone joining mid-conversation could understand. Don't over-abbreviate. Token references should include the human-readable color name in parentheses on first mention (e.g. --color-freecash-green-500 (brand green)).
Generic design words that must be translated before they enter the normalized prompt. Left column is what users say; right column is what the skill renders against.
| User says | Translate to |
|---|---|
| "bold" / "loud" / "attention-grabbing" | "Use the documented high-emphasis vocabulary: green primary CTA, dollar-amount in --color-freecash-green-500, or category accent color. Do NOT saturate the whole surface." |
| "subtle" / "understated" / "quiet" | "Use --color-grey-blue-700 or -800 surface, no color accents beyond hairline borders, body copy in --color-grey-blue-50." |
| "premium" / "high-end" / "polished" | RESERVED — ask the user what they mean. Premium isn't a documented Freecash mode. Likely they mean either "use button_special rewards treatment" or "tighten density." |
| "playful" / "fun" / "energetic" | "Use the gradient-and-sparkle illustration convention from .pip__image in my-offers.html. Category accent colors (yellow / fuschia / cyan) for section emphasis." |
| "promotional" / "marketing-y" | "Card-style surface with eyebrow pill, headline, subhead, primary CTA. Surface stays --color-grey-blue-700. Loudness comes from the CTA, not the background fill." |
| "modern" / "clean" / "minimal" | NEAR-MEANINGLESS — Freecash is already dark, sans-serif, token-driven. Drop these words from the normalized prompt entirely; they add no constraint. |
| "primary button" / "main CTA" | Green Button component, variant=primary, subVariant=green, per components.md. Background --color-freecash-green-500. NEVER yellow/gold. |
| "special button" / "rewards button" | button_special (gold or bronze), scoped to rewards-tier high-emphasis moments only (streak claim, gold-tier reward unlock). Hard-edge shadow is signature. |
| "hero" / "featured" | Use Offer Card with Size=Large, Emphasis=Highest per components.md. Maximum one per screen view. |
| "card" | Default to --color-grey-blue-700 surface, --radius-04 (16px) corner, 1px hairline --color-neutral-0-a10 inset. |
| "make it stand out" | Specify which mechanism: (a) elevation contrast (lighter surface), (b) accent color border, (c) larger size, (d) different position. Don't leave open-ended. |
If the user's prompt uses a word not in this table that feels like a tonal/emotional descriptor, flag it in the normalized prompt: "User used the word 'X' — interpreting as Y based on context. Confirm if this is wrong."
Apply to all output, whether from ideation mode or execution mode.
Do not produce any visual output before completing every numbered step below. If a step cannot be completed, stop and tell the user rather than proceeding with degraded output. Skipping or batching steps in this section is a failure of the task.
Step 0: Confirm the normalized prompt is locked. Render must not begin until either (a) the user has confirmed the normalized prompt via the Normalize step, or (b) the user's original prompt cleared the auto-skip check (had structural anchor + emphasis anchor + anti-pattern block). If neither is true, return to Normalize. The normalized prompt is the binding spec for everything that follows.
Step 1: Read the design system files in this skill folder. All of them, in order:
tokens.md — the exact CSS variable values you must usecomponents.md — the component patterns and their ruleslayouts.md — the page composition rulesexamples/earn.html — visual reference for feed-style screensexamples/my-offers.html — visual reference for filter + offer screensStep 2: Confirm what you read. Output a single line listing the files you successfully read and the specific tokens you'll use as CSS variables. Example: "Read tokens.md, components.md, layouts.md, examples/earn.html, examples/my-offers.html. Using --color-bg-primary, --color-brand-green, --color-text-default, --space-md, --space-lg, --radius-card, --font-primary." Then add a second line declaring the screen archetype: one of feed (Earn), reward-list (My Offers / offer-detail Rewards tab), cashback, quests, cashout, or other — and for reward-list specifically, confirm the body will use Bubbles + Active Offer Header + Section Header + Reward Row patterns from components.md. If any file failed to read, stop and tell the user.
Density rule (applies to every component). Every numeric value — width, height, padding, gap, font-size, line-height, border-radius — must come from either (a) a token in tokens.md, (b) an explicit pixel value documented in the relevant components.md section under "Density (these are not suggestions)", or (c) a value lifted directly from the matching block in examples/my-offers.html or examples/earn.html. Do not eyeball. If you find yourself thinking "32px feels right" or "let's make it 16px," stop — go look up what the example uses. The example file is the canonical pixel-level reference. If example and components.md disagree, the example wins. If neither covers the case, flag the gap inline with [density gap — verify with design] and use the closest documented value.
Step 3: Render as a full HTML artifact. This is non-negotiable.
Required tool sequence:
create_file producing a .html file saved to /mnt/user-data/outputs/present_files immediately after, to make the artifact visible to the user in Claude's artifact panelThe user must be able to open the rendered output at full fidelity — 390px mobile viewport at native size, fully scrollable, inspectable in the artifact panel. Inline previews shrink the output to thumbnail size and make evaluation impossible.
Forbidden:
visualize tool — produces inline previews instead of artifactsIf you find yourself reaching for any of the forbidden tools, stop — the only correct rendering path for HTML/React is create_file followed by present_files.
Filenames: use the direction or variant name with hyphens (e.g. direction-inline-whisper.html, variant-subtle-default.html). One file per direction or variant.
See Output count below for how many files to create.
After creating files, keep your chat message brief. The artifacts are the deliverable, not the prose around them. A short summary of what each artifact shows is enough — let the user open and judge the work directly.
Step 4: Self-check before presenting. Run this checklist against your output. If any answer is "no" (or "yes" for items framed as failures), regenerate before calling present_files:
var(--color-bg-primary) (dark)?:root?:root? (Should be no.)'Poppins', 'Inter', sans-serif?Button component (variant=primary, subVariant=green, background --color-freecash-green-500)? Yellow/gold buttons are button_special, scoped to rewards-tier high-emphasis only — they are NOT the default primary CTA. If the rendered output uses yellow for a non-rewards CTA (e.g. a promotional banner, a generic action button, a navigation CTA), regenerate with green.components.md? (If you did invent, did you flag them with [candidate for components.md V1.1]?)examples/my-offers.html?Anti-patterns — if your output looks like any of these, regenerate:
examples/my-offers.html. Promotional banners or other additions sit ABOVE this structure, never replace it.button_special (rewards-tier high-emphasis: streak claims, gold-tier reward unlocks, etc.). Standard primary CTAs — including promotional banners, navigation actions, and general conversion buttons — use the green Button component per components.md.--color-freecash-green-500 background filling its full area is wrong. Cards live on --color-grey-blue-700 or -800. Brand color appears in CTAs, accent text (dollar amounts), eyebrow pills, and small decorative gradients — never as a full-card fill.--color-freecash-green-500 for value, --color-yellow-400 for bonus, etc.), or size — never decoration.Reward-list screens — required pattern. If the screen is a reward list (My Offers, an offer's Rewards tab, anything that enumerates ways to earn), the body must be:
tab_primary Horizontal Menu at the top (Earn / Cashback / Surveys / Rewards / Referrals — sticky pill row, horizontally scrollable). This is required, not optional, on the My Offers / offer-detail surface. See examples/my-offers.html line 1036 for the canonical markup.<section class="offer-details"> wrapper with background: var(--color-grey-blue-800) — this is required when the screen shows an offer's reward details. The wrapper contains everything from step 4 onward. The screen stays --color-grey-blue-900; the offer-details area is --color-grey-blue-800. Don't skip this wrapper — without it, the screen reads as a generic dark theme, not as Freecash.tab_secondary (Rewards / Details) — optional, only if the screen is an offer detail[Section Header with Icon] → [Reward Row] × 2-6 → next sectionDo not substitute generic cards, tiles, or list items for Reward Rows on these screens.
If all checks pass, proceed to present_files.
These rules are the floor. They apply even if file reads return less detail than expected.
var(--color-bg-primary), which is #141521. No light mode, ever.'Poppins', 'Inter', sans-serif. No other families. No system-ui as a primary, only as a secondary fallback.:root from tokens.md. No hex codes scattered in rules. No magic pixel values. If a needed value isn't in tokens.md, flag the gap inline with a comment; do not hardcode silently.components.md. Do not invent components. If a needed pattern isn't documented, implement inline and flag with [candidate for components.md V1.1].Button component with variant=primary, subVariant=green per components.md — background --color-freecash-green-500, dark text. Yellow/gold is the button_special component, which is scoped specifically to rewards-tier high-emphasis moments (streak claim, gold-tier reward unlock) and is NOT the default primary CTA. The "Play and Earn $X" button in examples/earn.html is button_special, not the standard primary — do not generalize that pattern to non-rewards CTAs like promotional banners or navigation actions.@phosphor-icons/web) for HTML output or @phosphor-icons/react for React. Default to Regular weight; use Fill for active or emphasized states. Never use Lucide, Heroicons, Material Icons, emoji, or inline SVGs as icon substitutes.navigation icons component set per layouts.md. These are custom Freecash icons and must NOT be replaced with Phosphor.examples/earn.html and examples/my-offers.html. Never invent illustrations, generate fake artwork, or use emoji as illustration stand-ins.Before the final choice prompt, add a short Notes block (2-4 bullets total):
[V1 known gap]Then use ask_user_input_v0 for the final choice:
Question: "Which direction should we go?"
Options (larger changes): Direction A / B / C / Combine elements / Neither, try again Options (small changes): Variant A / B / Combine elements / Neither, try again
Never commit silently. Always give the user the choice.
Unless the prompt specifies otherwise:
<style> block. All tokens defined in :root at the top. No external CSS, no external fonts loaded (reference Poppins in font-family with Inter fallback), no JavaScript unless layout absolutely requires it.bg-[var(--color-bg-primary)]). Import Phosphor icons from @phosphor-icons/react.figma-console MCP plugin for programmatic operations. Load fonts in a separate call before creating text nodes. This is the ONLY case where MCP tools are permitted — for HTML/React output, MCP is forbidden per the Render section.Respect these user signals to change the flow:
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub almedia-tm/almedia-tm-code --plugin almedia-code