---
name: rsyslog_commit
description: Ensures compliance with rsyslog's strict commit message and branching policies.
---

# rsyslog_commit

This skill standardizes the final step of the development workflow: committing and contributing.

## Quick Start

1.  **Format First**: For C/H changes, agents MUST run
    `devtools/format-code.sh --git-changed` to rewrite formatting when needed.
2.  **Commit Message**: Follow the 62/72 rule and the mandatory "Why" structure.
3.  **Attribution**: Include the AI-Agent footer.

## Detailed Instructions

### 1. Pre-Commit Checklist
- **Code Style**: Agents MUST run `devtools/format-code.sh --git-changed` if
  any `.c` or `.h` files were modified and formatting may need to be applied.
  This is mandatory for C source changes before commit. For a read-only local
  validation gate, agents MUST run
  `devtools/format-code.sh --git-changed --check --check-if-available`; this
  skips with a warning if the exact configured `clang-format` executable is not
  installed. CI will not pass with improperly formatted C/H code; a missing
  local formatter is only a local tooling limitation, not permission to skip
  formatting.
- **Python Style**: If Python files changed and `pycodestyle` is installed, run `devtools/format-python.sh <changed-python-files>`. Use `devtools/format-python.sh --fix <changed-python-files>` only when you intentionally want `autopep8` rewrites. If the tools are missing, suggest installing them (`sudo apt-get install -y pycodestyle python3-autopep8` on Debian/Ubuntu) but do not block unrelated build or test validation. The shared 120-column style configuration lives in `setup.cfg`; review `autopep8` output carefully for legacy Python-2-style scripts.
- **Local Preflight Linters**: Before heavier validation or opening/updating a
  PR, run useful diff-scoped linters when installed: `shellcheck` for changed
  `*.sh`, `checkbashisms -p` for changed scripts that claim POSIX `sh`
  portability, `devtools/format-python.sh --check-if-available` for changed
  Python, `actionlint` and pinned `zizmor` for changed workflows, `hadolint`
  for changed Dockerfiles, `trivy config` for changed infrastructure/config
  files, and `jscpd` for larger changed source/test sets. Guard optional
  commands with `command -v`; if a tool is missing, suggest installing it but
  do not block unrelated build or test validation. On Debian/Ubuntu,
  `checkbashisms` is provided by `devscripts`. Do not run `cppcheck` routinely
  unless requested; it is too noisy for the rsyslog tree.
- **Validation**: Ensure the relevant build/test path passed. For PR-ready
  implementation work, prefer the local container-testing skill's change-gated
  validation over unconditional full-suite local runs.
  - **Late Prompt Audits**: For non-trivial C/H, concurrency, or test/build
    plumbing changes, follow the local container-testing skill's late
    prompt-audit stage. Read and apply the project's canned prompts directly;
    do not launch another AI CLI from repository scripts.
  - **Optional AI Review**: Local Cubic review may provide useful additional
    feedback when `cubic` is installed and reachable, especially for
    non-trivial code, test, workflow, build, or tooling changes. It is not a
    required validation gate. Hosted Cubic/Gemini PR comments likewise provide
    supplemental review feedback and must be considered when present.
  - **Container Gate**: For implementation changes, run the
    `rsyslog_local_container_testing` skill's PR-ready change-gated local
    container sequence when container tooling is available. Focused
    `run-ci.sh TEST=...` commands are targeted container tests, not PR-ready
    local container validation unless that skill explicitly permits the reduced
    lane.
  - **Mock Smoke Check**: If you added or renamed test files, run `make distcheck TEST_RUN_TYPE=MOCK-OK -j$(nproc)` as a final distribution check.
  - **Note**: If you already successfully built and tested your changes immediately *before* formatting, you do NOT need to re-run the build/test cycle. Formatting is a normalization step and does not affect functionality. A read-only formatting check is already part of the deterministic local validation helper for changed C/H files.

### 2. Commit Message Structure
Rsyslog requires rich, structured commit messages (plain ASCII).
- **Title**: `<component>: <action>` (Max 62 characters).
- **Body**: Max 72 characters per line.
- **GitHub Issues**: Use **full URLs** (e.g., `https://github.com/rsyslog/rsyslog/issues/883`) instead of shorthand `#883`.
- **Mandatory Sections**:
  - **Why**: Brief non-technical rationale.
  - **Impact**: One line if behavior/tests changed.
  - **Before/After**: One-line summary.
  - **Technical Overview**: 4–12 lines describing the change conceptually.
- **AI Footer**: `With the help of AI-Agents: <agent-name>`

### 3. Using the Assistant
- **Offline/Agents**: Use the base prompt at `ai/rsyslog_commit_assistant/base_prompt.txt`.
- **Web**: [rsyslog.com/tool_rsyslog-commit-assistant](https://www.rsyslog.com/tool_rsyslog-commit-assistant)

### 4. Branching & PRs
- **Base Branch**: Always target `main`.
- **Naming**: `i-<issue-number>` or `<agent-name>-i-<issue-number>`.
- **Target**: PRs must target `rsyslog/rsyslog` directly.

## Related Skills
- `rsyslog_build`: To verify the code before committing.
- `rsyslog_test`: To provide validation metrics for the commit message.
