Matter SDK Incremental Documentation Discovery Skill
Operational Philosophy
The Matter SDK is an extensive, multi-layered repository. AI assistants and
contributors must avoid making implicit assumptions or guessing architectural
patterns. Instead, adopt an Incremental Documentation Discovery approach for
every task.
Discovery Workflow
Level 1: Monorepo Root Documentation
When investigating high-level SDK workflows, core specification rules, or
repository-wide testing schemas, always start by consulting the top-level
documentation sheets located in the monorepo root:
docs/: Umbrella directory housing authoritative architectural overviews,
API preferences, and Interaction Model specification guides.
ARCHITECTURE.md: High-level structural overview of current monorepo
operational layers.
Level 2: Example-Specific Reference Guides
Whenever a task directs you to analyze, debug, extend, or operate on a concrete
example application (e.g., examples/all-devices-app, examples/chip-tool,
examples/lighting-app), do not rely solely on generic root guides.
Individual example applications maintain their own customized landing
documentation detailing custom CLI parameters, dynamic runtime composition
models, and operational test harnesses.
Before generating code, adding classes, or running test suites in an example
application, you MUST consult that application's landing README.md or its
dedicated docs/ subdirectory.
Prime Blueprint Example: all-devices-app
To demonstrate this incremental discovery protocol in practice, when working
with examples/all-devices-app/, agents must proactively read its dedicated
reference suite:
examples/all-devices-app/docs/architecture.md: Demonstrates the
Code-Driven Data Model structure, explicit C++ DeviceInterface lifecycle
registration (Register/Unregister), and explicit node teardown rules.
examples/all-devices-app/docs/starting_up.md: Outlines dynamic
Interaction Model startup via CLI (--device), runtime node commissioning
arguments, and network setup variables.
examples/all-devices-app/docs/adding_new_device.md: End-to-end tutorial
on implementing a new simulated Matter device, deriving from
SingleEndpointDevice, constructor dependency injection, DeviceFactory
registration, and updating targets.py golden snapshots.
examples/all-devices-app/docs/testing.md: Factual verification
methodologies demonstrating interactive commissioning via chip-tool,
automated Python CI harnesses (local.py), and standalone test runners
(run_python_test.py).
examples/all-devices-app/docs/custom_product_baseline.md: Transitioning
from the dynamic runtime simulator to a fixed, static production firmware
blueprint, optimizing RAM/Flash usage, and direct C++ member object
instantiation.
Strict Agent Invariants
- Never Alter Code Blindly: Always verify example-specific documentation
to match prevailing patterns before writing code.
- Canonical Output Paths: When running compilation blocks or executing
binaries discovered in documentation, ensure all commands reference
canonical
./out/ output directories.
1---2name: documentation-discovery3description: Essential guidelines instructing AI agents on how to incrementally discover, read, and consult top-level monorepo documentation and example-specific reference guides before altering code or executing test harnesses.4---56# Matter SDK Incremental Documentation Discovery Skill78## Operational Philosophy910The Matter SDK is an extensive, multi-layered repository. AI assistants and11contributors must avoid making implicit assumptions or guessing architectural12patterns. Instead, adopt an **Incremental Documentation Discovery** approach for13every task.1415## Discovery Workflow1617### Level 1: Monorepo Root Documentation1819When investigating high-level SDK workflows, core specification rules, or20repository-wide testing schemas, always start by consulting the top-level21documentation sheets located in the monorepo root:2223- `docs/`: Umbrella directory housing authoritative architectural overviews,24 API preferences, and Interaction Model specification guides.25- `ARCHITECTURE.md`: High-level structural overview of current monorepo26 operational layers.2728### Level 2: Example-Specific Reference Guides2930Whenever a task directs you to analyze, debug, extend, or operate on a concrete31example application (e.g., `examples/all-devices-app`, `examples/chip-tool`,32`examples/lighting-app`), do **not** rely solely on generic root guides.33Individual example applications maintain their own customized landing34documentation detailing custom CLI parameters, dynamic runtime composition35models, and operational test harnesses.3637Before generating code, adding classes, or running test suites in an example38application, you **MUST** consult that application's landing `README.md` or its39dedicated `docs/` subdirectory.4041## Prime Blueprint Example: `all-devices-app`4243To demonstrate this incremental discovery protocol in practice, when working44with `examples/all-devices-app/`, agents must proactively read its dedicated45reference suite:46471. **`examples/all-devices-app/docs/architecture.md`**: Demonstrates the48 Code-Driven Data Model structure, explicit C++ `DeviceInterface` lifecycle49 registration (`Register`/`Unregister`), and explicit node teardown rules.502. **`examples/all-devices-app/docs/starting_up.md`**: Outlines dynamic51 Interaction Model startup via CLI (`--device`), runtime node commissioning52 arguments, and network setup variables.533. **`examples/all-devices-app/docs/adding_new_device.md`**: End-to-end tutorial54 on implementing a new simulated Matter device, deriving from55 `SingleEndpointDevice`, constructor dependency injection, `DeviceFactory`56 registration, and updating `targets.py` golden snapshots.574. **`examples/all-devices-app/docs/testing.md`**: Factual verification58 methodologies demonstrating interactive commissioning via `chip-tool`,59 automated Python CI harnesses (`local.py`), and standalone test runners60 (`run_python_test.py`).615. **`examples/all-devices-app/docs/custom_product_baseline.md`**: Transitioning62 from the dynamic runtime simulator to a fixed, static production firmware63 blueprint, optimizing RAM/Flash usage, and direct C++ member object64 instantiation.6566## Strict Agent Invariants6768- **Never Alter Code Blindly**: Always verify example-specific documentation69 to match prevailing patterns before writing code.70- **Canonical Output Paths**: When running compilation blocks or executing71 binaries discovered in documentation, ensure all commands reference72 canonical `./out/` output directories.