If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/project-chip/connectedhomeip shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 46+ active contributors
• Distributed ownership (top contributor 17% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live project-chip/connectedhomeip repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/project-chip/connectedhomeip.

What it runs against: a local clone of project-chip/connectedhomeip — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in project-chip/connectedhomeip | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of project-chip/connectedhomeip. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/project-chip/connectedhomeip.git
#   cd connectedhomeip
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of project-chip/connectedhomeip and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "project-chip/connectedhomeip(\\.git)?\\b" \\
  && ok "origin remote is project-chip/connectedhomeip" \\
  || miss "origin remote is not project-chip/connectedhomeip (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f ".github/workflows/build.yaml" \\
  && ok ".github/workflows/build.yaml" \\
  || miss "missing critical file: .github/workflows/build.yaml"
test -f ".github/CODEOWNERS" \\
  && ok ".github/CODEOWNERS" \\
  || miss "missing critical file: .github/CODEOWNERS"
test -f ".devcontainer/Dockerfile" \\
  && ok ".devcontainer/Dockerfile" \\
  || miss "missing critical file: .devcontainer/Dockerfile"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".clang-format" \\
  && ok ".clang-format" \\
  || miss "missing critical file: .clang-format"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/project-chip/connectedhomeip"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Matter is an open-source IoT connectivity standard implementation that enables reliable, secure, and interoperable communication between smart home devices across different manufacturers and platforms. It provides a unified protocol stack (with C++/Python/Kotlin implementations) and device certification infrastructure, eliminating the fragmentation of proprietary IoT ecosystems and allowing a smart light bulb to work with any Matter-certified hub or controller. Monorepo structure with separate implementation stacks: src/protocols/ contains core Matter protocol (TLV, CASE, PASE), src/lib/ has reusable libraries (crypto, transport, zigbee bridging), examples/ contains reference implementations per platform (esp32, darwin, linux, ameba, etc.), and scripts/tools contain ZAP (cluster definition generator) and chip-tool (testing CLI). Language bindings (Python in scripts/, Kotlin/Java for Android, Objective-C++ for iOS) wrap the C++ core.

Device manufacturers building smart home products (lighting, thermostats, locks, sensors), platform developers integrating Matter into Android/iOS/Linux ecosystems, and embedded systems engineers targeting platforms like ESP32, EFR32, NXP, or TI microcontrollers who need a standards-based alternative to Zigbee, Z-Wave, or proprietary protocols.

Highly mature and production-ready: the repository shows 42M+ lines of C++ core code, comprehensive CI/CD with platform-specific workflows (Darwin, Android, ESP32, EFR32, etc.), organized test dashboards (Allure reports for CI and nightly runs), and is backed by the Connectivity Standards Alliance. The large multi-language codebase and active GitHub Actions workflows indicate continuous active development with professional infrastructure.

Low technical risk for core adoption, but integration complexity is high: the monorepo spans 15+ programming languages and targets 10+ embedded platforms with different build systems (.github/workflows shows 15+ platform-specific examples), requiring careful platform-specific configuration. Dependency on Connectivity Standards Alliance governance means feature velocity follows standards committee timelines rather than typical open-source cadence; breaking changes require coordination across entire ecosystem.

Active platform expansion and cluster development: the .agents/skills directory indicates ongoing work on code-driven cluster migration and specification access automation. GitHub workflows show regular builds across Android, EFR32, ESP32, NXP, BouffaloLab, and ASR platforms. CI infrastructure tests both basic connectivity and higher-level cluster implementations with automated testing via chip-tool.

Clone and bootstrap with the official flow: git clone --recursive https://github.com/project-chip/connectedhomeip.git && cd connectedhomeip && ./scripts/build/gn_build.sh. For Python environment setup: python -m pip install -r requirements.txt (implied by large Python codebase). For quick testing of compiled examples: ./out/linux-x86_64-chip-tool attribute read 1 0 (chip-tool is the primary testing CLI).

Daily commands: Build the reference implementation with platform-specific GN targets: ./scripts/build/gn_build.sh --target linux-x86_64-chip-tool produces the chip-tool testing binary in ./out/linux-x86_64-chip-tool/chip-tool. Run an example endpoint: ./out/linux-x86_64-all-clusters/chip-all-clusters-app. For Android: ./scripts/build/gn_build.sh --target android-arm64-chip-tool requires Android SDK/NDK. For embedded platforms (ESP32, etc.), use platform-specific scripts in examples/[platform]/build.sh which invoke platform SDKs (IDF, SES, etc.).

• .github/workflows/build.yaml — Primary CI/CD pipeline orchestrating all build and test workflows across platforms—essential for understanding the project's validation and release process
• .github/CODEOWNERS — Defines code ownership and required reviewers for critical subsystems—required reading to know who approves changes in your domain
• .devcontainer/Dockerfile — Sets up the standardized development environment with all dependencies—use this to bootstrap your local setup and understand toolchain requirements
• README.md — Project overview, build instructions, and documentation links—entry point for understanding Matter SDK scope and architecture
• .clang-format — Enforces code style across the entire C++ Matter implementation—must comply with this before any PR submission
• .github/workflows/codeql.yml — Security analysis pipeline scanning for vulnerabilities in native code—understanding these checks prevents build failures
• .gitattributes — Git configuration for line endings and binary file handling across multi-platform Matter source—critical for avoiding whitespace merge conflicts

Add a new Matter cluster implementation

1. Define cluster XML specification and code generation templates in the data model (.agents/skills/code-driven-cluster-development/SKILL.md)
2. Run code generation to create cluster interface stubs and attribute/command handlers (.github/workflows/chef.yaml)
3. Implement cluster handlers in platform-specific layer (ESP32, NRF, Linux, Darwin, etc.) (.github/workflows/examples-esp32.yaml)
4. Add cluster tests to certification test suite (.github/workflows/cert_test_checks.yaml)
5. Update CODEOWNERS to assign cluster ownership for code review (.github/CODEOWNERS)

Add support for a new embedded platform

1. Create platform-specific GitHub Actions workflow for build compilation (.github/workflows/examples-esp32.yaml)
2. Configure platform build tools and cross-compiler in devcontainer (.devcontainer/Dockerfile)
3. Add platform-specific pre-commit checks and linting rules (.githooks/pre-commit)
4. Implement platform abstraction layer in Matter SDK core (.clang-tidy)
5. Add platform to main build matrix workflow (.github/workflows/build.yaml)

Integrate new testing or validation tool

1. Define tool dependencies and installation in development container (.devcontainer/Dockerfile)
2. Create new GitHub Actions workflow or add to existing one (.github/workflows/build.yaml)
3. Add tool-specific code quality rules (clang-tidy, clang-format) (.clang-tidy)
4. Update PR checklist to include new validation (.github/PULL_REQUEST_TEMPLATE.md)
5. Assign ownership for validation failures if tool-specific (.github/CODEOWNERS)

Update CI/CD pipeline and parallel build optimization

1. Modify workflow job structure, parallelization, and caching strategy (.github/workflows/build.yaml)
2. Configure ccache integration for C/C++ compilation speedup (.github/actions/setup-ccache/action.yml)
3. Update cache deletion and artifact retention policies (.github/workflows/artifacts.yaml)
4. Add timing notes and resource requirements in workflow comments (.github/workflows/bloat_check.yaml)

• GitHub Actions — Tight integration with repository; native support for complex multi-platform build matrices; secrets management; artifact caching and size reporting
• Docker (devcontainer) — Ensures reproducible development environment across macOS, Linux, Windows; eliminates 'works on my machine' issues; simplifies toolchain management for multiple ARM/RISC-V targets
• Clang Format + Clang Tidy — LLVM toolchain consistency across platforms; C++17/20 language support for Matter SDK; built-in static analysis catches common errors early
• CodeQL — Semantic code analysis for C/C++; detects memory safety, logic, and security vulnerabilities; GitHub-integrated dashboard for tracking findings

• Multi-platform CI/CD (Linux, macOS, ESP32, NRF, EFR32, NXP, etc.)

  • Why: Matter SDK must run on resource-constrained embedded systems and desktop controllers; each platform has unique toolchains and SDKs
  • Consequence: Complex workflow matrix exponentially increases CI time (~45–60m for full suite); higher GitHub Actions costs; stale caches across platform variants

• Strict code style enforcement (clang-format pre-commit hook)

  • Why: Large distributed team across vendors; enforces readability and reduces merge conflicts
  • Consequence: Developers must format code before push; some flexibility sacrificed; tooling must match format exactly or false rejections occur

• Distributed CODEOWNERS instead of centralized gatekeeping

  • Why: Matter clusters owned by their domain experts (Lighting, Climate, Security, etc.); faster review turnaround; clear accountability
  • Consequence: PR approval flow depends on external team availability; potential bottlenecks if CODEOWNERS are unavailable; requires strong communication discipline

• Certification testing in CI (cert_test_checks.yaml)

  • Why: Catches compliance regressions before release; Matter spec violations caught early
  • Consequence: Long test runtime (~20m+); flaky tests on shared CI runners; cert test failures can block releases; requires expertise to debug

• Real-time Matter device simulation
• Web-based IDE or Matter device emulator
• Automatic cluster migration across Matter versions
• Mobile app development (iOS/Android support is delegated to platform SDKs)
• Non-IP transport protocols (Bluetooth mesh, Thread not included; offloaded to platform stacks)

Build system requires GN (not CMake despite CMake files existing); use ./scripts/build/gn_build.sh not cmake directly. Platform-specific SDKs required: ESP-IDF for ESP32, Nordic SDK for nRF52, TI SDK for CC13xx, each with version constraints. The ZAP generator requires XML schemas in src/app/zap-templates/; regenerating clusters without ZAP will break codegen. Commissionable Matter devices require BLE or IP multicast (mDNS); some CI environments don't allow multicast, breaking device discovery tests. Thread/IPv6 support varies by platform SDK (requires OpenThread integration); Linux examples may default to Thread-less Wi-Fi mode.

• TLV (Tag-Length-Value) Encoding — Matter uses TLV for all payload serialization in src/protocols/; understanding TLV structure is mandatory for protocol debugging and cluster attribute parsing
• CASE (Certificate-Authenticated Session Establishment) — Matter's core session security handshake in src/protocols/; all device-to-device communication requires CASE after initial Bluetooth commissionable pairing
• Cluster-Attribute-Command Model — Matter device data model organizes functionality as clusters (Lighting, OnOff) containing attributes and commands; essential for understanding how src/app/clusters/ works
• Fabric Topology & Commissioner Role — Devices form a fabric (network) controlled by a commissioner (controller); core to Server.h lifecycle and commissionable device onboarding
• MRP (Matter Reliable Protocol) — Retransmission and acknowledgment layer above UDP/TCP in src/protocols/CHIPMRPConfig.h; ensures packet delivery on unreliable networks
• Thread Mesh Networking — Optional self-healing mesh layer (via openthread integration) for range extension; critical for understanding examples/esp32/ and multi-hop topologies
• GN Build System — Matter uses Google's GN (Not CMake) as primary build tool; understanding gn_build.sh and .gn files is essential for platform porting and CI configuration

• project-chip/zap — Separate repo for ZAP cluster definition format and codegen engine that Matter uses to generate cluster boilerplate
• openthread/openthread — Thread protocol implementation that Matter uses for mesh networking on compatible platforms
• signalwire/freeswitch — Not directly related; ignore. Instead: NXP has nxp-qoriq/ls2088a-rdb for reference platform targets Matter sometimes runs on
• project-chip/certification-tool — Companion tool for Matter device certification testing; validates compliance of implementations against Matter spec
• espressif/esp-idf — ESP32 SDK that examples/esp32/ depends on; required for embedded platform builds and includes essential crypto/BLE drivers

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive testing for AI agent skills framework

The repo contains a new .agents/skills directory with multiple skill modules (chip-tool-testing, code-driven-cluster-development, python-test-reviewer, etc.) but appears to lack unit tests. Each SKILL.md file documents capabilities, but there are no corresponding test files (e.g., .agents/skills/*/tests/ or *_test.py). Adding test coverage for the agent skills would ensure reliability as these become core tooling for the project.

• [ ] Create test directory structure: .agents/skills/*/tests/ for each skill
• [ ] Add unit tests for chip-tool-testing skill validation and execution logic
• [ ] Add integration tests for python-test-reviewer skill against sample test files
• [ ] Add test runner configuration to existing CI workflow (reference .github/workflows/)
• [ ] Document test execution in .agents/skills.md

Create GitHub Action for automated .clang-format and .clang-tidy enforcement

The repo has .clang-format and .clang-tidy configuration files in the root, indicating code style and static analysis standards, but there's no dedicated GitHub Action in .github/actions/ to enforce these checks on PRs. Adding a reusable action would catch style violations early and reduce review friction, similar to existing actions like setup-ccache and perform-codeql-analysis.

• [ ] Create .github/actions/clang-format-check/action.yaml to validate formatting
• [ ] Create .github/actions/clang-tidy-check/action.yaml to run static analysis
• [ ] Add both actions to the main build workflow (.github/workflows/build.yaml)
• [ ] Document usage in action files with example inputs for file patterns
• [ ] Test against a sample PR to ensure it catches real violations

Add CI workflow for validating ISSUE_TEMPLATE and PR template consistency

The repo has extensive issue templates (.github/ISSUE_TEMPLATE/ with 13+ files covering bugs, features, cert blockers, etc.) and a pull request template, but no validation that these files follow consistent structure or that required labels are enforced. A workflow could validate YAML syntax, enforce required fields, and ensure frontmatter consistency, preventing broken templates from being merged.

• [ ] Create .github/workflows/validate-templates.yaml workflow
• [ ] Add schema validation for all YAML files in .github/ISSUE_TEMPLATE/
• [ ] Validate .github/PULL_REQUEST_TEMPLATE.md for required sections (e.g., Description, Testing, Impact)
• [ ] Add check to ensure .github/.wordlist.txt is updated with new terms in templates
• [ ] Run workflow on PRs that modify files in .github/ directory

• Add cluster documentation: most src/app/clusters/ implementations lack doxygen comments explaining attribute/command semantics. Pick a cluster (OnOff, Identify, Descriptor) and document its Matter spec compliance in code comments.
• Expand Python test coverage: src/python_testing/ has many clusters untested in automated test harness (see gaps in test_*.py files). Write end-to-end tests for a cluster endpoint using chip-tool commands to validate attribute reads/writes.
• Platform porting: ESP-IDF example in examples/esp32/ lacks full Thread support documentation. Document which IDF version, OpenThread config, and memory constraints are required for Thread-enabled builds (check build warnings in CI logs).

The Matter SDK repository demonstrates a structured security posture with vulnerability reporting guidance and organized CI/CD infrastructure. However, several areas require attention: (1) The vulnerability reporting process relies entirely on an external portal without local contact fallbacks, (2) no security.txt file following RFC 9116 standards is present, (3) pre-commit hooks and DevContainer configurations require additional security hardening and verification, and (4) GitHub Actions workflows need audit for secrets handling and dependency pinning. The project appears mature with established security practices (SECURITY.md exists, CODEOWNERS in place), but would benefit from enhanced transparency in security contacts, automated supply chain security measures, and regular vulnerability scanning of development infrastructure. No critical vulnerabilities were identified in the available structure, though full assessment requires review of actual source code and configuration files.

• Medium · Vulnerability Reporting Redirects to External CSA Portal — SECURITY.md. The SECURITY.md file redirects all vulnerability reports to an external CSA-IOT portal (https://csa-iot.org/vulnerability-reporting/). While this is acceptable for coordinated disclosure, there is no fallback contact method (email, PGP key) directly in the repository for security researchers who may have issues accessing the external portal or need alternative reporting channels. Fix: Add a direct security contact email address and PGP key fingerprint in SECURITY.md as a primary reporting method, with the CSA portal as a secondary option. Follow best practices from CERT/CC and maintain a security@project-chip.org contact.
• Low · No Security.txt File — Repository root / .well-known/. The repository does not contain a .well-known/security.txt file (as per RFC 9116), which would provide standardized security contact information and vulnerability disclosure policies in a machine-readable format. Fix: Create a .well-known/security.txt file following RFC 9116 with contact information, preferred disclosure timeline, and security policy details.
• Low · Git Pre-commit Hook Present Without Verification Details — .githooks/pre-commit. A .githooks/pre-commit file exists but without visible verification of its contents in the provided analysis. Pre-commit hooks can be modified to introduce malicious behavior during development. Fix: Document the purpose of all pre-commit hooks, ensure they are cryptographically signed, and provide clear instructions for developers on verifying hook integrity. Consider using a framework like husky with proper verification.
• Low · Comprehensive CI/CD Configuration Requires Review — .github/workflows/. The presence of multiple GitHub Actions workflows (.github/workflows/) indicates extensive CI/CD automation. Without reviewing the actual workflow files, there is a potential risk of insecure secrets handling, overly permissive permissions, or supply chain vulnerabilities through third-party actions. Fix: Audit all GitHub Actions workflows for: 1) Minimal permission scope (principle of least privilege), 2) Pinned versions for third-party actions (not using 'main' or floating tags), 3) Secure secret handling (never logging or exporting secrets), 4) OIDC token usage instead of personal access tokens where possible.
• Low · DevContainer Configuration Requires Security Review — .devcontainer/Dockerfile. A DevContainer Dockerfile exists (.devcontainer/Dockerfile) which may contain base image vulnerabilities or insecure configurations if not regularly updated and scanned. Fix: Implement automated vulnerability scanning for the DevContainer image, use specific digest-pinned base image versions, and regularly rebuild with updated dependencies. Consider using a minimal base image (alpine) where appropriate.
• Low · No CODEOWNERS Visibility Provided — .github/CODEOWNERS. While CODEOWNERS file exists (.github/CODEOWNERS), its contents were not provided. Without verification, there's a risk that security-critical components may not have appropriate ownership or review requirements. Fix: Ensure CODEOWNERS includes security-sensitive paths (crypto, authentication, TLS, network code) with mandatory multi-reviewer requirements. Document ownership structure in CONTRIBUTING.md.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.