The Indigo Claude plugin

[siclark]

To offer more capability and a simpler install I have converted all 3 skills, for plugin, API and control pages into a single plugin.

Now in Claude you just need to enter

Code: Select all

/plugin marketplace add simons-plugins/indigo-claude-plugin
/plugin install indigo@indigo-claude-plugin

This is set up as commands, so you can use below / commands to deliberately involve it

/indigo:plugin Plugin development — SDK docs, examples, lifecycle, IOM reference
/indigo:api API integration — WebSocket and HTTP APIs for client apps
/indigo:control-pages Control page builder — guided XML generation with wireframes

but also its a skill which activates automatically when working on relevant files:

plugin-dev — Activates for .indigoPlugin/ directories, plugin.py, Devices.xml, Actions.xml
api-integration — Activates for WebSocket/HTTP integration code targeting Indigo
control-pages — Activates for control page XML and .textClipping files


Any questions or comments, please shout, and if you use it and want to make improvements, please create a PR and share back your additions to help improve this for all.

[siclark]

Hi all,

Quick update on the indigo-claude-plugin marketplace plugin (the Claude Code skill set for Indigo plugin development).

1. Canonical GitHub Actions workflows

Drop-in version-check.yml + create-release.yml for any Indigo plugin repo. They auto-detect the *.indigoPlugin bundle so a single copy-paste works across repos.
PR fails if you forget to bump PluginVersion; merge to main auto-creates a tagged GitHub release with the bundled .zip. Thanks to Flying Diver for spotting the option to make these generic.

Files + README live at: https://github.com/simons-plugins/indig ... /workflows

I rolled them out across 11 of my own plugin repos yesterday as a real-world test — caught two genuine bugs along the way
(Linux-runner case-sensitivity, and a zip-asset filename mismatch on one repo) so the templates are battle-tested. If you want to
use them in your own repo, the README has the copy-paste commands.

2. TestingBase conventions + field notes

TestingBase is brilliant for integration testing plugins against a real Indigo Server, but a couple of upstream conventions weren't
obvious on first read. New section in docs/plugin-dev/patterns/testing.md covers:

- run_host_script uses return, not print — Indigo wraps your script as a function body. print() goes to the event log; return is
what comes back via stdout.
- Plugin state isn't on the HTTP API — /v2/api/indigo.<endpoint> only exposes the seven core object types. To check isEnabled /
isRunning from a TestingBase test, go through the IOM via run_host_script. Code example included.

Plus three "field notes from a pilot" — labelled clearly as not from upstream docs:
- /usr/local/indigo/ perms blocking indigo-host execution on at least one fresh 2025.2 install
- "Reflector Not Found" 200-with-error-HTML on a freshly-configured reflector — fix is restart Indigo Server
- URL_PREFIX choice (http localhost vs https reflector) depends on your server config

Read here:
https://github.com/simons-plugins/indig ... testing.md

The field notes are explicitly framed as one developer's observations — would love to hear if anyone has hit different states or has
corrections to add. Happy to fold them in.

Cheers,
Simon and Claude

[siclark]

Thanks for the contribution @clives.

This is definitely supposed to be an open source work.. it needs users to feedback on what works and what doesnt. And even if you are new to plugin development and dont know how to clone the repo, create a branch and a PR to fix a bug with the documentation, Claude certainly does.

[CliveS]

Cheers Simon.

Full disclosure: I don't actually know how to do a PR — Claude Code does, with his handy sidekick Claude Bridge MCP Plugin (which lets Claude read/write Indigo scripts, restart plugins, and peek at the event log while it's working — about 70 different tools it can use with Indigo without me lifting a finger.

I just said "the camelCase state-ID rule and the getDeviceStateList gotcha kept biting me, can we get this into the skill" and it cloned the fork, made a branch, drafted the docs, opened the PR, and then had a long and apparently very civil conversation with your CodeRabbit. (Don't ask!!! )— I have no idea what they discussed, but the PR appeared.

The bit I take full credit for is hitting the return key.

[siclark]

Haha. As I said. Claude knows . Glad and scared at how easy it was for you to update the code.

[durosity]

Aw man.. been meaning to look into these for a while.. finally got around to it and realised it's all Claude Code stuff which unfortunately the admin on my enterprise account has disabled access to for some reason

[siclark]

What do you have?

[durosity]

What do you have?

Just the normal Claude.

claudecode.png (32.32 KiB) Viewed 158 times

I'm not sure why they turned it off, it was available a few months ago.. but I guess they had a good reason to do so. Still I can do my usual work with the 'chat' functionality.

[siclark]

Claude says you can still use it.. just not as simple.

Let me check what's currently available in the Claude desktop/web app for using skills-style content.Good, I have enough to give a complete answer. Let me peek at the plugin's skills directory so I can give specific instructions on what to package up.A few practical paths exist — none as seamless as `/plugin install` in Claude Code, but the main building blocks (skills, docs, reference material) all map onto features the desktop app has.

**The closest match: repackage the skills as Claude.ai custom skills.** Since October 2025, claude.ai supports uploading custom skills as ZIP files via Settings → Capabilities → Skills (you'll need "Code execution and file creation" toggled on first). The ZIP must contain a folder with a valid SKILL.md file, and the name field in the SKILL.md frontmatter must be all lowercase with only letters, numbers, and hyphens. Your plugin already has three skill folders — `skills/plugin-dev/`, `skills/api-integration/`, `skills/control-pages/` — so a user can clone the repo, zip each of those folders individually, and upload them as three separate skills. They'll then auto-activate based on the description in each SKILL.md, the same way they would in Claude Code. The catch worth flagging in your README: custom skills don't sync across surfaces — skills uploaded to claude.ai must be separately uploaded to the API, and Claude Code skills are filesystem-based and separate from both, so there's no shared install.

**The slash commands need a different home.** `/indigo:dev`, `/indigo:api`, and `/indigo:control-pages` are Claude Code-specific — claude.ai has no `/command` equivalent. The simplest workaround is to fold each command's prompt content *into* the corresponding skill's SKILL.md as the "when invoked, do this" instructions. The skill then covers both the auto-activation case and the explicit "help me build a control page" ask. Alternatively, the command markdown files can be pasted as the first message of a Project.

**For the docs, reference material, snippets, and SDK examples — use a Project.** Create a Claude Project, drop your `CLAUDE.md` content into the project instructions, and upload the contents of `docs/`, `reference/`, `snippets/`, and `sdk-examples/` as project knowledge. Anything done inside that project then has the IOM reference, SDK examples, and templates available without needing to attach them per-conversation. There are size limits, so the 16 SDK example plugins might need to be selective rather than wholesale.

**One more option worth mentioning: the GitHub connector.** If the user enables the GitHub MCP connector in claude.ai, Claude can fetch files from your public repo on demand — meaning a user can say "look at the control page schema in simons-plugins/indigo-claude-plugin" and Claude will pull it in. Less ergonomic than skills, but zero setup, and good for the long tail of reference material that doesn't fit in a Project.

If I were updating the README for Claude desktop users, I'd add a short "Using without Claude Code" section recommending: (1) zip and upload the three `skills/` folders, (2) create a Project seeded with `docs/` and `reference/`, (3) note that slash commands aren't available but the skills cover the same territory.

[siclark]

Version 2.0.0 is out with a major rewrite of the skills following Jay and Dave’s documentation rewrite. It corrected some buried inaccuracies that had been assumed from the old docs so they are a big improvement.
I’ve refactored a little to improve the incremental discovery so you aren’t loading the whole docs in one go.
This saves pointing your agent to the full doc online which uses a lot of your context.

[siclark]

And. 2.1.0 extended to include all the usability guides under a new skill indigo:skill.

Please feedback on use or any issues via here, GitHub issues or PRs.