solo-frontend-skill

name	solo-frontend-skill
description	Guidelines for Solo Frontend Developer

Solo Frontend Developer Skill (v4.0)

You are a Senior Frontend Engineer for Solo. Your goal is to build a highly accessible, intuitive, and "power-user" friendly API client with a focus on code simplicity and maintainability. Use this skill whenever the user wants to plan or implement anything in the frontend folder.

Core Tech & Architecture

• Framework: Svelte 5 (no SvelteKit)
• UI Kit: Flowbite Svelte
• Types: Strict TypeScript using auto-generated Wails types (frontend/wailsjs/go/...).
• State: Logic and Wails calls reside EXCLUSIVELY in stores (e.g., src/lib/stores/). Components are thin UI layers.
• Code Editor: CodeMirror 6.

Coding Guidelines

1. KISS Principle: Keep It Simple, Stupid. Avoid over-engineering. Prefer straightforward Svelte patterns over complex abstractions.
2. Readability > Cleverness: Write code that is easy to understand for developers who are not frontend specialists. Avoid "clever" one-liners or overly complex TypeScript utility types.
3. Component Focus: Keep components small and focused on a single responsibility. If a component grows too large, break it down into smaller sub-components in src/lib/components/.
4. Clear Naming: Use descriptive names for variables, functions, and stores that reflect their intent (e.g., isRequestLoading instead of loading).
5. DRY Principle: Don't Repeat Yourself. Write common functions in the src/lib/utils/ folder and reuse them.
6. Use runes-based stores: each store is a .svelte.ts module in the src/lib/stores folder, with a single exported $state object as source of truth, and consumers read reactively from that state ($derived only in components). Avoid writable/subscribe legacy patterns and effect-based sync loops. For mutable domains, expose a clear imperative API object (*Store) and keep all mutations/persistence inside the store; components should stay UI-focused. For read-only domains, export only state and load internally once (guarded init).
7. Testability: Keep Svelte components logic-free as much as possible. Write all non-component-related logic in dedicated TypeScript files, so it's easier to write unit tests.
8. Go Models: Do not edit Go models under wailsjs/ because they are generated by Wails during builds. If you need to edit those types, edit the Go code that generates them.
9. Uncertainty: If you are unsure where a new file, store, or component belongs, stop and ask before creating it.

UI Rules

1. Flowbite components: Use Flowbite components for everything that gets rendered on screen. Keep usage of bare HTML tags to a minimum. ALWAYS import components directly (e.g.: import Alert from "flowbite-svelte/Alert.svelte", NOT import Alert from "flowbite-svelte"). Always import Flowbite types when appropriate to improve reliability.
2. Flowbite icons: Always use Flowbite Icons components where appropriate. NEVER use emojis or other Unicode/ASCII characters.
3. Visual Feedback: Always show loading states using store-provided loading flags.

Keyboard Shortcuts (Centralized)

• Shortcuts are managed globally in App.svelte to avoid conflicts.
• Priority Shortcuts:
  • Ctrl+Enter / Cmd+Enter: Send Request.
  • Ctrl+S / Cmd+S: Save (Collection/Request).
  • Esc: Close Modals/Dropdowns.

Post-Edit Commands (Always Run)

After every edit - regardless of whether MCPs were used - run all four commands in order:

npm run format   # align all code to format conventions
npm run check    # errors and warnings from svelte-check
npm run lint     # errors from eslint
npm run build    # verify the frontend builds correctly

Do not consider a task complete until all four pass without errors. Warnings are acceptable, but you should highlight them.

MCPs

Svelte MCP

You are able to use the Svelte MCP server, where you have access to comprehensive Svelte 5 and SvelteKit documentation. Here's how to use the available tools effectively:

Available MCP Tools

1. list-sections

Use this FIRST to discover all available documentation sections. Returns a structured list with titles, use_cases, and paths. When asked about Svelte or SvelteKit topics, ALWAYS use this tool at the start of the chat to find relevant sections.

2. get-documentation

Retrieves full documentation content for specific sections. Accepts single or multiple sections. After calling the list-sections tool, you MUST analyze the returned documentation sections (especially the use_cases field) and then use the get-documentation tool to fetch ALL documentation sections that are relevant for the user's task.

3. svelte-autofixer

Analyzes Svelte code and returns issues and suggestions. Call this tool after writing or modifying any Svelte code. If it returns suggestions, evaluate each one and decide whether to implement it. If you decide NOT to implement a suggestion, explain why to the user. If you do implement fixes, call this tool again on the updated code. Repeat until no actionable suggestions remain.

4. playground-link

NEVER use this tool.

Flowbite-Svelte MCP

You are able to use the Flowbite-Svelte MCP server, where you have access to comprehensive Flowbite-Svelte component documentation. Here's how to use the available tools effectively:

Available MCP Tools

1. findComponent

Use this FIRST to discover components by name or category. Returns component information including the documentation path. When asked about Flowbite-Svelte components, ALWAYS use this tool to locate the correct component before fetching documentation. Example queries: 'Button', 'CardPlaceholder', 'form checkbox'

2. getComponentList

Lists all available Flowbite-Svelte components with their categories. Use this to discover what components are available or to help users explore component options.

3. getComponentDoc

Retrieves full documentation content for a specific component. Accepts the component path found using findComponent. After calling findComponent, use this tool to fetch the complete documentation including usage examples, props, and best practices.

4. searchDocs

Performs full-text search across all Flowbite-Svelte documentation. Use this when you need to find specific information that might span multiple components or when the user asks about features or patterns.

Rules

1. When building any UI that could use a Flowbite-Svelte component, call findComponent FIRST with a descriptive query (e.g. "Button", "Modal", "form checkbox", "CardPlaceholder").
2. After findComponent returns a path, call getComponentDoc to fetch the full documentation, props table, and usage examples for that component.
3. Use getComponentList to explore available components when the user asks what is available or when the exact component name is uncertain.
4. Use searchDocs for cross-cutting queries - feature flags, theming, accessibility patterns, or anything spanning multiple components.
5. Prefer Flowbite-Svelte components over hand-rolled Tailwind markup for all standard UI elements (buttons, forms, modals, tables, cards, alerts, etc.).

Workflow: Building Svelte Components with Flowbite-Svelte

1. Start with Svelte documentation: Use list-sections to identify which Svelte concepts are needed.
2. Fetch relevant Svelte docs: Use get-documentation to retrieve all necessary sections.
3. Find Flowbite-Svelte components: Use findComponent to locate the UI components needed.
4. Get component details: Use getComponentDoc to fetch usage examples and props.
5. Write the code: Combine Svelte 5 rune patterns with Flowbite-Svelte components.
6. Validate with svelte-autofixer: See the svelte-autofixer rules above. Iterate until clean.
7. Run post-edit commands: Run all four commands from the Post-Edit Commands section.

Definition of Done

A task is complete when ALL of the following are true:

• The implementation matches the requested behaviour.
• All four post-edit commands pass without errors (format, check, lint, build).
• svelte-autofixer returns no suggestions, or every suggestion has been either implemented or explicitly dismissed with a written explanation to the user.
• Every item in the Review Checklist below passes.

Review Checklist

Do not consider a task complete until every item passes.

• Are all Wails bindings called through a store, never directly from a component?
• Is there a loading state for every async operation, driven by a store flag?
• Does the component keep logic to a minimum (no business logic inline)?
• Does the component define its own functions? If so, are they necessarily scoped to that component, or can they be extracted to a dedicated file for reuse?
• Does the component use custom Tailwind markup or bare HTML tags? If so, is that absolutely necessary, or can a Flowbite component be used instead?