{"owner":"zephyrproject-rtos","repo":"zephyr","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".github/copilot-instructions.md"],"skills":{".github/copilot-instructions.md":"# Zephyr Project — Copilot Instructions\n\nThese instructions are derived from `doc/contribute/` and apply to all AI-assisted\ncontributions to the Zephyr RTOS repository.\n\n## Prerequisites\n\n- All contributions target the `main` branch via GitHub Pull Requests.\n- Familiarity with CMake, Git, and GitHub is assumed.\n\n---\n\n## Licensing & File Headers\n\n- All new files must use **Apache 2.0** and include SPDX headers at the very top using\n  the file's native comment syntax:\n\n  ```\n  SPDX-FileCopyrightText: Copyright The Zephyr Project Contributors\n  SPDX-License-Identifier: Apache-2.0\n  ```\n\n  The copyright statement may refer to the individual or organization who authored the contribution\n  but \"Copyright The Zephyr Project Contributors\" is always the preferred form.\n\n- External code under a license other than Apache 2.0 requires TSC + governing board\n  approval before integration.\n\n---\n\n## Developer Certificate of Origin (DCO)\n\n- Every commit requires a `Signed-off-by` line — **only humans** may add this; AI agents\n  should not add `Signed-off-by` tags unless explicitly requested by humans.\n- The human submitter is responsible for reviewing all AI-generated code, ensuring license\n  compliance, and signing off.\n- Use a real legal name and real email address (no pseudonyms, no noreply addresses).\n\nDo not add a `Co-authored-by` tag to commit messages.\n\nWhen AI tools are used, add an attribution tag in the commit message:\n\n```\nAssisted-by: [Agent Name]:[Model Version] [Tool1] [Tool2]\n```\n\nExample:\n\n```\nAssisted-by: Claude:claude-opus-4.6 coccinelle\n```\n\nBasic tools (git, gcc, make, editors) should not be listed.\n\n---\n\n## C Code Style\n\nFollow the\n[Linux kernel coding style](https://kernel.org/doc/html/latest/process/coding-style.html)\nwith these Zephyr-specific rules:\n\n- **Tabs** are 8 characters; **line length** ≤ 100 columns.\n- Use `snake_case` for all code and variable names.\n- **Always add braces** to `if`, `else`, `do`, `while`, `for`, and `switch` bodies — even\n  single-line blocks.\n- Use `/* */` for comments; `//` is not allowed.\n- Use `/** */` for Doxygen API documentation.\n- Avoid ASCII decoration or ASCII rulers delimiters in comments\n- No binary literals (`0b...`).\n- No non-ASCII symbols in code (no emojis under any circumstances).\n- Capitalize correctly in comments: `UART` not `uart`, `CMake` not `cmake`.\n- Use spaces (not tabs) to align inline comments after declarations.\n- Style is enforced on new or modified code only — do not reformat unrelated existing code.\n\n---\n\n## Naming Conventions (C)\n\n- All public APIs must be prefixed by subsystem: `k_` (kernel), `sys_`, `net_`, `bt_`,\n  `i2c_`, etc.\n- Identifiers must be unique across all scopes; no shadowing of outer-scope identifiers.\n- `typedef` names and tag names must be globally unique identifiers.\n- Macro identifiers must be distinct from all other identifiers.\n\n---\n\n## MISRA-C Coding Guidelines\n\nAll new code must comply with the Zephyr MISRA-C subset. Key required rules:\n\n- **No dynamic memory allocation** (`malloc`, `calloc`, etc.).\n- Document all implementation-defined behavior on which program output depends.\n- All source files must compile without errors.\n- No unreachable code and no dead code.\n- No commented-out code sections.\n- Check return values of all functions that return error information.\n- Use fixed-width typedefs (`uint8_t`, `int32_t`, etc.) instead of bare `int`, `char`.\n- Prefer `inline` or `static` functions over function-like macros.\n- All header files must have include guards.\n- Octal constants are not allowed.\n- Apply a `u` or `U` suffix to all unsigned integer constants.\n- Do not use the lowercase `l` suffix in literals.\n- Identifiers in the same namespace with overlapping visibility must be typographically\n  distinct.\n\n---\n\n## Kconfig Style\n\n- **Indentation**: tabs; `help` text: one tab + two extra spaces.\n- **Line length**: ≤ 100 columns.\n- One blank line between symbol declarations.\n- Comments: `# Comment` (space after `#`).\n- One blank line before and after top-level `if` / `endif` blocks.\n\n### Symbol Naming\n\n| Subtree | Symbol format | Prompt format |\n|---|---|---|\n| Drivers | `{DRIVER_TYPE}_{DRIVER_NAME}` | `{Driver Name} {Driver Type} driver` |\n| Sensors | `SENSOR_{SENSOR_NAME}` | `{Sensor Name} sensor driver` |\n| Samples | `SAMPLE_...` | — |\n| Tests | `TEST_...` | — |\n| Boards | `BOARD_...` | — |\n| SoCs | `SOC_FAMILY_...`, `SOC_SERIES_...`, or `SOC_...` | — |\n\n- Use `menuconfig` (not `config`) for enabling symbols that have sub-options.\n- Encapsulate sub-symbols in an `if` block keyed to the enabling symbol.\n- Prefix sub-symbols with the enabling symbol's name.\n\n---\n\n## CMake Style\n\n- **Indentation**: 2 spaces (no tabs).\n- **Line length**: ≤ 100 characters.\n- Always use **lowercase** CMake commands: `add_library`, not `ADD_LIBRARY`.\n- No space between a command name and its opening parenthesis: `if(...)` not `if (...)`.\n- One source file argument per line in `target_sources()` and similar calls.\n- **UPPERCASE** for cache variables and variables shared across files\n  (`option`, `set(... CACHE ...)`).\n- **lowercase / snake_case** for local variables.\n- Always quote strings and path variables; do not quote boolean values (`ON`, `OFF`).\n- Use CMake variables (`CMAKE_SOURCE_DIR`, `CMAKE_BINARY_DIR`) — never hardcode paths.\n- Use comments to document complex logic.\n\n---\n\n## Documentation Style\n\n- Written in reStructuredText (`.rst`).\n- Public API headers must use Doxygen `/** */` block comments.\n- Follow `doc/contribute/documentation/guidelines.rst` for formatting details.\n- URL references are the only allowed exception to the 100-column line limit in docs.\n\n---\n\n## Commit Message Guidelines\n\nEvery commit message must follow this format:\n\n```\n[area]: [summary of change]\n\n[Commit message body]\n\nAssisted-by: [Agent Name]:[Model Version]\nSigned-off-by: Your Full Name <your.email@example.com>\n```\n\n### Title (`[area]: [summary]`)\n\n- **One line**, **<= 75 characters**, followed by a **completely blank line**\n- `[area]` identifies the subsystem or context being changed. Examples:\n  - `doc:` — documentation changes\n  - `drivers: foo:` — changes to the `foo` driver\n  - `Bluetooth: shell:` — Bluetooth shell changes\n  - `net: ethernet:` — Ethernet networking changes\n  - `dts:` — treewide devicetree changes\n  - `.github:` — CI/tooling configuration changes\n- If unsure, run `git log FILE` on a file you're changing and follow existing conventions\n\n### Body\n\n- **Must not be empty** — even trivial changes require a descriptive body (CI will fail otherwise)\n- Explain **what** the change does, **why** you chose this approach, **what** assumptions\n  were made, and **how** you know it works (e.g. which tests were run)\n- Lines should be ≤ **75 characters**; exceptions for long URLs or email addresses\n\n### Signed-off-by\n\n- Required on every commit for DCO compliance — use `git commit -s` to add automatically\n- Must use your **legal name** and **real email** matching the commit `Author:` field\n- **AI agents must not add `Signed-off-by`** — only the human submitter may sign off\n- Do not add a `Co-authored-by` tag to commit messages\n\n### Linking Issues\n\nTo close a GitHub issue automatically on merge, add to the commit or PR description:\n\n```\nFixes #[issue number]\n```\n\nOr cross-repo:\n\n```\nFixes zephyrproject-rtos/zephyr#[issue number]\n```\n\n---\n\n## Pull Request Guidelines\n\n- Search existing issues and PRs before starting work.\n\n### Modifying Others' Contributions\n\n- Cherry-picking from a stale PR: explain the reason in your PR and invite the original\n  author to review.\n- Force-pushing to another contributor's branch: state the reason explicitly in the PR.\n- If patches are substantially modified, either obtain the original author's acknowledgment\n  or resubmit as your own work with a reference to the original PR.\n\n---\n\n## Source Tree Quick Reference\n\n| Directory | Contents |\n|---|---|\n| `arch/` | Architecture-specific kernel and SoC code |\n| `boards/` | Board configurations |\n| `doc/` | Documentation sources |\n| `drivers/` | Device drivers |\n| `dts/` | Devicetree source files |\n| `include/` | Public API headers |\n| `kernel/` | Architecture-independent kernel code |\n| `lib/` | Library code (minimal libc, etc.) |\n| `samples/` | Sample applications |\n| `scripts/` | Build and test tooling |\n| `subsys/` | Subsystems (networking, BT, USB, FS, …) |\n| `tests/` | Tests and benchmarks |\n| `soc/` | SoC-specific code and configuration |\n"},"files":{".github/copilot-instructions.md":"# Zephyr Project — Copilot Instructions\n\nThese instructions are derived from `doc/contribute/` and apply to all AI-assisted\ncontributions to the Zephyr RTOS repository.\n\n## Prerequisites\n\n- All contributions target the `main` branch via GitHub Pull Requests.\n- Familiarity with CMake, Git, and GitHub is assumed.\n\n---\n\n## Licensing & File Headers\n\n- All new files must use **Apache 2.0** and include SPDX headers at the very top using\n  the file's native comment syntax:\n\n  ```\n  SPDX-FileCopyrightText: Copyright The Zephyr Project Contributors\n  SPDX-License-Identifier: Apache-2.0\n  ```\n\n  The copyright statement may refer to the individual or organization who authored the contribution\n  but \"Copyright The Zephyr Project Contributors\" is always the preferred form.\n\n- External code under a license other than Apache 2.0 requires TSC + governing board\n  approval before integration.\n\n---\n\n## Developer Certificate of Origin (DCO)\n\n- Every commit requires a `Signed-off-by` line — **only humans** may add this; AI agents\n  should not add `Signed-off-by` tags unless explicitly requested by humans.\n- The human submitter is responsible for reviewing all AI-generated code, ensuring license\n  compliance, and signing off.\n- Use a real legal name and real email address (no pseudonyms, no noreply addresses).\n\nDo not add a `Co-authored-by` tag to commit messages.\n\nWhen AI tools are used, add an attribution tag in the commit message:\n\n```\nAssisted-by: [Agent Name]:[Model Version] [Tool1] [Tool2]\n```\n\nExample:\n\n```\nAssisted-by: Claude:claude-opus-4.6 coccinelle\n```\n\nBasic tools (git, gcc, make, editors) should not be listed.\n\n---\n\n## C Code Style\n\nFollow the\n[Linux kernel coding style](https://kernel.org/doc/html/latest/process/coding-style.html)\nwith these Zephyr-specific rules:\n\n- **Tabs** are 8 characters; **line length** ≤ 100 columns.\n- Use `snake_case` for all code and variable names.\n- **Always add braces** to `if`, `else`, `do`, `while`, `for`, and `switch` bodies — even\n  single-line blocks.\n- Use `/* */` for comments; `//` is not allowed.\n- Use `/** */` for Doxygen API documentation.\n- Avoid ASCII decoration or ASCII rulers delimiters in comments\n- No binary literals (`0b...`).\n- No non-ASCII symbols in code (no emojis under any circumstances).\n- Capitalize correctly in comments: `UART` not `uart`, `CMake` not `cmake`.\n- Use spaces (not tabs) to align inline comments after declarations.\n- Style is enforced on new or modified code only — do not reformat unrelated existing code.\n\n---\n\n## Naming Conventions (C)\n\n- All public APIs must be prefixed by subsystem: `k_` (kernel), `sys_`, `net_`, `bt_`,\n  `i2c_`, etc.\n- Identifiers must be unique across all scopes; no shadowing of outer-scope identifiers.\n- `typedef` names and tag names must be globally unique identifiers.\n- Macro identifiers must be distinct from all other identifiers.\n\n---\n\n## MISRA-C Coding Guidelines\n\nAll new code must comply with the Zephyr MISRA-C subset. Key required rules:\n\n- **No dynamic memory allocation** (`malloc`, `calloc`, etc.).\n- Document all implementation-defined behavior on which program output depends.\n- All source files must compile without errors.\n- No unreachable code and no dead code.\n- No commented-out code sections.\n- Check return values of all functions that return error information.\n- Use fixed-width typedefs (`uint8_t`, `int32_t`, etc.) instead of bare `int`, `char`.\n- Prefer `inline` or `static` functions over function-like macros.\n- All header files must have include guards.\n- Octal constants are not allowed.\n- Apply a `u` or `U` suffix to all unsigned integer constants.\n- Do not use the lowercase `l` suffix in literals.\n- Identifiers in the same namespace with overlapping visibility must be typographically\n  distinct.\n\n---\n\n## Kconfig Style\n\n- **Indentation**: tabs; `help` text: one tab + two extra spaces.\n- **Line length**: ≤ 100 columns.\n- One blank line between symbol declarations.\n- Comments: `# Comment` (space after `#`).\n- One blank line before and after top-level `if` / `endif` blocks.\n\n### Symbol Naming\n\n| Subtree | Symbol format | Prompt format |\n|---|---|---|\n| Drivers | `{DRIVER_TYPE}_{DRIVER_NAME}` | `{Driver Name} {Driver Type} driver` |\n| Sensors | `SENSOR_{SENSOR_NAME}` | `{Sensor Name} sensor driver` |\n| Samples | `SAMPLE_...` | — |\n| Tests | `TEST_...` | — |\n| Boards | `BOARD_...` | — |\n| SoCs | `SOC_FAMILY_...`, `SOC_SERIES_...`, or `SOC_...` | — |\n\n- Use `menuconfig` (not `config`) for enabling symbols that have sub-options.\n- Encapsulate sub-symbols in an `if` block keyed to the enabling symbol.\n- Prefix sub-symbols with the enabling symbol's name.\n\n---\n\n## CMake Style\n\n- **Indentation**: 2 spaces (no tabs).\n- **Line length**: ≤ 100 characters.\n- Always use **lowercase** CMake commands: `add_library`, not `ADD_LIBRARY`.\n- No space between a command name and its opening parenthesis: `if(...)` not `if (...)`.\n- One source file argument per line in `target_sources()` and similar calls.\n- **UPPERCASE** for cache variables and variables shared across files\n  (`option`, `set(... CACHE ...)`).\n- **lowercase / snake_case** for local variables.\n- Always quote strings and path variables; do not quote boolean values (`ON`, `OFF`).\n- Use CMake variables (`CMAKE_SOURCE_DIR`, `CMAKE_BINARY_DIR`) — never hardcode paths.\n- Use comments to document complex logic.\n\n---\n\n## Documentation Style\n\n- Written in reStructuredText (`.rst`).\n- Public API headers must use Doxygen `/** */` block comments.\n- Follow `doc/contribute/documentation/guidelines.rst` for formatting details.\n- URL references are the only allowed exception to the 100-column line limit in docs.\n\n---\n\n## Commit Message Guidelines\n\nEvery commit message must follow this format:\n\n```\n[area]: [summary of change]\n\n[Commit message body]\n\nAssisted-by: [Agent Name]:[Model Version]\nSigned-off-by: Your Full Name <your.email@example.com>\n```\n\n### Title (`[area]: [summary]`)\n\n- **One line**, **<= 75 characters**, followed by a **completely blank line**\n- `[area]` identifies the subsystem or context being changed. Examples:\n  - `doc:` — documentation changes\n  - `drivers: foo:` — changes to the `foo` driver\n  - `Bluetooth: shell:` — Bluetooth shell changes\n  - `net: ethernet:` — Ethernet networking changes\n  - `dts:` — treewide devicetree changes\n  - `.github:` — CI/tooling configuration changes\n- If unsure, run `git log FILE` on a file you're changing and follow existing conventions\n\n### Body\n\n- **Must not be empty** — even trivial changes require a descriptive body (CI will fail otherwise)\n- Explain **what** the change does, **why** you chose this approach, **what** assumptions\n  were made, and **how** you know it works (e.g. which tests were run)\n- Lines should be ≤ **75 characters**; exceptions for long URLs or email addresses\n\n### Signed-off-by\n\n- Required on every commit for DCO compliance — use `git commit -s` to add automatically\n- Must use your **legal name** and **real email** matching the commit `Author:` field\n- **AI agents must not add `Signed-off-by`** — only the human submitter may sign off\n- Do not add a `Co-authored-by` tag to commit messages\n\n### Linking Issues\n\nTo close a GitHub issue automatically on merge, add to the commit or PR description:\n\n```\nFixes #[issue number]\n```\n\nOr cross-repo:\n\n```\nFixes zephyrproject-rtos/zephyr#[issue number]\n```\n\n---\n\n## Pull Request Guidelines\n\n- Search existing issues and PRs before starting work.\n\n### Modifying Others' Contributions\n\n- Cherry-picking from a stale PR: explain the reason in your PR and invite the original\n  author to review.\n- Force-pushing to another contributor's branch: state the reason explicitly in the PR.\n- If patches are substantially modified, either obtain the original author's acknowledgment\n  or resubmit as your own work with a reference to the original PR.\n\n---\n\n## Source Tree Quick Reference\n\n| Directory | Contents |\n|---|---|\n| `arch/` | Architecture-specific kernel and SoC code |\n| `boards/` | Board configurations |\n| `doc/` | Documentation sources |\n| `drivers/` | Device drivers |\n| `dts/` | Devicetree source files |\n| `include/` | Public API headers |\n| `kernel/` | Architecture-independent kernel code |\n| `lib/` | Library code (minimal libc, etc.) |\n| `samples/` | Sample applications |\n| `scripts/` | Build and test tooling |\n| `subsys/` | Subsystems (networking, BT, USB, FS, …) |\n| `tests/` | Tests and benchmarks |\n| `soc/` | SoC-specific code and configuration |\n"},"items":[{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","title":"copilot-instructions.md","content":"# Zephyr Project — Copilot Instructions\n\nThese instructions are derived from `doc/contribute/` and apply to all AI-assisted\ncontributions to the Zephyr RTOS repository.\n\n## Prerequisites\n\n- All contributions target the `main` branch via GitHub Pull Requests.\n- Familiarity with CMake, Git, and GitHub is assumed.\n\n---\n\n## Licensing & File Headers\n\n- All new files must use **Apache 2.0** and include SPDX headers at the very top using\n  the file's native comment syntax:\n\n  ```\n  SPDX-FileCopyrightText: Copyright The Zephyr Project Contributors\n  SPDX-License-Identifier: Apache-2.0\n  ```\n\n  The copyright statement may refer to the individual or organization who authored the contribution\n  but \"Copyright The Zephyr Project Contributors\" is always the preferred form.\n\n- External code under a license other than Apache 2.0 requires TSC + governing board\n  approval before integration.\n\n---\n\n## Developer Certificate of Origin (DCO)\n\n- Every commit requires a `Signed-off-by` line — **only humans** may add this; AI agents\n  should not add `Signed-off-by` tags unless explicitly requested by humans.\n- The human submitter is responsible for reviewing all AI-generated code, ensuring license\n  compliance, and signing off.\n- Use a real legal name and real email address (no pseudonyms, no noreply addresses).\n\nDo not add a `Co-authored-by` tag to commit messages.\n\nWhen AI tools are used, add an attribution tag in the commit message:\n\n```\nAssisted-by: [Agent Name]:[Model Version] [Tool1] [Tool2]\n```\n\nExample:\n\n```\nAssisted-by: Claude:claude-opus-4.6 coccinelle\n```\n\nBasic tools (git, gcc, make, editors) should not be listed.\n\n---\n\n## C Code Style\n\nFollow the\n[Linux kernel coding style](https://kernel.org/doc/html/latest/process/coding-style.html)\nwith these Zephyr-specific rules:\n\n- **Tabs** are 8 characters; **line length** ≤ 100 columns.\n- Use `snake_case` for all code and variable names.\n- **Always add braces** to `if`, `else`, `do`, `while`, `for`, and `switch` bodies — even\n  single-line blocks.\n- Use `/* */` for comments; `//` is not allowed.\n- Use `/** */` for Doxygen API documentation.\n- Avoid ASCII decoration or ASCII rulers delimiters in comments\n- No binary literals (`0b...`).\n- No non-ASCII symbols in code (no emojis under any circumstances).\n- Capitalize correctly in comments: `UART` not `uart`, `CMake` not `cmake`.\n- Use spaces (not tabs) to align inline comments after declarations.\n- Style is enforced on new or modified code only — do not reformat unrelated existing code.\n\n---\n\n## Naming Conventions (C)\n\n- All public APIs must be prefixed by subsystem: `k_` (kernel), `sys_`, `net_`, `bt_`,\n  `i2c_`, etc.\n- Identifiers must be unique across all scopes; no shadowing of outer-scope identifiers.\n- `typedef` names and tag names must be globally unique identifiers.\n- Macro identifiers must be distinct from all other identifiers.\n\n---\n\n## MISRA-C Coding Guidelines\n\nAll new code must comply with the Zephyr MISRA-C subset. Key required rules:\n\n- **No dynamic memory allocation** (`malloc`, `calloc`, etc.).\n- Document all implementation-defined behavior on which program output depends.\n- All source files must compile without errors.\n- No unreachable code and no dead code.\n- No commented-out code sections.\n- Check return values of all functions that return error information.\n- Use fixed-width typedefs (`uint8_t`, `int32_t`, etc.) instead of bare `int`, `char`.\n- Prefer `inline` or `static` functions over function-like macros.\n- All header files must have include guards.\n- Octal constants are not allowed.\n- Apply a `u` or `U` suffix to all unsigned integer constants.\n- Do not use the lowercase `l` suffix in literals.\n- Identifiers in the same namespace with overlapping visibility must be typographically\n  distinct.\n\n---\n\n## Kconfig Style\n\n- **Indentation**: tabs; `help` text: one tab + two extra spaces.\n- **Line length**: ≤ 100 columns.\n- One blank line between symbol declarations.\n- Comments: `# Comment` (space after `#`).\n- One blank line before and after top-level `if` / `endif` blocks.\n\n### Symbol Naming\n\n| Subtree | Symbol format | Prompt format |\n|---|---|---|\n| Drivers | `{DRIVER_TYPE}_{DRIVER_NAME}` | `{Driver Name} {Driver Type} driver` |\n| Sensors | `SENSOR_{SENSOR_NAME}` | `{Sensor Name} sensor driver` |\n| Samples | `SAMPLE_...` | — |\n| Tests | `TEST_...` | — |\n| Boards | `BOARD_...` | — |\n| SoCs | `SOC_FAMILY_...`, `SOC_SERIES_...`, or `SOC_...` | — |\n\n- Use `menuconfig` (not `config`) for enabling symbols that have sub-options.\n- Encapsulate sub-symbols in an `if` block keyed to the enabling symbol.\n- Prefix sub-symbols with the enabling symbol's name.\n\n---\n\n## CMake Style\n\n- **Indentation**: 2 spaces (no tabs).\n- **Line length**: ≤ 100 characters.\n- Always use **lowercase** CMake commands: `add_library`, not `ADD_LIBRARY`.\n- No space between a command name and its opening parenthesis: `if(...)` not `if (...)`.\n- One source file argument per line in `target_sources()` and similar calls.\n- **UPPERCASE** for cache variables and variables shared across files\n  (`option`, `set(... CACHE ...)`).\n- **lowercase / snake_case** for local variables.\n- Always quote strings and path variables; do not quote boolean values (`ON`, `OFF`).\n- Use CMake variables (`CMAKE_SOURCE_DIR`, `CMAKE_BINARY_DIR`) — never hardcode paths.\n- Use comments to document complex logic.\n\n---\n\n## Documentation Style\n\n- Written in reStructuredText (`.rst`).\n- Public API headers must use Doxygen `/** */` block comments.\n- Follow `doc/contribute/documentation/guidelines.rst` for formatting details.\n- URL references are the only allowed exception to the 100-column line limit in docs.\n\n---\n\n## Commit Message Guidelines\n\nEvery commit message must follow this format:\n\n```\n[area]: [summary of change]\n\n[Commit message body]\n\nAssisted-by: [Agent Name]:[Model Version]\nSigned-off-by: Your Full Name <your.email@example.com>\n```\n\n### Title (`[area]: [summary]`)\n\n- **One line**, **<= 75 characters**, followed by a **completely blank line**\n- `[area]` identifies the subsystem or context being changed. Examples:\n  - `doc:` — documentation changes\n  - `drivers: foo:` — changes to the `foo` driver\n  - `Bluetooth: shell:` — Bluetooth shell changes\n  - `net: ethernet:` — Ethernet networking changes\n  - `dts:` — treewide devicetree changes\n  - `.github:` — CI/tooling configuration changes\n- If unsure, run `git log FILE` on a file you're changing and follow existing conventions\n\n### Body\n\n- **Must not be empty** — even trivial changes require a descriptive body (CI will fail otherwise)\n- Explain **what** the change does, **why** you chose this approach, **what** assumptions\n  were made, and **how** you know it works (e.g. which tests were run)\n- Lines should be ≤ **75 characters**; exceptions for long URLs or email addresses\n\n### Signed-off-by\n\n- Required on every commit for DCO compliance — use `git commit -s` to add automatically\n- Must use your **legal name** and **real email** matching the commit `Author:` field\n- **AI agents must not add `Signed-off-by`** — only the human submitter may sign off\n- Do not add a `Co-authored-by` tag to commit messages\n\n### Linking Issues\n\nTo close a GitHub issue automatically on merge, add to the commit or PR description:\n\n```\nFixes #[issue number]\n```\n\nOr cross-repo:\n\n```\nFixes zephyrproject-rtos/zephyr#[issue number]\n```\n\n---\n\n## Pull Request Guidelines\n\n- Search existing issues and PRs before starting work.\n\n### Modifying Others' Contributions\n\n- Cherry-picking from a stale PR: explain the reason in your PR and invite the original\n  author to review.\n- Force-pushing to another contributor's branch: state the reason explicitly in the PR.\n- If patches are substantially modified, either obtain the original author's acknowledgment\n  or resubmit as your own work with a reference to the original PR.\n\n---\n\n## Source Tree Quick Reference\n\n| Directory | Contents |\n|---|---|\n| `arch/` | Architecture-specific kernel and SoC code |\n| `boards/` | Board configurations |\n| `doc/` | Documentation sources |\n| `drivers/` | Device drivers |\n| `dts/` | Devicetree source files |\n| `include/` | Public API headers |\n| `kernel/` | Architecture-independent kernel code |\n| `lib/` | Library code (minimal libc, etc.) |\n| `samples/` | Sample applications |\n| `scripts/` | Build and test tooling |\n| `subsys/` | Subsystems (networking, BT, USB, FS, …) |\n| `tests/` | Tests and benchmarks |\n| `soc/` | SoC-specific code and configuration |\n","category":".github","tokens":2110}]}