Skip to main content

matchplane-ui

Build, redesign, or audit MatchPlane's root and subplatform interfaces with a clean chat-first hierarchy, mobile-first usability, and low-noise Anthropic-art and Apple-design guidance. Use when changing web/, a subplatform UI, login/admin flows, theme/locale controls, or interaction tests.

معلومات المصدر

المستودع
LIghtJUNction/matchplane
آخر نشاط في المصدر
٢٣ أغسطس ٢٠٢٦ في ٠٥:٤٠
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٣
التفرعات
٥

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
5 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
matchplane-ui
description
Build, redesign, or audit MatchPlane's root and subplatform interfaces with a clean chat-first hierarchy, mobile-first usability, and low-noise Anthropic-art and Apple-design guidance. Use when changing web/, a subplatform UI, login/admin flows, theme/locale controls, or interaction tests.
# MatchPlane UI Treat the root shell and every mounted subplatform as the same product surface. The root owns navigation, identity, consent, and platform state; a subplatform owns its domain copy, fields, results, and visual accent through the manifest. Never hard-code a vehicle catalogue into the root shell. ## Workflow 1. Inspect the current route, role, manifest, locale, theme, and authenticated state before changing layout or copy. Reuse existing generic components and API helpers. 2. Read `PRODUCT.md`, `docs/subplatform-contract.md`, and the relevant component tests. For visual work, also use the `impeccable` skill; use `anthropic-art` for requested editorial/illustration assets and `apple-design` for material, motion, and responsive shape decisions. 3. Keep one clear primary action. The chat input is the primary entry on public pages; login, registration, consent, payment, and admin actions must remain explicit and genuinely wired. 4. Keep visible chrome quiet: no decorative security badges, technical digests, fake confidence percentages, or placeholder buttons in buyer/seller views. Move diagnostics and capability details into administrator or debug surfaces. 5. Use the same login/register surface for humans. Preserve pending chat text through auth and resume it only after a valid Better Auth session. Do not add a separate child credential store. 6. Verify keyboard focus, Escape/outside-click dismissal, loading/error/empty states, reduced motion, dark/light theme, Chinese/English copy, and 320px–1440px layouts. A control that only changes local state while claiming a server action succeeded is a defect. 7. Run the smallest relevant tests, then `just check` before handoff. Do not create screenshots or caches in `/tmp`; use an explicit ignored output directory and report its size. ## Interaction rules - Prefer stable headings and subtle entrance transitions over looping typewriter text. - Keep headings readable on narrow screens; allow natural wrapping rather than clipping one-line marketing copy. - Put account, language, and theme controls in the account/preferences area, aligned to the right; hide role-specific admin links from public navigation and reveal them only when authorized. - Make result cards actionable only when the backing API and consent policy are available. Never expose phone/WeChat values from a listing or from an Agent result. - Pass `theme` and `locale` through the plugin context and let a child package translate its own copy. Root code must not invent child-domain fields. See [references/review-checklist.md](references/review-checklist.md) for the compact acceptance checklist used in code review and browser smoke tests.
عرض على GitHub