form-style
Use when asked to select a UI style, choose a design direction, pick a visual approach for a product, or match a style to an industry. Examples: "what style fits a fintech app", "choose between neumorphism and glassmorphism", "design direction for healthcare SaaS"
Allowed Tools
Provided by Plugin
tonone
Engineering + Product + Operations + Legal + Design + Data Science + Security Operations + Developer Experience + Infrastructure Specialist + AI Operations team — 100 agents as Claude Code specialists. Infrastructure, DevOps, backend, security, ML/AI, mobile, UX, analytics, growth, revenue, content, PR, customer success, finance, people, operations, support, contracts, compliance, IP, governance, regulatory, color systems, typography, motion, accessibility, design tokens, forecasting, feature engineering, model training, drift monitoring, vector search, LLM fine-tuning, pen testing, detection engineering, incident response, zero trust, API docs, SDK design, developer onboarding, Kubernetes, Terraform, FinOps, service mesh, edge computing, caching, queuing, multi-cloud, chaos engineering, model deployment, LLM evaluation, AI observability, guardrails, prompt engineering, embeddings, ranking, and more.
Installation
This skill is included in the tonone plugin:
/plugin install tonone@claude-code-plugins-plusClick to copy
Instructions
form-style — UI Style Selection
Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
When to use
Product needs a visual direction. Industry or product type is known or discoverable from context.
Workflow
- Identify product type from user request or project context
- Search product reasoning:
python3 -m form_agent.uiux search --domain product --query "{product_type}" --limit 3
- Get recommended style details:
python3 -m form_agent.uiux search --domain style --query "{recommended_style}" --limit 3
- Cross-reference anti-patterns from the product search results — check the Anti_Patterns field
- Output the recommendation using the format below
Output format
┌─ Style Recommendation ─────────────────────┐
│ Product: {product_type} │
│ Style: {primary_style} │
│ Fallback: {secondary_style} │
├─ Effects ───────────────────────────────────┤
│ {key_effects from style search} │
├─ Anti-patterns ─────────────────────────────┤
│ ✗ {anti_pattern_1} │
│ ✗ {anti_pattern_2} │
├─ Implementation Checklist ──────────────────┤
│ □ {checklist_item_1} │
│ □ {checklist_item_2} │
└─────────────────────────────────────────────┘
Anti-patterns
- Never pick style based on aesthetics alone — match to product type + audience
- Never ignore anti-pattern list from reasoning rules
- Never recommend more than 2 combined styles (primary + fallback)
- Never recommend a style marked as incompatible with the target framework
Delivery
If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.