AI-assisted coding
Use AI coding assistants with the toolkit's Markdown, API definitions, and complete examples to implement features within current capabilities. Run an existing example in Studio first, then have AI create a small independent project containing only the core feature. Work toward being able to build, run, and modify it yourself.
A complete AI-assisted development cycle#
Step 1: give the AI assistant access to your project#
- Complete preparation and run an existing example to confirm Studio can load it. Set up Python before coding; the phone Web route also needs Node.js.
- In an AI editor or tool supporting local projects, open the root containing GlassSDK, PhoneSDK, Studio, and build.py. On macOS, this is the retained downloaded toolkit directory, not the installed Studio.app.
- Ask AI to list the root files it actually read to confirm access to the current SDK. To have it do the work directly, allow project reads, edits, and build commands in the tool's settings.
- For chat-only tools, supply relevant README files, API definitions, example source, and directory structure. A local path alone does not grant file access. Save returned code to the specified files and run commands yourself.
- Choose C for a glasses-only UI. For a phone page displaying on glasses, start with Web plus GM Web Bridge. Create a paired project when custom glasses logic is actually needed.
Introduce the current toolkit to your AI assistant#
Paths below are relative to the complete plugin-open-platform root. Start with references for your route and one close example, then add material by feature. You need neither all documentation at once nor private Studio, App, or glasses-firmware source.
| Development Tasks | Start with these references |
|---|---|
| Understand the project and build entry points | README.md, GlassSDK/README.md, PhoneSDK/README.md, root directory build.py; Confirm the current working directory and SDK to build first. |
| Glasses UI, input, and hardware capabilities | GlassSDK/docs/ABI.md, GlassSDK/docs/GRAPHICS.md, and GlassSDK/docs/CAPABILITY_MATRIX.md. APIs are in GlassSDK/include/gm_plugin.h and gm_plugin_lvgl_api.h. |
| Phone Web pages and permissions | PhoneSDK/docs/web-plugin/permission-debug.md and runtime-and-lifecycle.md. Types: PhoneSDK/packages/web-sdk/src/index.d.ts. Permission/method mapping: PhoneSDK/packages/bridge-contract/src/permission-policy.js. |
| Choose a runnable starting point | GlassSDK/examples/README.md, PhoneSDK/examples/README.md, and the chosen example's README.md, manifest.json, and source. |
| Custom paired Communications | PhoneSDK/examples/display-control-lab/README.md, GlassSDK/docs/PROTOCOL_COMPATIBILITY.md, and both examples' protocol files. |
| Studio integration and delivery | Studio/README.md, GlassSDK/docs/REVIEW_PACKAGES.md, and this site's scanning and device-runtime guides. |
Step 2: choose a task and have the AI create the project#
Copy either the C or Web template below and replace bracketed OS, path, and requirement fields. Use the general template for a defined business feature or paired project. Start with one small feature, verify it, then expand.
Create a plugin project using the current plugin-open-platform toolkit.
My requirements:
- Purpose: [for example, a counter on the glasses that can be paused]
- Glasses display and controls: [what to display and which actions control it]
- Phone Web page: [not needed, or describe the page and interactions]
- Project name and plugin ID: [for example, hello-counter / com.example.hello-counter]
- Computer OS: [Windows / macOS / Linux]
- Complete toolkit directory: [actual absolute path]
Complete these steps in order:
1. Read the root README.md and the relevant SDK Markdown documentation, API definitions and examples.
2. Choose the closest example as a starting point and explain which public APIs are needed. Explicitly identify anything the current SDK cannot implement.
3. Create an independent project under GlassSDK/examples or PhoneSDK/examples without overwriting the original example. Complete the source, assets and manifest, and retain stop, exit and resource-cleanup logic.
4. For Web or paired communication, handle permissions, plugin identity, versions and the pairing protocol together.
5. Run ./build.py glass or ./build.py web from the complete toolkit root. On Windows, use py build.py glass or py build.py web. Build both sides separately for a paired project. Fix the first actual error. Explain missing tools or network blockers, and do not treat old artifacts as a successful new build.
6. List changed files, commands actually run and artifact paths. Explain what to select in Studio and the verification steps after scanning with the phone.
Distinguish checks you performed from checks I must perform on the phone and glasses.
If you cannot read or write files or execute commands, explain the limitation and provide complete files to save and commands to run in order.Template A: create a glasses C plugin#
This task creates a counter incremented by a single click, with no phone business page. After AI finishes, compare the project, outputs, and run steps with the My Glass tutorial.
Create a glasses C plugin in the current plugin-open-platform toolkit.
Computer OS: [Windows / macOS / Linux]
Complete toolkit directory: [actual absolute path]
Requirement: display Count: 0, increment it by 1 on each single click of the main glasses button, and exit on a long press. Add no other features yet.
First read README.md, GlassSDK/README.md, GlassSDK/docs/ABI.md, GlassSDK/docs/GRAPHICS.md, GlassSDK/include/gm_plugin.h, gm_plugin_lvgl_api.h, and the closest UI example.
Requirements:
1. Create an independent project at GlassSDK/examples/my_counter/ with id com.example.my-counter and name My Counter. Keep the original example. If the directory already exists, inspect it before changing anything to avoid overwriting existing work.
2. Complete manifest.json, the C source and required assets. Follow the current SDK entry checks, Host function table and lifecycle. Release resources correctly and do not block callbacks.
3. Run ./build.py glass from the complete toolkit root; on Windows use py build.py glass. If execution permission is unavailable, macOS/Linux can use python3 build.py glass. Fix errors based on actual output.
4. Check the .gmp, .review.json and .review-source.enc generated for this project in this build and list their actual paths. Do not use old files or other projects' artifacts as evidence of success.
5. List changed files and actual build results. Explain which workspace to import in Studio, how to select No phone plugin on the phone side and My Counter on the glasses side, and how to verify single-click, exit and restart behavior.
6. Explain how to wait for the new ZIP, scan from the App developer workspace, and verify on real glasses connected over Bluetooth. Clearly separate completed checks from actions I must perform.Template B: create a phone Web plugin#
This task creates a phone page using the toolkit's generic glasses bridge. First display input text on the glasses, then add your business logic.
Create a phone Web plugin in the current plugin-open-platform toolkit.
Computer OS: [Windows / macOS / Linux]
Complete toolkit directory: [actual absolute path]
Requirement: a phone page with a text input and a Send to glasses button. Clicking the button displays the text on the glasses. Show ready, send-failure and empty-input states. Do not add networking or recording yet.
First read README.md, PhoneSDK/README.md, PhoneSDK/docs/web-plugin/permission-debug.md, PhoneSDK/docs/web-plugin/runtime-and-lifecycle.md, PhoneSDK/packages/web-sdk/src/index.d.ts and PhoneSDK/packages/bridge-contract/src/permission-policy.js, plus an existing example that displays text through GM Web Bridge.
Requirements:
1. Create an independent static project at PhoneSDK/examples/my-web/ with id com.example.my-web and name My Web. Keep the original example and inspect any existing directory before editing it. Complete manifest.json, index.html, plugin.js and local SDK files.
2. Use the current public SDK APIs and object-based permission declarations. Set permissions and deviceRequirements for the actual functionality. Reuse GM Web Bridge rather than inventing another protocol or writing a new bridge GMP.
3. Establish the Bridge and call gm.ready() first. Disable sending until ready. Do not wait for a glasses reply before calling gm.ready(). Bundle the SDK and static assets using relative paths; runtime must not depend on a local development-computer service.
4. Run ./build.py web from the complete toolkit root, then ./build.py glass to prepare the matching bridge artifacts. On Windows use py build.py web and py build.py glass. Fix actual errors and list the MMPKG, bridge GMP and build-sidecar paths.
5. Explain which workspace to import in Studio. Select My Web on the phone side and GM Web Bridge on the glasses side. Verify that sending Hello from My Web displays the same text on the glasses.
6. Provide the same device check after scanning from the App developer workspace, plus the procedure for changing the default text, rebuilding, refreshing and scanning again. Report actual results and tests I still need to perform.Step 3: provide errors and unexpected results to the AI#
Identify the failing stage: build, Studio discovery, QR packaging, phone download, or wrong behavior after glasses startup. Provide the first error and surrounding logs from the current attempt instead of only saying “It does not run”.
If the display remains old after building, check saved files, build success, and both Studio dropdown selections. Generate a new ZIP and scan again before comparing. Fix one issue per round while preserving verified behavior.
Continue fixing the existing plugin; do not create an unrelated project.
Current goal: [one feature or issue]
Project directory: [project path]
Working directory and command: [actual terminal directory and complete command]
Failing stage: [build / Studio load / ZIP packaging / phone QR scan / Bluetooth installation / plugin execution]
Current Studio selection: [phone plugin name and glasses plugin name]
Versions: [SDK commit or release, Studio, phone OS/App, glasses firmware; mark unknown values as unknown]
Reproduction steps: [start with which app to open and which button to click]
Expected result: [what should appear]
Actual result: [what happens now; include a screenshot if useful]
Errors and logs: [the first error from this attempt with relevant surrounding lines, or App/Studio logs]
Inspect the relevant source, API definitions and Markdown documentation first. Change only the files needed, rerun the relevant build, report actual results, and list checks I should repeat in the simulator, on the phone and on the glasses. Explicitly state which steps you cannot execute.Step 4: verify the result, then add features#
| Checkpoint | What you should receive or observe |
|---|---|
| Independent project | Saved source, manifest, and assets with your own id, name, and version. The original example still works. |
| Actual Build | Working directory, command, and actual successful build result. C produces a GMP and two matching attachments; Web produces an MMPKG. When reusing a bridge, retain its matching GMP and attachments too. |
| API and permissions | APIs exist in current headers or Web types. Permissions, scope, and pairing match actual functionality. |
| Studio Run | Import the correct workspace and select your plugin. Verify expected text, button behavior, and successful restart after exit. |
| Real glasses | Connect the App to the glasses, scan Studio's current QR code, download the ZIP, and perform the same actions on-device. Download completion or simulator success is not a device-test pass. |
| Ability to continue editing yourself | Change visible text or a value, update the version, rebuild, refresh Studio, wait for the new ZIP, and scan again. Verify new results in both simulator and device. |
Add AI capabilities to the plugin itself#
AI coding assists development. To give plugin users question answering, recognition, or generation at runtime, integrate your own service and handle networking, authorization, waiting, and failures. Using an AI coding tool does not automatically give the plugin these online features.