alieslami745-bot/landing-skill

Figma Design-System Landing

Overview

Turn a complete landing-page brief into a finished Figma design. Infer the smallest useful page structure from the brief, map each requirement to the authorized design system, compose a local derived pattern only when the system has no single matching component, and run an automatic visual polish pass after assembly.

This skill designs in Figma. It does not write HTML, CSS, React, Next.js, or other implementation code. It never edits or publishes the source design-system library.

The authorized visual language remains the source of truth. The only deliberate exceptions are:

• a locally applied Figma font fallback when the design-system font is unavailable;
• a local derived composition/component built from approved design-system parts and Figma primitives whose visual values are bound to design-system styles or variables;
• an empty asset slot when neither the design-system nor the brief contains a suitable asset.

Every exception must be visible in the completion report.

Routing: Basalam or custom Design System

Resolve the Design System route per landing run, before any Figma or Mobbin operation:

• BASALAM_MODE: use the bundled Basalam source in this package. Do not ask the user for a Design System link or another Design System.
• CUSTOM_DS_MODE: use the Design System or installed Design-System skill supplied by the user.
• ROUTE_PENDING: the user requested a landing but the brand route is not explicit yet.

If the brief explicitly says the landing is for Basalam, select BASALAM_MODE without asking again. If it explicitly names another brand or product context, select CUSTOM_DS_MODE. If neither is clear, ask exactly:

این لندینگ برای باسلام است؟ بله / خیر

Make no Figma or Mobbin mutation while the route is ROUTE_PENDING. Keep the answer scoped to the current landing run; if the brief or brand changes, resolve the route again.

First-use onboarding

After the route is known, on the first invocation in a new conversation, if the user has not already supplied all required inputs, send one short route-specific message before detailed questions or preflight:

• BASALAM_MODE:

  برای شروع بفرست: ۱) brief ۲) نود/فریم مقصد در Figma ۳) assetهای لازم، در صورت وجود.

• CUSTOM_DS_MODE:

  برای شروع بفرست: ۱) brief ۲) design system یا اسکیل آن ۳) نود/فریم مقصد در Figma ۴) assetهای لازم، در صورت وجود.

If the inputs are already complete, skip onboarding and run preflight. Do not repeat it after the user has supplied the inputs. Continue to collect only missing details and return BLOCKED without mutation when a prerequisite is still absent.

When to use

Use this skill when the user wants a landing page designed in Figma and provides:

1. a complete brief and its approved content;
2. either BASALAM_MODE with the bundled source or CUSTOM_DS_MODE with one explicit, accessible Figma design-system source;
3. one exact, editable Figma destination.

Mobbin is an optional research aid, not a required input. If a configured Mobbin MCP is available, use it read-only to find nearby UX patterns before composing a missing pattern. When Mobbin research is actually needed but no configured, authorized Mobbin MCP is available, pause before any Figma mutation and offer the connection choice described below. After the user chooses local continuation—or when a connected Mobbin has no useful match—continue with the local UI/UX method in this skill.

Do not use this skill for code, copy-only work, design-system creation, source-library maintenance, or an unconstrained visual exploration that does not have an authorized Figma source and destination.

Required inputs

Treat blank, unknown, TBD, ambiguous, inaccessible, or conflicting values as missing. Do not silently choose a destination or invent business facts.

0. Route

Require a resolved BASALAM_MODE or CUSTOM_DS_MODE. If the route is unknown, use ROUTE_PENDING, ask the Basalam question, make zero mutations, and wait for the answer.

1. Brief

Require:

• product or service and offer;
• target audience, user problem, awareness level, and important objections;
• value proposition and supported benefits;
• one conversion goal and one primary CTA;
• approved facts, claims, proof, prices, legal text, and section copy when those are needed;
• required and forbidden sections, if the user has either;
• language, writing direction, requested breakpoints, and viewport sizes;
• the intended role, aspect ratio, or content need for each expected image, icon, or illustration.

Use supplied assets or approved design-system assets when available. A missing visual asset does not by itself block the run: it may be resolved with the nearest permitted material or an explicit empty asset slot as described below.

Draft ordinary interface copy only when the brief explicitly permits it and the supplied facts are sufficient. Never invent claims, proof, prices, testimonials, legal language, or business facts.

2. Design-system source

In BASALAM_MODE, resolve the bundled source only from these package-relative paths:

• references/basalam-design-system/manifest.json
• references/basalam-design-system/BASALAM-RULES.md
• references/basalam-design-system/kit/
• assets/basalam-design-system/fonts/

Verify the manifest, required coordination files, relevant component references, and font assets before Figma mutation. Do not ask the user for a Design System URL or silently substitute another system. If the bundle is missing or fails integrity checks, return BASALAM_DEPENDENCY_MISSING with the exact missing/corrupt paths and make zero mutations.

In CUSTOM_DS_MODE, require an unambiguous Figma library/file URL or key, with read access and identifiable relevant published components, variants, variables, text styles, and surface/background styles, plus any available icons/assets. Absence of a suitable icon or asset is handled by ASSET_NEAREST or ASSET_SLOT; it does not make the source invalid by itself. Require the intended theme or mode when more than one exists.

If the user names an installed design-system skill in CUSTOM_DS_MODE, load it alongside this skill. A skill name is sufficient only when it resolves one authorized Figma source unambiguously; otherwise report the source as missing.

Bundled Basalam source

The Basalam route is portable: the package contains a versioned snapshot of the user-provided basalam-design-system rules, kit references, and Dana font files. Resolve them relative to this skill package; never use a personal absolute path and never require a separately installed basalam-design-system skill for BASALAM_MODE.

Read BASALAM-RULES.md and the two coordination files in kit/ first, then load only the component/token references relevant to the brief. The bundle is read-only during a design run. Its manifest records provenance, snapshot date, file sizes, and SHA-256 hashes. Bundled fonts are resources, not permission to install fonts automatically; verify their availability in Figma and apply the documented font policy if the runtime cannot see Dana.

3. Figma destination

Require a Figma Design file plus an exact existing destination page and insertion node/frame, supplied as a node URL or equivalent identifiers, with edit access. Do not create a replacement file, page, or destination when any part is absent.

A file-level URL alone never satisfies this requirement. Do not choose a default page, use the canvas root, or create an insertion frame. Report the missing exact page, insertion node/frame, and any unverified edit access as separate gaps.

Non-negotiable boundaries

• Work only in Figma. Never output implementation code.
• Directly mapped visual components must have provenance in the explicitly authorized design-system source.
• A local derived composition is allowed only in the destination file. Its visual children may be authorized design-system instances, published variants, variables, text styles, surface/background styles, icons, approved assets, and native Figma primitives such as Frame, Auto Layout, Text, Rectangle, and Component.
• Every visual property of a local primitive must be bound to an authorized design-system token/style. No hard-coded color, gradient, overlay, font size, weight, line-height, spacing, radius, shadow, effect, or arbitrary visual value is allowed, except the documented FONT_FALLBACK family override.
• A local derived component must never be detached from an authorized instance, published to the source library, or used to silently create a second design language. It stays inside the destination and its provenance is recorded.
• Never use a third-party library, an external asset, a hand-drawn icon, a copied Mobbin visual, or a foreign component.
• Mobbin results are UX references only. Reinterpret their hierarchy, interaction pattern, and composition with the authorized design system; do not reproduce branded styling or import their assets.
• Do not mention or pause for Mobbin when every required pattern is DIRECT_MAPPED. Never install or connect Mobbin on the user's behalf unless they explicitly ask for setup help.
• In BASALAM_MODE, use only the bundled Basalam source and its verified provenance. Never silently fall back to a custom or unrelated Design System.
• The primary design-system font is always preferred. A font fallback is allowed only under the Font fallback policy below.
• Background polish may use only existing design-system surface/background styles. Never create a new gradient, overlay, color, or background effect.
• Do not change copy, claims, section order, section count, CTA meaning, or supplied assets during Polish Pass.
• Never edit, publish, or mutate the source design-system library.
• Never make a partial design while a required prerequisite, destination, permission, content, token, or valid construction plan is missing. An approved empty asset slot is an explicit completion exception, not an unreported partial.

Construction modes and statuses

Use these terms in the internal coverage map and final report:

• DIRECT_MAPPED: an existing authorized design-system component/variant is used.
• DS_COMPOSED: a local composition or local reusable component is built in the destination from authorized DS parts and token-bound Figma primitives.
• ASSET_NEAREST: the closest permitted asset from the design system or the brief is used.
• ASSET_SLOT: no suitable asset exists; an empty replacement slot is created with DS layout/surface rules.
• FONT_FALLBACK: the primary DS font is unavailable and an accessible Figma font is applied while DS typography metrics are preserved.
• POLISH_COMMITTED: the automatic polish passed QA.
• ASSEMBLY_DELIVERED_POLISH_ROLLED_BACK: assembly is valid, but polish failed after two attempts and was removed.
• AWAITING_MOBBIN_CHOICE: reference research is needed, Mobbin is not connected, and the user has not chosen whether to connect it or continue locally; no mutation has occurred.
• MOBBIN_SKIPPED_BY_USER: the user chose the local UI/UX method after Mobbin was found unavailable.
• ROUTE_PENDING: the landing brand route is unknown and the Basalam question is waiting for an answer; no mutation has occurred.
• BASALAM_MODE: the bundled Basalam source is selected for this landing run.
• CUSTOM_DS_MODE: a user-supplied Design System source is selected for this landing run.
• BASALAM_DEPENDENCY_MISSING: the bundled Basalam source or its integrity requirements are missing or invalid; no mutation has occurred.
• BLOCKED: a prerequisite or required construction rule cannot be satisfied.

DS_COMPOSED, ASSET_SLOT, and FONT_FALLBACK are permitted, documented exceptions. AWAITING_MOBBIN_CHOICE and ROUTE_PENDING are temporary pauses, not BLOCKED. BASALAM_DEPENDENCY_MISSING is a preflight stop with zero mutations. These statuses do not authorize arbitrary custom styling.

Atomic preflight gate

Before any mutating Figma operation, run one complete read-only preflight. Creating a file, page, frame, node, component, instance, placeholder, or partial section counts as mutation.

Load figma:figma-generate-design and figma:figma-use before any Figma read or write operation. In BASALAM_MODE, load the bundled Basalam rules and verify its manifest before resolving components; in CUSTOM_DS_MODE, load the named design-system skill before resolving its source.

Validate all of the following together:

1. The route is resolved. In BASALAM_MODE, the bundled manifest, required references, and font assets are present and valid; in CUSTOM_DS_MODE, the user-supplied Design System source is explicit and reachable.
2. The brief contains the required facts, approved content, CTA, language/direction, and breakpoint requirements.
3. The destination file, page, insertion node, file type, and edit permission are valid.
4. The landing structure can be inferred without inventing business facts.
5. Every selected section, breakpoint, and required state is either DIRECT_MAPPED or has a valid DS_COMPOSED plan.
6. Every DS_COMPOSED plan can be built from authorized DS parts and token-bound native Figma primitives without a new token, style, component-library edit, or foreign asset.
7. Every expected asset has one of these outcomes: supplied/authorized asset, ASSET_NEAREST, or ASSET_SLOT.
8. The primary DS font is available for every required script, weight, and style; or a valid accessible Figma fallback candidate has been identified.
9. Determine whether Mobbin research is needed. Record MOBBIN_NOT_NEEDED when every required pattern is DIRECT_MAPPED. Otherwise record MOBBIN_USED, MOBBIN_SKIPPED_BY_USER, MOBBIN_ERROR, MOBBIN_NO_MATCH, or LOCAL_UX_METHOD. If Mobbin is needed but unavailable and the user has not yet chosen a path, use the Mobbin connection choice below before returning READY.

Build a coverage table before mutation:

Requirement	Section purpose	Construction mode	DS children/primitives	Tokens/styles	Content source	Asset status	Font status	Mobbin/local rationale	Breakpoint/state	Status

Return READY only when every required row has a valid construction mode, every visual value has an authorized source or a documented FONT_FALLBACK/ASSET_SLOT exception, every asset gap has an explicit nearest-material or slot plan, and any required font fallback is verifiable.

If any check fails:

• return BASALAM_DEPENDENCY_MISSING when the bundled Basalam source or its integrity check fails; otherwise return BLOCKED;
• make zero mutations;
• collect all gaps in one pass instead of asking for them one at a time;
• group gaps under Brief, Content, Assets, Design System, Destination, Permissions, Construction, and Font;
• name the exact missing/invalid item and the exact action needed to resolve it.

A change to the brief, content, design-system source, destination, permissions, Mobbin result, font availability, or construction map invalidates READY and requires a fresh read-only preflight.

Waiting for the user's Mobbin connection choice is not BLOCKED. Set AWAITING_MOBBIN_CHOICE, make zero mutations, send only the short choice prompt below, and resume preflight after the reply.

Design thinking and section inference

Analyze before selecting components:

1. Empathize: extract the audience, job to be done, pain, awareness, motivations, and objections.
2. Define: state the offer, value proposition, conversion goal, primary CTA, and main message.
3. Structure: choose the smallest sequence of sections that moves this audience from context to action.
4. Map: connect each section and state to DIRECT_MAPPED or DS_COMPOSED components and approved content/assets.
5. Validate: confirm that narrative order, component capacity, font metrics, assets, breakpoints, CTA priority, and accessibility agree.

Possible section roles include Header, Hero, Problem, Benefits, Features, Media/Demo, How It Works, Use Cases, Social Proof, Case Studies, Comparison, Pricing, Risk Reduction, Testimonials, FAQ, Final CTA, and Footer. This is a catalog, not a checklist. Do not impose a fixed number of sections.

Start with explicit required, forbidden, and ordered sections. Add a section only when the audience, offer, conversion path, objection, or supplied evidence gives it a clear job. Once Design Thinking marks a section/state as needed, it cannot be silently removed to hide a coverage gap.

Mobbin and local UX method

For a missing pattern or a DS_COMPOSED section:

1. Check whether a configured, authorized Mobbin MCP is available. Do this only after identifying a missing pattern that would benefit from reference research.

2. If Mobbin is unavailable, unauthorized, or has a connection/authentication failure and the user has not already chosen local continuation for this run, make zero mutations, set AWAITING_MOBBIN_CHOICE, and send this exact short prompt:

   برای پیدا کردن الگوی نزدیک، Mobbin لازم شده اما وصل نیست. اگر می‌خواهی اول آن را وصل کن و بگو «ادامه بده»؛ اگر نه بگو «بدون Mobbin ادامه بده» تا با منطق محلی UI/UX و قوانین Design System جلو بروم.

   Stop and wait for the reply. If the user confirms the connection, recheck Mobbin before continuing. If the user chooses to continue without it, record MOBBIN_SKIPPED_BY_USER, use the local method, and do not ask again during that run.

3. When Mobbin is connected, search it read-only by semantic intent (for example, pricing comparison, trust proof, onboarding steps, or FAQ), not by brand name.

4. Extract only the familiar UX job, hierarchy, interaction model, density, and responsive behavior. Do not copy the screenshot, brand, colors, typography, or assets.

5. If a connected Mobbin returns no close result, record MOBBIN_NO_MATCH and use the local method without another connection prompt. If the connected service has a non-connection operational error, record MOBBIN_ERROR, explain it briefly, and use the local method.

6. For the local method, choose the simplest familiar pattern that supports the CTA, progressive disclosure, scanning, readable content density, responsive stacking, RTL/LTR order, accessibility, and the available DS components/tokens.

7. Record whether the decision came from Mobbin or the local UX method, any user choice, and why the chosen pattern is appropriate.

Missing patterns and local reusable components

Prefer DIRECT_MAPPED when an authorized component and variant satisfy the semantic role. If no single component exists, use DS_COMPOSED:

1. Resolve the closest authorized components, variants, primitives, text styles, surfaces, variables, icons, and approved assets.
2. Create the composition only inside the supplied destination node.
3. Use native Figma Frame, Auto Layout, Text, Rectangle, or Component primitives only as structural or token-bound visual pieces.
4. Bind every fill, text style, spacing, radius, effect, and layout value to an authorized DS style/variable. Do not approximate a missing token with a guessed value.
5. If the same composition is used more than once, create one local reusable Figma component in the destination and instance it. Keep its name, source-child map, exposed properties, and usage locations in the report. Do not publish it.
6. Preserve the same semantic order and CTA priority across requested breakpoints. Add only the states needed by the brief and the DS-compatible interaction.

A primitive composition counts as DS_COMPOSED only when all of those conditions are met. A near-name match, arbitrary frame, generic accordion, manual icon, or unbound primitive is not coverage. If the required pattern cannot be expressed with the available DS parts and token-bound primitives, return BLOCKED before mutation.

Font fallback policy

Use the design-system family, text styles, sizes, weights, line-heights, letter spacing, and hierarchy whenever the family is available in the current Figma environment.

If the DS family is unavailable, inaccessible, missing a required script/glyph, or missing a required style/weight:

1. Select an accessible font available in Figma. Prefer, in order: required script/glyph coverage; closest style category and width/metrics; closest semantic weight; then closest brand-appropriate tone.
2. Keep the design-system font size, semantic weight, line-height, letter spacing, casing, and hierarchy. If an exact weight is unavailable, use the nearest accessible weight and report the mapping.
3. Apply the fallback directly in the destination without editing the source library or silently changing other typography tokens. Preserve the original DS text-style reference where Figma permits and record the local family override.
4. Recheck glyph rendering, RTL shaping, line breaks, text height, clipping, overflow, CTA position, and responsive behavior at every requested breakpoint before Polish Pass.
5. Mark the result FONT_FALLBACK and report the expected family, why it was unavailable, the selected Figma family, weight/style mappings, affected nodes/sections, risks, and QA result.

Never silently use a default/system font, download an external font, or claim a pure DS typography match when a fallback was used. If no accessible Figma font can cover the required scripts, stop with BLOCKED and report the exact font gap.

Asset policy

Search only the authorized design-system assets and files explicitly supplied in the brief. Do not fetch assets from Mobbin or any other external source.

• If a close material exists, use the closest appropriate asset and mark ASSET_NEAREST. Preserve the intended role, crop, aspect ratio, and content meaning.
• If no close material exists, create an empty ASSET_SLOT using an authorized structural container, surface/background style, aspect ratio, and layout rules. Do not insert a fake image, generic illustration, or invented icon. Name the slot with the required asset role so it can be replaced later.
• Asset slots are deliverable exceptions. Include their node IDs, intended asset type, aspect ratio, breakpoint behavior, and replacement instruction in the final report.

Figma assembly transaction

After the preflight returns READY:

1. Load figma:figma-generate-design and figma:figma-use for the write workflow. In BASALAM_MODE, use the verified bundled Basalam source; in CUSTOM_DS_MODE, use the named design-system skill when provided.
2. Record the exact pre-run destination state and a precise rollback plan.
3. Build only inside the authorized destination node, in the planned section order.
4. Assemble DIRECT_MAPPED instances and DS_COMPOSED local components; create ASSET_NEAREST or ASSET_SLOT outcomes; apply FONT_FALLBACK before final layout checking.
5. Track every created node and every changed property. Inspect each major section and each requested breakpoint.

If an unforeseen provenance, component, token, content, asset, permission, or font failure appears during assembly, stop, undo only this run's assembly mutations, verify the destination matches its pre-run state, and report BLOCKED. If exact rollback cannot be guaranteed, do not begin assembly.

Automatic Polish Pass

Immediately after a valid assembly, take a polish snapshot and run Polish Pass automatically. Do not wait for intermediate user approval.

Polish may change only:

• layout, alignment, spacing rhythm, whitespace, hierarchy, and density;
• an already mapped component variant or property;
• the ordering and combination of existing design-system surface/background styles to make adjacent sections coherent, with readable contrast and intentional transitions;
• responsive constraints and sizing needed to preserve the same structure.

Polish must not change:

• copy, claims, content, CTA meaning, section count, section order, or narrative;
• the chosen font family after the Font fallback policy has run;
• assets, except to preserve their already planned crop/fit;
• the design-system library;
• any color, gradient, overlay, shadow, effect, token, style, component, or asset that is not already authorized.

Use at most two polish rounds. For each round:

1. snapshot the current post-assembly/polish state;
2. make only targeted DS-bound changes;
3. inspect screenshots and metadata at every requested breakpoint;
4. run the final QA checklist below.

If a round fails, roll back that round and use the last valid state for the next attempt. If polish or QA still fails after round two, roll back all Polish Pass mutations to the pre-polish assembly snapshot, keep the valid assembly, and deliver it with status ASSEMBLY_DELIVERED_POLISH_ROLLED_BACK. Do not roll back the valid assembly merely because polish was unsuccessful.

Validation and QA

Before reporting completion, verify:

• every direct instance has authorized provenance;
• every DS_COMPOSED local component has only authorized DS children or token-bound native Figma primitives and remains in the destination;
• there are no detached instances, foreign-library components, hard-coded visual values (except the documented FONT_FALLBACK family override), external assets, or unreported exceptions;
• all planned sections and required states are present, with no unjustified extras;
• copy and assets occupy the intended slots; ASSET_SLOT nodes are clearly named;
• section order and CTA hierarchy match the Design Thinking plan;
• FONT_FALLBACK, if used, passed glyph, RTL, reflow, height, overflow, and breakpoint checks;
• every requested breakpoint has coherent hierarchy and direction;
• there is no clipping, overlap, or horizontal overflow;
• grid/alignment and spacing rhythm are coherent;
• hierarchy and primary CTA are clear;
• contrast meets WCAG AA and interactive touch targets are usable;
• the final screenshot and metadata inspection match the reported status.

If an assembly validation issue (including contrast, touch target, or responsive failure) cannot be fixed with already authorized components, variants, tokens, styles, and assets, roll back the assembly and report BLOCKED. If a Polish Pass validation issue requires a new token, style, asset, component-library edit, or unbound value, roll back only polish and deliver the valid assembly.

Response contract

When blocked, respond in this form:

PREFLIGHT: BLOCKED
Changes made: none

Missing or invalid:
- [Category] Exact item and why it blocks the design.

Required next actions:
- Exact action the user must take.

When ready, continue without requesting another approval. In the completion report include:

• Figma file, target page, insertion node, and created frame/node IDs;
• final section order for each breakpoint;
• DIRECT_MAPPED and DS_COMPOSED mappings, local reusable component names/IDs, child provenance, and token/style bindings;
• route/mode, bundled Basalam source version or custom Design System source, and dependency status;
• Mobbin status, any connection/local-continuation choice, and the UX rationale used;
• font status, including any fallback reason and mappings;
• ASSET_NEAREST and ASSET_SLOT details;
• number of Polish Pass rounds, changes, QA result, or rollback status;
• assumptions, unresolved replacement work, and final validation status.