with one click
github-pr-description-writer
Guidelines for generating clear, concise, and objective GitHub Pull Request descriptions.
Menu
Guidelines for generating clear, concise, and objective GitHub Pull Request descriptions.
| name | github-pr-description-writer |
| description | Guidelines for generating clear, concise, and objective GitHub Pull Request descriptions. |
This skill provides guidelines for creating clear, concise, and objective pull request descriptions for the ConnectedHomeIP repository. The goal is to make PRs easy for human maintainers to understand and review.
These rules apply globally to all sections of the PR description.
Caveats or #### Related issues)
has no content, omit the heading and content entirely to reduce noise.
Exception: The #### Testing section must always be present; you may use
N/A there for trivial changes if accompanied by a brief justification.The PR description must follow a structured format based on the repository's template, focusing on: Summary, Related Issues, and Testing.
#### Summary)The summary should explain the "what", "why", and "how" of the changes. It must
use the following sub-headings (where ##### Impact is optional):
##### Impact section should be omitted to reduce noise.##### Problem section.#### Related issues)Fixes #12345) if the PR should close the issue
upon merging.#### Testing)Every PR must document how the changes were tested.
Added unit tests in src/app/tests/...).Verified with TC_S_2_3.py).#### Testing section. You may use N/A with a brief justification.Here is an example of a good PR description:
#### Summary
Fixes a crash in the DNS-SD client when processing malformed SRV responses.
##### Problem
- The DNS-SD client does not validate the target host name length in incoming
SRV records before copying it to a fixed-size buffer.
##### Impact
- A malformed SRV record with a target host name longer than 63 characters
causes a buffer overflow, leading to a crash.
##### Solution
- Added validation to ensure the host name length does not exceed
`kMaxHostNameLength` before copying.
- Malformed records are now safely discarded and a warning is logged.
##### Caveats
- This change discards malformed records and logs a warning.
#### Related issues
Fixes #72327
#### Testing
- Added unit test `TestDnssdClient_MalformedSrvRecord` in
`src/lib/dnssd/tests/TestDnssdImpl.cpp` to verify that malformed records are
discarded and do not cause a crash.
Here is an example using a structured breakdown with bold highlights for the problem, and a high-level solution summary:
#### Summary
Implemented `WaitForAttributeValue` command in YAML runner to allow tests to
wait for an attribute to reach a specific value, improving test robustness and
reducing execution time. Supported in all Python-based runners.
##### Problem
- YAML tests lacked polling, requiring a fragile **"trigger transition → sleep
→ verify"** pattern.
- This fixed-delay pattern is:
- **Racy**: Leads to flakiness in slow environments (like CI) if
transitions take longer than the sleep duration.
- **Inefficient**: Forces fast runs to wait for the maximum padded
duration even if the transition finishes early.
##### Solution
- Added support for the `WaitForAttributeValue` command to wait for an
attribute to reach a target value within a timeout, avoiding fixed sleeps.
- Added the underlying infrastructure to support this across all Python-based
runners (`chip-tool`, `darwin-framework-tool`, and the REPL runner).
- Made the extra timeout buffer (slop) configurable (defaults to 250ms
locally, but configured to 2000ms in GitHub Actions workflows to prevent
flakiness on slow CI runners).
- Included a polling history (last 10 attempts with values/errors) in the
timeout exception message to improve debuggability when a wait fails.
##### Caveats
- The command uses active polling (100ms interval) to check the attribute
value.
#### Testing
- Added integration test
`src/app/tests/suites/Test_WaitForAttributeValue.yaml` to verify the
command's timeout behavior.
- Registered the new test in `src/app/tests/suites/ciTests.json` to enable it
in CI.
- Migrated Step 5b of `src/app/tests/suites/certification/Test_TC_S_2_3.yaml`
to use `WaitForAttributeValue` and verified it passes successfully.
Guidelines and instructions for building prerequisite example applications and running python-based integration and certification tests located in `src/python_testing/`. Use this skill to run important regression tests during developement or, when building new example apps, or when there is a need to execute python test scripts or "certification test scripts" or mentions of run_python_test.py and local.py.
Guidelines and common jq/grep/awk queries for investigating ZAP (.zap) and Matter (.matter) files to understand endpoints, clusters, attributes, and commands.
Guidelines for implementing or migrating Matter server clusters to the code-driven pattern using Test-Driven Development (TDD).
Guidelines for building Matter examples and chip-tool, and testing examples using chip-tool.
Guidelines for implementing or migrating Matter server clusters (code that resides in `src/app/clusters`) using the DefaultServerCluster base class (code-driven data model approach), as opposed to the legacy ZAP/Ember codegen approach.
Step-by-step procedure for migrating a legacy Ember-based Matter server cluster in src/app/clusters/ to the code-driven pattern. Use this skill when converting an existing cluster. All rules from code-driven-cluster-development still apply; this skill adds the migration-specific workflow on top.