Build with ChatGPT or Claude

Use ChatGPT or Claude in your browser to build your own smabar plugin. You do not need to connect an MCP server. Choose a chat that can open links and create downloadable files.

From your idea to your bar

1. Start a new chat. Copy the request below into ChatGPT or Claude. Replace the placeholders with your idea, operating system and smabar version.
2. Let the AI build it. It reads the smabar SDK, styling rules and complete examples, asks about anything missing, and creates your plugin as a ZIP.
3. Install your plugin. Download the ZIP and follow the installation guide. Check its appearance and actions in your own smabar app.

Copy this request

Read https://smabar.com/build-my-plugin.md and follow its build workflow.
Open the linked manifest, SDK, styling and relevant example documents.
Build this smabar plugin: [describe your idea].
My operating system and smabar version: [fill in].
Create the complete plugin as a downloadable ZIP, including all source,
translations and required assets. Explain how to install it and list the
checks you actually ran. Do not claim to have tested it in my running app.

Useful details: what the tile should show, what belongs in the flyout, update frequency, actions, settings, and any external services. Keep passwords and API keys out of the conversation and generated source; document how the user supplies them locally.

For the AI: read this page as Markdown. Follow the references below before implementing the plugin. Do not assume an MCP connection exists.

The technical references are exported from the same contracts and examples the app uses.

Build workflow for the AI

1. Understand the target. Ask for missing requirements that change the implementation, especially operating system and installed smabar version. Read capabilities and provider topics and the reference index. The source version is recorded on every reference page. If it differs from the user’s version, resolve compatibility before promising support. Availability of a live host service or provider cannot be inferred from these docs.
2. Learn the plugin contract. Read terms, manifest, manifest schema, SDK, lifecycle and storage. For external APIs, consult their current official documentation. The references contain original MCP call names; these are reference pointers, not tools available in this chat.
3. Design with the complete UI kit. Read the styling index, design rules, best practices, tile sizing, cover layouts, sanitizer and render targets. Then open the class categories you need, conventions, behaviour hooks and snippets. Read the linked forms, charts, icons and media rules when using them. Tokens and reference themes define the styling vocabulary; they do not reveal the user’s active theme. Plugin HTML has no custom JavaScript. Use supported classes and hooks, accessible labels and the theme’s tokens.
4. Start from a complete example. Read the starter template and choose a relevant example plugin. Every example includes the file tree, complete source, original assets and a ZIP. Follow its related styling references. Choose a new plugin ID; the bundled example IDs are already installed in smabar. Preserve applicable license notices.
5. Create all files. Work in a local folder outside any live smabar profile. Include the manifest, PEP 723 entry script, every imported sibling, English and German translations and assets actually used. The SDK is provided by smabar; do not vendor it or add it as a package dependency. Render first in on_ready, keep slow work off the handler, store writable data through app.data_dir, and report actionable failures through app.log. Never package credentials or cached user data.
6. Check and deliver. Follow the checklist below, make the ZIP, then provide the installation instructions. Do not call unavailable plugin_write_file, plugin_reload, plugin_logs or screenshot tools. The connected MCP golden path describes additional live verification, which the user can perform after installation.

Before delivering the ZIP

• Parse every JSON file and check the manifest against the downloadable schema when a schema validator is available. Check that the folder and manifest ID match, the entry file exists, and rendered tile IDs are declared.
• Parse the Python files for syntax without starting the plugin. Check all sibling imports, translations and asset references. Run meaningful deterministic checks for the plugin’s own logic where your environment permits.
• Check the markup against the documented sanitizer, classes, render targets and action/form contracts. Include useful empty, loading and error states, accessible names for controls and a layout that fits the documented tile/flyout dimensions.
• Include one top-level <plugin-id>/ folder in the ZIP. It must contain smabar.json, all runtime files, and a README with setup, dependencies, installation and checks performed. Include the required license notices. Leave out the SDK, .venv, caches, secrets and machine-specific data.
• Reopen the finished ZIP and verify its file list and JSON. Report which checks ran, which could not run, and that real provider availability, actions and appearance still need a check in smabar. Do not invent screenshots or test results.

After installation

Use the ZIP installation and local verification checklist. If something fails, the debugging reference explains common errors. The user can share the relevant log lines or screenshots with their AI after removing personal data and credentials.

Creating a downloadable ZIP requires a file creation tool in the AI service. A documentation link cannot enable that tool. If it is unavailable, the AI should provide the complete files and a local packaging command and clearly state that no downloadable archive was created. An AI that cannot open links can read downloaded Markdown files supplied by the user instead.

Optional sharing through the Community Store is described in publishing. Creating a ZIP does not publish it.