Hello everyone,
Following @pierre-gilles’ remark, many people still haven’t seen just how much Claude simplifies development. Here’s how I handle my external integrations and how I fix your bugs, often within the same day ![]()
A small but important detail: I’m not a developer by trade. If I can do it, so can you ![]()
What I don’t need
None of the usual tools a developer uses—I don’t use any of them:
- No local development
- No IDE
- No Node or Docker to install on my machine
- No manual commits
This is exactly what @pierre-gilles pointed out: many developers still work this way, even though it’s no longer necessary.
What I do instead
- I describe the need in simple French
- Claude Code web handles everything else on the GitHub repository: the code, the pull request, the merge, and the release
- It also prepares the response to post on the forum
- I follow up on feedback and test when I have the device
It works just as well from my phone, and I can launch multiple fixes at the same time.
Common foundations for my 24 repositories
- Manifest verification for each pull request, with the same checks as the store
- Automatic tests on Node 22 and 24, lint, and formatting
- Docker image build
- Dependabot for updates
- A GitHub Release per version, with its changelog
- Documentation in French and English
Result: an error is caught before it reaches the store.
How I start an integration
While waiting for the next SDK, I give this message to Claude Code web, on an empty GitHub repository:
In this repo, on the main branch, I want you to create an external integration "Dyson".
Start from the official integration template: https://github.com/GladysAssistant/integration-template-js
Don't forget SECURITY.md, CHANGELOG.md, and CLAUDE.md
Don't forget the cloud and/or local tag
Set up the same workflows as https://github.com/prohand/gladys-devmel
Don't forget the widgets, triggers, and scene actions
Why each line:
- The official template: the expected structure for Gladys is respected from the start
- SECURITY.md: explains how to report a vulnerability
- CHANGELOG.md: keeps track of each version
- CLAUDE.md: the project rules for Claude, reviewed at each new session
- Cloud/local tag: indicates in the store whether the integration needs the internet
- gladys-devmel workflows: tests, store checks, Docker image, and releases, already set up
- Widgets, triggers, scenes: otherwise, Claude often limits itself to devices
Just replace « Dyson » with your integration.
A bug, from A to Z (real example with Dyson)
1. You post feedback
@mutmut tested the Dyson integration and posted detailed feedback with screenshots:
2. I give the message to Claude Code web
I paste the link to the forum message on the correct repository and ask it to handle everything: the fix, the pull request, the merge, and the release.
Claude reads the feedback, finds the cause in the code, fixes it, adds tests, updates the documentation, and the changelog.
3. Claude opens a pull request
Each forum feedback becomes a pull request. The title indicates which message it responds to.
In the pull request, Claude explains what was fixed, what changed, and what was added. It also indicates what couldn’t be tested on a real device.
For example, we can see that it found why the PM values were different from Matter: the integration was reading the wrong series of measurements from the Dyson.
4. Automatic checks pass
Tests, lint, store checks, Docker image: everything is verified on the pull request, then after the merge.
These checks are what allow me to let Claude go all the way on its own.
5. Claude merges and publishes the version
It merges the pull request and launches the release: the GitHub Release, its changelog, and the Docker image are published. The new version arrives in the store.
6. Claude prepares the forum response
I ask it for a response for the forum, and I just have to paste it. It explains what was fixed, why, and what to do after the update.
All my responses on the Dyson topic were made this way.
The result on Dyson
- 1.0.0 on the evening of October 10, 1.4.0 on the evening of the 11th
- 5 pull requests, one per feedback from @mutmut
- Fixed along the way: missing « Update » button, incorrect PM values, ignored local IP, delayed widget, names in English…
- And I don’t have a Dyson at home

The limits
- Claude can make mistakes: hence the automatic checks… and your tests
- Without the device, I rely on what it sends: your feedback is invaluable
- Some issues come from the core of Gladys. In this case, I propose a fix to Gladys (e.g., PR #3188 for tile colors)
How to get started (developer or not)
- Create an empty GitHub repository, open Claude Code web, and link your GitHub account
- Give it the starting message above, with the name of your integration
- Start small: a simple integration, then a bug, a translation, a test
- Set up automatic checks before letting Claude merge on its own: it’s your safety net
- At first, review the pull requests to understand what Claude does
How to help (testers)
- One topic per integration on the forum, or a GitHub issue
- Specify: model, integration version, local or cloud
- Add screenshots and logs, without email, IP, or serial number
The more precise your feedback, the faster the fix. Thanks to all the testers, and especially to @mutmut ![]()




