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.
Scanned 8/31/2026
Install to Claude Code
npx -y skills add LIghtJUNction/matchplane --skill matchplane-ui --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Matchplane Ui?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/lightjunction-matchplane-ui)More formats (shields.io, HTML) on the badges page.
---
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!