# Rsyslog Commit > Rsyslog Commit is an Agent Skill for devops & security published in the rsyslog/rsyslog repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task. Ensures compliance with rsyslog's strict commit message and branching policies. - Skill name: `rsyslog_commit` - Category: [DevOps & Security](https://www.openparable.com/skill/devops-security/1) - Source: https://github.com/rsyslog/rsyslog/blob/HEAD/.agent/skills/rsyslog_commit/SKILL.md - Repository: rsyslog/rsyslog (2,318 GitHub stars when collected) ## SKILL.md # 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 `. Use `devtools/format-python.sh --fix ` 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. - **Local Cubic**: Run local Cubic review for code changes when `cubic` is installed and reachable. Skip Cubic for documentation-only changes. For tests, workflows, build tooling, and mixed changes, use Cubic when the change is non-trivial, behavior-affecting, security-sensitive, or large. Hosted Cubic/Gemini PR comments are additional review feedback, not a substitute for local Cubic where local Cubic applies. - **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**: `: ` (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: ` ### 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-` or `-i-`. - **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. --- Source: https://www.openparable.com/skill/devops-security/rsyslog-commit (OpenParable). Cite the canonical URL above.