Skip to main content

sdk-commit

Commit-message conventions for dd-sdk-android. Use when drafting or reviewing commit messages and PR titles, making a requested commit, or generating messages for other skills.

Informations de source

Dépôt
DataDog/dd-sdk-android
Dernière activité de la source
20 octobre 2026 à 14:30
Langue détectée de SKILL.md
anglais
Étoiles
227
Forks
87

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
sdk-commit
description
Commit-message conventions for dd-sdk-android. Use when drafting or reviewing commit messages and PR titles, making a requested commit, or generating messages for other skills.
when_to_use
Writing commit subjects and bodies, formatting a requested Git commit, or preparing commit messages and PR titles.
# sdk-commit — Commit Message Format ## Structure ``` <header> <blank line> <body> ``` ## Rules ### 1. Header (first line) - Write a short, imperative summary in English. - Follow the repository format: `<JIRA-KEY>-<number>: <short description>`. - Extract the ticket from the current branch, including branches following `<username>/<ticket>/<short-description>`; normalize the ticket to uppercase. - Example branch: `jdoe/rum-1234/add-logging` - Example header: `RUM-1234: Add structured logging to ingest pipeline` - Keep the header at most 72 characters. Put longer explanations in the body. - If the ticket cannot be determined from the branch or session context, ask the user before committing. Never invent a ticket or omit it. ### 2. Body (second line onward) - Leave one blank line between the header and the body. - Use the body for a short description of what was changed. - Any longer explanation MUST go in the body, never in the header. - If another skill produces a commit message, place its output in the body — always below the header line. ### 3. Attribution - NEVER add `Co-authored-by: Claude` or any similar co-authorship/attribution trailer. ### 4. File endings Every text file touched by a commit must end with exactly one newline character, with no blank lines after the last line of content. Before committing: - For `.kt`/`.kts` files, run `./gradlew ktlintFormatAll` instead of checking them manually. - Check other text files manually: - If a file has no trailing newline — add one. - If a file ends with blank lines — remove them, leaving a single trailing newline. - Never touch binary files (images, archives, keystores, etc.). ### 5. Commit body vs. PR description — keep them separate The commit body and the GitHub PR description serve different audiences and must NOT be conflated. - **Commit body** (what goes in git history): a brief 1–3 line description of *what* changed and *why*, written for a future reader of `git log`. Keep it technical and concise — it is not a PR description. - **PR description** (what goes on GitHub): a separate artifact. Do NOT embed PR descriptions in commit bodies. **When to add a body to the commit:** Add a body when the change is non-trivial and a one-line header does not fully capture the intent. A body is NOT needed for tiny, obviously self-explanatory changes. If the branch name encodes a ticket (`RUM-xxxx`), add `Ref: RUM-xxxx` on its own line in the body so GitHub/Jira auto-links it. The header prefix alone is not enough for some integrations. Commit bodies are always in English, regardless of session language.
Voir sur GitHub