Add comprehensive IOM documentation with modular structure#5
Conversation
- Add new docs/api/iom/ folder with focused topic files: - architecture.md: Client-server model, replaceOnServer pattern - command-namespaces.md: Device/trigger/variable commands - devices.md: Device class hierarchy and properties - triggers.md: Trigger types and plugin events - containers.md: indigo.Dict/List copy semantics - filters.md: Device and trigger iteration filters - subscriptions.md: Change callbacks and low-level events - constants.md: State icons, actions, protocols - utilities.md: Helper functions - Add docs/patterns/api-patterns.md with common patterns - Refactor docs/concepts/devices.md to remove duplication: - Remove lifecycle callbacks (now references plugin-lifecycle.md) - Remove state update examples (now in patterns/) - Focus on device design: Devices.xml, ConfigUI, validation - Update docs/api/indigo-object-model.md as index with quick reference - Update docs/README.md with use-case routing - Update skill.md with modular file guidance This restructuring reduces redundancy and optimizes context usage by ~30-40% through modular topic-based documentation. https://claude.ai/code/session_01XunLg49DqkQ2jV9SBhyB86
- Add docs/concepts/plugin-preferences.md: - Reading/writing pluginPrefs - PluginConfig.xml integration - Validation and change callbacks - Hidden preferences and migration patterns - Add docs/concepts/events.md: - Events.xml structure for custom trigger events - Event callback methods (triggerStartProcessing, etc.) - Firing events from plugin code - Complete working example - Update docs/api/iom/subscriptions.md: - Add schedules and controlPages subscriptions - Add schedule/controlPage callbacks - Add "Finding What Changed" diff pattern - Add multi-device sync example - Update docs/api/iom/architecture.md: - Expand pluginProps section with patterns - Add globalProps for cross-plugin access - Add self vs indigo.activePlugin clarification - Add ID copy tip - Update docs/README.md and skill.md with new files https://claude.ai/code/session_01XunLg49DqkQ2jV9SBhyB86
- Fix 3 broken links in quick-start.md pointing to non-existent files - Remove duplicate content in api-patterns.md (now references architecture.md) - Update external URLs to wiki.indigodomo.com format in plugin-lifecycle.md - Add See Also cross-references across concept and pattern files https://claude.ai/code/session_01XunLg49DqkQ2jV9SBhyB86
📝 WalkthroughWalkthroughComprehensive documentation restructuring and expansion introducing modular, task-oriented organization. Replaces broad library-style structure with focused concept modules, modular IOM reference files, and Claude context optimization guidance including file-loading strategies and routing workflows. Includes 8+ new documentation files covering IOM architecture, command namespaces, constants, containers, devices, filters, subscriptions, triggers, and utilities. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Fix all issues with AI agents
In `@docs/api/iom/architecture.md`:
- Line 41: Update the tip text that currently reads "Control-click on any object
in Indigo's Main Window to copy its ID." to describe the full interaction:
explain that Control-click (or right-click) on an object opens the context menu
and then the user must select the "Copy ID" menu item to copy the ID, and ensure
both Control-click and right-click are mentioned along with the explicit step of
choosing "Copy ID" from the context menu so the instruction is complete and
unambiguous.
- Around line 128-138: The example uses a plain Python dict as the default when
reading cross-plugin properties; update the dev.globalProps.get call to use
indigo.Dict() as the default to match Indigo's API and ensure correct typed
behavior for globalProps access (replace the current
dev.globalProps.get("com.other.plugin", {}) usage with a call that supplies
indigo.Dict() as the fallback so subsequent reads like
other_plugin_data.get("someKey") operate on an Indigo Dict).
In `@docs/api/iom/utilities.md`:
- Around line 127-138: The docs example uses the wrong callback signature;
change the function declaration from handleWebRequest(self, path, params) to the
Indigo plugin signature handleWebRequest(self, action, dev=None,
callerWaitingForResult=None) and update the body to read request details from
action.props (e.g., action.props.get("url_query_args"),
action.props.get("request_body"), action.props.get("incoming_request_method"),
action.props.get("headers"), action.props.get("file_path")) and then route based
on the requested path contained in action.props (or
action.props["url_query_args"] as appropriate), returning the static files and a
404 status via the existing indigo.utils.return_static_file call sites.
In `@skill.md`:
- Around line 13-48: Update the size estimates in the "Safe to Load" table for
the specified docs: set docs/concepts/plugin-lifecycle.md to 17KB,
docs/examples/sdk-examples-guide.md to 12KB,
docs/troubleshooting/common-issues.md to 14KB, docs/concepts/devices.md to 6KB,
docs/concepts/plugin-preferences.md to 5KB, and docs/concepts/events.md to 6KB
in the skill.md Safe to Load section (leave all other entries, the Modular IOM
Reference list, and the sdk-examples 1.3MB note unchanged).
- Around line 173-175: Replace the legacy Developer Forum link string "-
Developer Forum: https://forums.indigodomo.com/viewforum.php?f=18" with the
active "Extending Indigo" forum URL on Perceptive Automation (use
https://forums.perceptiveautomation.com/forum/15-extending-indigo/), leaving the
other two wiki links unchanged; update the line that contains "Developer Forum"
so the displayed text and URL both point to the new forum.
🧹 Nitpick comments (1)
docs/README.md (1)
75-124: Consider the audience and placement of meta-documentation section.The "For Claude (Context Optimization)" section provides guidance for AI assistants on how to efficiently load documentation files. While potentially useful, this meta-documentation might be better placed in a separate file (e.g.,
CLAUDE.mdor.github/AI_USAGE.md) to keep the main README focused on human developers.Alternative: Move meta-documentation to dedicated file
Create a new file
.github/AI_USAGE.mdordocs/CLAUDE.md:# AI Assistant Usage Guide This documentation is optimized for AI assistants like Claude. Follow these guidelines for efficient context usage: ## File Loading Strategy [... move content from lines 79-124 here ...]Then reference it from README.md:
## For AI Assistants See [AI Usage Guide](.github/AI_USAGE.md) for context optimization strategies.This keeps the main README focused on developers while preserving the meta-documentation.
| indigo.device.turnOn("Living Room") # Avoid - name can change | ||
| ``` | ||
|
|
||
| **Tip**: Control-click on any object in Indigo's Main Window to copy its ID. |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Indigo 2025.1 how to copy object ID main window UI
💡 Result:
In Indigo 2025.1 (Mac client main window), you copy an object’s internal database ID from the list/table it’s shown in:
- Click the item (device / variable / trigger / action group / control page, etc.) in the main window list.
- Right‑click (or control‑click) the row.
- Choose “Copy ID (####)” (wording may appear as “Copy ID”) to copy it to your clipboard. [1][2]
If you meant Indigo Touch Web (ITW) instead: open the device tile’s … menu and select Copy ID. [3]
Sources: [1] [2] [3]
Clarify the complete Control-click interaction for copying object IDs.
The tip is incomplete. Control-clicking (or right-clicking) an object in the Main Window opens a context menu; you then select "Copy ID" from that menu to copy the ID. Update to reflect both steps of this interaction.
🤖 Prompt for AI Agents
In `@docs/api/iom/architecture.md` at line 41, Update the tip text that currently
reads "Control-click on any object in Indigo's Main Window to copy its ID." to
describe the full interaction: explain that Control-click (or right-click) on an
object opens the context menu and then the user must select the "Copy ID" menu
item to copy the ID, and ensure both Control-click and right-click are mentioned
along with the explicit step of choosing "Copy ID" from the context menu so the
instruction is complete and unambiguous.
| ### globalProps (Cross-Plugin Access) | ||
|
|
||
| Plugins have read-only access to other plugins' props: | ||
|
|
||
| ```python | ||
| dev = indigo.devices[123456] | ||
|
|
||
| # Access another plugin's data (read-only) | ||
| other_plugin_data = dev.globalProps.get("com.other.plugin", {}) | ||
| some_value = other_plugin_data.get("someKey") | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n docs/api/iom/architecture.md | sed -n '120,145p'Repository: simons-plugins/indigo-claude-skill
Length of output: 876
🌐 Web query:
Indigo plugin globalProps cross-plugin access documentation
💡 Result:
In Indigo Domotics plugin scripting, “cross-plugin access” to another plugin’s stored metadata is done via an object’s globalProps:
globalPropsis anindigo.Dict()containing all plugins’ metadata, stored in per-plugin namespaces:globalProps[pluginId]. Any plugin/script can read these namespaces.pluginPropsis a shortcut to your plugin’s namespace and is only writable by the owning plugin (updated viareplacePluginPropsOnServer()/ similar methods).- Many Indigo objects also expose
sharedPropsfor truly shared metadata (editable via the “Global Properties” plugin), separate from per-plugin namespaces.
Sources: Device class + Trigger class docs and “Plugin Extending Tutorial” notes. (wiki.indigodomo.com)
Minimal example (read another plugin’s metadata)
dev = indigo.devices[123]
other_plugin_id = "com.vendor.plugin"
other_props = dev.globalProps.get(other_plugin_id, indigo.Dict())
value = other_props.get("someKey")(Structure globalProps[pluginId] and read-only cross-plugin access are documented in the Device/Trigger class references and plugin tutorial notes.) (wiki.indigodomo.com)
Citations:
- 1: https://wiki.indigodomo.com/doku.php?id=indigo_2021.1_documentation%3Adevice_class&utm_source=openai
- 2: https://wiki.indigodomo.com/doku.php?id=indigo_2021.1_documentation%3Adevice_class&utm_source=openai
Use indigo.Dict() instead of {} for consistency with the globalProps API.
The globalProps cross-plugin access pattern is correct—plugins have read-only access to other plugins' properties via globalProps[pluginId]. However, the default value in the .get() call should use indigo.Dict() instead of {} to be consistent with how Indigo's API works:
Suggested change
dev = indigo.devices[123456]
# Access another plugin's data (read-only)
other_plugin_data = dev.globalProps.get("com.other.plugin", indigo.Dict())
some_value = other_plugin_data.get("someKey")🤖 Prompt for AI Agents
In `@docs/api/iom/architecture.md` around lines 128 - 138, The example uses a
plain Python dict as the default when reading cross-plugin properties; update
the dev.globalProps.get call to use indigo.Dict() as the default to match
Indigo's API and ensure correct typed behavior for globalProps access (replace
the current dev.globalProps.get("com.other.plugin", {}) usage with a call that
supplies indigo.Dict() as the fallback so subsequent reads like
other_plugin_data.get("someKey") operate on an Indigo Dict).
| ```python | ||
| def handleWebRequest(self, path, params): | ||
| if path == "/status": | ||
| return indigo.utils.return_static_file("static/status.html") | ||
| elif path == "/data.json": | ||
| return indigo.utils.return_static_file("static/data.json") | ||
| else: | ||
| return indigo.utils.return_static_file( | ||
| "static/404.html", | ||
| status=404 | ||
| ) | ||
| ``` |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Indigo HTTP responder handleWebRequest callback signature
💡 Result:
In Indigo’s Example HTTP Responder pattern, the “web request handler” is just an Action callback (invoked via /message/<pluginId>/<actionId>/...), so the callback signature is:
def handleWebRequest(self, action, dev=None, callerWaitingForResult=None):
...Indigo Web Server (IWS) sets callerWaitingForResult=True for these calls, and injects request details into action.props (e.g., incoming_request_method, headers, body_params, url_query_args, request_body, file_path). Your handler should return either a simple string (commonly JSON) or a dict describing the HTTP response (e.g., status, headers, content), and can also return an indigo.Dict that instructs IWS to stream a file back. [1]
Source(s)
[1] (wiki.indigodomo.com)
Citations:
Fix incorrect handleWebRequest callback signature in documentation example.
The example uses handleWebRequest(self, path, params), but the official Indigo plugin callback signature is handleWebRequest(self, action, dev=None, callerWaitingForResult=None). Request details are injected into action.props (e.g., incoming_request_method, headers, body_params, url_query_args, request_body, file_path), not passed as separate parameters. The current example code will not work with actual Indigo HTTP responders.
🤖 Prompt for AI Agents
In `@docs/api/iom/utilities.md` around lines 127 - 138, The docs example uses the
wrong callback signature; change the function declaration from
handleWebRequest(self, path, params) to the Indigo plugin signature
handleWebRequest(self, action, dev=None, callerWaitingForResult=None) and update
the body to read request details from action.props (e.g.,
action.props.get("url_query_args"), action.props.get("request_body"),
action.props.get("incoming_request_method"), action.props.get("headers"),
action.props.get("file_path")) and then route based on the requested path
contained in action.props (or action.props["url_query_args"] as appropriate),
returning the static files and a 404 status via the existing
indigo.utils.return_static_file call sites.
| **DO NOT load all files.** This skill contains 1.3MB of SDK examples. Use Read tool selectively. | ||
|
|
||
| ### Safe to Load (Small Files) | ||
|
|
||
| | File | Size | Use For | | ||
| |------|------|---------| | ||
| | `docs/quick-start.md` | 9KB | Getting started | | ||
| | `docs/concepts/plugin-lifecycle.md` | 12KB | Lifecycle methods | | ||
| | `docs/concepts/devices.md` | 7KB | Device design (Devices.xml, ConfigUI) | | ||
| | `docs/concepts/plugin-preferences.md` | 4KB | Plugin preferences (pluginPrefs) | | ||
| | `docs/concepts/events.md` | 5KB | Custom trigger events (Events.xml) | | ||
| | `docs/api/indigo-object-model.md` | 3KB | API overview and quick reference | | ||
| | `docs/examples/sdk-examples-guide.md` | 8KB | Example catalog | | ||
| | `docs/troubleshooting/common-issues.md` | 11KB | Troubleshooting | | ||
| | `docs/patterns/api-patterns.md` | 5KB | Common API patterns | | ||
|
|
||
| ### Modular IOM Reference (Load by Topic) | ||
|
|
||
| The Indigo Object Model is split into focused files (~4KB each): | ||
|
|
||
| | Topic | File | | ||
| |-------|------| | ||
| | Architecture | `docs/api/iom/architecture.md` | | ||
| | Command namespaces | `docs/api/iom/command-namespaces.md` | | ||
| | Device classes | `docs/api/iom/devices.md` | | ||
| | Trigger classes | `docs/api/iom/triggers.md` | | ||
| | Filters | `docs/api/iom/filters.md` | | ||
| | Subscriptions | `docs/api/iom/subscriptions.md` | | ||
| | Constants | `docs/api/iom/constants.md` | | ||
| | indigo.Dict/List | `docs/api/iom/containers.md` | | ||
| | Utilities | `docs/api/iom/utilities.md` | | ||
|
|
||
| ### NEVER Load All at Once | ||
|
|
||
| - `sdk-examples/` - 16 complete plugins (1.3MB total) | ||
| - All `docs/api/iom/` files together |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify files referenced in skill.md exist and check their sizes
echo "=== Safe to Load files ==="
for file in \
"docs/quick-start.md" \
"docs/concepts/plugin-lifecycle.md" \
"docs/concepts/devices.md" \
"docs/concepts/plugin-preferences.md" \
"docs/concepts/events.md" \
"docs/api/indigo-object-model.md" \
"docs/examples/sdk-examples-guide.md" \
"docs/troubleshooting/common-issues.md" \
"docs/patterns/api-patterns.md"
do
if [ -f "$file" ]; then
size=$(wc -c < "$file" | awk '{printf "%.0fKB", $1/1024}')
echo "✓ $file ($size)"
else
echo "✗ MISSING: $file"
fi
done
echo -e "\n=== Modular IOM Reference files ==="
for file in \
"docs/api/iom/architecture.md" \
"docs/api/iom/command-namespaces.md" \
"docs/api/iom/devices.md" \
"docs/api/iom/triggers.md" \
"docs/api/iom/filters.md" \
"docs/api/iom/subscriptions.md" \
"docs/api/iom/constants.md" \
"docs/api/iom/containers.md" \
"docs/api/iom/utilities.md"
do
if [ -f "$file" ]; then
size=$(wc -c < "$file" | awk '{printf "%.0fKB", $1/1024}')
echo "✓ $file ($size)"
else
echo "✗ MISSING: $file"
fi
done
echo -e "\n=== Checking sdk-examples directory ==="
if [ -d "sdk-examples" ]; then
total_size=$(du -sh sdk-examples | cut -f1)
file_count=$(find sdk-examples -type f | wc -l)
echo "✓ sdk-examples/ exists: $total_size, $file_count files"
else
echo "✗ MISSING: sdk-examples/"
fiRepository: simons-plugins/indigo-claude-skill
Length of output: 890
Update file size estimates in the "Safe to Load" section.
All referenced files exist, but several size estimates are inaccurate for context optimization purposes. Correct the following:
docs/concepts/plugin-lifecycle.md: Listed as 12KB, actually 17KBdocs/examples/sdk-examples-guide.md: Listed as 8KB, actually 12KBdocs/troubleshooting/common-issues.md: Listed as 11KB, actually 14KBdocs/concepts/devices.md: Listed as 7KB, actually 6KBdocs/concepts/plugin-preferences.md: Listed as 4KB, actually 5KBdocs/concepts/events.md: Listed as 5KB, actually 6KB
The Modular IOM Reference files and sdk-examples size (1.3MB) are accurate.
🤖 Prompt for AI Agents
In `@skill.md` around lines 13 - 48, Update the size estimates in the "Safe to
Load" table for the specified docs: set docs/concepts/plugin-lifecycle.md to
17KB, docs/examples/sdk-examples-guide.md to 12KB,
docs/troubleshooting/common-issues.md to 14KB, docs/concepts/devices.md to 6KB,
docs/concepts/plugin-preferences.md to 5KB, and docs/concepts/events.md to 6KB
in the skill.md Safe to Load section (leave all other entries, the Modular IOM
Reference list, and the sdk-examples 1.3MB note unchanged).
| - Official Plugin Guide: https://wiki.indigodomo.com/doku.php?id=indigo_2025.1_documentation:plugin_guide | ||
| - Object Model Reference: https://wiki.indigodomo.com/doku.php?id=indigo_2025.1_documentation:object_model_reference | ||
| - Developer Forum: https://forums.indigodomo.com/viewforum.php?f=18 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
https://wiki.indigodomo.com/doku.php?id=indigo_2025.1_documentation:plugin_guide
💡 Result:
The page is Indigo Plugin Developer’s Guide v2.0 (Indigo 2025.1 documentation) and explains how Indigo plugins are structured and built, focusing on Indigo Server Plugins and their supporting files. Key points: [1]
- Where plugins live on disk: Indigo keeps enabled plugins in
.../Indigo [VERSION]/Pluginsand disabled ones in.../Indigo [VERSION]/Plugins (Disabled). [1] - Plugin bundle format (
.indigoPlugin): A plugin is a macOS bundle that looks like a single file in Finder but contains a standard bundle structure underContents/. Users install by double-clicking the bundle. [1] - Required
Info.plist: Describes the plugin (name, versions, ID, support URL). The guide calls out important required keys, including:PluginVersion(numeric dotted version string)ServerApiVersion(minimum required Indigo server API)CFBundleDisplayName,CFBundleIdentifier,CFBundleVersionCFBundleURLTypes(support URL used by “About [PLUGIN NAME]”) [1]
- Common bundle folders:
Menu Items: Python scripts that appear under Indigo’s Plugins menu and execute when selected. [1]Resources: Assets; optionally exposesimages/,public/,static/,videos/via the Indigo Web Server (with different auth behaviors). [1]Packages: Optional place for third-party Python packages your plugin needs. [1]
- Server plugin approach: Describes why server plugins exist, how they integrate devices/triggers/actions, and that Indigo’s server plugin API is implemented in Python with UI/components described via XML/HTML conventions. [1]
Source: Indigo wiki “plugin_guide” page. [1]
🌐 Web query:
https://wiki.indigodomo.com/doku.php?id=indigo_2025.1_documentation:object_model_reference
💡 Result:
The page is the Indigo 2025.1 “Indigo Object Model (IOM) Reference”, which documents the Python object model used by embedded scripts and server plugins. It covers: [1]
- Core usage rules / architecture: scripts run in a separate process from IndigoServer, so objects you fetch are copies. To change definitions you typically edit the local copy then call
replaceOnServer(), and to resync you userefreshFromServer(). Commands (turn on, etc.) are sent via the appropriate command namespace (for exampleindigo.device.*,indigo.dimmer.*, etc.). [1] - Major object families and where they live in the API: Devices, Triggers, Schedules (not yet implemented), Action Groups (not yet fully implemented), Variables, Folders, plus the Action base/subclasses (not yet complete). [1]
- Class ↔ namespace mapping table (e.g.,
indigo.Device→indigo.device.*,indigo.DimmerDevice→indigo.dimmer.*, trigger subclasses → their respective namespaces, etc.). [1] - Identifiers (
id): top-level objects have globally unique integer IDs; commands accept either anidor an object reference, and the docs advise not storing object names. [1] - Indigo containers:
indigo.Dict()andindigo.List()(differences vs nativedict/list, constraints on values/keys, and the important “returned values are copies” behavior). Also shows efficient nested access helpers likesetitem_in_item/getitem_in_item, and conversion to native Python containers (includingdict(my_indigo_dict)/list(my_indigo_list)). [2] - Built-in top-level collections:
indigo.devices,indigo.triggers,indigo.schedules,indigo.actionGroups,indigo.variables(read-only collections with conveniences like.foldersandgetName()). [2] - Change subscriptions:
subscribeToChanges()for receiving notifications when objects of a type (e.g., devices) actually change—intended to be used sparingly due to traffic. [2] - Object-to-dictionary serialization: printing objects shows all properties; you can convert an Indigo object to a native Python
dictviadict(dev)for serialization (e.g., JSON). [3]
Sources: Indigo Wiki “Indigo Object Model Reference” (Indigo 2025.1). [1][2][3]
🌐 Web query:
https://forums.indigodomo.com/viewforum.php?f=18
💡 Result:
That URL is the “Extending Indigo with Plugins and Python” sub-forum on the Indigo Domotics forums. It’s explicitly marked as a legacy forum that’s locked for new topics, and it directs users to start new topics in the newer “Extending Indigo” forums under perceptiveautomation.com. The most recent threads shown on page 1 date to August 2013, and the forum spans 8 pages of older topics. (forums.indigodomo.com)
Citations:
Update the Developer Forum link to point to the current forum.
The wiki URLs for Plugin Guide and Object Model Reference are valid and accessible for Indigo 2025.1. However, the Developer Forum URL (https://forums.indigodomo.com/viewforum.php?f=18) is a legacy forum locked for new topics since 2013. Update the link to direct users to the active "Extending Indigo" forum on perceptiveautomation.com instead.
🤖 Prompt for AI Agents
In `@skill.md` around lines 173 - 175, Replace the legacy Developer Forum link
string "- Developer Forum: https://forums.indigodomo.com/viewforum.php?f=18"
with the active "Extending Indigo" forum URL on Perceptive Automation (use
https://forums.perceptiveautomation.com/forum/15-extending-indigo/), leaving the
other two wiki links unchanged; update the line that contains "Developer Forum"
so the displayed text and URL both point to the new forum.
2 participants
Summary
Integrates official Indigo documentation into the Claude skill with a modular structure for efficient context loading.
Documentation Added:
∙ Indigo Object Model (IOM) - Complete API reference from the wiki
∙ Plugin Tutorial - Plugin preferences, custom events, and advanced patterns
∙ Code review fixes - Broken links, redundancy reduction, cross-references
Changes
New Files (13)
IOM Reference (docs/api/iom/):
∙ architecture.md - Client-server model, copy semantics, replaceOnServer
∙ command-namespaces.md - indigo.dimmer., indigo.relay., etc.
∙ devices.md - Device class hierarchy and properties
∙ triggers.md - Trigger classes and execution
∙ containers.md - indigo.Dict/List copy semantics
∙ filters.md - Iteration filters for all object types
∙ subscriptions.md - subscribeToChanges() patterns
∙ constants.md - kStateImageSel, error codes
∙ utilities.md - JSON encoding, server functions
Plugin Concepts (docs/concepts/):
∙ plugin-preferences.md - pluginPrefs, PluginConfig.xml
∙ events.md - Events.xml, custom triggers
Patterns (docs/patterns/):
∙ api-patterns.md - State updates, iteration, anti-patterns
Modified Files (6)
∙ docs/api/indigo-object-model.md - Refactored as index to modular files
∙ docs/concepts/devices.md - Reduced 11KB→7KB, removed duplication
∙ docs/README.md - Added use-case routing for file selection
∙ docs/quick-start.md - Fixed 3 broken links, updated URLs
∙ docs/concepts/plugin-lifecycle.md - Fixed broken links, standardized URLs
∙ skill.md - Added new files to safe-to-load list, query routing
Test plan
∙ Verify all internal links resolve correctly
∙ Confirm modular IOM files load independently
∙ Test skill.md routing directs to correct files
∙ Validate See Also cross-references
Summary by CodeRabbit
Release Notes
✏️ Tip: You can customize this high-level summary in your review settings.